DSM 7.x Loaders and Platforms

Before installing XPEnology using DSM 7.x, you must select a DSM platform and loader. XPEnology supports a variety of platforms that enable specific hardware and software features. All platforms support a minimum of 4 CPU cores, 64GB of RAM, 10Gbe network cards and 16 drives. Each can run "baremetal" as a stand-alone operating system OR as a virtual machine within a hypervisor. A few specific platforms are preferred for typical installs. Review the table and decision tree below to help you navigate the options.

NOTE: DSM 6.x is still a viable system and is the best option for certain types of hardware. See this link for more information.

DSM 7.x LOADERS ARE DIFFERENT:

A loader allows DSM to install and run on non-Synology hardware. The loaders for DSM 5.x/6.x were monolithic; i.e. a single loader image was applicable to all installs. With DSM 7.x, a custom loader must be created for each DSM install. TinyCore RedPill (TCRP) is currently the most developed tool for building 7.x loaders. TCRP installs with two step-process. First, a Linux OS (TinyCore) boots and evaluates your hardware configuration. Then, an individualized loader (RedPill) is built and written to the loader device. After that, you can switch between starting DSM with RedPill, and booting back into TinyCore to adjust and rebuild as needed.

TCRP's Linux boot image (indicated by the version; i.e. 0.8) changes only when a new DSM platform or version is introduced. However, you can and should update TCRP itself prior to each loader build, adding fixes, driver updates and new features contributed by many different developers. Because of this ongoing community development, TCRP capabilities change rapidly. Please post new or divergent results when encountered, so that this table may be updated.

7.x Loaders and Platforms as of 06-June-2022

* FMA3 instruction support required. All Haswell Core processors or later support it.  Very few Pentiums/Celerons do (J-series CPUs are a notable exception).

   Piledriver is believed to be the minimum AMD CPU architecture equivalent to Intel Haswell.
** Based on history, DS920+ should require Haswell. There is anecdotal evidence gradually emerging that DS920+ will run on x86-64 hardware.

NOT ALL HARDWARE IS SUITABLE:

DSM 7 has a new requirement for the initial installation. If drive hotplug is supported by the motherboard or controller, all AHCI SATA ports visible to DSM must either be configured for hotplug or have an attached drive during initial install. Additionally, if the motherboard or controller chipset supports more ports than are physically implemented, DSM installation will fail unless they are mapped out of visibility. On some hardware, it may be impossible to install (particularly on baremetal) while retaining access to the physical ports. The installation tutorial has more detail on the causes of this problem, and possible workarounds.

DRIVE SLOT MAPPING CONSIDERATIONS:

On most platforms, DSM evaluates the boot-time Linux parameters SataPortMap and DiskIdxMap to map drive slots from disk controllers to a usable range for DSM.  Much has been written about how to set up these parameters. TCRP's satamap command determines appropriate values based on the system state during the loader build. It is also simple to manually edit the configuration file if your hardware is unique or misidentified by the tool.

On the DS920+ and DS1621+ platforms, DSM uses a Device Tree to identify the hardware and ignores SataPortMap and DiskIdxMap. The device tree hardcodes the SATA controller PCI devices and drive slots (and also NVMe slots and USB ports) prior to DSM installation. Therefore, an explicit device tree that matches your hardware must be configured and stored within the loader image.

TCRP automatic device tree configuration is limited. For example, any disk ports left unpopulated at loader build time will not be accessible later. VMware ESXi is not currently supported. Host bus adapters (SCSI, SAS, or SATA RAID in IT mode) are not currently supported.
 

Manually determining correct values and updating the device tree is complex. Device Tree support is being worked on and will improve, but presently you will generally be better served by choosing platforms that support SataPortMap and DiskIdxMap (see Tier 1 below).

CURRENT PLATFORM RECOMMENDATIONS AND DECISION TREE:

VIRTUALIZATION: 

All the supported platforms can be run as a virtual machine within a hypervisor. Some use case examples:

• virtualize unsupported network card

• virtualize SAS/NVMe storage and present to DSM as SATA

• run other VMs in parallel on the same hardware (as an alternative to Synology VMM)

• share 10GBe network card with other non-XPEnology VMs

• testing and rollback of updates

Prerequisites: ESXi (requires a paid or free license) or open-source hypervisor (QEMU, Proxmox, XenServer). Hyper-V is NOT supported.

Preferred Configurations: passthrough SATA controller and disks, and/or configure RDM/RAW disks

This post will be updated as more documentation is available for the various TCRP implementations.

there are different api's that software like jellyfin (free, syno package or docker) or plex/emby (needs license/paying for hardware transcoding) can use

syno's videostation seems to be intel qsv exclusive, guess it would not do hardware transcoding with dva3221 with just nvidia drivers

so not just yes/no, maybe Intel QSV for 918/920 and Nvidia ( not sure if its NVENC/CUDA/VDPAU) for DVA3221 as the nvidia kernel driver is installed and with the nvidia package from synology it gets nvidia support for using plex or jellyfin (as also done for 3615, 3617, 918+ on 6.2.3), even a "optional Nvidia" might be possible on all other (with a "*" because there is no driver yet for 3622 or other units)

https://xpenology.com/forum/topic/22272-nvidia-runtime-library/

i contrary to the missing i915 support in other kernels then 918/920 there was no problem in compiling additional nvidia drivers (matching the version synology uses) for other units, afaik there should be no problem having nvidia drivers in 3622 for using jellyfin/emby/plex instead of the intel qsv we cant have with this unit

it might also be useful to mention the base kernel version, its 4.4.x for all but 3615, that one still has  3.10.x (with 6.2.3 and kernel 4.4 on 918 and 3.10 on 3615/3617 i was unable to compile some drivers for 3.10 like the realtek 2.5G nic driver)

for 3617 and cpu threads i had found out (syno kernel config published) that its 24 with 7.x (syno might have used the kernel config of longer standing broadwellnk as base for bringing broadwell from 3.10 to 4.4)

https://xpenology.com/forum/topic/38603-suggestions-for-units-to-have-a-loader-for-with-70/?do=findComment&comment=264214

does not change the outcome of 3617 being replaced by 3622 but makes them more or less the same (there might be slight differences in the driver versions syno has ootb tipping the scale to 3622)

it might be worth mentioning that there is still no hyper-v support, so anyone hoping for this needs to choose something different then xpenology

afair we already tested dva3221 for older cpu support and it was the same as 918/920

https://xpenology.com/forum/topic/58499-dva3221-loader-development-thread/?do=findComment&comment=270216

DS3617xs is listed as "NVMe Cache Support" No - it should be a Yes

https://kb.synology.com/en-id/DSM/tutorial/Which_Synology_NAS_models_support_SSD_cache

it supports E10M20-T1, M2D20 (has a pcie slot) and can have nvme in the regular version from synology, so the nvme support is present and we could use it the same way as with the other units (i guess all kernel 4.4 units have nvme support in general, the only one left out are the 3.10 kernel units like DS3615xs)

打赏

支付宝微信扫一扫，打赏作者吧～

本文链接：https://www.kinber.cn/post/2947.html 转载需授权！

推荐本站淘宝优惠价购买喜欢的宝贝:

 您阅读本篇文章共花了：