Problem with U-boot | Configuration Signature not being checked while booting
Hope you are doing well and everything is going good at your end. I am using Raspi 4B and Compute Model 4 and trying to configure U-boot with Verified boot support, *but while booting the signing of the configuration is not being checked*. I am using the latest master branch from GitHub. https://github.com/u-boot/u-boot
We have checked the signature verification via the *"fit_check_sign" *utility that comes with u-boot and it does verify the configuration of the signature so, I am sure that the image is signed properly and the Control FDT is good as well.
[image: fit_check_sign.png]
but while booting, it doesn't check the signature of the configuration. It should be showing "*Verifying Hash Integrity ... sha1,rsa2048:dev+ OK*" [image: image.png]
*I believe that maybe I am not adding Control FDT in the U-boot binary properly.* Following is the command that I am using to add control FDT to U-boot.
$ make EXT_DTB=bcm2711-rpi-4-b-pubkey.dtb -j8 I have also tried $ make DEV_TREE_BIN=bcm2711-rpi-4-b-pubkey.dtb -j8
The bytes size of the u-boot.bin and u-boot-nodtb.bin after using both the above commands is the same.
Attached is the FIT source file, rpi_4_defconfig and the control FDT file. Also, the following has been added in configs/rpi_4_defconfig.
CONFIG_OF_CONTROL=y CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y CONFIG_RSA=y
*Can you please help me with how to add Control FDT to the U-boot.bin binary or what can be the reason that it isn't checking the signature of the configuration while booting? Any kind of help would be really appreciated.*
+Tom Rini
Hi Moiz,
On Thu, 9 Sept 2021 at 14:21, Moiz Imtiaz moizimtiaz1@gmail.com wrote:
Hope you are doing well and everything is going good at your end. I am using Raspi 4B and Compute Model 4 and trying to configure U-boot with Verified boot support, but while booting the signing of the configuration is not being checked. I am using the latest master branch from GitHub.
We have checked the signature verification via the "fit_check_sign" utility that comes with u-boot and it does verify the configuration of the signature so, I am sure that the image is signed properly and the Control FDT is good as well.
but while booting, it doesn't check the signature of the configuration. It should be showing "Verifying Hash Integrity ... sha1,rsa2048:dev+ OK"
I believe that maybe I am not adding Control FDT in the U-boot binary properly. Following is the command that I am using to add control FDT to U-boot.
$ make EXT_DTB=bcm2711-rpi-4-b-pubkey.dtb -j8 I have also tried $ make DEV_TREE_BIN=bcm2711-rpi-4-b-pubkey.dtb -j8
The bytes size of the u-boot.bin and u-boot-nodtb.bin after using both the above commands is the same.
Attached is the FIT source file, rpi_4_defconfig and the control FDT file. Also, the following has been added in configs/rpi_4_defconfig.
CONFIG_OF_CONTROL=y CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y CONFIG_RSA=y
Can you please help me with how to add Control FDT to the U-boot.bin binary or what can be the reason that it isn't checking the signature of the configuration while booting? Any kind of help would be really appreciated.
There is an example of this flow in the sandbox vboot test. There is also an example for Beaglebone Black in doc/uImage.FIT/beaglebone_vboot.txt
I wonder if rpi is not using the devicetree compiled with U-Boot, but instead one provided by the earlier-stage firmware? Can you check that the required 'signature' node is present? You can use the 'fdt' command in U-Boot to look at it.
Looking at rpi_4 it uses CONFIG_OF_BOARD which means it has its own special way of getting the devicetree into U-Boot. The older boards use CONFIG_OF_EMBED which is actually not even allowed in production boards....
Also you may need the -r argument to mkimage to mark the key as required.
Regards, Simon
Hi Simon,
Thanks for the reply. I already followed the steps mentioned in "doc/uImage.FIT/beaglebone_vboot.txt".
I wonder if rpi is not using the devicetree compiled with U-Boot, but
instead one provided by the earlier-stage firmware?
Not sure, but seems like this is the case. I checked and there isn't any dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to add the dtb and other dts dtsi https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcomfiles from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and it would just give a blank screen*. I wonder why there isn't any device tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by RPI4?
and if I tried CONFIG_OF_BOARD (the default rpi_4 configuration), it will take us back to the initial problem, signature not being checked.
Can you check that the required 'signature' node is present? You can use
the 'fdt' command in U-Boot to look at it. I tried the "fdt checksign" but it didn't return anything. Screenshot inlined, image.itb is the fit image. If I am not doing it wrong, or some other commands needs to be executed, please let me know.
[image: image.png]
Just for reference, I am inlining the steps I followed: 1. clone the master branch of u-boot. 2. Add FIT, RSA & SIGNATURE support to rpi_4_defconfig 3. Build with 64-bit architecture. (CROSS_COMPILE=aarch64-linux-gnu-) 4. Build U-boot ($make -j8) 5. copy device tree and make a clone by appending pubkey to it. $ cp bcm2711-rpi-4-b.dtb bcm2711-rpi-4-b-pubkey.dtb 6. generate the keys and make .its file and sign it with the following command: mkdir keys openssl genrsa -F4 -out keys/dev.key 2048 openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt mkimage -f image.its -K bcm2711-rpi-4-b-pubkey.dtb -k keys -r image.itb 7. rebuild uboot with control FDT (bcm2711-rpi-4-b-pubkey.dtb) $make EXT_DTB=bcm2711-rpi-4-b-pubkey.dtb -j8 8. Copy u-boot.bin and image.itb to boot partition.
But since I had CONFIG_OF_BOARD set, I am assuming it didn't add control FDT into u-boot.bin as byte size for both binaries (u-boot.bin & u-boot-nodtb.bin) was the same. I tried to concatenate them with cat but while booting, U-Boot still didn't read the Control FDT.
Can anyone please help with enabling verified boot (signature check) support for Raspberry Pi4. It's a very mainstream board and support for it would be great to have. I am willing to contribute, whatever I can.
Best, Moiz Imtiaz
On Fri, Sep 10, 2021 at 9:37 AM Simon Glass sjg@chromium.org wrote:
+Tom Rini
Hi Moiz,
On Thu, 9 Sept 2021 at 14:21, Moiz Imtiaz moizimtiaz1@gmail.com wrote:
Hope you are doing well and everything is going good at your end. I am
using Raspi 4B and Compute Model 4 and trying to configure U-boot with Verified boot support, but while booting the signing of the configuration is not being checked. I am using the latest master branch from GitHub.
We have checked the signature verification via the "fit_check_sign"
utility that comes with u-boot and it does verify the configuration of the signature so, I am sure that the image is signed properly and the Control FDT is good as well.
but while booting, it doesn't check the signature of the configuration.
It should be showing "Verifying Hash Integrity ... sha1,rsa2048:dev+ OK"
I believe that maybe I am not adding Control FDT in the U-boot binary
properly. Following is the command that I am using to add control FDT to U-boot.
$ make EXT_DTB=bcm2711-rpi-4-b-pubkey.dtb -j8 I have also tried $ make DEV_TREE_BIN=bcm2711-rpi-4-b-pubkey.dtb -j8
The bytes size of the u-boot.bin and u-boot-nodtb.bin after using both
the above commands is the same.
Attached is the FIT source file, rpi_4_defconfig and the control FDT
file. Also, the following has been added in configs/rpi_4_defconfig.
CONFIG_OF_CONTROL=y CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y CONFIG_RSA=y
Can you please help me with how to add Control FDT to the U-boot.bin
binary or what can be the reason that it isn't checking the signature of the configuration while booting? Any kind of help would be really appreciated.
There is an example of this flow in the sandbox vboot test. There is also an example for Beaglebone Black in doc/uImage.FIT/beaglebone_vboot.txt
I wonder if rpi is not using the devicetree compiled with U-Boot, but instead one provided by the earlier-stage firmware? Can you check that the required 'signature' node is present? You can use the 'fdt' command in U-Boot to look at it.
Looking at rpi_4 it uses CONFIG_OF_BOARD which means it has its own special way of getting the devicetree into U-Boot. The older boards use CONFIG_OF_EMBED which is actually not even allowed in production boards....
Also you may need the -r argument to mkimage to mark the key as required.
Regards, Simon
From: Moiz Imtiaz moizimtiaz1@gmail.com Date: Sat, 11 Sep 2021 23:19:05 +0500
Hi Simon,
Thanks for the reply. I already followed the steps mentioned in "doc/uImage.FIT/beaglebone_vboot.txt".
I wonder if rpi is not using the devicetree compiled with U-Boot, but
instead one provided by the earlier-stage firmware?
Not sure, but seems like this is the case. I checked and there isn't any dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to add the dtb and other dts dtsi https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcomfiles from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and it would just give a blank screen*. I wonder why there isn't any device tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by RPI4?
The issue with the rpi4 is that the addresses of devices move around based on the version of the Raspberry Pi firmware you're using. And possibly on the amount of memory on the board as well. So U-Boot pretty much has to use the device tree passed by the firmware since the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think the idea of having all U-Boot configuration information in a single device tree with the hardware description doesn't work everywhere.
On Sat, Sep 11, 2021 at 09:18:46PM +0200, Mark Kettenis wrote:
From: Moiz Imtiaz moizimtiaz1@gmail.com Date: Sat, 11 Sep 2021 23:19:05 +0500
Hi Simon,
Thanks for the reply. I already followed the steps mentioned in "doc/uImage.FIT/beaglebone_vboot.txt".
I wonder if rpi is not using the devicetree compiled with U-Boot, but
instead one provided by the earlier-stage firmware?
Not sure, but seems like this is the case. I checked and there isn't any dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to add the dtb and other dts dtsi https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcomfiles from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and it would just give a blank screen*. I wonder why there isn't any device tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by RPI4?
The issue with the rpi4 is that the addresses of devices move around based on the version of the Raspberry Pi firmware you're using. And possibly on the amount of memory on the board as well. So U-Boot pretty much has to use the device tree passed by the firmware since the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think the idea of having all U-Boot configuration information in a single device tree with the hardware description doesn't work everywhere.
In this case, doesn't the Pi firmware pass along apply overlays and construct the device tree it's going to pass along, so in this case you would want to make an "overlay" for the Pi firmware to apply and pass along to U-Boot, that includes the required information?
Date: Sat, 11 Sep 2021 17:05:45 -0400 From: Tom Rini trini@konsulko.com
On Sat, Sep 11, 2021 at 09:18:46PM +0200, Mark Kettenis wrote:
From: Moiz Imtiaz moizimtiaz1@gmail.com Date: Sat, 11 Sep 2021 23:19:05 +0500
Hi Simon,
Thanks for the reply. I already followed the steps mentioned in "doc/uImage.FIT/beaglebone_vboot.txt".
I wonder if rpi is not using the devicetree compiled with U-Boot, but
instead one provided by the earlier-stage firmware?
Not sure, but seems like this is the case. I checked and there isn't any dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to add the dtb and other dts dtsi https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcomfiles from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and it would just give a blank screen*. I wonder why there isn't any device tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by RPI4?
The issue with the rpi4 is that the addresses of devices move around based on the version of the Raspberry Pi firmware you're using. And possibly on the amount of memory on the board as well. So U-Boot pretty much has to use the device tree passed by the firmware since the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think the idea of having all U-Boot configuration information in a single device tree with the hardware description doesn't work everywhere.
In this case, doesn't the Pi firmware pass along apply overlays and construct the device tree it's going to pass along, so in this case you would want to make an "overlay" for the Pi firmware to apply and pass along to U-Boot, that includes the required information?
yes, that might work. The overlay can be specified in the config.txt file.
I think truly verified boot is impossible on the Pi though, as u-boot and the overlay file will need to be stored on the uSD card of the Pi. But that applies to the scenario where the public key is stored in the device tree embedded in u-boot itself as well.
On Sat, Sep 11, 2021 at 11:30:00PM +0200, Mark Kettenis wrote:
Date: Sat, 11 Sep 2021 17:05:45 -0400 From: Tom Rini trini@konsulko.com
On Sat, Sep 11, 2021 at 09:18:46PM +0200, Mark Kettenis wrote:
From: Moiz Imtiaz moizimtiaz1@gmail.com Date: Sat, 11 Sep 2021 23:19:05 +0500
Hi Simon,
Thanks for the reply. I already followed the steps mentioned in "doc/uImage.FIT/beaglebone_vboot.txt".
I wonder if rpi is not using the devicetree compiled with U-Boot, but
instead one provided by the earlier-stage firmware?
Not sure, but seems like this is the case. I checked and there isn't any dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to add the dtb and other dts dtsi https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcomfiles from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and it would just give a blank screen*. I wonder why there isn't any device tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by RPI4?
The issue with the rpi4 is that the addresses of devices move around based on the version of the Raspberry Pi firmware you're using. And possibly on the amount of memory on the board as well. So U-Boot pretty much has to use the device tree passed by the firmware since the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think the idea of having all U-Boot configuration information in a single device tree with the hardware description doesn't work everywhere.
In this case, doesn't the Pi firmware pass along apply overlays and construct the device tree it's going to pass along, so in this case you would want to make an "overlay" for the Pi firmware to apply and pass along to U-Boot, that includes the required information?
yes, that might work. The overlay can be specified in the config.txt file.
I think truly verified boot is impossible on the Pi though, as u-boot and the overlay file will need to be stored on the uSD card of the Pi. But that applies to the scenario where the public key is stored in the device tree embedded in u-boot itself as well.
Yes, a more general problem is that some platforms are really only proof-of-concept useful. If you can't start with the ROM, you're going to be limited.
Completely agreed, that a fully secure boot on pi won't be achievable because the Root of Trust (ROT) cant be established from the BOTROM/EEPROM. Plus Pi doesn't have any High Assurance Boot (HAB). But given the scenerio, whatever we can achieve i.e if we can verify the kernel, the device tree, from the bootloader, (u-boot) that would be great.
Currently the issue with Pi4 is that , signature verification is not being done with u-boot, so wondering if that can be made possible.
But that applies to the scenario where the public key is stored in the device tree embedded in u-boot itself as well
Just for the sake of knowledge, Isn't this the case with all u-boot, that the public key is stored in the device tree (control FDT) and is embedded in the u-boot.
On Sun, 12 Sep 2021, 02:34 Tom Rini, trini@konsulko.com wrote:
On Sat, Sep 11, 2021 at 11:30:00PM +0200, Mark Kettenis wrote:
Date: Sat, 11 Sep 2021 17:05:45 -0400 From: Tom Rini trini@konsulko.com
On Sat, Sep 11, 2021 at 09:18:46PM +0200, Mark Kettenis wrote:
From: Moiz Imtiaz moizimtiaz1@gmail.com Date: Sat, 11 Sep 2021 23:19:05 +0500
Hi Simon,
Thanks for the reply. I already followed the steps mentioned in "doc/uImage.FIT/beaglebone_vboot.txt".
I wonder if rpi is not using the devicetree compiled with U-Boot,
but
instead one provided by the earlier-stage firmware?
Not sure, but seems like this is the case. I checked and there
isn't any
dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I
tried to
add the dtb and other dts dtsi <
https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/bro...
files
from the raspberry pi Linux and compile them with
CONFIG_OF_SEPARATE and
CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the
U-Boot and
it would just give a blank screen*. I wonder why there isn't any
device
tree in the U-boot repo for RPI4. Is U-boot control FDT not
supported by
RPI4?
The issue with the rpi4 is that the addresses of devices move around based on the version of the Raspberry Pi firmware you're using. And possibly on the amount of memory on the board as well. So U-Boot pretty much has to use the device tree passed by the firmware since the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think the idea of having all U-Boot configuration information in a single device
tree
with the hardware description doesn't work everywhere.
In this case, doesn't the Pi firmware pass along apply overlays and construct the device tree it's going to pass along, so in this case you would want to make an "overlay" for the Pi firmware to apply and pass along to U-Boot, that includes the required information?
yes, that might work. The overlay can be specified in the config.txt
file.
I think truly verified boot is impossible on the Pi though, as u-boot and the overlay file will need to be stored on the uSD card of the Pi. But that applies to the scenario where the public key is stored in the device tree embedded in u-boot itself as well.
Yes, a more general problem is that some platforms are really only proof-of-concept useful. If you can't start with the ROM, you're going to be limited.
-- Tom
On Sun, Sep 12, 2021 at 02:58:12AM +0500, Moiz Imtiaz wrote:
Completely agreed, that a fully secure boot on pi won't be achievable because the Root of Trust (ROT) cant be established from the BOTROM/EEPROM. Plus Pi doesn't have any High Assurance Boot (HAB). But given the scenerio, whatever we can achieve i.e if we can verify the kernel, the device tree, from the bootloader, (u-boot) that would be great.
Currently the issue with Pi4 is that , signature verification is not being done with u-boot, so wondering if that can be made possible.
Right, OK. Yes, I think it would be possible, but you'll need to experiment a bit. You'll basically want to take the signature information that the U-Boot docs talk about out of the created device tree, and put it in its own file, and then have the Pi firmware apply that as an "overlay", as it assembles the tree to use. Then the regular mechanism U-Boot uses to use the passed in device tree should work.
But that applies to the scenario where the public key is stored in the device tree embedded in u-boot itself as well
Just for the sake of knowledge, Isn't this the case with all u-boot, that the public key is stored in the device tree (control FDT) and is embedded in the u-boot.
You're in experimental territory here, yes. The existing examples all are on platforms where a prior stage wouldn't be giving us a device tree. U-Boot should not actually care where the device tree comes from so long as it is correct.
I've only got a Pi 3 in my CI lab, and since it's CI I also really hate fiddling with it since I then end up spending more time re-setting it for CI.
Thanks a lot Tom and U-boot Team,
What I did is that I made a control FDT (with Public_key and signature_node) and replaced the default dtb (bcm2711-rpi-4-b.dtb) in the boot directory of rpi_4-b(the board I am using) with the Control FDT
I compiled U-boot with "Config_OF_BOARD" and thought that since the pi second stage bootloader is gonna decide what dtb to use, how about replacing the default with our Contro FDT and it worked :)
[image: image.png]
It's like when I will be copying u-boot.bin in the /boot directory I will replace the default dtb with the Control FDT. If there is any concern with the above implementation from a security perspective (i.e manually replacing the default dtb of pi with control FDT), please let me know so that I can improve it. I am completely open to suggestions.
I also checked by modifying the config kernel hash and it throw rejection and didn't boot up. [image: changing_the_hash_verfication.png]
Kudos on the awesome writeup https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/beaglebone_vboot.txt of manual verification by modifying the hash, saved me a couple of hours of googling :D
Also, one quick question, why do we not accept boot scripts with FIT enabled? I really like the idea of disabling legacy image support with FIT enabled but what is the recommended way of achieving boot scripts action then, if we won't allow boot script for e.g loading the FIT image in memory and then booting it up with bootm? Currently, I am using the following in my boot script.
setenv bootargs 8250.nr_uarts=1 console=ttyS0,115200 root=/dev/mmcblk0p2
rootwait rw; fatload mmc 0:1 0x20000000 image.itb; bootm 0x20000000;
Again, thanks a lot and appreciate your input and suggestions.
Best, Moiz Imtiaz Khan
On Sun, Sep 12, 2021 at 8:02 PM Tom Rini trini@konsulko.com wrote:
On Sun, Sep 12, 2021 at 02:58:12AM +0500, Moiz Imtiaz wrote:
Completely agreed, that a fully secure boot on pi won't be achievable because the Root of Trust (ROT) cant be established from the
BOTROM/EEPROM.
Plus Pi doesn't have any High Assurance Boot (HAB). But given the scenerio, whatever we can achieve i.e if we can verify the kernel, the device tree, from the bootloader, (u-boot) that would be great.
Currently the issue with Pi4 is that , signature verification is not
being
done with u-boot, so wondering if that can be made possible.
Right, OK. Yes, I think it would be possible, but you'll need to experiment a bit. You'll basically want to take the signature information that the U-Boot docs talk about out of the created device tree, and put it in its own file, and then have the Pi firmware apply that as an "overlay", as it assembles the tree to use. Then the regular mechanism U-Boot uses to use the passed in device tree should work.
But that applies to the scenario where the public key is stored in the device tree embedded in u-boot itself as well
Just for the sake of knowledge, Isn't this the case with all u-boot, that the public key is stored in the device tree (control FDT) and is embedded in the u-boot.
You're in experimental territory here, yes. The existing examples all are on platforms where a prior stage wouldn't be giving us a device tree. U-Boot should not actually care where the device tree comes from so long as it is correct.
I've only got a Pi 3 in my CI lab, and since it's CI I also really hate fiddling with it since I then end up spending more time re-setting it for CI.
-- Tom
On Mon, Sep 13, 2021 at 01:45:56AM +0500, Moiz Imtiaz wrote:
Thanks a lot Tom and U-boot Team,
What I did is that I made a control FDT (with Public_key and signature_node) and replaced the default dtb (bcm2711-rpi-4-b.dtb) in the boot directory of rpi_4-b(the board I am using) with the Control FDT
I compiled U-boot with "Config_OF_BOARD" and thought that since the pi second stage bootloader is gonna decide what dtb to use, how about replacing the default with our Contro FDT and it worked :)
[image: image.png]
It's like when I will be copying u-boot.bin in the /boot directory I will replace the default dtb with the Control FDT. If there is any concern with the above implementation from a security perspective (i.e manually replacing the default dtb of pi with control FDT), please let me know so that I can improve it. I am completely open to suggestions.
I also checked by modifying the config kernel hash and it throw rejection and didn't boot up. [image: changing_the_hash_verfication.png]
Kudos on the awesome writeup https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/beaglebone_vboot.txt of manual verification by modifying the hash, saved me a couple of hours of googling :D
Nice! If you want to write something up extending the documentation on how you made this work for Pi it would be much appreciated.
Also, one quick question, why do we not accept boot scripts with FIT enabled? I really like the idea of disabling legacy image support with FIT enabled but what is the recommended way of achieving boot scripts action then, if we won't allow boot script for e.g loading the FIT image in memory and then booting it up with bootm? Currently, I am using the following in my boot script.
setenv bootargs 8250.nr_uarts=1 console=ttyS0,115200 root=/dev/mmcblk0p2
rootwait rw; fatload mmc 0:1 0x20000000 image.itb; bootm 0x20000000;
Again, thanks a lot and appreciate your input and suggestions.
I believe the general reason is that we want to have the vboot build as locked down as possible. You should be able to embed the bootargs in to the FIT image, if you don't need to support some sort of A/B rootfs scheme, or in to the default U-Boot environment otherwise.
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Moiz Imtiaz moizimtiaz1@gmail.com Date: Sat, 11 Sep 2021 23:19:05 +0500
Hi Simon,
Thanks for the reply. I already followed the steps mentioned in "doc/uImage.FIT/beaglebone_vboot.txt".
I wonder if rpi is not using the devicetree compiled with U-Boot, but
instead one provided by the earlier-stage firmware?
Not sure, but seems like this is the case. I checked and there isn't any dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to add the dtb and other dts dtsi https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcomfiles from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and it would just give a blank screen*. I wonder why there isn't any device tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by RPI4?
The issue with the rpi4 is that the addresses of devices move around based on the version of the Raspberry Pi firmware you're using. And possibly on the amount of memory on the board as well. So U-Boot pretty much has to use the device tree passed by the firmware since the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think the idea of having all U-Boot configuration information in a single device tree with the hardware description doesn't work everywhere.
From my reading of this thread, it rather reinforces the need to
provide a way to give U-Boot the config it needs, in the devicetree.
It seems that rpi is actually OK in this regard. If you think about it, it would be pretty hopeless if first-stage firmware assumed that it could provide a devicetree to whatever is next. For example, if U-Boot evolves to support more devices, they could not be supported. If UEFI is used, the devicetree would have no effect, since it doesn't support devicetree.
So perhaps the only remaining issue is with qemu on ARM / Risc-V?
Regards, Simon
Le mer. 15 sept. 2021 à 12:13, Simon Glass sjg@chromium.org a écrit :
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Moiz Imtiaz moizimtiaz1@gmail.com Date: Sat, 11 Sep 2021 23:19:05 +0500
Hi Simon,
Thanks for the reply. I already followed the steps mentioned in "doc/uImage.FIT/beaglebone_vboot.txt".
I wonder if rpi is not using the devicetree compiled with U-Boot, but
instead one provided by the earlier-stage firmware?
Not sure, but seems like this is the case. I checked and there isn't
any
dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I
tried to
add the dtb and other dts dtsi <
https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/bro...
files
from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE
and
CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot
and
it would just give a blank screen*. I wonder why there isn't any device tree in the U-boot repo for RPI4. Is U-boot control FDT not supported
by
RPI4?
The issue with the rpi4 is that the addresses of devices move around based on the version of the Raspberry Pi firmware you're using. And possibly on the amount of memory on the board as well. So U-Boot pretty much has to use the device tree passed by the firmware since the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think the idea of having all U-Boot configuration information in a single device tree with the hardware description doesn't work everywhere.
From my reading of this thread, it rather reinforces the need to provide a way to give U-Boot the config it needs, in the devicetree.
It seems that rpi is actually OK in this regard. If you think about it, it would be pretty hopeless if first-stage firmware assumed that it could provide a devicetree to whatever is next. For example, if U-Boot evolves to support more devices, they could not be supported. If UEFI is used, the devicetree would have no effect, since it doesn't support devicetree.
Please use EDK2 when you refer to it and not by the interface it implements. And even if we read “If EDK2 is used” this is false as Socionext has a platform that can select ACPI or DT for its EDK2 implementation. TF-A has fat less drivers than U-Boot. There is no problem in having a “verified” platform DT stored in BL33_CONFIG part of a FIP, verified by TFa and handed over by U-Boot to OS. That can be the same thing in RPI4 case or FPGA boards.
So perhaps the only remaining issue is with qemu on ARM / Risc-V?
Regards, Simon
Hi François,
On Wed, 15 Sept 2021 at 04:26, François Ozog francois.ozog@linaro.org wrote:
Le mer. 15 sept. 2021 à 12:13, Simon Glass sjg@chromium.org a écrit :
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Moiz Imtiaz moizimtiaz1@gmail.com Date: Sat, 11 Sep 2021 23:19:05 +0500
Hi Simon,
Thanks for the reply. I already followed the steps mentioned in "doc/uImage.FIT/beaglebone_vboot.txt".
I wonder if rpi is not using the devicetree compiled with U-Boot, but
instead one provided by the earlier-stage firmware?
Not sure, but seems like this is the case. I checked and there isn't any dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to add the dtb and other dts dtsi https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcomfiles from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and it would just give a blank screen*. I wonder why there isn't any device tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by RPI4?
The issue with the rpi4 is that the addresses of devices move around based on the version of the Raspberry Pi firmware you're using. And possibly on the amount of memory on the board as well. So U-Boot pretty much has to use the device tree passed by the firmware since the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think the idea of having all U-Boot configuration information in a single device tree with the hardware description doesn't work everywhere.
From my reading of this thread, it rather reinforces the need to provide a way to give U-Boot the config it needs, in the devicetree.
It seems that rpi is actually OK in this regard. If you think about it, it would be pretty hopeless if first-stage firmware assumed that it could provide a devicetree to whatever is next. For example, if U-Boot evolves to support more devices, they could not be supported. If UEFI is used, the devicetree would have no effect, since it doesn't support devicetree.
Please use EDK2 when you refer to it and not by the interface it implements. And even if we read “If EDK2 is used” this is false as Socionext has a platform that can select ACPI or DT for its EDK2 implementation.
OK I will try to remember to use 'EDK2' to describe a UEFI implementation. Since all the other UEFI implementations are closed-source(?) I suppose it is the only one that is relevant here. Not that EDK2 actually supports very many boards, so far as I can tell from the source tree.
I recall people complaining about libfdt being needed in EDK2 (I assume, perhaps it was some other UEFI?) Are you saying that EDK2 can use devicetree for its configuration? If not, thenI think you misunderstood my point.
TF-A has fat less drivers than U-Boot. There is no problem in having a “verified” platform DT stored in BL33_CONFIG part of a FIP, verified by TFa and handed over by U-Boot to OS. That can be the same thing in RPI4 case or FPGA boards.
OK. I think you are saying that we can use TF-A on rpi and have it provide a suitable devicetree for U-Boot. That's fine. However it happens is fine. It just needs to support the features U-Boot supports, not provide a partial devicetree forcing U-Boot to put its config elsewhere.
So perhaps the only remaining issue is with qemu on ARM / Risc-V?
Regards, Simon
HI Simon,
On Fri, 17 Sept 2021 at 18:21, Simon Glass sjg@chromium.org wrote:
Hi François,
On Wed, 15 Sept 2021 at 04:26, François Ozog francois.ozog@linaro.org wrote:
Le mer. 15 sept. 2021 à 12:13, Simon Glass sjg@chromium.org a écrit :
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis mark.kettenis@xs4all.nl
wrote:
From: Moiz Imtiaz moizimtiaz1@gmail.com Date: Sat, 11 Sep 2021 23:19:05 +0500
Hi Simon,
Thanks for the reply. I already followed the steps mentioned in "doc/uImage.FIT/beaglebone_vboot.txt".
I wonder if rpi is not using the devicetree compiled with U-Boot,
but
instead one provided by the earlier-stage firmware?
Not sure, but seems like this is the case. I checked and there
isn't any
dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I
tried to
add the dtb and other dts dtsi <
https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/bro...
files
from the raspberry pi Linux and compile them with
CONFIG_OF_SEPARATE and
CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the
U-Boot and
it would just give a blank screen*. I wonder why there isn't any
device
tree in the U-boot repo for RPI4. Is U-boot control FDT not
supported by
RPI4?
The issue with the rpi4 is that the addresses of devices move around based on the version of the Raspberry Pi firmware you're using. And possibly on the amount of memory on the board as well. So U-Boot pretty much has to use the device tree passed by the firmware since the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think the idea of having all U-Boot configuration information in a single device tree with the hardware description doesn't work everywhere.
From my reading of this thread, it rather reinforces the need to provide a way to give U-Boot the config it needs, in the devicetree.
It seems that rpi is actually OK in this regard. If you think about it, it would be pretty hopeless if first-stage firmware assumed that it could provide a devicetree to whatever is next. For example, if U-Boot evolves to support more devices, they could not be supported. If UEFI is used, the devicetree would have no effect, since it doesn't support devicetree.
Please use EDK2 when you refer to it and not by the interface it
implements. And even if we read “If EDK2 is used” this is false as Socionext has a platform that can select ACPI or DT for its EDK2 implementation.
OK I will try to remember to use 'EDK2' to describe a UEFI implementation. Since all the other UEFI implementations are closed-source(?) I suppose it is the only one that is relevant here. Not that EDK2 actually supports very many boards, so far as I can tell from the source tree.
I recall people complaining about libfdt being needed in EDK2 (I assume, perhaps it was some other UEFI?) Are you saying that EDK2 can use devicetree for its configuration? If not, thenI think you misunderstood my point.
I effectively did misunderstood your point. EDK2 configuration elements come from very different sources. It consumes HOBs from the pre-EFI world, has ACPI parameters, and even private storage. UEFI variables are used to control some functional elements but if you want to talk about PCI bifurcation control for instance it is not in ACPI, not in UEFI: just private structures may be stored in an EEPROM or other element.
TF-A has fat less drivers than U-Boot. There is no problem in having a
“verified” platform DT stored in BL33_CONFIG part of a FIP, verified by TFa and handed over by U-Boot to OS.
That can be the same thing in RPI4 case or FPGA boards.
OK. I think you are saying that we can use TF-A on rpi and have it provide a suitable devicetree for U-Boot. That's fine. However it happens is fine. It just needs to support the features U-Boot supports, not provide a partial devicetree forcing U-Boot to put its config elsewhere.
This is how I implemented LinuxBoot on MacchiatoBin: DT for the platform
in the FIP. For the RPI, I would just consume what has been assembled through config.txt overlays and other adjustments. But again, TFA shall ignore the exact nature of the BL33 (U-Boot, LinuxBoot, Xen...). That said I agree there is a need of a clearer/richer contract at the entry of BL33 (the HOBs/bloblist proposal by Harb is part of this extended contract discussion). The DT that TFA passes to BL33, may list a restricted set of devices because BL33 may not need all devices, or it may contain the same list of devices but with different bindings (I remember ST suggesting a display may need 4 parameters for BL33 while it may be thousands of bytes long for the full OS). This aspect is still open on the DT technical report from Linaro DTE project (Device Tree Evolution). U-Boot has a nice "environment" that can host parameters, it can even include a base64'ified DT. As I said earlier, any program can use DT to store self describing data. U-Boot can be one of them and use the FDT format to store its configuration data. It will not be visible by upstream or downstream firmware component. It is not an overlay of any sort. It feels an elegant way to store program specific configuration data. Let's just not make it a global thing on the platform.
So perhaps the only remaining issue is with qemu on ARM / Risc-V?
Regards, Simon
On Fri, Sep 17, 2021 at 10:21:38AM -0600, Simon Glass wrote:
Hi François,
On Wed, 15 Sept 2021 at 04:26, François Ozog francois.ozog@linaro.org wrote:
Le mer. 15 sept. 2021 à 12:13, Simon Glass sjg@chromium.org a écrit :
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Moiz Imtiaz moizimtiaz1@gmail.com Date: Sat, 11 Sep 2021 23:19:05 +0500
Hi Simon,
Thanks for the reply. I already followed the steps mentioned in "doc/uImage.FIT/beaglebone_vboot.txt".
I wonder if rpi is not using the devicetree compiled with U-Boot, but
instead one provided by the earlier-stage firmware?
Not sure, but seems like this is the case. I checked and there isn't any dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to add the dtb and other dts dtsi https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcomfiles from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and it would just give a blank screen*. I wonder why there isn't any device tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by RPI4?
The issue with the rpi4 is that the addresses of devices move around based on the version of the Raspberry Pi firmware you're using. And possibly on the amount of memory on the board as well. So U-Boot pretty much has to use the device tree passed by the firmware since the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think the idea of having all U-Boot configuration information in a single device tree with the hardware description doesn't work everywhere.
From my reading of this thread, it rather reinforces the need to provide a way to give U-Boot the config it needs, in the devicetree.
It seems that rpi is actually OK in this regard. If you think about it, it would be pretty hopeless if first-stage firmware assumed that it could provide a devicetree to whatever is next. For example, if U-Boot evolves to support more devices, they could not be supported. If UEFI is used, the devicetree would have no effect, since it doesn't support devicetree.
Please use EDK2 when you refer to it and not by the interface it implements. And even if we read “If EDK2 is used” this is false as Socionext has a platform that can select ACPI or DT for its EDK2 implementation.
OK I will try to remember to use 'EDK2' to describe a UEFI implementation. Since all the other UEFI implementations are closed-source(?) I suppose it is the only one that is relevant here.
Just for the record, AMI recently announced they will be supporting aarch64, and yes with ACPI.
From: Simon Glass sjg@chromium.org Date: Wed, 15 Sep 2021 04:13:24 -0600
Hi Simon,
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Moiz Imtiaz moizimtiaz1@gmail.com Date: Sat, 11 Sep 2021 23:19:05 +0500
Hi Simon,
Thanks for the reply. I already followed the steps mentioned in "doc/uImage.FIT/beaglebone_vboot.txt".
I wonder if rpi is not using the devicetree compiled with U-Boot, but
instead one provided by the earlier-stage firmware?
Not sure, but seems like this is the case. I checked and there isn't any dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to add the dtb and other dts dtsi https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcomfiles from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and it would just give a blank screen*. I wonder why there isn't any device tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by RPI4?
The issue with the rpi4 is that the addresses of devices move around based on the version of the Raspberry Pi firmware you're using. And possibly on the amount of memory on the board as well. So U-Boot pretty much has to use the device tree passed by the firmware since the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think the idea of having all U-Boot configuration information in a single device tree with the hardware description doesn't work everywhere.
From my reading of this thread, it rather reinforces the need to
provide a way to give U-Boot the config it needs, in the devicetree.
As long as that configuration is optional, yes, maybe.
It seems that rpi is actually OK in this regard. If you think about it, it would be pretty hopeless if first-stage firmware assumed that it could provide a devicetree to whatever is next.
Not hopeless. If that device tree provides a hardware description that is complete enough to boot Linux, it should be good enough to run U-Boot.
And yes, the Raspberry Pi has a nice way to load overlays to do additional hardware configuration and support add-on hardware that connects to the GPIO header on the Pi. Replicating all this in U-Boot would make very little sense.
For example, if U-Boot evolves to support more devices, they could not be supported.
Unless the device in question has a mechanism to load device tree overlays like the Pi, this would require a firmware update.
In practice, the device tree provided by the firmware will have more stuff than U-Boot will ever need though. Unless you're advocating that U-Boot evolves into a full-fledged OS ;).
If UEFI is used, the devicetree would have no effect, since it doesn't support devicetree.
That is not true. UEFI supports device trees just fine. All the arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER support use device trees. The idea that UEFI implies ACPI is a misconception.
So perhaps the only remaining issue is with qemu on ARM / Risc-V?
Maybe somebody can add device tree overlay support to QEMU?
On Wed, Sep 15, 2021 at 01:51:51PM +0200, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 15 Sep 2021 04:13:24 -0600
Hi Simon,
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Moiz Imtiaz moizimtiaz1@gmail.com Date: Sat, 11 Sep 2021 23:19:05 +0500
Hi Simon,
Thanks for the reply. I already followed the steps mentioned in "doc/uImage.FIT/beaglebone_vboot.txt".
I wonder if rpi is not using the devicetree compiled with U-Boot, but
instead one provided by the earlier-stage firmware?
Not sure, but seems like this is the case. I checked and there isn't any dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to add the dtb and other dts dtsi https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcomfiles from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and it would just give a blank screen*. I wonder why there isn't any device tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by RPI4?
The issue with the rpi4 is that the addresses of devices move around based on the version of the Raspberry Pi firmware you're using. And possibly on the amount of memory on the board as well. So U-Boot pretty much has to use the device tree passed by the firmware since the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think the idea of having all U-Boot configuration information in a single device tree with the hardware description doesn't work everywhere.
From my reading of this thread, it rather reinforces the need to
provide a way to give U-Boot the config it needs, in the devicetree.
As long as that configuration is optional, yes, maybe.
Lets be a little careful. We don't want to have two ways to provide the information for a given feature. But some configuration properties are certainly optional.
It seems that rpi is actually OK in this regard. If you think about it, it would be pretty hopeless if first-stage firmware assumed that it could provide a devicetree to whatever is next.
Not hopeless. If that device tree provides a hardware description that is complete enough to boot Linux, it should be good enough to run U-Boot.
And keep in mind that one of those long stated goals is that the device tree for a platform lives physically on the platform and doesn't require being replaced entirely at run-time with a new/different device tree.
And yes, the Raspberry Pi has a nice way to load overlays to do additional hardware configuration and support add-on hardware that connects to the GPIO header on the Pi. Replicating all this in U-Boot would make very little sense.
Note that in U-Boot we do have functionality to figure out and apply DT overlays for a platform, and it's generic enough that platforms can plugin their logic to detect what overlays are appropriate. This is under CMD_EXTENSION. It's not appropriate for Pi as they did all of this in their in-house firmware instead of using U-Boot.
For example, if U-Boot evolves to support more devices, they could not be supported.
Unless the device in question has a mechanism to load device tree overlays like the Pi, this would require a firmware update.
In that CMD_EXTENSION is about updating the tree for the next stage, and not ourself, yes. But this is also the same problem that OSes have that lead to overlays, at least in part. But also why it's so hard to support a static device tree on hardware, and have an evolving kernel. I'm not sure there's many / any good examples of wholly static and also feature complete device trees and OSes today, on a recent / semi-recent piece of hardware.
In practice, the device tree provided by the firmware will have more stuff than U-Boot will ever need though. Unless you're advocating that U-Boot evolves into a full-fledged OS ;).
If UEFI is used, the devicetree would have no effect, since it doesn't support devicetree.
That is not true. UEFI supports device trees just fine. All the arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER support use device trees. The idea that UEFI implies ACPI is a misconception.
So perhaps the only remaining issue is with qemu on ARM / Risc-V?
Maybe somebody can add device tree overlay support to QEMU?
Having gone through this thread, I wonder if U-Boot generating a device tree overlay (and also the keeping the source of it, before preprocessing if we can) isn't part of the solution here. Heinrich had suggested in another thread, and Simon had strongly disagreed with overlays being how we perhaps solve some portions of the overall "what should U-Boot require of the DT?" problem. I'm thinking that might be the right answer, in some cases.
On Wed, 15 Sept 2021 at 15:36, Tom Rini trini@konsulko.com wrote:
On Wed, Sep 15, 2021 at 01:51:51PM +0200, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 15 Sep 2021 04:13:24 -0600
Hi Simon,
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis mark.kettenis@xs4all.nl
wrote:
From: Moiz Imtiaz moizimtiaz1@gmail.com Date: Sat, 11 Sep 2021 23:19:05 +0500
Hi Simon,
Thanks for the reply. I already followed the steps mentioned in "doc/uImage.FIT/beaglebone_vboot.txt".
I wonder if rpi is not using the devicetree compiled with U-Boot,
but
instead one provided by the earlier-stage firmware?
Not sure, but seems like this is the case. I checked and there
isn't any
dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I
tried to
add the dtb and other dts dtsi <
https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/bro...
files
from the raspberry pi Linux and compile them with
CONFIG_OF_SEPARATE and
CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the
U-Boot and
it would just give a blank screen*. I wonder why there isn't any
device
tree in the U-boot repo for RPI4. Is U-boot control FDT not
supported by
RPI4?
The issue with the rpi4 is that the addresses of devices move around based on the version of the Raspberry Pi firmware you're using. And possibly on the amount of memory on the board as well. So U-Boot pretty much has to use the device tree passed by the firmware since the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think the idea of having all U-Boot configuration information in a single device
tree
with the hardware description doesn't work everywhere.
From my reading of this thread, it rather reinforces the need to
provide a way to give U-Boot the config it needs, in the devicetree.
As long as that configuration is optional, yes, maybe.
Lets be a little careful. We don't want to have two ways to provide the information for a given feature. But some configuration properties are certainly optional.
It seems that rpi is actually OK in this regard. If you think about it, it would be pretty hopeless if first-stage firmware assumed that it could provide a devicetree to whatever is next.
Not hopeless. If that device tree provides a hardware description that is complete enough to boot Linux, it should be good enough to run U-Boot.
And keep in mind that one of those long stated goals is that the device tree for a platform lives physically on the platform and doesn't require being replaced entirely at run-time with a new/different device tree.
And yes, the Raspberry Pi has a nice way to load overlays to do additional hardware configuration and support add-on hardware that connects to the GPIO header on the Pi. Replicating all this in U-Boot would make very little sense.
Note that in U-Boot we do have functionality to figure out and apply DT overlays for a platform, and it's generic enough that platforms can plugin their logic to detect what overlays are appropriate. This is under CMD_EXTENSION. It's not appropriate for Pi as they did all of this in their in-house firmware instead of using U-Boot.
For example, if U-Boot evolves to support more devices, they could not be supported.
Unless the device in question has a mechanism to load device tree overlays like the Pi, this would require a firmware update.
In that CMD_EXTENSION is about updating the tree for the next stage, and not ourself, yes. But this is also the same problem that OSes have that lead to overlays, at least in part. But also why it's so hard to support a static device tree on hardware, and have an evolving kernel. I'm not sure there's many / any good examples of wholly static and also feature complete device trees and OSes today, on a recent / semi-recent piece of hardware.
In practice, the device tree provided by the firmware will have more stuff than U-Boot will ever need though. Unless you're advocating that U-Boot evolves into a full-fledged OS ;).
If UEFI is used, the devicetree would have no effect, since it doesn't support devicetree.
That is not true. UEFI supports device trees just fine. All the arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER support use device trees. The idea that UEFI implies ACPI is a misconception.
So perhaps the only remaining issue is with qemu on ARM / Risc-V?
Maybe somebody can add device tree overlay support to QEMU?
Having gone through this thread, I wonder if U-Boot generating a device tree overlay (and also the keeping the source of it, before preprocessing if we can) isn't part of the solution here. Heinrich had suggested in another thread, and Simon had strongly disagreed with overlays being how we perhaps solve some portions of the overall "what should U-Boot require of the DT?" problem. I'm thinking that might be the right answer, in some cases.
+1 U-Boot is best placed to deal with hats, capes among other things.
-- Tom
Hi Tom,
On Wed, 15 Sept 2021 at 07:35, Tom Rini trini@konsulko.com wrote:
On Wed, Sep 15, 2021 at 01:51:51PM +0200, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 15 Sep 2021 04:13:24 -0600
Hi Simon,
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Moiz Imtiaz moizimtiaz1@gmail.com Date: Sat, 11 Sep 2021 23:19:05 +0500
Hi Simon,
Thanks for the reply. I already followed the steps mentioned in "doc/uImage.FIT/beaglebone_vboot.txt".
I wonder if rpi is not using the devicetree compiled with U-Boot, but
instead one provided by the earlier-stage firmware?
Not sure, but seems like this is the case. I checked and there isn't any dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to add the dtb and other dts dtsi https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcomfiles from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and it would just give a blank screen*. I wonder why there isn't any device tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by RPI4?
The issue with the rpi4 is that the addresses of devices move around based on the version of the Raspberry Pi firmware you're using. And possibly on the amount of memory on the board as well. So U-Boot pretty much has to use the device tree passed by the firmware since the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think the idea of having all U-Boot configuration information in a single device tree with the hardware description doesn't work everywhere.
From my reading of this thread, it rather reinforces the need to
provide a way to give U-Boot the config it needs, in the devicetree.
As long as that configuration is optional, yes, maybe.
Lets be a little careful. We don't want to have two ways to provide the information for a given feature. But some configuration properties are certainly optional.
It seems that rpi is actually OK in this regard. If you think about it, it would be pretty hopeless if first-stage firmware assumed that it could provide a devicetree to whatever is next.
Not hopeless. If that device tree provides a hardware description that is complete enough to boot Linux, it should be good enough to run U-Boot.
And keep in mind that one of those long stated goals is that the device tree for a platform lives physically on the platform and doesn't require being replaced entirely at run-time with a new/different device tree.
And yes, the Raspberry Pi has a nice way to load overlays to do additional hardware configuration and support add-on hardware that connects to the GPIO header on the Pi. Replicating all this in U-Boot would make very little sense.
Note that in U-Boot we do have functionality to figure out and apply DT overlays for a platform, and it's generic enough that platforms can plugin their logic to detect what overlays are appropriate. This is under CMD_EXTENSION. It's not appropriate for Pi as they did all of this in their in-house firmware instead of using U-Boot.
For example, if U-Boot evolves to support more devices, they could not be supported.
Unless the device in question has a mechanism to load device tree overlays like the Pi, this would require a firmware update.
In that CMD_EXTENSION is about updating the tree for the next stage, and not ourself, yes. But this is also the same problem that OSes have that lead to overlays, at least in part. But also why it's so hard to support a static device tree on hardware, and have an evolving kernel. I'm not sure there's many / any good examples of wholly static and also feature complete device trees and OSes today, on a recent / semi-recent piece of hardware.
In practice, the device tree provided by the firmware will have more stuff than U-Boot will ever need though. Unless you're advocating that U-Boot evolves into a full-fledged OS ;).
If UEFI is used, the devicetree would have no effect, since it doesn't support devicetree.
That is not true. UEFI supports device trees just fine. All the arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER support use device trees. The idea that UEFI implies ACPI is a misconception.
So perhaps the only remaining issue is with qemu on ARM / Risc-V?
Maybe somebody can add device tree overlay support to QEMU?
Having gone through this thread, I wonder if U-Boot generating a device tree overlay (and also the keeping the source of it, before preprocessing if we can) isn't part of the solution here. Heinrich had suggested in another thread, and Simon had strongly disagreed with overlays being how we perhaps solve some portions of the overall "what should U-Boot require of the DT?" problem. I'm thinking that might be the right answer, in some cases.
Note that my objection here is adding runtime to U-Boot. If the prior stage wants to arrange things that way, it seems OK to me. In particular for QEMU arm, we could add a -dtsi arg to provide a U-Boot tree to merge with what it generates.
Regards, Simon
On Fri, Sep 17, 2021 at 10:21:15AM -0600, Simon Glass wrote:
Hi Tom,
On Wed, 15 Sept 2021 at 07:35, Tom Rini trini@konsulko.com wrote:
On Wed, Sep 15, 2021 at 01:51:51PM +0200, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 15 Sep 2021 04:13:24 -0600
Hi Simon,
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Moiz Imtiaz moizimtiaz1@gmail.com Date: Sat, 11 Sep 2021 23:19:05 +0500
Hi Simon,
Thanks for the reply. I already followed the steps mentioned in "doc/uImage.FIT/beaglebone_vboot.txt".
>I wonder if rpi is not using the devicetree compiled with U-Boot, but instead one provided by the earlier-stage firmware?
Not sure, but seems like this is the case. I checked and there isn't any dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to add the dtb and other dts dtsi https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcomfiles from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and it would just give a blank screen*. I wonder why there isn't any device tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by RPI4?
The issue with the rpi4 is that the addresses of devices move around based on the version of the Raspberry Pi firmware you're using. And possibly on the amount of memory on the board as well. So U-Boot pretty much has to use the device tree passed by the firmware since the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think the idea of having all U-Boot configuration information in a single device tree with the hardware description doesn't work everywhere.
From my reading of this thread, it rather reinforces the need to
provide a way to give U-Boot the config it needs, in the devicetree.
As long as that configuration is optional, yes, maybe.
Lets be a little careful. We don't want to have two ways to provide the information for a given feature. But some configuration properties are certainly optional.
It seems that rpi is actually OK in this regard. If you think about it, it would be pretty hopeless if first-stage firmware assumed that it could provide a devicetree to whatever is next.
Not hopeless. If that device tree provides a hardware description that is complete enough to boot Linux, it should be good enough to run U-Boot.
And keep in mind that one of those long stated goals is that the device tree for a platform lives physically on the platform and doesn't require being replaced entirely at run-time with a new/different device tree.
And yes, the Raspberry Pi has a nice way to load overlays to do additional hardware configuration and support add-on hardware that connects to the GPIO header on the Pi. Replicating all this in U-Boot would make very little sense.
Note that in U-Boot we do have functionality to figure out and apply DT overlays for a platform, and it's generic enough that platforms can plugin their logic to detect what overlays are appropriate. This is under CMD_EXTENSION. It's not appropriate for Pi as they did all of this in their in-house firmware instead of using U-Boot.
For example, if U-Boot evolves to support more devices, they could not be supported.
Unless the device in question has a mechanism to load device tree overlays like the Pi, this would require a firmware update.
In that CMD_EXTENSION is about updating the tree for the next stage, and not ourself, yes. But this is also the same problem that OSes have that lead to overlays, at least in part. But also why it's so hard to support a static device tree on hardware, and have an evolving kernel. I'm not sure there's many / any good examples of wholly static and also feature complete device trees and OSes today, on a recent / semi-recent piece of hardware.
In practice, the device tree provided by the firmware will have more stuff than U-Boot will ever need though. Unless you're advocating that U-Boot evolves into a full-fledged OS ;).
If UEFI is used, the devicetree would have no effect, since it doesn't support devicetree.
That is not true. UEFI supports device trees just fine. All the arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER support use device trees. The idea that UEFI implies ACPI is a misconception.
So perhaps the only remaining issue is with qemu on ARM / Risc-V?
Maybe somebody can add device tree overlay support to QEMU?
Having gone through this thread, I wonder if U-Boot generating a device tree overlay (and also the keeping the source of it, before preprocessing if we can) isn't part of the solution here. Heinrich had suggested in another thread, and Simon had strongly disagreed with overlays being how we perhaps solve some portions of the overall "what should U-Boot require of the DT?" problem. I'm thinking that might be the right answer, in some cases.
Note that my objection here is adding runtime to U-Boot. If the prior stage wants to arrange things that way, it seems OK to me. In particular for QEMU arm, we could add a -dtsi arg to provide a U-Boot tree to merge with what it generates.
Right. I am talking about U-Boot applying an overlay to a provided by prior stage device tree. In the above example of Pi, the prior stage has an option already to apply an overlay before-hand, yes. But that's not going to be the case for all platforms.
Hi Tom,
On Fri, 17 Sept 2021 at 11:42, Tom Rini trini@konsulko.com wrote:
On Fri, Sep 17, 2021 at 10:21:15AM -0600, Simon Glass wrote:
Hi Tom,
On Wed, 15 Sept 2021 at 07:35, Tom Rini trini@konsulko.com wrote:
On Wed, Sep 15, 2021 at 01:51:51PM +0200, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 15 Sep 2021 04:13:24 -0600
Hi Simon,
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis mark.kettenis@xs4all.nl wrote:
> From: Moiz Imtiaz moizimtiaz1@gmail.com > Date: Sat, 11 Sep 2021 23:19:05 +0500 > > Hi Simon, > > Thanks for the reply. I already followed the steps mentioned in > "doc/uImage.FIT/beaglebone_vboot.txt". > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but > instead one provided by the earlier-stage firmware? > > Not sure, but seems like this is the case. I checked and there isn't any > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to > add the dtb and other dts dtsi > https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcomfiles > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and > it would just give a blank screen*. I wonder why there isn't any device > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by > RPI4?
The issue with the rpi4 is that the addresses of devices move around based on the version of the Raspberry Pi firmware you're using. And possibly on the amount of memory on the board as well. So U-Boot pretty much has to use the device tree passed by the firmware since the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think the idea of having all U-Boot configuration information in a single device tree with the hardware description doesn't work everywhere.
From my reading of this thread, it rather reinforces the need to
provide a way to give U-Boot the config it needs, in the devicetree.
As long as that configuration is optional, yes, maybe.
Lets be a little careful. We don't want to have two ways to provide the information for a given feature. But some configuration properties are certainly optional.
It seems that rpi is actually OK in this regard. If you think about it, it would be pretty hopeless if first-stage firmware assumed that it could provide a devicetree to whatever is next.
Not hopeless. If that device tree provides a hardware description that is complete enough to boot Linux, it should be good enough to run U-Boot.
And keep in mind that one of those long stated goals is that the device tree for a platform lives physically on the platform and doesn't require being replaced entirely at run-time with a new/different device tree.
And yes, the Raspberry Pi has a nice way to load overlays to do additional hardware configuration and support add-on hardware that connects to the GPIO header on the Pi. Replicating all this in U-Boot would make very little sense.
Note that in U-Boot we do have functionality to figure out and apply DT overlays for a platform, and it's generic enough that platforms can plugin their logic to detect what overlays are appropriate. This is under CMD_EXTENSION. It's not appropriate for Pi as they did all of this in their in-house firmware instead of using U-Boot.
For example, if U-Boot evolves to support more devices, they could not be supported.
Unless the device in question has a mechanism to load device tree overlays like the Pi, this would require a firmware update.
In that CMD_EXTENSION is about updating the tree for the next stage, and not ourself, yes. But this is also the same problem that OSes have that lead to overlays, at least in part. But also why it's so hard to support a static device tree on hardware, and have an evolving kernel. I'm not sure there's many / any good examples of wholly static and also feature complete device trees and OSes today, on a recent / semi-recent piece of hardware.
In practice, the device tree provided by the firmware will have more stuff than U-Boot will ever need though. Unless you're advocating that U-Boot evolves into a full-fledged OS ;).
If UEFI is used, the devicetree would have no effect, since it doesn't support devicetree.
That is not true. UEFI supports device trees just fine. All the arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER support use device trees. The idea that UEFI implies ACPI is a misconception.
So perhaps the only remaining issue is with qemu on ARM / Risc-V?
Maybe somebody can add device tree overlay support to QEMU?
Having gone through this thread, I wonder if U-Boot generating a device tree overlay (and also the keeping the source of it, before preprocessing if we can) isn't part of the solution here. Heinrich had suggested in another thread, and Simon had strongly disagreed with overlays being how we perhaps solve some portions of the overall "what should U-Boot require of the DT?" problem. I'm thinking that might be the right answer, in some cases.
Note that my objection here is adding runtime to U-Boot. If the prior stage wants to arrange things that way, it seems OK to me. In particular for QEMU arm, we could add a -dtsi arg to provide a U-Boot tree to merge with what it generates.
Right. I am talking about U-Boot applying an overlay to a provided by prior stage device tree. In the above example of Pi, the prior stage has an option already to apply an overlay before-hand, yes. But that's not going to be the case for all platforms.
There is no need for the prior stage to apply an overlay though. It just needs to provide the correct devicetree with the U-Boot properties.
I'm going to send a binding for the config node upstream and see what happens.
Regards, Simon
On Sat, Sep 18, 2021 at 03:27:40AM -0600, Simon Glass wrote:
Hi Tom,
On Fri, 17 Sept 2021 at 11:42, Tom Rini trini@konsulko.com wrote:
On Fri, Sep 17, 2021 at 10:21:15AM -0600, Simon Glass wrote:
Hi Tom,
On Wed, 15 Sept 2021 at 07:35, Tom Rini trini@konsulko.com wrote:
On Wed, Sep 15, 2021 at 01:51:51PM +0200, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 15 Sep 2021 04:13:24 -0600
Hi Simon,
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis mark.kettenis@xs4all.nl wrote: > > > From: Moiz Imtiaz moizimtiaz1@gmail.com > > Date: Sat, 11 Sep 2021 23:19:05 +0500 > > > > Hi Simon, > > > > Thanks for the reply. I already followed the steps mentioned in > > "doc/uImage.FIT/beaglebone_vboot.txt". > > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but > > instead one provided by the earlier-stage firmware? > > > > Not sure, but seems like this is the case. I checked and there isn't any > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to > > add the dtb and other dts dtsi > > https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcomfiles > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and > > it would just give a blank screen*. I wonder why there isn't any device > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by > > RPI4? > > The issue with the rpi4 is that the addresses of devices move around > based on the version of the Raspberry Pi firmware you're using. And > possibly on the amount of memory on the board as well. So U-Boot > pretty much has to use the device tree passed by the firmware since > the device tree in the U-Boot tree would be wrong for many > combinations of firmware and hardware. > > Simon, this sort of thing is exactly the reason why I think the idea > of having all U-Boot configuration information in a single device tree > with the hardware description doesn't work everywhere.
>From my reading of this thread, it rather reinforces the need to provide a way to give U-Boot the config it needs, in the devicetree.
As long as that configuration is optional, yes, maybe.
Lets be a little careful. We don't want to have two ways to provide the information for a given feature. But some configuration properties are certainly optional.
It seems that rpi is actually OK in this regard. If you think about it, it would be pretty hopeless if first-stage firmware assumed that it could provide a devicetree to whatever is next.
Not hopeless. If that device tree provides a hardware description that is complete enough to boot Linux, it should be good enough to run U-Boot.
And keep in mind that one of those long stated goals is that the device tree for a platform lives physically on the platform and doesn't require being replaced entirely at run-time with a new/different device tree.
And yes, the Raspberry Pi has a nice way to load overlays to do additional hardware configuration and support add-on hardware that connects to the GPIO header on the Pi. Replicating all this in U-Boot would make very little sense.
Note that in U-Boot we do have functionality to figure out and apply DT overlays for a platform, and it's generic enough that platforms can plugin their logic to detect what overlays are appropriate. This is under CMD_EXTENSION. It's not appropriate for Pi as they did all of this in their in-house firmware instead of using U-Boot.
For example, if U-Boot evolves to support more devices, they could not be supported.
Unless the device in question has a mechanism to load device tree overlays like the Pi, this would require a firmware update.
In that CMD_EXTENSION is about updating the tree for the next stage, and not ourself, yes. But this is also the same problem that OSes have that lead to overlays, at least in part. But also why it's so hard to support a static device tree on hardware, and have an evolving kernel. I'm not sure there's many / any good examples of wholly static and also feature complete device trees and OSes today, on a recent / semi-recent piece of hardware.
In practice, the device tree provided by the firmware will have more stuff than U-Boot will ever need though. Unless you're advocating that U-Boot evolves into a full-fledged OS ;).
If UEFI is used, the devicetree would have no effect, since it doesn't support devicetree.
That is not true. UEFI supports device trees just fine. All the arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER support use device trees. The idea that UEFI implies ACPI is a misconception.
So perhaps the only remaining issue is with qemu on ARM / Risc-V?
Maybe somebody can add device tree overlay support to QEMU?
Having gone through this thread, I wonder if U-Boot generating a device tree overlay (and also the keeping the source of it, before preprocessing if we can) isn't part of the solution here. Heinrich had suggested in another thread, and Simon had strongly disagreed with overlays being how we perhaps solve some portions of the overall "what should U-Boot require of the DT?" problem. I'm thinking that might be the right answer, in some cases.
Note that my objection here is adding runtime to U-Boot. If the prior stage wants to arrange things that way, it seems OK to me. In particular for QEMU arm, we could add a -dtsi arg to provide a U-Boot tree to merge with what it generates.
Right. I am talking about U-Boot applying an overlay to a provided by prior stage device tree. In the above example of Pi, the prior stage has an option already to apply an overlay before-hand, yes. But that's not going to be the case for all platforms.
There is no need for the prior stage to apply an overlay though. It just needs to provide the correct devicetree with the U-Boot properties.
Well, it depends on what upstream is and how it handles things. The case where U-Boot is optional in the boot chain, like Pi, is perhaps more common than we would like to admit, and at least Pi, and possibly other cases also have a mechanism for applying overlays to the generated device tree, in order to pass it to the kernel (or, U-Boot).
I'd almost say that if for no reason other than to make examples for vboot, and other things too, available on Pi (as nearly everyone has one in/on their desk), it's important to do so. It's the most common reference platform.
I'm going to send a binding for the config node upstream and see what happens.
OK, please make sure to CC me, thanks!
Hi Mark,
On Wed, 15 Sept 2021 at 05:52, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 15 Sep 2021 04:13:24 -0600
Hi Simon,
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Moiz Imtiaz moizimtiaz1@gmail.com Date: Sat, 11 Sep 2021 23:19:05 +0500
Hi Simon,
Thanks for the reply. I already followed the steps mentioned in "doc/uImage.FIT/beaglebone_vboot.txt".
I wonder if rpi is not using the devicetree compiled with U-Boot, but
instead one provided by the earlier-stage firmware?
Not sure, but seems like this is the case. I checked and there isn't any dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to add the dtb and other dts dtsi https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcomfiles from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and it would just give a blank screen*. I wonder why there isn't any device tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by RPI4?
The issue with the rpi4 is that the addresses of devices move around based on the version of the Raspberry Pi firmware you're using. And possibly on the amount of memory on the board as well. So U-Boot pretty much has to use the device tree passed by the firmware since the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think the idea of having all U-Boot configuration information in a single device tree with the hardware description doesn't work everywhere.
From my reading of this thread, it rather reinforces the need to
provide a way to give U-Boot the config it needs, in the devicetree.
As long as that configuration is optional, yes, maybe.
It seems that rpi is actually OK in this regard. If you think about it, it would be pretty hopeless if first-stage firmware assumed that it could provide a devicetree to whatever is next.
Not hopeless. If that device tree provides a hardware description that is complete enough to boot Linux, it should be good enough to run U-Boot.
Not in general. I hope I have covered this in enormous detail in the devicetree patch. But if you don't need verified boot, SPL or some other feature that needs config, then perhaps you will get away with it.
And yes, the Raspberry Pi has a nice way to load overlays to do additional hardware configuration and support add-on hardware that connects to the GPIO header on the Pi. Replicating all this in U-Boot would make very little sense.
Indeed, since AFAIK there is no way to use U-Boot as a first-stage bootloader on rpi.
For example, if U-Boot evolves to support more devices, they could not be supported.
Unless the device in question has a mechanism to load device tree overlays like the Pi, this would require a firmware update.
In practice, the device tree provided by the firmware will have more stuff than U-Boot will ever need though. Unless you're advocating that U-Boot evolves into a full-fledged OS ;).
It is a constant risk.
If UEFI is used, the devicetree would have no effect, since it doesn't support devicetree.
That is not true. UEFI supports device trees just fine. All the arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER support use device trees. The idea that UEFI implies ACPI is a misconception.
François made the same point and I'm pretty sure you are talking about booting a kernel using devicetree. Here, we are talking about setting up the U-Boot control dtb correctly and my point was that UEFI does not use a control dtb, so far as I know.
So perhaps the only remaining issue is with qemu on ARM / Risc-V?
Maybe somebody can add device tree overlay support to QEMU?
Yes. I'm actually willing to do this once we get the UEFI embedded signature reverted. I think it is pretty clear now that it is a dead end.
Regards, Simon
On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
Hi Mark,
On Wed, 15 Sept 2021 at 05:52, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 15 Sep 2021 04:13:24 -0600
Hi Simon,
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Moiz Imtiaz moizimtiaz1@gmail.com Date: Sat, 11 Sep 2021 23:19:05 +0500
Hi Simon,
Thanks for the reply. I already followed the steps mentioned in "doc/uImage.FIT/beaglebone_vboot.txt".
I wonder if rpi is not using the devicetree compiled with U-Boot, but
instead one provided by the earlier-stage firmware?
Not sure, but seems like this is the case. I checked and there isn't any dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to add the dtb and other dts dtsi https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcomfiles from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and it would just give a blank screen*. I wonder why there isn't any device tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by RPI4?
The issue with the rpi4 is that the addresses of devices move around based on the version of the Raspberry Pi firmware you're using. And possibly on the amount of memory on the board as well. So U-Boot pretty much has to use the device tree passed by the firmware since the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think the idea of having all U-Boot configuration information in a single device tree with the hardware description doesn't work everywhere.
From my reading of this thread, it rather reinforces the need to
provide a way to give U-Boot the config it needs, in the devicetree.
As long as that configuration is optional, yes, maybe.
It seems that rpi is actually OK in this regard. If you think about it, it would be pretty hopeless if first-stage firmware assumed that it could provide a devicetree to whatever is next.
Not hopeless. If that device tree provides a hardware description that is complete enough to boot Linux, it should be good enough to run U-Boot.
Not in general. I hope I have covered this in enormous detail in the devicetree patch. But if you don't need verified boot, SPL or some other feature that needs config, then perhaps you will get away with it.
Wait, why does SPL _need_ it? If something provides us with a device tree, we don't need u-boot,dm-spl as that's used to filter nodes in to a smaller DT to use. Dealing with u-boot,dm-pre-reloc could be trickier, but means whatever loaded us needs to have enabled any early clocks we need. But even then, it's just going to be output related? And some "was already configured" path could be used.
Hi Tom,
On Fri, 17 Sept 2021 at 11:26, Tom Rini trini@konsulko.com wrote:
On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
Hi Mark,
On Wed, 15 Sept 2021 at 05:52, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 15 Sep 2021 04:13:24 -0600
Hi Simon,
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Moiz Imtiaz moizimtiaz1@gmail.com Date: Sat, 11 Sep 2021 23:19:05 +0500
Hi Simon,
Thanks for the reply. I already followed the steps mentioned in "doc/uImage.FIT/beaglebone_vboot.txt".
>I wonder if rpi is not using the devicetree compiled with U-Boot, but instead one provided by the earlier-stage firmware?
Not sure, but seems like this is the case. I checked and there isn't any dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to add the dtb and other dts dtsi https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcomfiles from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and it would just give a blank screen*. I wonder why there isn't any device tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by RPI4?
The issue with the rpi4 is that the addresses of devices move around based on the version of the Raspberry Pi firmware you're using. And possibly on the amount of memory on the board as well. So U-Boot pretty much has to use the device tree passed by the firmware since the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think the idea of having all U-Boot configuration information in a single device tree with the hardware description doesn't work everywhere.
From my reading of this thread, it rather reinforces the need to
provide a way to give U-Boot the config it needs, in the devicetree.
As long as that configuration is optional, yes, maybe.
It seems that rpi is actually OK in this regard. If you think about it, it would be pretty hopeless if first-stage firmware assumed that it could provide a devicetree to whatever is next.
Not hopeless. If that device tree provides a hardware description that is complete enough to boot Linux, it should be good enough to run U-Boot.
Not in general. I hope I have covered this in enormous detail in the devicetree patch. But if you don't need verified boot, SPL or some other feature that needs config, then perhaps you will get away with it.
Wait, why does SPL _need_ it? If something provides us with a device tree, we don't need u-boot,dm-spl as that's used to filter nodes in to a smaller DT to use.
Yes, although if the filtering is not done I am not sure what SPL would do. In fact we don't have a way to provide two DTs (SPL, U-Boot proper) from a prior boot stage at present.
Dealing with u-boot,dm-pre-reloc could be trickier, but means whatever loaded us needs to have enabled any early clocks we need. But even then, it's just going to be output related? And some "was already configured" path could be used.
My point is that ignoring U-Boot's devicetree requirements doesn't work in general. It may work in specific cases. It cannot work for verified boot of course.
Regards, Simon
Nice! If you want to write something up extending the >documentation on how you made this work for Pi it would be much appreciated.
Sure, would love to do a PR.
I basically replaced the dtb that pi loads with control Dtb of uboot, but will do a PR of documentation addition in respect to pi_4, detailing everything shortly :)
It does verifies the kernel, and other loadables, except (Dtb) because this is what Pi is giving to Uboot , not sure whether at "starting kernel" stage Uboot passes its own Dtb (verified one) or the one passed by pi (unverified/ can't be verified, as it gets passed to Uboot by pi). So in true sense it's not a complete secure boot. Plus Pi_4 doesn't implement the trustzone that Armv8 provides (Cortex A-72 ) so I am not sure how difficult it would be for someone to change the config.txt(kernel=u-boot.bin) in memory (from attackers perspective), resulting in normal pi bootloader to be loaded rather Uboot on next reboot.
If pi can make the config.txt immutable from memory , have kind of secure world, than it would be great. Not sure, if pi has something as of this in mind in near future implementation either.
On Sat, 18 Sep 2021, 14:28 Simon Glass, sjg@chromium.org wrote:
Hi Tom,
On Fri, 17 Sept 2021 at 11:26, Tom Rini trini@konsulko.com wrote:
On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
Hi Mark,
On Wed, 15 Sept 2021 at 05:52, Mark Kettenis mark.kettenis@xs4all.nl
wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 15 Sep 2021 04:13:24 -0600
Hi Simon,
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <
mark.kettenis@xs4all.nl> wrote:
> From: Moiz Imtiaz moizimtiaz1@gmail.com > Date: Sat, 11 Sep 2021 23:19:05 +0500 > > Hi Simon, > > Thanks for the reply. I already followed the steps mentioned
in
> "doc/uImage.FIT/beaglebone_vboot.txt". > > >I wonder if rpi is not using the devicetree compiled with
U-Boot, but
> instead one provided by the earlier-stage firmware? > > Not sure, but seems like this is the case. I checked and there
isn't any
> dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in
u-boot. I tried to
> add the dtb and other dts dtsi > <
https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/bro...
files
> from the raspberry pi Linux and compile them with
CONFIG_OF_SEPARATE and
> CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the
U-Boot and
> it would just give a blank screen*. I wonder why there isn't
any device
> tree in the U-boot repo for RPI4. Is U-boot control FDT not
supported by
> RPI4?
The issue with the rpi4 is that the addresses of devices move
around
based on the version of the Raspberry Pi firmware you're using.
And
possibly on the amount of memory on the board as well. So U-Boot pretty much has to use the device tree passed by the firmware
since
the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think the
idea
of having all U-Boot configuration information in a single
device tree
with the hardware description doesn't work everywhere.
From my reading of this thread, it rather reinforces the need to
provide a way to give U-Boot the config it needs, in the
devicetree.
As long as that configuration is optional, yes, maybe.
It seems that rpi is actually OK in this regard. If you think about it, it would be pretty hopeless if first-stage firmware assumed
that
it could provide a devicetree to whatever is next.
Not hopeless. If that device tree provides a hardware description that is complete enough to boot Linux, it should be good enough to
run
U-Boot.
Not in general. I hope I have covered this in enormous detail in the devicetree patch. But if you don't need verified boot, SPL or some other feature that needs config, then perhaps you will get away with it.
Wait, why does SPL _need_ it? If something provides us with a device tree, we don't need u-boot,dm-spl as that's used to filter nodes in to a smaller DT to use.
Yes, although if the filtering is not done I am not sure what SPL would do. In fact we don't have a way to provide two DTs (SPL, U-Boot proper) from a prior boot stage at present.
Dealing with u-boot,dm-pre-reloc could be trickier, but means whatever loaded us needs to have enabled any early clocks we need. But even then, it's just going to be output related? And some "was already configured" path could be used.
My point is that ignoring U-Boot's devicetree requirements doesn't work in general. It may work in specific cases. It cannot work for verified boot of course.
Regards, Simon
From: Moiz Imtiaz moizimtiaz1@gmail.com Date: Sat, 18 Sep 2021 14:47:51 +0500
Nice! If you want to write something up extending the >documentation on how you made this work for Pi it would be much appreciated.
Sure, would love to do a PR.
I basically replaced the dtb that pi loads with control Dtb of uboot, but will do a PR of documentation addition in respect to pi_4, detailing everything shortly :)
Sorry, but I don't think this is safe. The Raspberry Pi firmware makes changes to the device tree and it is unclear what requirements it has in terms of names of nodes and compatible strings since the firmware is closed source. It should be fine to add stuff to the DTB that came with the firmware, but replacing it altogether is probably going to break things in subtle ways. So I don't think that is something we should advocate by documenting it in U-Boot.
Creating a DT overlay and specifying it in config.txt should be much more robust than doing a wholesale replacement of the firmware DT.
It does verifies the kernel, and other loadables, except (Dtb) because this is what Pi is giving to Uboot , not sure whether at "starting kernel" stage Uboot passes its own Dtb (verified one) or the one passed by pi (unverified/ can't be verified, as it gets passed to Uboot by pi). So in true sense it's not a complete secure boot. Plus Pi_4 doesn't implement the trustzone that Armv8 provides (Cortex A-72 ) so I am not sure how difficult it would be for someone to change the config.txt(kernel=u-boot.bin) in memory (from attackers perspective), resulting in normal pi bootloader to be loaded rather Uboot on next reboot.
If pi can make the config.txt immutable from memory , have kind of secure world, than it would be great. Not sure, if pi has something as of this in mind in near future implementation either.
On Sat, 18 Sep 2021, 14:28 Simon Glass, sjg@chromium.org wrote:
Hi Tom,
On Fri, 17 Sept 2021 at 11:26, Tom Rini trini@konsulko.com wrote:
On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
Hi Mark,
On Wed, 15 Sept 2021 at 05:52, Mark Kettenis
mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 15 Sep 2021 04:13:24 -0600
Hi Simon,
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis
mark.kettenis@xs4all.nl wrote:
> From: Moiz Imtiaz moizimtiaz1@gmail.com > Date: Sat, 11 Sep 2021 23:19:05 +0500 > > Hi Simon, > > Thanks for the reply. I already followed the steps
mentioned in
> "doc/uImage.FIT/beaglebone_vboot.txt". > > >I wonder if rpi is not using the devicetree compiled with
U-Boot, but
> instead one provided by the earlier-stage firmware? > > Not sure, but seems like this is the case. I checked and
there isn't any
> dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in
u-boot. I tried to
> add the dtb and other dts dtsi >
https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcomfiles
> from the raspberry pi Linux and compile them with
CONFIG_OF_SEPARATE and
> CONFIG_OF_EMBED (one at a time) *but it couldn't even boot
the U-Boot and
> it would just give a blank screen*. I wonder why there isn't
any device
> tree in the U-boot repo for RPI4. Is U-boot control FDT not
supported by
> RPI4?
The issue with the rpi4 is that the addresses of devices move
around
based on the version of the Raspberry Pi firmware you're
using. And
possibly on the amount of memory on the board as well. So
U-Boot
pretty much has to use the device tree passed by the firmware
since
the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think
the idea
of having all U-Boot configuration information in a single
device tree
with the hardware description doesn't work everywhere.
From my reading of this thread, it rather reinforces the need
to
provide a way to give U-Boot the config it needs, in the
devicetree.
As long as that configuration is optional, yes, maybe.
It seems that rpi is actually OK in this regard. If you think
about
it, it would be pretty hopeless if first-stage firmware assumed
that
it could provide a devicetree to whatever is next.
Not hopeless. If that device tree provides a hardware description that is complete enough to boot Linux, it should be good enough to
run
U-Boot.
Not in general. I hope I have covered this in enormous detail in the devicetree patch. But if you don't need verified boot, SPL or some other feature that needs config, then perhaps you will get away with it.
Wait, why does SPL _need_ it? If something provides us with a device tree, we don't need u-boot,dm-spl as that's used to filter nodes in to
a
smaller DT to use.
Yes, although if the filtering is not done I am not sure what SPL would do. In fact we don't have a way to provide two DTs (SPL, U-Boot proper) from a prior boot stage at present.
Dealing with u-boot,dm-pre-reloc could be trickier, but means whatever loaded us needs to have enabled any early clocks we need. But even then, it's just going to be output related? And some "was already configured" path could be used.
My point is that ignoring U-Boot's devicetree requirements doesn't work in general. It may work in specific cases. It cannot work for verified boot of course.
Regards, Simon
Le sam. 18 sept. 2021 à 12:10, Mark Kettenis mark.kettenis@xs4all.nl a écrit :
From: Moiz Imtiaz moizimtiaz1@gmail.com Date: Sat, 18 Sep 2021 14:47:51 +0500
Nice! If you want to write something up extending the >documentation on how you made this work for Pi it would be much appreciated.
Sure, would love to do a PR.
I basically replaced the dtb that pi loads with control Dtb of uboot, but will do a PR of documentation addition in respect to pi_4, detailing everything shortly :)
Sorry, but I don't think this is safe. The Raspberry Pi firmware makes changes to the device tree and it is unclear what requirements it has in terms of names of nodes and compatible strings since the firmware is closed source. It should be fine to add stuff to the DTB that came with the firmware, but replacing it altogether is probably going to break things in subtle ways. So I don't think that is something we should advocate by documenting it in U-Boot.
The way I see the chain of trust is: I don’t know how the GPU firmware is checked (or even if it is checked), The GPU firmware does not check or measure the booted kernel from kernel=xyz that it gets from the unverified config.txt which have been building a hardware description from unverified files from the file system.
Bottom line, trying to create a secure boot flow on RPI4 may lead into impression of security while it is not supported at hardware level. Impression of security can be worse than no security at all.
Creating a DT overlay and specifying it in config.txt should be much
more robust than doing a wholesale replacement of the firmware DT.
It does verifies the kernel, and other loadables, except (Dtb) because
this
is what Pi is giving to Uboot , not sure whether at "starting kernel"
stage
Uboot passes its own Dtb (verified one) or the one passed by pi (unverified/ can't be verified, as it gets passed to Uboot by pi). So in true sense it's not a complete secure boot. Plus Pi_4 doesn't implement
the
trustzone that Armv8 provides (Cortex A-72 ) so I am not sure how
difficult
it would be for someone to change the config.txt(kernel=u-boot.bin) in memory (from attackers perspective), resulting in normal pi bootloader
to be
loaded rather Uboot on next reboot.
If pi can make the config.txt immutable from memory , have kind of secure world, than it would be great. Not sure, if pi has something as of this
in
mind in near future implementation either.
On Sat, 18 Sep 2021, 14:28 Simon Glass, sjg@chromium.org wrote:
Hi Tom,
On Fri, 17 Sept 2021 at 11:26, Tom Rini trini@konsulko.com wrote:
On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
Hi Mark,
On Wed, 15 Sept 2021 at 05:52, Mark Kettenis
mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 15 Sep 2021 04:13:24 -0600
Hi Simon,
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis
mark.kettenis@xs4all.nl wrote:
> > > From: Moiz Imtiaz moizimtiaz1@gmail.com > > Date: Sat, 11 Sep 2021 23:19:05 +0500 > > > > Hi Simon, > > > > Thanks for the reply. I already followed the steps
mentioned in
> > "doc/uImage.FIT/beaglebone_vboot.txt". > > > > >I wonder if rpi is not using the devicetree compiled with
U-Boot, but
> > instead one provided by the earlier-stage firmware? > > > > Not sure, but seems like this is the case. I checked and
there isn't any
> > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in
u-boot. I tried to
> > add the dtb and other dts dtsi > >
<
https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/bro...
files
> > from the raspberry pi Linux and compile them with
CONFIG_OF_SEPARATE and
> > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot
the U-Boot and
> > it would just give a blank screen*. I wonder why there isn't
any device
> > tree in the U-boot repo for RPI4. Is U-boot control FDT not
supported by
> > RPI4? > > The issue with the rpi4 is that the addresses of devices move
around
> based on the version of the Raspberry Pi firmware you're
using. And
> possibly on the amount of memory on the board as well. So
U-Boot
> pretty much has to use the device tree passed by the firmware
since
> the device tree in the U-Boot tree would be wrong for many > combinations of firmware and hardware. > > Simon, this sort of thing is exactly the reason why I think
the idea
> of having all U-Boot configuration information in a single
device tree
> with the hardware description doesn't work everywhere.
>From my reading of this thread, it rather reinforces the need
to
provide a way to give U-Boot the config it needs, in the
devicetree.
As long as that configuration is optional, yes, maybe.
It seems that rpi is actually OK in this regard. If you think
about
it, it would be pretty hopeless if first-stage firmware assumed
that
it could provide a devicetree to whatever is next.
Not hopeless. If that device tree provides a hardware description that is complete enough to boot Linux, it should be good enough to
run
U-Boot.
Not in general. I hope I have covered this in enormous detail in the devicetree patch. But if you don't need verified boot, SPL or some other feature that needs config, then perhaps you will get away with it.
Wait, why does SPL _need_ it? If something provides us with a device tree, we don't need u-boot,dm-spl as that's used to filter nodes in to
a
smaller DT to use.
Yes, although if the filtering is not done I am not sure what SPL would do. In fact we don't have a way to provide two DTs (SPL, U-Boot proper) from a prior boot stage at present.
Dealing with u-boot,dm-pre-reloc could be trickier, but means whatever loaded us needs to have enabled any early clocks we need. But even then, it's just going to be output related? And some "was already configured" path could be used.
My point is that ignoring U-Boot's devicetree requirements doesn't work in general. It may work in specific cases. It cannot work for verified boot of course.
Regards, Simon
Tbh, the reason why I didn't do overlay is that I am not comfortable with it. I still have to learn how to do dtbo, and that is why I didn't add a PR to the documentation. I understand adding a dtbo is more robust and better way.
What I replaced with was a copy of the original device tree that came with the firmware or one can get it from pi's GitHub and using mkimage added the public key to it.
I completely agree that achieving a complete secure boot in pi is not possible and I have mentioned few reasons in the initial thread as well. One reason being that the Root of Trust can't be achieved in its true way. The pi loads from GPU and we get control at 3rd stage of the pi bootloader from where, our U-boot comes, what happens before it, can't be verified because the (bootloader.bin) and (start.elf) are both closed source and PI doesn't offer any HAB either.
Secondly, relying on an unverified config.txt which theoretically speaking can be replaced by an attacker having shell access is not a secure way. as in PI, AFAIK, it's flat memory and there isn't any Arm trustzone or TF-A implemented, so one would be relying completely on an unverified congif.txt file.
Other than that, since there isn't any HAB, or efuses, the physcial attack vector is always there. Anyone with physical access can flash the emmc or sdcard and replace it with their own FIT (having kernel) and Control FDT or just replace the u-boot.bin with their own u-boot.
I guess, pi wanted to reduce the cost and compensated on the security features.
I will try to learn how to create a dtbo, and do a PR to documentation. I ain't an embedded or kernel guru like you guys.
I have a complete security background with primarily appsec :)
But I agree that we should have some documentation because 1. It's a common reference platform 2. At the moment we don't have any public doc on how to achieve signature validation on Pi-4.
I know it won't be a complete secure boot, but will do a PR nonetheless. :)
We can then improve the writeup, with the passage of time,if needs required.
On Sat, 18 Sep 2021, 18:24 Moiz Imtiaz, moizimtiaz1@gmail.com wrote:
Tbh, the reason why I didn't do overlay is that I am not comfortable with it. I still have to learn how to do dtbo, and that is why I didn't add a PR to the documentation. I understand adding a dtbo is more robust and better way.
What I replaced with was a copy of the original device tree that came with the firmware or one can get it from pi's GitHub and using mkimage added the public key to it.
I completely agree that achieving a complete secure boot in pi is not possible and I have mentioned few reasons in the initial thread as well. One reason being that the Root of Trust can't be achieved in its true way. The pi loads from GPU and we get control at 3rd stage of the pi bootloader from where, our U-boot comes, what happens before it, can't be verified because the (bootloader.bin) and (start.elf) are both closed source and PI doesn't offer any HAB either.
Secondly, relying on an unverified config.txt which theoretically speaking can be replaced by an attacker having shell access is not a secure way. as in PI, AFAIK, it's flat memory and there isn't any Arm trustzone or TF-A implemented, so one would be relying completely on an unverified congif.txt file.
Other than that, since there isn't any HAB, or efuses, the physcial attack vector is always there. Anyone with physical access can flash the emmc or sdcard and replace it with their own FIT (having kernel) and Control FDT or just replace the u-boot.bin with their own u-boot.
I guess, pi wanted to reduce the cost and compensated on the security features.
On Sat, Sep 18, 2021 at 12:26:00PM +0200, François Ozog wrote:
Le sam. 18 sept. 2021 à 12:10, Mark Kettenis mark.kettenis@xs4all.nl a écrit :
From: Moiz Imtiaz moizimtiaz1@gmail.com Date: Sat, 18 Sep 2021 14:47:51 +0500
Nice! If you want to write something up extending the >documentation on how you made this work for Pi it would be much appreciated.
Sure, would love to do a PR.
I basically replaced the dtb that pi loads with control Dtb of uboot, but will do a PR of documentation addition in respect to pi_4, detailing everything shortly :)
Sorry, but I don't think this is safe. The Raspberry Pi firmware makes changes to the device tree and it is unclear what requirements it has in terms of names of nodes and compatible strings since the firmware is closed source. It should be fine to add stuff to the DTB that came with the firmware, but replacing it altogether is probably going to break things in subtle ways. So I don't think that is something we should advocate by documenting it in U-Boot.
The way I see the chain of trust is: I don’t know how the GPU firmware is checked (or even if it is checked), The GPU firmware does not check or measure the booted kernel from kernel=xyz that it gets from the unverified config.txt which have been building a hardware description from unverified files from the file system.
Bottom line, trying to create a secure boot flow on RPI4 may lead into impression of security while it is not supported at hardware level. Impression of security can be worse than no security at all.
In general, there's always the questionable value of enabling some level of "secure" boot on platforms where we don't have a root of trust starting from the hardware, nor hardware assist later on. But there is some value in documenting how to enable the commodity (versus SoC-specific) functionality on very common reference platforms. Sometimes even more so even on platforms you can't otherwise potentially lock yourself out of.
From: Simon Glass sjg@chromium.org Date: Sat, 18 Sep 2021 03:27:48 -0600
Hi Tom,
On Fri, 17 Sept 2021 at 11:26, Tom Rini trini@konsulko.com wrote:
On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
Hi Mark,
On Wed, 15 Sept 2021 at 05:52, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 15 Sep 2021 04:13:24 -0600
Hi Simon,
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis mark.kettenis@xs4all.nl wrote:
> From: Moiz Imtiaz moizimtiaz1@gmail.com > Date: Sat, 11 Sep 2021 23:19:05 +0500 > > Hi Simon, > > Thanks for the reply. I already followed the steps mentioned in > "doc/uImage.FIT/beaglebone_vboot.txt". > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but > instead one provided by the earlier-stage firmware? > > Not sure, but seems like this is the case. I checked and there isn't any > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to > add the dtb and other dts dtsi > https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcomfiles > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and > it would just give a blank screen*. I wonder why there isn't any device > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by > RPI4?
The issue with the rpi4 is that the addresses of devices move around based on the version of the Raspberry Pi firmware you're using. And possibly on the amount of memory on the board as well. So U-Boot pretty much has to use the device tree passed by the firmware since the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think the idea of having all U-Boot configuration information in a single device tree with the hardware description doesn't work everywhere.
From my reading of this thread, it rather reinforces the need to
provide a way to give U-Boot the config it needs, in the devicetree.
As long as that configuration is optional, yes, maybe.
It seems that rpi is actually OK in this regard. If you think about it, it would be pretty hopeless if first-stage firmware assumed that it could provide a devicetree to whatever is next.
Not hopeless. If that device tree provides a hardware description that is complete enough to boot Linux, it should be good enough to run U-Boot.
Not in general. I hope I have covered this in enormous detail in the devicetree patch. But if you don't need verified boot, SPL or some other feature that needs config, then perhaps you will get away with it.
Wait, why does SPL _need_ it? If something provides us with a device tree, we don't need u-boot,dm-spl as that's used to filter nodes in to a smaller DT to use.
Yes, although if the filtering is not done I am not sure what SPL would do. In fact we don't have a way to provide two DTs (SPL, U-Boot proper) from a prior boot stage at present.
I still think that if there is some sort of prior stage firmware, there typically is no need for SPL. And if there is, DRAM is probably set up already and there are no space constraints so using the full DT isn't an issue.
Dealing with u-boot,dm-pre-reloc could be trickier, but means whatever loaded us needs to have enabled any early clocks we need. But even then, it's just going to be output related? And some "was already configured" path could be used.
My point is that ignoring U-Boot's devicetree requirements doesn't work in general. It may work in specific cases. It cannot work for verified boot of course.
And this is I think the root of the controversy. IMHO, U-Boot should have no "hard" devicetree requirements other than the requirement that the device tree provides a complete enough description of the hardware using standardized DT bindings.
That doesn't mean you can't have something like a /config node with U-Boot specific options. I'd say that would be a great way for prior stage firmware to control U-Boot behaviour.
But what it does mean is that none of those options can be a "hard" requirement in the sense that in order to have a functioning U-Boot on a platform you absolutely have to have U-Boot specific nodes and/or properties in your DT.
I guess what I'm saying/asking is, why can't we have some sort of middle ground here?
If there is no prior-stage firmware to speak of and U-Boot is entirely responsible for bootstrapping a board (the typical scenario where you need SPL/TPL) I don't see a problem with having a control DT that specifies everything.
If there is prior-stage firmware, and U-Boot proper is the canonical payload for that firmware on a board, adding U-Boot specific stuff to the DT should be no issue. There are some obvious issues here in keeping DT bindings in synch between the prior-stage firmware and U-Boot in that case, so standardizing/upstreaming the U-Boot DT bindings would be helpful in this scenario.
If U-Boot is just one of many choices for the payload having U-Boot specific stuff in the DT may not make sense. In that scenario you'd just get reasonable default behaviour (and potentially no verified boot). But it should be possible to change the default behaviour using the U-Boot environment variables in cases where it makes sense.
I'm not yet sure where my Apple M1 work is going to land on this spectrum. I think doing verified boot here is doable when using u-boot as a payload. Currently the m1n1 bootloader, the DTB and U-Boot are combined into a single Mach-O binary and there is a special procedure that requires username/password verification to "enroll" that binary as a bootable "kernel" for Apple's bootloader. I believe that means that it can't be tampered with without physical access to the machine and providing the password of the "owner" of the machine. So embedding the public key that verifies subsequent stages (e.g. a FIT image or an EFI binary) should work just fine.
Cheers,
Mark
Hi Mark,
On Sat, 18 Sept 2021 at 05:15, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Sat, 18 Sep 2021 03:27:48 -0600
Hi Tom,
On Fri, 17 Sept 2021 at 11:26, Tom Rini trini@konsulko.com wrote:
On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
Hi Mark,
On Wed, 15 Sept 2021 at 05:52, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 15 Sep 2021 04:13:24 -0600
Hi Simon,
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis mark.kettenis@xs4all.nl wrote: > > > From: Moiz Imtiaz moizimtiaz1@gmail.com > > Date: Sat, 11 Sep 2021 23:19:05 +0500 > > > > Hi Simon, > > > > Thanks for the reply. I already followed the steps mentioned in > > "doc/uImage.FIT/beaglebone_vboot.txt". > > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but > > instead one provided by the earlier-stage firmware? > > > > Not sure, but seems like this is the case. I checked and there isn't any > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to > > add the dtb and other dts dtsi > > https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcomfiles > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and > > it would just give a blank screen*. I wonder why there isn't any device > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by > > RPI4? > > The issue with the rpi4 is that the addresses of devices move around > based on the version of the Raspberry Pi firmware you're using. And > possibly on the amount of memory on the board as well. So U-Boot > pretty much has to use the device tree passed by the firmware since > the device tree in the U-Boot tree would be wrong for many > combinations of firmware and hardware. > > Simon, this sort of thing is exactly the reason why I think the idea > of having all U-Boot configuration information in a single device tree > with the hardware description doesn't work everywhere.
>From my reading of this thread, it rather reinforces the need to provide a way to give U-Boot the config it needs, in the devicetree.
As long as that configuration is optional, yes, maybe.
It seems that rpi is actually OK in this regard. If you think about it, it would be pretty hopeless if first-stage firmware assumed that it could provide a devicetree to whatever is next.
Not hopeless. If that device tree provides a hardware description that is complete enough to boot Linux, it should be good enough to run U-Boot.
Not in general. I hope I have covered this in enormous detail in the devicetree patch. But if you don't need verified boot, SPL or some other feature that needs config, then perhaps you will get away with it.
Wait, why does SPL _need_ it? If something provides us with a device tree, we don't need u-boot,dm-spl as that's used to filter nodes in to a smaller DT to use.
Yes, although if the filtering is not done I am not sure what SPL would do. In fact we don't have a way to provide two DTs (SPL, U-Boot proper) from a prior boot stage at present.
I still think that if there is some sort of prior stage firmware, there typically is no need for SPL. And if there is, DRAM is probably set up already and there are no space constraints so using the full DT isn't an issue.
The DT does need to be paired with U-Boot, I think. For example, if the DT adds new devices then the pre-reloc malloc size may need to be increased as well.
For the SPL case, we may have enough memory to init devices, but it may not be configured that way. Typically SPL uses a small RAM size even if it is not initing the SDRAM. SPL does not relocate.
For the non-SPL case we still need to consider pre-reloc, where boot time could be adversely affected by initing devices that are not needed.
So I thnk we should say that if you are using a particular U-Boot version, you should provide U-Boot with the DT from that version too.
Dealing with u-boot,dm-pre-reloc could be trickier, but means whatever loaded us needs to have enabled any early clocks we need. But even then, it's just going to be output related? And some "was already configured" path could be used.
My point is that ignoring U-Boot's devicetree requirements doesn't work in general. It may work in specific cases. It cannot work for verified boot of course.
And this is I think the root of the controversy. IMHO, U-Boot should have no "hard" devicetree requirements other than the requirement that the device tree provides a complete enough description of the hardware using standardized DT bindings.
That doesn't mean you can't have something like a /config node with U-Boot specific options. I'd say that would be a great way for prior stage firmware to control U-Boot behaviour.
But what it does mean is that none of those options can be a "hard" requirement in the sense that in order to have a functioning U-Boot on a platform you absolutely have to have U-Boot specific nodes and/or properties in your DT.
I guess what I'm saying/asking is, why can't we have some sort of middle ground here?
If there is no prior-stage firmware to speak of and U-Boot is entirely responsible for bootstrapping a board (the typical scenario where you need SPL/TPL) I don't see a problem with having a control DT that specifies everything.
If there is prior-stage firmware, and U-Boot proper is the canonical payload for that firmware on a board, adding U-Boot specific stuff to the DT should be no issue. There are some obvious issues here in keeping DT bindings in synch between the prior-stage firmware and U-Boot in that case, so standardizing/upstreaming the U-Boot DT bindings would be helpful in this scenario.
If U-Boot is just one of many choices for the payload having U-Boot specific stuff in the DT may not make sense. In that scenario you'd just get reasonable default behaviour (and potentially no verified boot). But it should be possible to change the default behaviour using the U-Boot environment variables in cases where it makes sense.
I think we are saying the same thing. If you don't need U-Boot features which rely on config, and you have a tail wind, then you should be able to boot with whatever DT there is.
But I don't think we should recommend this. It is a 'fallback' case when (for whatever reason) the U-Boot DT for that board is not provided. You are 'on your own' and things may or may not work, depending on memory requirements, what features are used, etc.
Note that verified boot will actually boot (without verifying) when the U-Boot devicetree is not provided.
I'm not yet sure where my Apple M1 work is going to land on this spectrum. I think doing verified boot here is doable when using u-boot as a payload. Currently the m1n1 bootloader, the DTB and U-Boot are combined into a single Mach-O binary and there is a special procedure that requires username/password verification to "enroll" that binary as a bootable "kernel" for Apple's bootloader. I believe that means that it can't be tampered with without physical access to the machine and providing the password of the "owner" of the machine. So embedding the public key that verifies subsequent stages (e.g. a FIT image or an EFI binary) should work just fine.
Sounds right to me.
Regards, Simon
On Sat, Sep 18, 2021 at 01:15:07PM +0200, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Sat, 18 Sep 2021 03:27:48 -0600
Hi Tom,
On Fri, 17 Sept 2021 at 11:26, Tom Rini trini@konsulko.com wrote:
On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
Hi Mark,
On Wed, 15 Sept 2021 at 05:52, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 15 Sep 2021 04:13:24 -0600
Hi Simon,
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis mark.kettenis@xs4all.nl wrote: > > > From: Moiz Imtiaz moizimtiaz1@gmail.com > > Date: Sat, 11 Sep 2021 23:19:05 +0500 > > > > Hi Simon, > > > > Thanks for the reply. I already followed the steps mentioned in > > "doc/uImage.FIT/beaglebone_vboot.txt". > > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but > > instead one provided by the earlier-stage firmware? > > > > Not sure, but seems like this is the case. I checked and there isn't any > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to > > add the dtb and other dts dtsi > > https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcomfiles > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and > > it would just give a blank screen*. I wonder why there isn't any device > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by > > RPI4? > > The issue with the rpi4 is that the addresses of devices move around > based on the version of the Raspberry Pi firmware you're using. And > possibly on the amount of memory on the board as well. So U-Boot > pretty much has to use the device tree passed by the firmware since > the device tree in the U-Boot tree would be wrong for many > combinations of firmware and hardware. > > Simon, this sort of thing is exactly the reason why I think the idea > of having all U-Boot configuration information in a single device tree > with the hardware description doesn't work everywhere.
>From my reading of this thread, it rather reinforces the need to provide a way to give U-Boot the config it needs, in the devicetree.
As long as that configuration is optional, yes, maybe.
It seems that rpi is actually OK in this regard. If you think about it, it would be pretty hopeless if first-stage firmware assumed that it could provide a devicetree to whatever is next.
Not hopeless. If that device tree provides a hardware description that is complete enough to boot Linux, it should be good enough to run U-Boot.
Not in general. I hope I have covered this in enormous detail in the devicetree patch. But if you don't need verified boot, SPL or some other feature that needs config, then perhaps you will get away with it.
Wait, why does SPL _need_ it? If something provides us with a device tree, we don't need u-boot,dm-spl as that's used to filter nodes in to a smaller DT to use.
Yes, although if the filtering is not done I am not sure what SPL would do. In fact we don't have a way to provide two DTs (SPL, U-Boot proper) from a prior boot stage at present.
I still think that if there is some sort of prior stage firmware, there typically is no need for SPL. And if there is, DRAM is probably set up already and there are no space constraints so using the full DT isn't an issue.
This isn't strictly true. You can look at the TI Keystone 3 platforms where there's both R5 and A72 cores and it's still an intentional software design to use SPL at the A72 stage. I think this is explained in the U-Boot docs, but if not I think it has been on the mailing list, perhaps? But that's just an FYI really.
Dealing with u-boot,dm-pre-reloc could be trickier, but means whatever loaded us needs to have enabled any early clocks we need. But even then, it's just going to be output related? And some "was already configured" path could be used.
My point is that ignoring U-Boot's devicetree requirements doesn't work in general. It may work in specific cases. It cannot work for verified boot of course.
And this is I think the root of the controversy. IMHO, U-Boot should have no "hard" devicetree requirements other than the requirement that the device tree provides a complete enough description of the hardware using standardized DT bindings.
That doesn't mean you can't have something like a /config node with U-Boot specific options. I'd say that would be a great way for prior stage firmware to control U-Boot behaviour.
But what it does mean is that none of those options can be a "hard" requirement in the sense that in order to have a functioning U-Boot on a platform you absolutely have to have U-Boot specific nodes and/or properties in your DT.
I guess what I'm saying/asking is, why can't we have some sort of middle ground here?
If there is no prior-stage firmware to speak of and U-Boot is entirely responsible for bootstrapping a board (the typical scenario where you need SPL/TPL) I don't see a problem with having a control DT that specifies everything.
If there is prior-stage firmware, and U-Boot proper is the canonical payload for that firmware on a board, adding U-Boot specific stuff to the DT should be no issue. There are some obvious issues here in keeping DT bindings in synch between the prior-stage firmware and U-Boot in that case, so standardizing/upstreaming the U-Boot DT bindings would be helpful in this scenario.
If U-Boot is just one of many choices for the payload having U-Boot specific stuff in the DT may not make sense. In that scenario you'd just get reasonable default behaviour (and potentially no verified boot). But it should be possible to change the default behaviour using the U-Boot environment variables in cases where it makes sense.
I concur. And I would just note that everyone using DT is supposed to be using the same bindings, so the in-sync part shouldn't be a big issue.
On Sat, Sep 18, 2021 at 03:27:48AM -0600, Simon Glass wrote:
Hi Tom,
On Fri, 17 Sept 2021 at 11:26, Tom Rini trini@konsulko.com wrote:
On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
Hi Mark,
On Wed, 15 Sept 2021 at 05:52, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Wed, 15 Sep 2021 04:13:24 -0600
Hi Simon,
Hi Mark,
On Sat, 11 Sept 2021 at 13:18, Mark Kettenis mark.kettenis@xs4all.nl wrote:
> From: Moiz Imtiaz moizimtiaz1@gmail.com > Date: Sat, 11 Sep 2021 23:19:05 +0500 > > Hi Simon, > > Thanks for the reply. I already followed the steps mentioned in > "doc/uImage.FIT/beaglebone_vboot.txt". > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but > instead one provided by the earlier-stage firmware? > > Not sure, but seems like this is the case. I checked and there isn't any > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to > add the dtb and other dts dtsi > https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcomfiles > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and > it would just give a blank screen*. I wonder why there isn't any device > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by > RPI4?
The issue with the rpi4 is that the addresses of devices move around based on the version of the Raspberry Pi firmware you're using. And possibly on the amount of memory on the board as well. So U-Boot pretty much has to use the device tree passed by the firmware since the device tree in the U-Boot tree would be wrong for many combinations of firmware and hardware.
Simon, this sort of thing is exactly the reason why I think the idea of having all U-Boot configuration information in a single device tree with the hardware description doesn't work everywhere.
From my reading of this thread, it rather reinforces the need to
provide a way to give U-Boot the config it needs, in the devicetree.
As long as that configuration is optional, yes, maybe.
It seems that rpi is actually OK in this regard. If you think about it, it would be pretty hopeless if first-stage firmware assumed that it could provide a devicetree to whatever is next.
Not hopeless. If that device tree provides a hardware description that is complete enough to boot Linux, it should be good enough to run U-Boot.
Not in general. I hope I have covered this in enormous detail in the devicetree patch. But if you don't need verified boot, SPL or some other feature that needs config, then perhaps you will get away with it.
Wait, why does SPL _need_ it? If something provides us with a device tree, we don't need u-boot,dm-spl as that's used to filter nodes in to a smaller DT to use.
Yes, although if the filtering is not done I am not sure what SPL would do. In fact we don't have a way to provide two DTs (SPL, U-Boot proper) from a prior boot stage at present.
The need to filter the DT down for SPL tends to be because we don't otherwise have enough initialized memory to retrieve / work with / etc the DT. That can't be true if some other stage is handing us something.
Dealing with u-boot,dm-pre-reloc could be trickier, but means whatever loaded us needs to have enabled any early clocks we need. But even then, it's just going to be output related? And some "was already configured" path could be used.
My point is that ignoring U-Boot's devicetree requirements doesn't work in general. It may work in specific cases. It cannot work for verified boot of course.
I'm trying to not belabor the point here, since you've said you'll post some bindings for review, but it's not _our_ device tree. That breaks the whole blasted point of having "a" device tree, rather than everyone having their own device tree. So figuring out a good path forward for verified boot is something that'll require a little more thinking quite possibly and explaining how you do it on something again modern and potentially hardware-assisted.
participants (5)
-
François Ozog -
Mark Kettenis -
Moiz Imtiaz -
Simon Glass -
Tom Rini