OP-TEE developer build v3.22.0 fails to boot on new RPi 3B+ board #6284
Comments
|
I have also encountered the same issue and have not yet been able to resolve it. |
|
Thanks for bring this to my attention. I do have an older RPi3B+ myself, which I use when we're making the OP-TEE releases. I cannot say why it doesn't boot when bumping the firmware. Perhaps there is a need to use another DT blob or alternative perhaps some addresses etc might have changed. Unfortunately I don't know if and when I'd have time to look into this. |
|
Thank you for responding. I was curious if you had managed to resolve it,
but it seems like there's still a roadblock. 😔 I'll try some other methods
myself! If you come across a solution, could you please let me know? Thanks!
… Message ID: ***@***.***>
|
Absolutely, I'll respond to this issue/thread. I'll mark this as a "bug" which will force the issue to stay open. |
|
I've managed to get the system booting with some manual intervention. Autoboot still fails, but when you are kicked back to the u-boot command prompt you can manually load the device tree file that's in the boot partition, and then try booting again like so: I used 0x01000000 as it's the device_tree_address found in If I try to point u-boot to 0x01000000 using |
|
I'm still not sure about a root cause, but a band-aid fix is to integrate the above commands into u-boot's autoboot process. In # bootcmd & bootargs configuration
preboot=usb start
bootcmd=run mmcboot
load_kernel=fatload mmc 0:1 ${kernel_addr_r} kernel8.img
+ load_fdt=fatload mmc 0:1 ${fdt_addr_r} bcm2710-rpi-3-b-plus.dtb
- mmcboot=run load_kernel; run set_bootargs_tty set_bootargs_mmc set_common_args; run boot_it
- nfsboot=run load_kernel; run set_bootargs_tty set_bootargs_nfs set_common_args; run boot_it
+ mmcboot=run load_fdt; run load_kernel; run set_bootargs_tty set_bootargs_mmc set_common_args; run boot_it
+ nfsboot=run load_fdt; run load_kernel; run set_bootargs_tty set_bootargs_nfs set_common_args; run boot_it |
|
@RossPorter506 did you change the revision in the |
Yes.
Before. To clarify, first update the RPi firmware version in the |
|
Thank you for your sharing. 🥲
3.. Edit the uboot.env.txt File After going through this process, typing make img-help instructs to enter sudo dd if=/path/to/../out/rpi-sdcard.img of=/dev/ bs=1024k conv=fsync status=progress, but entering this results in /out/rpi-sdcard.img: No such file or directory being displayed. I'm curious if you also encounter this error? |
|
@Chae0510 I don't think it's related to this issue, but I have encountered it before. |
|
Any help on this ? i am also stuck at same point |
Hello! My name is Se-hyun Jung, and I am an undergraduate research assistant working on research related to OP-TEE. To give a brief overview: Please try this out, and if you have any further questions, leave a comment. I will help as much as I can. Sending support for your enthusiasm, Se-hyun Jung. e-mail address: [email protected] |
The OP-TEE developer build fails to boot on my newly purchased RPi 3B+ board. I believe I've traced the issue down to a recent board revision (late 2022) that is incompatible with the old (~2019) raspberry pi firmware used in the OP-TEE build.
I used release v3.22.0 and followed the build instructions from here: https://optee.readthedocs.io/en/latest/building/devices/rpi3.html
The ACT LED flashes 4 times slowly, then 7 times fast. Serial terminal shows no output. As a sanity check I flashed a recent Raspbian release (2023-05-03) which boots fine, however an older Raspbian release (2018-03-13) fails and gives the same LED pattern. I searched around and according to this thread https://forums.raspberrypi.com/viewtopic.php?t=349340 the recent RPi 3B+ rev1.4 board has hardware changes which make it incompatible with older firmware. I ran the following to check my board revision:
The above thread mentions that replacing the start*.elf, fixup*.dat and bootcode.bin files in the boot partition with those from a newer (2021+) Raspbian release makes older Raspbian versions bootable. Unfortunately the OP-TEE developer build does not appear to be quite so easy to fix. Bumping the raspberry pi firmware repo to 1.20230405 in the manifest is enough to get further into the boot process, including actual serial output, but u-boot complains about the lack of a valid device tree (see below).
I'm not sure where to go from here. Any advice would be appreciated.
The text was updated successfully, but these errors were encountered: