Support for the Raspberry Pi 4

[Googulator]

Today, the Raspberry Pi 4 was unexpectedly released. The new Pi is a lot more powerful, and it would be great to see it receive UEFI firmware.

[pbatard]

😄

I was wondering how long it would take from the official RPi4 announcement for someone to start asking for an UEFI firmware here...

For all the people who might feel like asking, I have no doubt that, given the expected interest, in time, we should see an UEFI firmware for the Pi4 just like we've seen one for the Pi3.

As to an estimate of how soon this might happen, which I guess is the one thing people coming to this thread will be really interested in, the answer is that it will depend greatly on how much work will be required to be spent on producing the various drivers that are going to be needed for UEFI boot, as we can expect quite a few of them to be different from their Pi3 counterpart (i.e. it won't be a matter of "Just pick the Pi3 drivers, add a few lines of code here and there, and it'll work").

To get an idea of all the drivers we'll need, you can take a look at the ones we have on the Pi3.

Especially the USB 2.0/USB 3.0 host is likely to require extensive work, and, most realistically, require either brand new code or porting code that was never designed with UEFI usage in mind, so it'll probably take months at best and, if we're unlucky (i.e. don't have someone willing to invest the large amount of time that's required to perform such a task, or can't easily leverage the resources that would help with that task), possibly a year or more...

And we're not even talking about using that firmware to run Windows, as we'll need ACPI tables for that, and the ones we got from the Pi3 were obtained from Microsoft, so we'll probably need to obtain something similar from Microsoft for the Pi4, which is entirely dependent on Microsoft's willingness and interest to do so.

All in all, though I don't speak with authority here, I'd say that, if you expect to see a usable UEFI firmware within a couple of months of the RPi4 release, you're probably going to be very disappointed. But eventually, since there is of course a lot of interest to see that happening, we should get there.

Now, if I may, could I strongly suggest that any effort to produce an UEFI firmware for the RPi4 actually happens with the EDK2 and not on an unaffiliated repository?

We already have the Pi3 UEFI firmware there, which is really the place it should reside, and the EDK2 people are very eager to help getting popular platforms, such as the Pi4, into their official codebase, so, since I have a vested interest in this, I would very much like to avoid having a bunch of people develop an "unofficial" UEFI firmware on the side, that would then need to be integrated, as an extra step, back into the official UEFI development repository. Even if submitting stuff to the EDK2 obviously adds more constraints than doing it separately on your own, the advantage of doing it that way are:

• You're going to raise the profile of this effort with people who are actually best placed to contribute, and might very well decide to do so to help you out (for instance, it may enable us to reach out to the Microsoft devs who frequent the mailing list to see if they could help us with ACPI)
• You're also going to get some good advice from a lot of experienced folks, on matters that might be crucial in the long run.
• You're going to offset some of the maintenance tasks to people who are pretty much paid to do so.

All of the above could actually help speed up the release of a working Pi4 UEFI firmware. So I can only hope that the Pi4 UEFI firmware effort will happen as part of a formal platform introduction with the EDK2 project.

[Googulator]

The USB host is VIA VL805, which is is xHCI-compliant, so assuming EDK2 has an xHCI-over-PCIE driver already, that should be enough for it.

Bringing up PCIE itself is another matter, though.

[MlgmXyysd]

waiting for rpi4.

[mullcom]

will it not be easier if not using drivers that are already developed by default from Microsoft? after all, this table is better built from scratch. so as ethernet does not go via usb anymore and Now we have usb3. I can't do much about programming but will be able to set up as a test user.

Another thing I thought of is just a place where the people interested in getting started woa on pi4. I guess it can be dump to load both pi3 and pi4 in the same development thread on GitHub. So I want to ask the owner of this thread to create a new one for pi4 so we can start collecting all those interested there.

If the time does not exist, I would like to receive answers about this so someone else can or willing to open such a thread.

[mullcom]

For users in Sweden ..

Still available in shop. https://www.netonnet.se/art/hem-hushall/smarta-hem/raspberrypi/raspberry-pi-4-model-b-4gb/1009084.14591/

[rsedlmeier]

Just got the pi4 delivered. Can report the sd card which is working on pi3+ containing firmware from this source doesnt work. Hope for a new thread ..

[andreiw]

So...generally speaking, getting the upstream TF-A booting is as easy as switching the old UART and INTC base addresses to new ones, fixing up the clock and adding a72 CPU helpers (don't forget about the nasty A72 erratum).

Obviously the TF-A code would need slight reorg. Also, someone added sdhost support to it, and that should be disabled for rpi4, as it cannot be routed to the sdcard at all (see Googulator asking about SD controller wiring here - https://github.com/raspberrypi/documentation/issues/1209).

For UEFI things get more complicated. There's no "shortcut" here per se and I agree with Pete that considering the painful massaging of code to do things right it better be done on the upstream and not somewhere else. So I'll talk about upstream code, not this original version.

Most of the code under Platform/RaspberryPi/RPi3 can now be moved into an RPix or similar "common" platform. Most of the drivers hard code the core base addresses, which come from Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h, and that's going to need to be cleaned up. Probably via PCDs is best.

Some odd choices were made with the Pi 4. I thought that the front USB ports were wired up to the Dwc2 USB, but in fact they're not... the USB Type-C is. So you can't get away from having to write a PCIe RC driver. Apparently the SoC has its own xHCI core as well, but that must have been real good if the final solution ended up with a discrete xHCI controller...

The good news is that video (via DisplayDxe) works just fine. (and I have no idea why the property interface is only reporting 1GB on my 4GB board 👎 )

More good news is that you don't need a GIC driver in UEFI because the legacy INTC is still present.

As Googulator found out in https://github.com/raspberrypi/documentation/issues/1209, we can still reuse the Arasan driver (and avoid having to add EMMC2 support).

Here's my config.txt. This gives you both working miniUART and HDMI:

arm_64bit=1
core_freq=250
enable_uart=1
#I tried both with == 0 and == 1. The legacy intc is not affected.
enable_gic=1
#total_mem=1024

armstub=RPI_EFI.fd
disable_commandline_tags=1
#Pick something that will work with the core_freq=250 required my miniUART
hdmi_group=2
hdmi_mode=85
config_hdmi_boost=11
disable_overscan=1

[pbatard]

Wow, very nice! 😎

I agree that we'll need to sort out some factorization of the common code in edk2-platorms. Judging by what the other platforms do (mostly in Silicon/ but the same should be applicable to Platforms/) we should be able to sort that out by simply moving things the common stuff one level, and then have the model specific thing into that repo so that we have an RPi3/ and RPi4/ sitting at the same level as Drivers/, Include/, Library/ under RaspberryPi/ (instead of just RPi3/ as we have right now).

With regards to ATF, I'm kind of expecting that the Raspberry Pi maintainers there are in the process of sorting out Pi 4 support too, so I'd be tempted to just use a stopgap solution if we have one, and wait until we see a Pi 4 platform appearing there.

[mullcom]

Is there any way to support this in some way. I am not a programmer only IT supporter. So i cam test and report. But maybe us that not contribute in code can send in some Beer donation in some way to you all that can bild this?

send from mobile

Den fre 26 juli 2019 14:55Pete Batard notifications@github.com skrev:

Wow, very nice! 😎

I agree that we'll need to sort out some factorization of the common code in edk2-platorms. Judging by what the other platforms do (mostly in Silicon/ but the same should be applicable to Platforms/) we should be able to sort that out by simply moving things the common stuff one level, and then have the model specific thing into that repo so that we have an RPi3/ and RPi4/ sitting at the same level as Drivers/, Include/, Library/ under RaspberryPi/ (instead of just RPi3/ as we have right now).

With regards to ATF, I'm kind of expecting that the Raspberry Pi maintainers there are in the process of sorting out Pi 4 support too, so I'd be tempted to just use a stopgap solution if we have one, and wait until we see a Pi 4 platform appearing there.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/andreiw/RaspberryPiPkg/issues/130?email_source=notifications&email_token=AIJOPLX6GNWY2Q6PCIYMIKLQBLX3BA5CNFSM4H24LG5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD24PWEQ#issuecomment-515439378, or mute the thread https://github.com/notifications/unsubscribe-auth/AIJOPLQIVPWGKJYQLT5IGULQBLX3BANCNFSM4H24LG5A .

[ShireCiel]

I try to build a uefi for pi4.

1. clone https://github.com/ARM-software/arm-trusted-firmware
2. edit ATF source by using code in "andreiw" first picture
3. build ATF use comand

   export CROSS_COMPILE=aarch64-linux-gnu-
   make -C PLAT=rpi3 PRELOADED_BL33_BASE=0x30000 SUPPORT_VFP=1 DEBUG=0 V=1 fip all

   (found in https://github.com/andreiw/raspberry-pi3-atf with some edit, debug version of fip.bin so big, so i build for release.)

4. git clone code in https://github.com/tianocore/edk2-platforms.
5. copy step 3 two files to edk2-non-osi/Platform/RaspberryPi/RPi3/TrustedFirmware/
6. build uefi use "build -n $NUM_CPUS -a AARCH64 -t GCC5 -p Platform/RaspberryPi/RPi3/RPi3.dsc"
7. copy RPI_EFI.fd to tf card root
8. edit config to "andreiw" posted. (using "bootcode.bin,fixup.dat,start.elf" in rpi4 normal linux system files)

And...It cannot boot like "andreiw" picture 2. The hdmi no output. How can I do for build a bootable uefi for rpi4. @andreiw

[ykla]

Anyone make it?

[andreiw]

Kinda. No official support yet. See the thread for hints.

A

25 авг. 2019 г., в 9:52, FindWaySociety-ykla notifications@github.com написал(а):

Anyone do it?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[ShireCiel]

Kinda. No official support yet. See the thread for hints. A … 25 авг. 2019 г., в 9:52, FindWaySociety-ykla @.***> написал(а): Anyone do it? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

I want try my best to help this project. I am a developer, but never developed low-level project like this(uefi).(but interest in it.) I cannot find any way to debug boot process. What can i do for this project? Is there have a guide for uefi dev or equipment adaptation for uefi?

[ehem]

With regards to ATF, I'm kind of expecting that the Raspberry Pi maintainers there are in the process of sorting out Pi 4 support too, so I'd be tempted to just use a stopgap solution if we have one, and wait until we see a Pi 4 platform appearing there.

I would suggest trying to get this to the attention of the Raspberry PI Foundation ASAP. UEFI is much simpler to deal with than custom firmware setups. Get their attention and perhaps the Raspberry PI 5 will ship with UEFI support (and hopefully other open platforms will see this as a standard of support).

[pbatard]

@ehem, there are a few things to unpack here:

1. I'm not sure that you understand that I was talking about the maintainers of the Raspberry Pi platform for the ARM Trusted Firmware, which is an independent Open Source project, that we rely on in part for the UEFI firmware, but that has no involvement whatsoever (as far as I know) from the Raspberry Pi Foundation. In other words, when you read "Raspberry Pi maintainers" above, it's in no way people that are associated with the Raspberry Pi Foundation.

2. As to the idea that "someone else should get the Raspberry Pi Foundation's attention about X or Y", I wish that people could pause for a minute and understand that this is not how things work or even how things should work. The way to get the Raspberry Pi Foundation's attention is if users like you do contact them to let them know that they want a UEFI firmware, instead of requesting/wishing that others will do that for you. For the record, developers of independent Open Source projects don't have a "special channel" that we can use to communicate with the Foundation, and even if we did, I'm pretty sure that the only thing the Foundation cares about is whether a feature is likely to be requested by many people or not. Therefore, as long as regular users like you don't make your voice heard about how important a feature is, it's unlikely to bother investing resources for it.

3. This being said, I have been trying to raise awareness to the fact that we have a UEFI firmware in the Raspberry Pi user forums (which I know are monitored by people like James Hay the Senior Product Manager for Pi development) as well as point out that it would be nice if the Foundation could help with that effort. But again, unless they see that message repeated over and over again by people just like you, I doubt you will see much changing...

[ehem]

2. As to the idea that _"someone else should get the Raspberry Pi Foundation's attention about X or Y"_, I wish that people could pause for a minute and understand that this is not how things work or even how things should work. The way to get the Raspberry Pi Foundation's attention is if users **like you** do contact them to let them know that they want a UEFI firmware, instead of requesting/wishing that others will do that for you. For the record, developers of independent Open Source projects don't have a "special channel" that we can use to communicate with the Foundation, and even if we did, I'm pretty sure that the only thing the Foundation cares about is whether a feature is likely to be requested by many people or not. Therefore, as long as regular users like you don't make your voice heard about how important a feature is, it's unlikely to bother investing resources for it.

I was mentioning the existance of this project to people behind Devuan (a Debian fork) and suggesting it might be an easier base to target than the raw Raspberry PI. Get other Linux distributions targetting Raspberry PI via UEFI and this could get attention to how there is an easier target than the raw PI.

3. This being said, I have been trying to raise awareness to the fact that we have a UEFI firmware in the Raspberry Pi user forums (which I know are monitored by people like _James Hay_ the Senior Product Manager for Pi development) as well as point out that it would be nice if the Foundation could help with that effort. But again, unless they see that message repeated over and over again by people just like you, I doubt you will see much changing...

Strictly getting UEFI out there isn't my goal. My goal is a setup that is likely be easier to setup with GRUB, and vanilla GRUB is likely to be more obtainable via UEFI than trying to get GRUB directly talking to a Raspberry PI. I try to avoid creating yet more accounts on additional forums unless there is a major gain by doing so. As such I hope to avoid being on their forums, but I'll likely be pointing towards this project in several other places. (I'm on GitHub for distinct purposes, so adding messages here is easy)

[webash]

This request from the product design team at Raspberry Pi Foundation might just be the right time to be asking for UEFI: https://www.raspberrypi.org/blog/help-us-make-it-easier-for-you-to-design-products-with-raspberry-pi/

[pedrospinto]

@andreiw wrote:

I thought that the front USB ports were wired up to the Dwc2 USB, but in fact they're not... the USB Type-C is. So you can't get away from having to write a PCIe RC driver.

Maybe what I'm about to suggest is complete nonsense: if one powers the PI over ethernet so the USB Type-C port is free, can one use it to connect a memory card, say, with an adaptor like this? If possible, it would be an alternative to writing that PCIe driver...

[driver1998]

Maybe what I'm about to suggest is complete nonsense: if one powers the PI over ethernet so the USB Type-C port is free, can one use it to connect a memory card, say, with an adaptor like this?

Well for storage we can still use the MicroSD, maybe connect mouse & kbd via USB-C.

[andreiw]

Yes, if you power the Pi via PoE or similar you can just plug a USB-C Hub with whatever you want - storage, net, keyb

A

9 сент. 2019 г., в 15:52, driver1998 notifications@github.com написал(а):

Maybe what I'm about to suggest is complete nonsense: if one powers the PI over ethernet so the USB Type-C port is free, can one use it to connect a memory card, say, with an adaptor like this?

Well for storage we can still use the MicroSD, maybe connect mouse & kbd via USB-C.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[pedrospinto]

Great! So, with such a setup, what's still missing for a successful test to boot Win10 on RPi4?

[andreiw]

Everything. There’s no firmware ready yet for the Pi 4.

A

9 сент. 2019 г., в 18:10, pedrospinto notifications@github.com написал(а):

Great! So, with such a setup, what's still missing for a successful test to boot Win10 on RPi4?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[pedrospinto]

...I didn't mean ready, ready. :wink: Anyway, thanks for your work. You the man!

[pedrospinto]

Yes, if you power the Pi via PoE or similar you can just plug a USB-C Hub with whatever you want - storage, net, keyb

Indeed! Couldn't do it at first using a USB-C hub, but with a USB2 hub (with an adapter) I was able to boot the UEFI from Googulator, navigate the menus with the keyboard and could also see in the boot menu the storage devices connected to the hub. Couldn't go forward with starting windows installation, as expected. The cheapest way I could find to power the RPi4 is the Adafruit PiUART. Works fine.

P.

[ehem]

So...generally speaking, getting the upstream TF-A booting is as easy as switching the old UART and INTC base addresses to new ones, fixing up the clock and adding a72 CPU helpers (don't forget about the nasty A72 erratum).

Where is this? I can't find the referenced platform_def.h platform.mk rpi3_hw.h files in edk2-platform. Unless that is spread among the various files in Platform/RaspberryPi/RPi3 (ick!). Do you have experimental builds available anywhere? I hope to hold off until a v1.1 or v2.0 board comes out with fixed USB-C, but depending on timing...

[andreiw]

Have a look at https://github.com/andreiw/lampone/blob/master/lampone_build.sh

[andreiw]

This is happening, but it’s going to happen upstream, based on the repos I referenced in that build script in my prev message. It’s not yet really usable.

[andreiw]

Https://rpi4-uefi.dev