The world of dtb/dts and ARM booting is so alien to me, I’m really happy to see stories about how people work it out.
I’ve tried a few times to follow guides but I always end up at dead ends such as tools that don’t exist or files I can’t get (the guides are out of date?).
I really hope the whole “provide your own dt file” and “every SOC boots differently” gets replaced with something better. For as much as we (me) complain about BIOS/EFI/ACPI it’s still a thousand times more consumer (and environmentally) friendly than the struggle of getting an ARM board to boot anything other than a years-old vendor-supplied disk image.
It depends a lot on the board. Arm has a server spec that has a fairly standard UEFI configuration and provides everything that you need for dynamic discovery. A lot of the hobbyist boards don’t use this, but do provide U-Boot that provides a valid DTB as init metadata to the kernel, so that any kernel that has the correct drivers can work with it. Consumer devices often skip this and just compile the DTB directly into the kernel to save some space (and boot complexity) and that’s where the pain comes in.
I wasn’t aware u-boot could provide the dtb, that’s much nicer. But doesn’t the dtb need to be updated to suit newer kernels? Or are kernels very backwards compatible with old dtb files (like they are with old and broken acpi/UEFI/bios)?
There’s nothing kernel-specific in DTB, the same blobs generally work with Linux and FreeBSD. DTB is just a map of the physical memory and the MMIO space, including some text specifying the names of the devices that can be used to find the corresponding driver. Some newer features, such as overlays, need newer kernels (overlays allow the kernel to get two or more device tree blobs from different ROMs and combine them).
Ah, TK1: that weird generation with both a 32-bit and a 64-bit variant :)
Hopefully this gets to the level of Linux on Pixel C which even has nouveau working..
Interesting. The link you mentioned seems to have an old Linux kernel version (over 4 years ago). Does it work from mainline?
The world of dtb/dts and ARM booting is so alien to me, I’m really happy to see stories about how people work it out.
I’ve tried a few times to follow guides but I always end up at dead ends such as tools that don’t exist or files I can’t get (the guides are out of date?).
I really hope the whole “provide your own dt file” and “every SOC boots differently” gets replaced with something better. For as much as we (me) complain about BIOS/EFI/ACPI it’s still a thousand times more consumer (and environmentally) friendly than the struggle of getting an ARM board to boot anything other than a years-old vendor-supplied disk image.
It depends a lot on the board. Arm has a server spec that has a fairly standard UEFI configuration and provides everything that you need for dynamic discovery. A lot of the hobbyist boards don’t use this, but do provide U-Boot that provides a valid DTB as init metadata to the kernel, so that any kernel that has the correct drivers can work with it. Consumer devices often skip this and just compile the DTB directly into the kernel to save some space (and boot complexity) and that’s where the pain comes in.
I wasn’t aware u-boot could provide the dtb, that’s much nicer. But doesn’t the dtb need to be updated to suit newer kernels? Or are kernels very backwards compatible with old dtb files (like they are with old and broken acpi/UEFI/bios)?
There’s nothing kernel-specific in DTB, the same blobs generally work with Linux and FreeBSD. DTB is just a map of the physical memory and the MMIO space, including some text specifying the names of the devices that can be used to find the corresponding driver. Some newer features, such as overlays, need newer kernels (overlays allow the kernel to get two or more device tree blobs from different ROMs and combine them).
Thankyou, I didn’t know this.
I guess unfortunately there is still this bit:
I will give it a try nonetheless.