dracutdevs / dracut

dracut the event driven initramfs infrastructure
https://github.com/dracutdevs/dracut/wiki
GNU General Public License v2.0
598 stars 397 forks source link

Device tree scripts for embedded devices. #1375

Open necrose99 opened 3 years ago

necrose99 commented 3 years ago

Describe the enhancement A clear and concise description of what the enhancement is that you would like to see.

Script/features to add device tree blobs to dracuts capabilities (Or add enhancement scripts to extend dracut, with a simple api. For doing embedded stuff , user-friendly etc. )

could load device trees much like existing kernel modules Ie. (Simular Treatment akin to kernel modules or ease of use)

Example: Dracaut add rtc_ds3231.. rtc_ds1307 Adding Arm64 Real Time clock rtc_ds3231, rtc_ds3231 into rpi4.intramfs..

which if using the new uefi firmware could be of use. And bit more dynamic than the static txt file.

Or latte panda etc, x86, arm64,riscv , etc single board pcs.

Anyway, making a custom kernel with blobs and easy load dtd's into intramfs via dracut would be a nice to have..

Treatment of them much like nvidia or well known modules , would also make for ease of management on embedded systems. Ie rpi4-rtc , rpi4-cmc , and carrying boards. Thier are several but search find probe etc esp. With a FREINDLY-ID , easy for users with lookup tables.
LCD, touchscreen , camera..

... probe for varrious rtc hardware on product detection add correct to list for dracut to insert into intramfs Load unload device trees automatically, probe device null , unload Load device found keep. Also a plus.

Hardware makers could script dracut to shim thier cool additions ie RasPad 3 into any kernel via dracut. Etc. Load device trees, kernel modules for hardware no problemo..

Arduino fans can add the new gizmos etc.. simple install via dracut script reboot , and pain free..

Recompile newer kernels, without breaking stuff... (Hopefully)

Dracut to manage device tree blobs for embedded devices, been hopeful feature for sometime. Ie. A Multiple arm64 device kernel. One could switch to just the bloobs they need.. however same os image on multiple devices.. rpi4 , pinebook pro etc , (uefi and newer onboard firmware) or add new hardware , camera etc painlessly.

tpgxyz commented 3 years ago

I may have a closer look on this, as i was getting into a shape a Pine64 RockPro64 sbc. One thing, there is no standard in booting process for various a{arch64,rmv7} boards and manufacurers.

necrose99 commented 3 years ago

RockPro64/pinebook-pro gentoo , one can run uefi with sbi one newer firmware with no boot blobs ie uboot .. on sbi-ep/rom looks for uefi firmware ie grub-aarch64.efi or uboot kernel settings for chainload... https://github.com/pftf/RPi4 , grub2 debian or etc .. https://stikonas.eu/wordpress/2019/09/15/blobless-boot-with-rockpro64/

ebay happens to have bare bonse 40 core ... thunder-x2 boards/towers esp since the 80 x 2 successors Ampere-altra server boards also a easy to likely implement for dtd dracut initrd extensions

stock debian can switch to grub-efi easily also..

Full Uefi , able boot firmwares would be the lower hanging fruit .. ie lcd , camera or touch screen ... etc... easily targets to test ... with dynamic dtd/dtb's

anyboards that can boot uefi grub , would be the easier targets , oems could extend to fit this own sbc's if more fininiky

as an enthusiast user I know enough to be ''Dangerous'' however most SBC's are a pain w/o uefi to update kernels and the overlay bits easily... , add Dyslexia , chances of bricking something .... goes up let alone novice users... or users with low english skills ie non-native speakers...

i'm aware of some of the arm related boot joys.. less users screw with that end ... looks for grub2 or etc all the better '>>> grub2+uefi-enable uboot+dracut-initrd +modern kernels to boot less of a jenga tower to fu((*&^...up... ' --ie brick the os-image--

OEMS with fickle boots can add extensions to this as a set of plug-ins / extensibility for devs is definitely in mind... Less hell for us users to update kernels etc..

OEMS with ''DKMS '' Like daughterboard overlay blobs make dracut-embedded-extensions wala .. item can single build dracut would shim into initramfs any add a script at boot thus uboot and crap users might break is less an issue .. -- easy rpms/debs/etc of overlay blobs for addon-cards etc. ..

For now its a hopeful concept wishlisted for sure. that might prove useful in easing some of the woes.. won't fix them all however perhaps automation of the boot blobs into initramfs were supportable might make administration for users/devs/oems less hassle ... automate some of the pain points away .... definitely areas of possibilities in this concept .... if you build it will they (come? ) (the oem's or other devs keep extending it to likewise ease their woes)