IG-88

J5040 would be kind of ideal for dva1622 as this system uses ai ss with the intel internal gpu (original unit from synology is also gemin lake refresh but J4125) the dva3221 comes in original with a cpu that does not have a internal gpu and a nvidia gpu, so a internal gpu would be of no use und only a nvidia gpu would work for the ai stuff in ss afair dva3221 can serve 16 cams and dva1622 8 cams you need to look closer, the tinycore rp loader does support multiple units (and there is a newer developer version too that was announced about 4 weeks ago her in the developer area you can test https://xpenology.com/forum/topic/61634-dsm-7x-loaders-and-platforms/ https://xpenology.com/forum/topic/62221-tutorial-installmigrate-to-dsm-7x-with-tinycore-redpill-tcrp-loader/ https://xpenology.com/forum/topic/62871-tinycore-redpill-loader-tcrp-development-release-09/ https://github.com/pocopico/tinycore-redpill/tree/develop there is also a new loader (should also support dva1622) https://xpenology.com/forum/topic/63486-automated-redpill-loader

there are some newer developments around these problems like the mode used in newer system 920+ called device tree, for handling disks and ports i guess this will find its way to the actual loader shortly beside this there is e new loader https://xpenology.com/forum/topic/63486-automated-redpill-loader not all the drivers yet as with tc loader but i guess that can be changed quickly as the structure of the drivers is less complicated to handle manually but using a hypervisor might not be that bad is it offers more options in the long run (but it also more complex to handle, i still prefer baremetal and a single purpose system but when having to juggle more vm's then just DSM and docker then i would switch to a hypervisor too)

and there was a list of selections, you might have overlooked the "DS3622xs+" its often used without the "+" or "p" and that can be confusing, there is no "DS3622xs" from synology its always the "DS3622xs+" even if its writen DS3622xsp or DS3622xs, the "+" might be avoided here an there as its not a letter or number https://www.asrock.com/mb/Intel/J5005-ITX/index.asp#Specification - 2 x SATA3 6.0 Gb/s Connectors, support NCQ, AHCI and Hot Plug - 2 x SATA3 6.0 Gb/s Connectors by ASMedia ASM1061, support NCQ, AHCI and Hot Plug so its two sata controllers, 920+ uses a different way then the older units and the new way needs to be matched to the hardware (device tree) my guess its that you only see the 1st controller and the other two drives are on the 2nd there is a way to redo the default tree file to match the hardware, in the later iterations of the tc rp loader it should be done when building the loader in auto mode but i cant say much about that from memory as i have not used it yet, look in the forum for "device tree dts", the automation might be newer stuff that is not yet in the normal tc rp loader (yet)

the picture shows a pcie 1x card (now?), if thats real then only one pcie lane out of two would be used and thats not desirable the one i have looks the same but has a pcie 4x connector (as there is no 2x defined in the standard - at least not as a slot, but i've also seen cards with a 2x connector cards) the pcb has no vendor but a number marking PCE6SAT-A01, VER006S mine is like this https://www.amazon.de/-/en/BEYIMEI-Support-Devices-Distribution-ASM1166-PCI-4X-6SATA/dp/B08DFK4LZ7/ and i did only test it briefly, its laying around for over a year as i was using jmb585/582 (and a older pcie 1x marvell) in my normal systems so i cant say much about it other then it worked for testing with a few different disks but i guess by now there should be more reports about asm1166 based cards, so you should use a search engine to get some more information

i exchanged the sata cables to get rid of this use dmesg to check the log if there is anything unusual or related in the time to the failure of the raid

i usually suggest pcie 3.0 capable ahci controller like jmb585 or asm1166 because of the double bandwidth of pcie 3.0 and the limit of all there (cheaper) controllers to two pcie lanes i use jmb585 (with dsm 6.2.3) without any problems but as can be seen here (link below), there might be some trouble with jmb585 as synology has some special fixes build into dsm 7.x for that one (needs further inspection, couls still be some special problem of the single system) https://xpenology.com/forum/topic/63475-dsm-7-proxmox-hdd-hibernation-issue/#comment-288716

where does that come from? the files used for update are named geminilake (as th cpu used in th dva1622) https://global.download.synology.com/download/DSM/criticalupdate/update_pack/42661-2/synology_geminilake_dva1622.pat

because all systems use dts config (device tree) now?

you could take (copy) some stuff from here and add the file used for the config manifest.yml https://github.com/pocopico/rp-ext the extensionn are now addons and are just copied into directory (not all compiled into some file you cant change as in the original) 3rd partition, addons, looks kind of self explaining makes it easy to extend, osfmount or copy directly to usb (after creating the right files)

along with the new platforms: epyc7002 (no hardware announced so far?) synology seems to introduce kernel 5.10 beside the epyc there is als a arm based unit with kernel 5.10 so maybe we will see more of that when DSM 7.2 comes along that would be good news for i915 driver and that way the intel 2.5G nic (igc.ko) should be usable for DSM systems https://archive.synology.com/download/ToolChain/toolchain/7.1-42661

thats not going to work with 3622, bromolow is 3615 the system choosen to build and the serial to generate need to match (the serial has a fixed part that is for the model and a variable part that is randomized by the generator) this has some basic information about platform and model https://xpenology.com/forum/topic/61634-dsm-7x-loaders-and-platforms/ as you got some experience now, maybe try the more recent howto from here in the forum https://xpenology.com/forum/topic/62221-tutorial-installmigrate-to-dsm-7x-with-tinycore-redpill-tcrp-loader/

the fact it boots and you find it in network is enough, the problem with 918+/920+/dva3221 is that the kernel does not start on older cpu's so the loader never comes up when booting we will see what other find out about cpu gen and ai surveillance

i would suggest to check syno's own knowledge base for that if dsm let's you activate a ssd read cache with just one disk then its expected behavior to not loose any data if the cache ssd fails, anything else would be ridiculous read cache would even need to do more then that because its also important to make sure that the cache content is recent, if not you might read old data from cache, change it and overwrite newer data on the volume - and imho thats the point where your risk is with read cache

on a 3rd gen intel cpu hevc/h.265 is not expected to work (see table her https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video) i guess it should be deactivated in jellyfin (same for vp8/9, av1)

looking through some kernel setting i found something interesting in 7.1 kernel config file # CONFIG_SYNO_JMICRON_585_GPIO_LED_CTRL is not set # CONFIG_SYNO_JMICRON_585_FIX is not set # CONFIG_SYNO_JMICRON_585_DUBIOUS_IFS_FIX is not set beside some extra LED control there seems to some extra code for jmb585, can be syno specific or backported code from newer kernel that would need some more investigation to see if its code we have in the source of 7.0 or if it is something we have no code fore (like in source of 7.1) and was this code is about the jmb585 part seems to be active in gemini lake kernel config but not in apollo lake (the two fix entry's) so i'd suggest trying/testing 920+ instead of 918+ for the mentioned problem above there is also something about asm1166/1162 but no special fix for problems # CONFIG_SYNO_ASM_116X_GPIO_LED_CTRL is not set

@flyride if you do a new entry for dva1622 in the platform list for 7.x - looks like no min. cpu requirement like 4th gen intel (at least not for booting, the AI surveillance needs intel qsv in a newer version then a 3rd gen has)

7.1 in both cases i guess? the kernel config file should be in toolkit ds.geminilake-7.1.dev.txz and would be he same for both so it it will be difficult to find out what the difference is but as long as it works ... maybe there are even more differences? best case the 8 cpu thread limit is gone too, maybe a vm with 16 cpu's can be used for testing to see if dva1622 uses more then 8 cpu threads

with a i7 3632qm (https://ark.intel.com/content/www/us/en/ark/products/71670/intel-core-i73632qm-processor-6m-cache-up-to-3-20-ghz-bga.html) thats kind of interesting as (in theory) the dva1622 would have the same minimum as 918+/920+ (same platform gemini lake), 4th gen aka haswell, but with the hint already here (no cpu gen mentioned, only that its to old for the other dva, https://xpenology.com/forum/topic/63410-develop-and-refine-the-dva1622-loader/?do=findComment&comment=288453) and that now it seems the dva1622 is much more interesting as it might open the field for a lot of older systems using transcoding if it does not need 4th gen as minimum - i'd say need a test with something older like 2nd gen sandybridge or older (and a good look into the kernel config files of 920+ and dva1622) that might be because of the differences in features of gpu gen's https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video its not documented yet what the min. requirement for the AI survailance to work, worst case it might be exclusive to gemini lake and above Intel GPU Gen's (but there are also list of intel qsv gen's with differents gen numbers) Gen 1 810, 815 Gen 2 i830M, 845G, 855GM, 865G Gen 3 915G/GM, 945G/GM, G/Q33, Q35, Atom D4xx/D5xx/N4xx/N5xx Gen 4 965G/GM/Q, G35, G41, G/Q43, G/GM/Q45 Gen 5 Nehalem (Ironlake) Gen 6 Sandy Bridge Gen 7 Ivy Bridge, Valley View, Bay Trail Gen 7.5 Haswell Gen 8 Broadwell, Cherryview Gen 9 Skylake, Broxton, Apollo Lake Gen 9.5 Kaby Lake, Coffee Lake, Gemini Lake Gen 10 Cannon Lake Gen 11 Elkhart Lake, Ice Lake Gen 12 Tiger Lake

you could also do a raw mapping with the disks to the vm and let proxmox have the control over the controller (to handle power management) not that i could do much about it but the kernel source related looks like this (given that the 7.0 source 4180 still matches to 7.0.1 42281 drivers/ata/libata-core.c:453 SYNO_CTRL_HDD_POWERON edit2: the thing wanted to say is that it might be something that need to be emulated by the loader to work properly, but i can't say for sure as i don't know enough about the handling of the disks in the loader ... int SYNO_CTRL_HDD_POWERON(int index, int value) { #ifdef MY_DEF_HERE if (0 < g_smbus_hdd_powerctl) { if (!SynoSmbusHddPowerCtl.bl_init){ syno_smbus_hdd_powerctl_init(); } if (syno_is_hw_version(HW_DS1621p)) { if (NULL != SynoSmbusHddPowerCtl.syno_smbus_hdd_enable_write_all_once) { SynoSmbusHddPowerCtl.syno_smbus_hdd_enable_write_all_once(gSynoSmbusHddAdapter, gSynoSmbusHddAddress); } } else { if (NULL != SynoSmbusHddPowerCtl.syno_smbus_hdd_enable_write) { SynoSmbusHddPowerCtl.syno_smbus_hdd_enable_write(gSynoSmbusHddAdapter, gSynoSmbusHddAddress, index, value); } } return 0; } #endif /* MY_DEF_HERE */ if (!HAVE_HDD_ENABLE(index)) { // index is 1-based printk("No such hdd enable pin. Index: %d\n", index); WARN_ON(1); return -EINVAL; } #if defined(MY_DEF_HERE) rtk_hdd_pwren_reset(index, value); #else /* MY_DEF_HERE */ SYNO_GPIO_WRITE(HDD_ENABLE_PIN(index), value); #endif /* MY_DEF_HERE */ ... edit: in 6.2 source (I'm also using jmb585 but baremetal dsm 6.2.3) the code looks very different ... int SYNO_CTRL_HDD_POWERON(int index, int value) { if (!HAVE_HDD_ENABLE(index)) { printk("No such hdd enable pin. Index: %d\n", index); WARN_ON(1); return -EINVAL; } SYNO_GPIO_WRITE(HDD_ENABLE_PIN(index), value); return 0; } EXPORT_SYMBOL(SYNO_CTRL_HDD_POWERON); int SYNO_CHECK_HDD_DETECT(int index) { int ret; if (!HAVE_HDD_DETECT(index)) { return 1; } ret = SYNO_GPIO_READ(HDD_DETECT_PIN(index)); #ifdef MY_DEF_HERE if (ACTIVE_LOW == HDD_DETECT_POLARITY(index)) { #else if (ACTIVE_LOW == HDD_DETECT_POLARITY()) { #endif ...

thanks, i was about to point out about it in the source https://github.com/pocopico/tinycore-redpill/blob/main/rploader.sh 2479 ff for the compile manual) echo "Using static compiled redpill extension" getstaticmodule echo "Got $REDPILL_MOD_NAME " echo "Manual extension handling,skipping extension auto detection " echo "Starting loader creation " buildloader

afair its not suggested (supported?) to have old style parallel scsi, it should be sata or at least lsi sas

there is no detail about the setup and disk arrangements any lsi sas controllers involved? how did you make the disks in the vm available for the use in dsm? if its more then a "test system" (any backup of the data on disk?) you might want to disable disk sleep in dsm's gui to prevent raid problems and do some testing with another vm before re-enabling it

in theory there should be one zero less in usbportcfg 0xc00000 0x3fffff the 3 and the c shold be on the same position but i dont think that causes a problem here maybe you try to do the same with 3617 (broadwell-7.1.0-42661)

well its also possible to revert the order of a controller, 7,8 is on the 2rd controller 1st and 2nd port as dummy found, if we revers the order of the 2nd controller the two usable ports will be 1st and 2nd port on that controller ... "SataPortMap": "22", "DiskIdxMap": "0006", "DiskSeqReverse": "04" },

maybe one last try? user-config-json.txt ... "SataPortMap": "6", "DiskIdxMap": "00", "sata_remap": "10\\>2:11\\>3" }, in theory it should map the two ports ata11/ata12 into the 1st dummy gap (ata3/ata4), close the gap and leave only 6 ports usable