The officially official Devuan Forum!

c0rnelius

Member

Registered: 2020-06-13

Posts: 51  

Re: Is any work planned for devuan on the raspberry pi 4?

On other SoCs the device tree blob/binary needs to be loaded with the kernel in Extlinux and is defined by using

fdtdir /location

and

fdt /location/file

but on the PI this can't been done. Not sure why Grub would be able to handle this, but ok? I'll read over ur post further when I have some time.

ehem

Member

Registered: 2021-07-24

Posts: 10  

Re: Is any work planned for devuan on the raspberry pi 4?

On other SoCs the device tree blob/binary needs to be loaded with the kernel in Extlinux and is defined by using

fdtdir /location

and

fdt /location/file

but on the PI this can't been done. Not sure why Grub would be able to handle this, but ok? I'll read over ur post further when I have some time.

Why wouldn't GRUB be able to handle this?  Loading a device-tree like this is simply loading a file and placing it at an appropriate address address in an appropriate structure in memory.

The setup I've described is accomplishing this in two pieces.  "flash-kernel" copies the kernel device-tree into /boot/dtb-${kernel}.  The GRUB patch modifies /etc/grub.d/10_linux which in turn adds lines to the resultant grub.cfg file, the crucial line is "devicetree /boot/dtb-${kernel}" (where ${kernel} is the kernel version string).

I've been given the impression GRUB's "devicetree" command exists in 2.02.  Yet without the linked to patch (or an equivalent) the invocation of "devicetree" doesn't appear in grub.cfg and the device-tree never gets loaded.

c0rnelius

Member

Registered: 2020-06-13

Posts: 51  

Re: Is any work planned for devuan on the raspberry pi 4?

You are missing the point.

Device Tree files
There are various Device Tree blob files, which have the extension .dtb. These contain the hardware definitions of the various models of Raspberry Pi, and are used on boot to set up the kernel according to which Pi model is detected.

https://www.raspberrypi.org/documentati … _folder.md

The keyword here is: Detected.

The DTB file should not be defined, as the bootloader detects which version of the pi and loads it accordingly. You can however define it inside the /boot/config.txt file, but that is usually only done if it's not in its default location or someone is using a custom DTB. Either way, this is done during the normal boot process of the Pi and has nothing to do with u-boot ==> {boot.scr,extlinux,grub}

So the problem still becomes, how does each kernel know which DTB to load if it is not definable when using u-boot and only takes place after the fact? I believe you had mentioned before that it may be/is possible for grub to copy the correct dtb into place during the boot process and if so I assume this would be doable. But then we still have the problem of Kernel packaging, which at this time isn't suitable.

You are more than welcome to work out the logistical elements of this and contribute if you wanna make this happen. You can find me on irc @ libera: #devuan-arm or #arm-img-builder

ehem

Member

Registered: 2021-07-24

Posts: 10  

Re: Is any work planned for devuan on the raspberry pi 4?

You are missing the point.

Device Tree files
There are various Device Tree blob files, which have the extension .dtb. These contain the hardware definitions of the various models of Raspberry Pi, and are used on boot to set up the kernel according to which Pi model is detected.

https://www.raspberrypi.org/documentati … _folder.md

The keyword here is: Detected.

I'm taking a look at the full history to check whether there is additional information of value.  I'm unsure which of us missed what, but it seems we're on opposite sides of a canyon.  We've got different goals and our priorities are very different.

You desire fully operational overlays and the advantages those give.  Notably you can use the full Raspberry PI ecosystem of hardware.

I meanwhile desire greater control over the boot process and the advantages that gives.  This allows for loading rather interesting OS setups, notably it can load Linux on Xen.

I don't know whether we're diametrically opposed or not.  What I can say is our goals are wildly different, thus we're going to make very different choices and push things in different directions.

My current thinking is we really need a minimum baseline of compatible device-trees.  Enough for storage and console I/O to function.  Once you have that what we really need is a program which can disassemble the device-tree passed in by the RP4's bootloader and replace the passed-in overlays with overlays associated with the current kernel.  Then turn this into a new device-tree and have the running kernel load this reinterpreted device-tree.

I'm unsure how complicated this is.  I recall seeing a kernel option to replace the passed-in device-tree with one built into the kernel, but I'm unsure whether the possibility of replacing the device-tree during initial ramdisk phase was offered.  I certainly wouldn't want to add this to U-Boot or GRUB, this is too Raspberry PI specific and a user-mode utility in initial ramdisk seems the right sort of place.