The README currently reads:

Create an SD card in MBR mode with a single partition of type 0x0c (FAT32 LBA) or 0x0e (FAT16 LBA). Then format this partition to FAT.

it would be extraordinary helpful to document how this might be done with Linux, Mac, or Windows tools, perhaps in a separate section. E.g. "can I use etcher or dd to do this" is a reasonable request.

Booting UEFI from USB or network still requires an SD card, because the Arasan 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.

The USB controller on Pi 4 can only do DMA to 3GB. ACPI has a way of describing this, but Linux's support for inheriting _DMA descriptor constraints is limited to PCI devices only.

There's a simple patch for 5.5 - https://gist.github.com/andreiw/f2d27fdf5ed18f4af0db95a380dc36af

NetBSD already supports 4GB.

Even though this is just a file on SD, we should aim to have a sample implementation, as SBBR requires capsule. There are constraints given to how the Pi boots, though...

Allow populating the MAC address (overriding the one returned by VPU mailbox) via the BIOS setup screen

When booting via Frontpage (which sets 800x600), Linux will not change resolution and things will look bad on screens that can do better. The principle of least surprise would imply that folks booting Linux with UEFI would not get stuck at 800x600.

One solution is just to disable the virtual resolutions by default. Are there others?

Today this is done elsewhere (too lazy to check, but I think DriverBinding Start()), but ought to be done in the Initialize callback, since that's how the initialize callback is documented.

(RPi4 4GB) trying 1.2 firmware on FreeBSD -CURRENT, xhci doesn't work: reading from 0x600000000 memory results in stuff like:

• "cap length" 0xad
• "xhci version" 0xdead
• "runtime offset" 0xdeaddea0
• "door offset" 0xdeaddeac

What could that be?..

Today Pi 4 UEFI only supports the Arasan SDHCI controller being routed to the SD card. This is the same controller as used on Pi 2/3. It is also present on Pi 4 but usually relegated to SDIO (for WiFi).

We should support MMC2.

This can be done in two approaches.

Approach 1

According to Jared from NetBSD, the Arasan driver should work just fine At least the NetBSD driver does. So, have ConfigDxe set a PCD for the right base depending on which controller is chosen.

Approach 2

According to Jared from NetBSD, the Arasan driver should work just fine At least the NetBSD driver does. So, refactor Arasan to be a driver-model compliant driver, and add another "discovery" driver, which would enable instantiating Arasan twice for both EMMC2 and the Arasan SDHCI.

Approach 3

Leverage the non-enumerated PCI device support and try using the "full" official SDMMC stack (e.g. SdMmcPciHcDxe). Might provide a path for migrating the Arasan support as well (although would involve figuring out how to add the notion of random quirks/hacks to the Intel SDHCI stack)

Local microSD card won't be available in Linux when booting in ACPI mode.

The Arasan driver should be taught how to bind to this device (see https://github.com/tianocore/edk2-platforms/blob/master/Platform/RaspberryPi/AcpiTables/Sdhc.asl#L23)

Device (SDC1)
{
Name (_HID, "BCM2847")
Name (_CID, "ARASAN")
...
}

Currently, the RPI3/4 uses its own private copy of PlatformBootManagerLib. Other Arm systems either use the common copy in ArmPkg or a slightly modified version.

This issue is to track switching from the RPI specific version to the more common version.

NetworkPkg/TlsDxe also didn't build. Samer will have a pull request.

Usually BL31 never is the first stage for TF-A to run, consequently, the expectation is that BL2 will handle the stack setup. That's how the Pi 3 TF-A works..

Pi 4 TFA is a "bare" BL31. I don't see a plat/common/aarch64/platform_mp_stack.S getting linked in, and I don't see a plat_set_my_stack being done by ./bl31/aarch64/bl31_entrypoint.S.

So it is highly likely that:

• the stack pointer is a random value (e.g. 0 or similar)
• the stack pointer is shared by all CPUs

This might explain the following observations:

• All ACS tests relying on PSCI fail
• I've seen CPU lock-ups in Linux relating to EA handling in TF-A. i.e. if I cause a repeatable stream of EAs, and maxcpus > 1, then it will lock up.

Use PCDs and proper enums and defined structs (see Socionext\DeveloperBox\SmbiosPlatformDxe for an example)

• Type 0: SystemBiosMajorRelease, SystemBiosMinorRelease, EmbeddedControllerFirmwareMajorRelease, EmbeddedControllerFirmwareMinorRelease are all required in SBBR 1.2, and Windows depend on them. We need reasonable values
• Type 1: UUID needs to be dynamic (per board, derived form SN and/or other board unique data). Added as an SBBR 1.2 requirement. Today this is derived from SN, but the SN is not unique enough. Should use MAC.
• Type 2: Per SBBR, need pointer to Chassis (Type 3) and location in chassis.
• Type 2 and 3: Per SBBR, need AssetTag populated
• Type 4: Missing ProcessorId for CPU identification
• Type 7: Invalid for Pi 4 (Pi 3 values)
• Type 8: Per SBBR recommendation
• Type 13: Per SBBR recommendation
• Type 16: Wrong values for 2G and 4G Pi 4 SKUs (MaximumCapacity and ExtendedMaximumCapacity)
• Type 17: Wrong values (Size) for 2G and 4G Pi 4 SKUs and strings.
• Type 41: Per SBBR recommendation

Reported by @pbatard on DIscord

Because the PI has no dedicated chip that could be used for NVRAM, the current variables support relies on modifying RPI_EFI.FD in place. This of course only works before UEFI transitions to the OS, because the the SD controller is exposed via ACPI and subsequently owned by the OS.

Several approaches here to evaluate at some point

Approach 1

The easiest would be to add a boot option that would keep the SD controller as entirely owned by firmware (i.e. removed from ACPI and DT). Then, the runtime support for variable services could be modified to work in runtime, but it would be messy (today the support involves the SD controller, MmcDxe, block driver, fs layer and FAT driver).

Approach 2

Support an optional hat/dongle with another device (SD card?) over SPI pins. Since we can't expect this to always exist, the variable services would have to be rewritten to support both the fall back (current approach) or the SPI-attached storage. Also, the backing SPI controller would still need to be hidden from OS at boot.

Oh and of course none of these methods can support secure var storage.

Thanks for your works. It's amazing USB port works fine.
I don't know could i report problem on this "doesn't have main code" project.
If cann't, please forgive.
I try boot windows 10 and windows 10 PE on latest release efi fv.
Got stop code: INTERRUPT EXCEPTION NOT HANDLED.
I enable debug and bootlog in boot options. It not write any debug file to boot storage.
Looks it normally started load drivers. (I patched some unsigned drivers, it can't boot and show crash on load xxx.sys before i am not yet add "testsigning on" boot option).
In previous version of code. Thought cannot use USB on pi4, but It could boot to WIndows 10 PE normally(after boot up, scripts works fun, just cannot control on otg or usb).
Maybe PCI-E support cause some problem?
Can u fix it?

At the server side:

wget http://cdimage.ubuntu.com/releases/20.04/release/ubuntu-20.04-live-server-arm64.iso
python3 -m http.server 8000

At the Pi side, with the v1.12 firmware, configuring HTTP Boot (e.g. http://192.168.1.69:8000/ubuntu-20.04-live-server-arm64.iso), and booting, it randomly fails at different downloading percentages, e.g.:

It's actually supposed to look something like:

Note the Results were saved in your boot media. You may now turn off the system and remove it. message.

Acpiview shows an error indicating RSDT Address needs to be NULL on ARM platforms.

This is consistent with SBBR 1.2 rule (section 4.2.1.1)

 --------------- RSDP Table --------------- 

Address  : 0x33D30014
Length   : 36
  
00000000 : 52 53 44 20 50 54 52 20 - 97 4D 43 52 53 46 54 02   RSD PTR .MCRSFT.
00000010 : 74 00 D2 33 24 00 00 00 - E8 00 D2 33 00 00 00 00   t..3$......3....
00000020 : EF 00 00 00                                         ....

Table Checksum : OK

RSDP                                 :
  Signature                          : RSD PTR 
  Checksum                           : 0x97
  Oem ID                             : MCRSFT
  Revision                           : 2
  RSDT Address                       : 0x33D20074
ERROR: Rsdt Address = 0x33D20074. This must be NULL on ARM Platforms.
  Length                             : 36
  XSDT Address                       : 0x33D200E8
  Extended Checksum                  : 0xEF
  Reserved                           : 0 0 0

Hi,

first of all thank you for your work and support. The UEFI on rpi4 works well, however, I encountered several problems trying to install official debian arm64 os (using https://pete.akeo.ie/2019/07/installing-debian-arm64-on-raspberry-pi.html as template for version for pi4)

The installator boots up normally but doesn't see sd card (no mmcblk entries in /dev), or ethernet / WiFi devices, so installation of system can only be done on pendrive using image from pendrive (because is'nt possible to mount sd card).

Do you have any idea what could cause that behaviour?

Problem: When I boot into Debian buster, on firmware v1.5, in DT mode, USB input devices cease to work. These are USB 2.0 input devices, attached to the USB 2.0 ports.

Repro instructions:

1. Burn this iso (Debian buster arm64 xfce) to a flash drive
2. put the UEFI into DT mode
3. Boot Debian
4. Select "install" at the bootloader
5. notice your input devices no longer work

after the bootloader is loaded the usb stop functioning

Raspberry Pi 4UEFI firmware does not recognize 32-bit boot program, in the boot manager to choose no use, bar config.txt file changed to arm_64bit=0 or delete this line to display a rainbow screen

This a long known issue of the DWC2 driver... seen first in RaspberryPiPkg, then upstream RPi3 and now RPi4.

Not a very important bug, but a bug nonetheless, and there were unconfirmed reports of some USB1 devices (mass storage) and HID (keyboards) not working, which all could be related.

I need to get a USB2 analyzer such as https://shop.lambdaconcept.com/home/35-usb2-sniffer.html and have a look.

The dirty secret was that it wasn't really tested on the Pi 3 either.

Today the time/date is not kept across power state transitions. This is not a bug, because the Pi hardware has no RTC.

There are however Pi Hats with RTCs. It would be interesting to support such a hat (or hats). Of course, it needs to be done in way that doesn't break base Pi support.

There is no need to carry our own GraphicsConsoleDxe. The version from MdeModulePkg seems to work just fine.

Some historical commits of why the override was needed back then:

andreiw/RaspberryPiPkg@2c8f675#diff-8fac8267e1fd36706978d0f7198bf681

andreiw/RaspberryPiPkg@765bfd9

We have a proposed PPTT table now (attached) from Jeremy. It just needs to show up in some future release.
0001-platform-rp4-acpi-Add-PPTT.patch.txt

On the Pi 4, the SoC's internal ROM loads the first external bootloader from SPI, only accessing the SD card for loading recovery.bin if necessary.
It's the SPI boot code that needs to read the SD card, and if that can't read GPT, that's a bug to be reported to the RPF.

Would be nice to show sample TPM implementation on the RPi4. This is not going to be complete or secure, but a PoC, and helps fill in the gap of existing TianoCore code.

This for instance is an example TPM module for RPi4 that could be used:
https://www.infineon.com/dgdl/Infineon-OPTIGA_SLx_9670_TPM_2.0_Pi_4-ApplicationNotes-v07_19-EN.pdf?fileId=5546d4626c1f3dc3016c3d19f43972eb

For ease of testing on RPI3 and RPI4, I host both RPI3_EFI.fd and RPI4_EFI.fd. But there is a problem, the settings are not saved, as they try to write to RPI_EFI. I did a workaround. When assembling rpm in the spec, I change RPI_EFI to RPI3_EFI and RPI4_EFI.

Can you set this to a variable?

I make the changes in three files:
edk2-platforms/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockService.c
edk2-platforms/Platform/RaspberryPi/RPi3/RPi3.fdf
edk2-platforms/Platform/RaspberryPi/RPi4/RPi4.fdf

I use such config.txt:

arm_64bit=1
disable_commandline_tags=2
disable_overscan=1
enable_uart=1
uart_2ndstage=1

[pi3]
armstub=RPI3_EFI.fd

[pi4]
armstub=RPI4_EFI.fd
device_tree_address=0x1f0000
device_tree_end=0x200000
device_tree=bcm2711-rpi-4-b.dtb
dtoverlay=miniuart-bt

[all]

Link to my spec:
http://git.altlinux.org/gears/e/edk2-rpi.git?p=edk2-rpi.git;a=blob;f=edk2-rpi.spec;h=5517e60e2c0a3dc187baa23243b42941d15125ae;hb=e2622bee1c81ea2baa9b4a61d9b84d8d12ad94f6

I didn't check a release build

there's a patch out already https://edk2.groups.io/g/devel/message/55459

Add PhyMode (to populate Genet->PhyMode) and inherit from the VPU-passed FDT

When to walk multilingual support

Also tracked on Pi 3 as pftf/RPi3#11

It looks like the firmware is ack'ing the request for higher clock rates >1500 but not actually changing the clock rate.

I noticed this while running perf stat where perf computes a rough clock frequency from the perf cpu cycles counter. It was claiming the machine was at 1.5Ghz despite the firmware saying it was at 2Ghz. The lmbench mhz utility reported similar clock rates. So, I manually overclocked with arm_freq in the config.txt file matching the uefi setting. Everything behaves as before, but now the perf stat sleep 1 reports the overclocked frequency. It also crashes in random places with the higher clock frequencies without additional voltage as one would expect from an overclocked machine.

This is with the apr 20th 2020 firmware (although I think it was happening with some of the older versions as well).

For Pi 3 this was reserved for TF-A.

On Pi 4 this region is not used by TF-A. We can reclaim it.

// TF-A reserved RAM                                                                                     
  VirtualMemoryTable[Index].PhysicalBase    = ATFBase;                                                     
  VirtualMemoryTable[Index].VirtualBase     = VirtualMemoryTable[Index].PhysicalBase;                      
  VirtualMemoryTable[Index].Length          = FixedPcdGet64 (PcdSystemMemoryBase) - ATFBase;               
  VirtualMemoryTable[Index].Attributes      = ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;                      
  VirtualMemoryInfo[Index].Type             = RPI_MEM_RESERVED_REGION;                                     
  VirtualMemoryInfo[Index++].Name           = L"TF-A RAM";     

This bit of code existed in RaspberryPiPkg as a cute thing to do, to see the Windows logo on explicit launches of the Windows bootloader:

https://github.com/tianocore/edk2-platforms/blob/master/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c#L719

This code doesn't work anyway because of missing upstream BootGraphicsResourceTableDxe patch (https://github.com/andreiw/RaspberryPiPkg/blob/3f5c70c9eb73e3f92ff42b05466f241561251b24/edk2Patches/0003-BootGraphicsResourceTableDxe-properly-handle-SetBoot.patch), so it could just be deleted (or we could spend time on edk2-devel arguing to get the DXE driver patch in). Anyway, for any kind of logo cert the OEM logo must be always shown...

There's no errant behavior seen...but the code is confusing, so I'll mark it as a v1.2 issue but not a bug.

We should pickup the new ASIX USB NIC drivers (currently in this branch) once up-streamed to EDK2:

• Ax88772c (version 2.8.0 replacing Ax88772c ver 1.0)
• Ax88179

In addition, we should look at picking up some of the compatible adapters with different VendorId/ProductID (for example as seen in the Linux ASIX driver)

Hello -

I'm doing something weird and I'm hoping I'm not offending anyone by talking about another project on this issue tracker.

This issue is more of a "Can you confirm this should not work yet?" I believe the trouble is a lack of support for the NIC (GENET) ?

I've been following "pipxe": https://github.com/ipxe/pipxe

Posted on their issue tracker was a lack of support for the RPi4. A dev from this project replied saying the underlying UEFI firmware would need to support the NIC on the newer RPi4:

ipxe/pipxe#2 (comment)

This is what I see with the "image I've created":

  iPXE initialising devices...ok


  iPXE 1.0.0+ (3fe68) - Open Source Network Boot Firmware -- http://ipxe.org
  Features: DNS HTTP iSCSI TFTP AoE EFI Menu

  No more network devices

  iPXE initialising devices...ok


  iPXE 1.0.0+ (3fe68) - Open Source Network Boot Firmware -- http://ipxe.org
  Features: DNS HTTP iSCSI TFTP AoE EFI Menu

  No more network devices

  BdsDxe: No bootable option or device was found.
  BdsDxe: Press any key to enter the Boot Manager Menu.

At this point I do not have any control with a keyboard. I believe at the end there it fell back to the UEFI bootloader?

My steps:

1. Copy the pipxe release here to your bootable FAT partition:
   https://github.com/ipxe/pipxe/releases/download/v20191103/sdcard.zip
2. Unzip the files from this to the same space, ovewriting maybe 5-6 files:
   https://github.com/pftf/RPi4/releases/download/v1.9/RPi4_UEFI_Firmware_v1.9.zip

(I used the default UEFI settings)

Wire up statistics (after driver is upstreamed)

There's still unexplained packet loss...

• Audit memory barrier use (the DSB [ArmDataSynchronizationBarrier] inside CSR write is a hammer approach that should not be necessary and it still doesn't fully help)

• use TBD network stress tool to help with analysis

Today this function does nothing (it is not allowed to fail at least within MnpDxe, so if it fails, there's no networking). We have promisc mode being enabled in Initialize() callback instead, and this needs to be moved into GenetSimpleNetworkReceiveFilters even if we don't bother supporting multicast.

(having promisc always on in a busy network just taxes the L2 stack)

About 20% of the time when powering up the RPi4 it gets stuck indefinitely at either

NOTICE:  BL31: v2.2(release):v2.1-997-gc293471b
NOTICE:  BL31: Built : 17:12:49, Mar  5 2020
UEFI firmware (version UEFI Firmware  built at 03:22:40 on Mar 31 2020)

or shortly after at
ESC (setup), F1 (shell), ENTER (boot)...

Tested with a 2GB RPi 4 and fw 1.5 as well as 1.7. Anybody else seeing this?

One suggestion for the RPi is to implement proper PrePeiCore phase

See as reference usage in the following platforms in edk2-platforms:

• Socionext DeveloperBox
• Arm VExpressPkg
• Arm SgiPkg
• Hisilicon D03 D05, D06
  etc...

Change the limit memory to 3072MB to your own input value or increase the option to limit the limit to 2048MB and 1024MB.
Using translation software, possible translation is incorrect

This includes the following

• BcmGenetDxe
• DisplayDxe
• DwUsbHostDxe

We need to use the proper mechanisim in EDK2 for driver model drivers of non-discoverable devices using gEdkiiNonDiscoverableDeviceProtocolGuid and the helper library NonDiscoverableDeviceRegistrationLib

Explanation summary courtesy of @ardbiesheuvel :

The idea is to install gEdkiiNonDiscoverableDeviceProtocolGuid instances in platform DXE driver that does not have any knowledge about the driver hardware itself, other than the resources needed for the platform (such as the MMIO base address of the IP block, and other device specific properties that are needed like PHY address). This installation should happen in an event notification callback that is registered for EndOfDxe. This ensures that the protocols are installed at the right time, but not any earlier.

Then the actual device driver that implements the UEFI Driver Model checks in its Supported() for existence of gEdkiiNonDiscoverableDeviceProtocolGuid on the input handle, and if so, checks the GUID to match the supported devices.

See for example implementations in

• Socionext NetsecDxe driver code , and platform code

• Socionext SynQuacerI2cDxe (driver code and platform code)

• NXP I2cDxe (driver code and platform code)

• DesignWare DwEmacSnpDxe (driver code , no sample platform code)

From Samer's feedback doc:

In addition to ACPI code refactoring/sharing that Pete is working on, we should refactor DSC (and FDF?) to have common includes.