Open RossPorter506 opened 1 year ago
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: @.***>
I'll try some other methods myself! If you come across a solution, could you please let me know? Thanks!
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:
setenv fdtdevice mmc 0:1
setenv fdtfile bcm2710-rpi-3-b-plus.dtb
setenv loadaddr 0x01000000
load ${fdtdevice} ${loadaddr} ${fdtfile}
fdt addr ${loadaddr}
boot
I used 0x01000000 as it's the device_tree_address found in /boot/config.txt
, so I'm presuming it should be here. Is this correct?
Anyway, after (re)loading the FDT to 0x01000000 and booting it then proceeds through the Linux kernel scroll and ends on a login screen. Logging in and running xtest
results in all tests passing:
27040 subtests of which 0 failed
104 test cases of which 0 failed
0 test cases were skipped
TEE test application done!
If I try to point u-boot to 0x01000000 using fdt addr 0x01000000
before (re)loading the FDT I get libfdt fdt_check_header(): FDT_ERR_BADMAGIC
, so perhaps the FDT address has changed? How can I check?
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 build/rpi3/firmware/uboot.env.txt
make the following modifications:
# 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 /.repo/manifests/rpi3.xml
file? I'm running into the exact same problem with the same rpi 3B+ board (same revision and model number). Also are the changes to the uboot.env.txt
file and the manifest file implemented before or after running make?
@RossPorter506 did you change the revision in the
/.repo/manifests/rpi3.xml
file?
Yes.
Are the changes to the
uboot.env.txt
file and the manifest file implemented before or after running make?
Before. To clarify, first update the RPi firmware version in the .repo/manifests/rpi3.xml
file from 1.20190401
to 1.20230405
, then do a repo sync -m rpi3.xml -j4 --no-clone-bundle
to pull the new firmware. Modify uboot.env.txt
as above, and then run make as usual.
Thank you for your sharing. 🥲
Locate the string 1.20190401
and change it to 1.20230405
repo sync -m rpi3.xml -j4 --no-clone-bundle
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/
@Chae0510 I don't think it's related to this issue, but I have encountered it before.
Silly question, but is there actually a rpi-sdcard.img
file at that filepath? If not, then it sounds like the build failed. If you use parallel compilation (by using make -j `nproc`
rather than make
) sometimes build errors can be hidden by the other compilation threads. Build it with only one thread (if you aren't already) and double check.
Any help on this ? i am also stuck at same point
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. I also encountered a related issue and happened to solve it, so I’ve organized the solution in a Notion link below. The post is written in Korean, but I believe you can understand it using a web page translator. (https://bead-bassoon-d51.notion.site/raspberry-Pi3-B-OP-TEE-ae055579747247138e5ac4d47ec91ae6)
To give a brief overview:
1. Use Buildroot to create a booting SD card for the Raspberry Pi 3B+ and extract the start.elf file.
2. Use sudo dd in OP-TEE to make an SD card, remove the existing start.elf file, and copy the start.elf file created with Buildroot onto the SD card.
3. Insert the SD card into the Raspberry Pi 3B+ board and attempt to boot.
4. This will take you to manual U-boot booting; entering the U-boot commands listed in Notion in sequence will successfully boot the system.
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: jjsshh3116@gmail.com
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.