pftf / rpi3 Goto Github PK

When I upgraded to v1.24, I got this on serial:

Raspberry Pi Bootcode
Read File: config.txt, 399
Read File: start.elf, 2976448 (bytes)
Read File: fixup.dat, 7270 (bytes)
NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v2.3():v2.3
NOTICE:  BL1: Built : 10:40:46, Apr 21 2020
NOTICE:  rpi3: Detected: Raspberry Pi 3 Model B (1GB, Embest, China) [0x00a22082]
NOTICE:  BL1: Booting BL2
ERROR:   rpi3_sdhost: unknown err, cmd = 0xd
ERROR:   rpi3_sdhost status: 0x10
ERROR:   rpi3_sdhost: unknown err, cmd = 0xd
ERROR:   rpi3_sdhost status: 0x10
ERROR:   rpi3_sdhost: unknown err, cmd = 0xd
ERROR:   rpi3_sdhost status: 0x10
...

The rpi3_sdhost error kept running endlessly and the device is not able to boot. Downgrade to v1.23 immediately fixed it.

Previously I boot from SD card and it's OK, except it's slow. So I decided to boot from a fast USB drive I have.

After I have the USB drive set up, and have the device USB boot mode enabled per this document, the bootloader successfully booted (as I could see the multi-colored screen). But the UEFI boot logo (the black and white raspberry) never showed. Here is what's on the serial output:

Raspberry Pi Bootcode
Read File: config.txt, 399
Read File: start.elf, 2976448 (bytes)
Read File: fixup.dat, 7270 (bytes)
NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v2.3():v2.3
NOTICE:  BL1: Built : 10:40:46, Apr 21 2020
NOTICE:  rpi3: Detected: Raspberry Pi 3 Model B (1GB, Embest, China) [0x00a22082]
NOTICE:  BL1: Booting BL2
ERROR:   rpi3_sdhost: timeout status 0x40
NOTICE:  BL2: v2.3():v2.3
NOTICE:  BL2: Built : 10:40:42, Apr 21 2020
NOTICE:  BL1: Booting BL31
NOTICE:  BL31: v2.3():v2.3
NOTICE:  BL31: Built : 10:40:44, Apr 21 2020
UEFI firmware (version UEFI Firmware v1.24 built at 16:56:19 on May  6 2020)

And there was not more output, no more activity on the HDMI screen. No any further changes if I press keys on keyboard or on serial console.

If I have the bootable SD card plugged in with the USB drive together, I can use the UEFI firmware booted from the SD to load GRUB from USB drive then boot my OS.

When I try to boot Fedora CoreOS with the latest version of the firmware (v1.39) on my Raspberry Pi 3 B, it fails with the message above. Booting the Fedora CoreOS live CD works though.

On the previous version (v1.38) it works, but there I sometimes encounter the rainbow screen issue.

Probably related to pftf/RPi4#235.

When trying to load Linux (e.g. using GRUB) with the 1.15 release of the firmware binaries, you may get the following error:

Loading Linux 4.19.0-8-arm64 ...
Loading initial ramdisk ...
error: out of memory.

Press any key to continue...

This doesn't seem to be an issue with the UEFI firmware itself but with the Raspberry Pi Foundation's start.elf which we download and include in the firmware archive, as using an older version (such as the one found in the v1.14 release archive) solves the issue...

Here's the breakdown:

• 2020.02.20 start.elf (latest version at the time of this post): FAILS
• 2020.02.12 start.elf: FAILS
• 2020.01.22 start.elf: FAILS
• 2020.01.06 start.elf (4.19.93): FAILS
• 2020.01.06 start.elf (4.19.89): WORKS
• 2019.12.11 start.elf: WORKS

And thus [raspberrypi/firmware@dc56225] broke Linux boot.

Hi Pete, I've followed your post (https://pete.akeo.ie/2019/07/installing-debian-arm64-on-raspberry-pi.html) and created the SDcard with Debian10 and Firmware files version 1.17 and to be able to install it over the serial console, the following must be done:

• When GRUB menu opens, hit "e"
• Replace --- quiet by --- console=ttyS0,115200n8
• Hit Ctrl-x to boot

Maybe it's a good addition to the post.

I have tried to run this firmware by passing an argument -bios RPI_EFI.fd to qemu with raspi3b machine, but it has no any output. how should I run it in qemu raspi3b?

Note: I start out with a comparison to FreeBSD use with pftf/RPi4. But this is not a request for pftf/RPi4 changes.

FreeBSD crashes in early kernel activity for Graphical for pftf/RPi4 but is useful with Serial selected (log in, build FreeBSD, etc.). (I use disable-bt .)

Turns out FreeBSD crashes in the same way for pftf/RPi3 (on a RPi3B v1.2) as for Graphical with pftf/RPi4 --but there is no explicit/alternative selection present in pftf/RPi3: implicitly/always Graphical, or so it appears. I expect that, with Serial available to select and save, the result would work like it does for pftf/RPi4 .

Beyond the above:
The crash is such that USB input to the kernel prompt is non-functional and the serial console is not available (no input, output stopped earlier in the sequence when it switched to Graphical). This makes capturing the messages leading to the kernel-backtrace difficult to capture. (I do not claim to know how this fits with pftf/RPI3 vs. the FreeBSD kernel vs. both but it is a difficulty for evidence gathering.) With a sustained serial output stream I'd be able to just record it and then report it on a FreeBSD list.

After following the https://www.raspberrypi.org/forums/viewtopic.php?f=50&t=249449&sid=603ea55543a7804affa4f421ecd32c64 guide, installation goes as planned but reboot fails with Synchronous Exception at 0x17FFFFFA9402E831. Is there something that I've missed that should be done for Debian 11 differently? It's a plain install, without desktop environment. EFI starts up, blinks the GRUB prompt and then the exception happens. Would appreciate any kind of help.

Booting UEFI from USB or network still requires an SD card, because the SDhost driver will loop forever on I/O errors. Unfortunately the Pi Foundation didn't wire up the card detect pin so we have to do something more creative.

It seems the rpi3 may also suffer from the same/similar regression issue mentioned here for the rpi4. I am unable to boot the 5.14 & 5.15 rpi kernels with the current release. I continue to use 1.35 with success.

Symptom for this is no fs0 while dblk seemingly works. "Connect -r" on a DEBUG build will complain about partition end being beyond LastBlock. The LastBlock value is bogus and incorrect for media, meaning that the ECSD data (CMD8) is coming back incorrectly, and it is an SdHost bug (does not affect when Arasan is used).

It doesn't affect CM3 due to sheer luck (the bogus value is large enough), but seen with other eMMC media on Pi 2 / Pi 3 via SD slot.

I've tried ensuring the data FIFO is empty before starting a command. It is. I also don't know how much data is actually available in the FIFO once CMD8 completes, so that's worth checking, although it's a little strange overall. Normal read/write I/O is fine.

on jetson nano :

virt-install
--name pi
--machine raspi3
--cpu arm1176
--memory 1024
--import \ --disk /root/Desktop/zi/Work/Android/Raspy/Debian/2019-09-26-raspbian-buster-lite.img,format=raw,bus=virtio
--network user,model=virtio
--video vga
--graphics spice
--rng device=/dev/urandom,model=virtio
--boot 'uefi=RPI_EFI.fd,dtb=bcm2710-rpi-3-b-plus.dtb,kernel=kernel8.img,kernel_args=root=/dev/vda2 rootwait panic=1 dwc_otg.fiq_fsm_enable=0'
--events on_reboot=destroy

But I get this error :

ERROR internal error: Unexpected enum value 0 for virDomainDeviceAddressType

I have a FreeBSD image on an USB stick. I can setup a VM with UEFI mode enabled and attached the USB as a SATA physical disk to the VM and it boots up just fine. However, With pftf/RPi3B+ burnt to an SD card and attaching the USB with FreeBSD to the raspberry pi 3B+, I am unable to boot FreeBSD.
Is there a recommend procedure to enable to boot? I am assuming my physical drive requires a hybrid MBR and GPT present.
Do I have to create a hybrid 300MB MBR partition, then sudo mkfs.fat -F 16 -n EFI /dev/sdb1 and copy pftf/RPi3B+ firmware in to this partition.
I assume if I'd add loader.efi as EFI/BOOT/bootaa64.efi to the EFI partition and create a freebsd-zfs partition and install to it FreeBSD would boot from that but it doesn't.

I cloned and tried to build it using build_firmware.sh. But I got this error

Processing meta-data .
Architecture(s) = AARCH64
Build target = DEBUG
Toolchain = GCC5

Active Platform = /home/jie/sources/rpi3-firmware/edk2-platforms/Platform/RaspberryPi/RPi3/RPi3.dsc
..

build.py...
/home/jie/sources/rpi3-firmware/edk2/CryptoPkg/Library/OpensslLib/OpensslLib.inf(-1): error 000E: File/directory not found in workspace
openssl/e_os.h is not found in packages path:
/home/jie/sources/rpi3-firmware/edk2
/home/jie/sources/rpi3-firmware/edk2-platforms
/home/jie/sources/rpi3-firmware/edk2-non-osi

• Failed -
  Build end time: 09:33:02, Feb.11 2020
  Build total time: 00:00:03

Using the latest start.elf/fixup.dat breaks the 115200 baudrate setting we apply in the Pi 3 firmware (but curiously not the one from TF-A).

So much from trying to detect what the Pi Foundation binaries may have altered to explain #22...

pftf/RPi4#37

I've just finished installing Debian on my CM3+ eMMC. At first I thought I can't boot this at all but I left it running and eventually found out things work but there some really long delays.

Timing goes like this:

• From initial menu to grub menu: six minutes
• From grub menu to installer start: 12 minutes

After installation, same six minutes to Grub menu. Booting to prompt another 15. System seems to work fine afterwards but these delays make the system pretty much unusable.

Hi,
I sometimes encounter a hang on (re)boot with 1.39 in that at the Press F1 ... Enter screen I get one '.' at the end and it never continues. I left it sit even for 24 hours and nothing anymore. Any way to debug what's going on?

I was unable to find a boot option for PXE over IPv4 or IPv6 for network booting. This is present on the RPi4 images.

I think the title summarizes this issue pretty well.
The usual rpi way of getting gpio to work, doesn't work. Exporting a GPIO gives back an invalid argument error. I did find out that there are two gpio chips as with the usual kernel, but it seems the port numbers are of?

An support for arm32 efi , doesn't boots arm32 efi

I followed the instructions on https://pete.akeo.ie/2019/07/installing-debian-arm64-on-raspberry-pi.html . I first did it for Debian arm64 testing (bullseye). I modified config.txt to use a custom device tree for Raspberry Pi 3 Model B. I placed the dtb file in Linux's /boot directory. It works. Then I tried to do the same for Debian arm64 buster. But it does not work. It still uses the builtin device tree. I tried to place the custom dtb file in the root of FAT partition. It does not either. What could be cause of this issue? Is there a way to get a detailed log for debugging.

Thanks.

Raspberry Pi Bootcode

Read File: config.txt, 161

Read File: start.elf, 2955648 (bytes)

Read File: fixup.dat, 7311 (bytes)

MESS:00:00:00.968554:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:00.972876:0: brfs: File read: 161 bytes
MESS:00:00:01.056792:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:01.061068:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
MESS:00:00:01.884477:0: gpioman: gpioman_get_pin_num: pin DISPLAY_DSI_PORT not defined
MESS:00:00:01.892006:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
MESS:00:00:01.897941:0: *** Restart logging
MESS:00:00:01.901819:0: brfs: File read: 161 bytes
MESS:00:00:01.939160:0: HDMI0: hdmi_pixel_encoding: 162000000
MESS:00:00:01.948512:0: dtb_file 'bcm2710-rpi-3-b.dtb'
MESS:00:00:01.956749:0: brfs: File read: /mfs/sd/bcm2710-rpi-3-b.dtb
MESS:00:00:01.961404:0: Loading 'bcm2710-rpi-3-b.dtb' to 0x1f0000 size 0x6ee8
MESS:00:00:01.981760:0: brfs: File read: 28392 bytes
MESS:00:00:02.051013:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:02.061043:0: brfs: File read: 161 bytes
MESS:00:00:02.064278:0: Failed to open command line file 'cmdline.txt'
MESS:00:00:02.086425:0: gpioman: gpioman_get_pin_num: pin EMMC_ENABLE not defined
MESS:00:00:03.999652:0: brfs: File read: /mfs/sd/RPI_EFI.fd
MESS:00:00:04.003509:0: Loading 'RPI_EFI.fd' to 0x0 size 0x1f0000
MESS:00:00:04.009333:0: No compatible kernel found
MESS:00:00:04.013835:0: Device tree loaded to 0x1f0000 (size 0x7320)
MESS:00:00:04.020943:0: uart: Set PL011 baud rate to 103448.300000 Hz
MESS:00:00:04.027601:0: uart: Baud rate change done...
MESS:00:00:04.031015:0: uart: Baud rateNOTICE: Booting Trusted Firmware
NOTICE: BL1: v2.3():v2.3
NOTICE: BL1: Built : 10:40:46, Apr 21 2020
NOTICE: rpi3: Detected: Raspberry Pi 3 Model B (1GB, Sony, UK) [0x00a02082]
NOTICE: BL1: Booting BL2
ERROR: rpi3_sdhost: unknown err, cmd = 0xd
ERROR: rpi3_sdhost status: 0x10
ERROR: rpi3_sdhost: unknown err, cmd = 0xd
ERROR: rpi3_sdhost status: 0x10
ERROR: rpi3_sdhost: unknown err, cmd = 0xd
ERROR: rpi3_sdhost status: 0x10
ERROR: rpi3_sdhost: unknown err, cmd = 0xd
ERROR: rpi3_sdhost status: 0x10
ERROR: rpi3_sdhost: unknown err, cmd = 0xd
ERROR: rpi3_sdhost status: 0x10
ERROR: rpi3_sdhost: unknown err, cmd = 0xd
ERROR: rpi3_sdhost status: 0x10
ERROR: rpi3_sdhost: unknown err, cmd = 0xd
ERROR: rpi3_sdhost status: 0x10
ERROR: rpi3_sdhost: unknown err, cmd = 0xd
ERROR: rpi3_sdhost status: 0x10
ERROR: rpi3_sdhost: unknown err, cmd = 0xd
ERROR: rpi3_sdhost status: 0x10
ERROR: rpi3_sdhost: unknown err, cmd = 0xd
ERROR: rpi3_sdhost status: 0x10
ERROR: rpi3_sdhost: unknown err, cmd = 0xd
ERROR: rpi3_sdhost status: 0x10
ERROR: rpi3_sdhost: unknown err, cmd = 0xd

how to reslove this error?

No longer boots (rainbow screen). Will have to analyze.

Thanks for your work here and the excellent blog post https://pete.akeo.ie/2019/07/installing-debian-arm64-on-raspberry-pi.html
I've successfullly installed vanilla debian 10 following your instructions (using your latest release here) with ethernet but I cannot make wifi work at install time nor when it is installed. The wlan0 device is there, wpa_supplicant configured, etc. but I cannot see any error log, it just doesn't connect.
I'm not sure if there is something missing wrt countries, channels, etc. Do you happen to have a successfull installation using wifi?
Thanks!

1. Installed UEFI on an sdcard
2. Flashed a fedora coreos (arm64) image to a usb drive
3. As per the readme, manually edited the cmdline in grub and added acpi=off (for some reason the uefi settings refused to save that option 🤷).
4. Press f10 to boot
5. I get exactly the following output:

Booting a command list

EFI stub: Decompressing Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services...

6. The usb continues flashing (i.e. either something is writing to it or something is reading from it), but nothing further happens. I let it sit for at least 10 minutes, but still nothing.

I've set up a SD card with the UEFI firmware v1.22 this evening and my Raspi 3 boots just fine into Grub. I can however not make any choices as my USB keyboard is not working/ not detected. I've rebooted multiple times to check all four USB ports with no success.

Hey folks,

Based on this comment I understand that the EFI firmware environment does support some degree of TFTP.

However when testing this boot asset set from a TFTP root I see that it gets wedged after RPI_EFI.fd loads from the TFTP server. The Pi's firmware and its FS abstraction layer happily pull down all the assets to boot into the EFI environment and I'm able to use the menu etc. but the EFI environment doesn't re-DHCP to get the TFTP root and doesn't seem to honor the firmware's previously configured TFTP root so the /efi/boot/bootaa64.efi on the TFTP server doesn't get picked up.

This produces a BdsDxe: No bootable option or device was found. error and the system boots through to the EFI console which shows only the console and a local SD card as bootable options.

The same exact TFTP /boot tree if appropriately applied to an SD card works a treat and happily chainloads the /boot/efi/boot/bootaa64.efi.

FS tree -

.
|-- RPI_EFI.fd
|-- Readme.md
|-- bcm2710-rpi-3-b-plus.dtb
|-- bcm2710-rpi-3-b.dtb
|-- bootcode.bin
|-- config.txt
|-- efi
|   `-- boot
|       `-- bootaa64.efi
|-- firmware
|   |-- LICENCE_bin+clm_blob.txt
|   |-- LICENSE_txt.txt
|   |-- Readme.txt
|   |-- brcmfmac43430-sdio.bin
|   |-- brcmfmac43430-sdio.clm_blob
|   |-- brcmfmac43430-sdio.txt
|   |-- brcmfmac43455-sdio.bin
|   |-- brcmfmac43455-sdio.clm_blob
|   `-- brcmfmac43455-sdio.txt
|-- fixup.dat
`-- start.elf

Should fetching bootaa64.efi from a TFTP root be working? Or am I off the reservation here.

I recently upgraded the UEFI firmware on my Pi 3 B+, by clearing my microSD and unpacking your release archive onto it. (Until now, I was successfully using a version from before it was merged into the tianocore repositories.) When booting my current NixOS system, I get:

EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Loaded initrd from command line option
EFI stub: Exiting boot services and installing virtual address map...
EFI stub: ERROR: Unable to construct new device tree.
EFI stub: ERROR: Failed to update FDT and exit boot services

Failed to execute NixOS (\efi\nixos\...-linux-5.8.10-Image.efi): Load Error

When trying to boot a debian live stick, the firmware interface shows up, and then GRUB, but after selecting * Install the boot process stalls and all I get is a stuck cursor in the top left of the screen.

I'm guessing this has something to do with device trees? In the debian stick's GRUB command-line, typing devicetree yields nothing.

As far as I know, the Raspberry PI Zero 2 has the same SoC as the 3 lineup. I tried to use the current version of the firmware on my Ζero 2 W. It boots to the setup/efi shell but can't read the SD card. Is this something that can be easily fixed?
Thanks

The SoC is BCM2710A1 as far as I know

Selecting this does nothing

Boot from file finds no partition

Edit:
EFI boot works perfectly fine with a usb stick so it seems to be an sdcard problem

I am quite confused. If I create an empty overlays directory, the boot stops with the rainbow. If I then copy in just the README file, it boots. If I add *.dtbo files to the overlays directory, boot hangs again.

I notice an overlays directory is not provided, as with the rpi4 package. Is the use of overlays not supported with the rpi3? Hard to believe I am the first ask about this, my google-foo has come up empty.

Will this work with the Raspberry PI 4? Any need or plan to create a RPi4 release?

i'm attempting to get an rpi3 running with rocky v9. i managed to download the minimal iso and burn it to a usb attached sata disk. i also downloaded the uefi firmware v1.39 and flashed that to the sd card. i'm able to get to the uefi bios screens, but when i try to boot the usb sata disk, it stops immediately with the sychronus exception 333ae89c

does anyone know what specifically might have gone wrong or the best method for troubleshooting it?

Thanks for an awesomely useful project to give the Pi a standards compliant boot loader.

I have UEFI booting via DHCP+TFTP without a local storage device on the Pi. This works great, but I would like to, from there, TFTP download and boot the dtb/kernel/inirtd. This leads me to two issues:

1. There appears to be no TFTP command in the shell. Is there a way to gain that?

2. Once I can get past 1), I still have the issue of instructing the TFTP booted Tianocore to "do stuff", either
   2.1) via the configuration menu which has no local storage to save the NVRAM to (does it?)
   2.2) via sending a custom startup.nsh via TFTP

How do I go about pushing out a custom startup.nsh script that makes use of TFTP (or httpboot) to fetch and boot a dtb/kernel/initrd?

Just installed RPi3_UEFI_Firmware_v1.32.zip to a SD card and attempted to boot NetBSD. I was told that the ACPI support for the RPI3 doesn't use the standard ARM interrupt controller, so needs to be disabled (the kernel panics when booting in ACPI mode). Problematically, the NetBSD bootloader still detects ACPI when devicetree-only mode is selected through EDK2's device configuration, which leads to it attempting ACPI booting anyway and immediately panicking.

The operating system shouldn't be able to detect the presence of ACPI when EDK2 is set to use only devicetrees, right?

If you try something like:

device_tree_address=0x10000
device_tree_end=0x20000
device_tree=bcm2710-rpi-3-b-plus.dtb

with the latest firmware, you will find that the external device tree provided is not being used.

This is due to changes in current versions of start.elf, as reported in raspberrypi/documentation#1424 and will be fixed once we apply changes similar to the ones done in pftf/RPi4#17 for the Pi 3.

Or you can try to revert to older versions of fixup.dat + start.elf.

I compiled it from scratch as DEBUG version, and I prepared RPI_EFI.fd and other dependencies on a FAT32 partiton of USB-HDD. When I plugged it onto USB port and powered it on, it just gave me a screen which says "Graphics Console Started", and it does not response any keyboard input. What's the issue and how to solve it?

when is load debug version，got an error：
Loading driver at 0x00036ECA000 EntryPoint=0x00036ED1D48 tftpDynamicCommand.efi
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 35BC1918
InstallProtocolInterface: 6A1EE763-D47A-43B4-AABE-EF1DE2AB56FC 36ED6070
ProtectUefiImageCommon - 0x35BC13C0

• 0x0000000036ECA000 - 0x000000000000F000
  SetUefiImageMemoryAttributes - 0x0000000036ECA000 - 0x0000000000001000 (0x0000000000004008)
  SetUefiImageMemoryAttributes - 0x0000000036ECB000 - 0x000000000000A000 (0x0000000000020008)
  SetUefiImageMemoryAttributes - 0x0000000036ED5000 - 0x0000000000004000 (0x0000000000004008)
  Status: 0x0000000E

ASSERT_EFI_ERROR (Status = Not Found)
/TftpDynamicCommand/TftpDynamicCommand/DEBUG/AutoGen.c(520): !EFI_ERROR (Status)

How to fix this？thank u

This is an interesting one since the image boots on the 64-bit Pi 2 but hangs on Pi 3/3B+/3A+.

I did not check serial.