Hi,
(BCC:ing Antonio as well)
not sure if someone gets notified, but I pushed a patch set to add Raspberry Pi 4 support to Trusted Firmware: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1629
This port is quite a departure from the existing RPi3 port, that's why I wanted to start a discussion about it here.
I originally started by copying files. But for the sake of simplicity, also to get away without a BL33 loader, it turned into just a BL31-only port (for now?). This ties more into the existing RPi Foundation boot style, as the resulting bl31.bin is a drop-in replacement for the existing armstub8.bin. So you put your AArch64 kernel into kernel8.img and copy bl31.bin to armstub8.bin (or use the respective config.txt options to point to any other filename), and it should work (TM). The code will pick up the actual kernel and DTB load address from the GPU firmware, patch the DT to use PSCI instead of spin tables, then will drop into EL2 at the kernel load address. There could (should?) be U-Boot or EDK-II there as well, or any other kernel, for that matter. The only thing Linux specific we do is to put the DTB address into x0. I guess this doesn't hurt, even if the BL33 payload does not use this information.
I would be grateful to hear some opinions about this approach.
Does that sound sensible? Is the split of the platform directory (plat/rpi3 -> plat/rpi/rpi[34]) reasonable? Shall we add this design as a build option to RPi3 as well? Shall we add the "full featured" RPi3 design to RPi4 also?
Looking forward to any feedback!
Cheers, Andre.
Hi Andre,
The idea of having all images (BL1, BL2 and BL31) was to have a cheap hardware platform that behaves the "proper" way the TF is supposed to behave. However, the actual usefulness of this is not that clear to me, so a BL31-only port doesn't sound bad.
Having a common rpi directory and then rpi3 and rpi4 as subdirectories seems to me like the best way to do it.
I have taken a look at the patch stack, and everything looks. Actually, the only comment is that you haven't added a new entry to the maintainers.rst file. Well, that, and that there are still quite a few RPI3/rpi3 sprinkled around the code. In hindsight, calling the platform and all its variables and defines "rpi3" was a mistake.
Cheers Antonio ________________________________ De: Andre Przywara andre.przywara@arm.com Enviado: miércoles, 24 de julio de 2019 06:23 p. m. Para: Ying-Chun Liu (PaulLiu) paul.liu@linaro.org; tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org CC: Ying-Chun Liu (PaulLiu) paulliu@debian.org Asunto: Raspberry Pi 4 ATF port
Hi,
(BCC:ing Antonio as well)
not sure if someone gets notified, but I pushed a patch set to add Raspberry Pi 4 support to Trusted Firmware: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1629
This port is quite a departure from the existing RPi3 port, that's why I wanted to start a discussion about it here.
I originally started by copying files. But for the sake of simplicity, also to get away without a BL33 loader, it turned into just a BL31-only port (for now?). This ties more into the existing RPi Foundation boot style, as the resulting bl31.bin is a drop-in replacement for the existing armstub8.bin. So you put your AArch64 kernel into kernel8.img and copy bl31.bin to armstub8.bin (or use the respective config.txt options to point to any other filename), and it should work (TM). The code will pick up the actual kernel and DTB load address from the GPU firmware, patch the DT to use PSCI instead of spin tables, then will drop into EL2 at the kernel load address. There could (should?) be U-Boot or EDK-II there as well, or any other kernel, for that matter. The only thing Linux specific we do is to put the DTB address into x0. I guess this doesn't hurt, even if the BL33 payload does not use this information.
I would be grateful to hear some opinions about this approach.
Does that sound sensible? Is the split of the platform directory (plat/rpi3 -> plat/rpi/rpi[34]) reasonable? Shall we add this design as a build option to RPi3 as well? Shall we add the "full featured" RPi3 design to RPi4 also?
Looking forward to any feedback!
Cheers, Andre.
Hi Andre,
Thanks for the patch. I'll review it very soon. Currently I'm at DebConf19 at Brazil. So it is a bit busy here. But will have some time next week.
Yours, Paul
On Wed, Jul 24, 2019 at 7:50 PM Antonio Niño Díaz antonio_nd@outlook.com wrote:
Hi Andre,
The idea of having all images (BL1, BL2 and BL31) was to have a cheap hardware platform that behaves the "proper" way the TF is supposed to behave. However, the actual usefulness of this is not that clear to me, so a BL31-only port doesn't sound bad.
Having a common rpi directory and then rpi3 and rpi4 as subdirectories seems to me like the best way to do it.
I have taken a look at the patch stack, and everything looks. Actually, the only comment is that you haven't added a new entry to the maintainers.rst file. Well, that, and that there are still quite a few RPI3/rpi3 sprinkled around the code. In hindsight, calling the platform and all its variables and defines "rpi3" was a mistake.
Cheers Antonio
*De:* Andre Przywara andre.przywara@arm.com *Enviado:* miércoles, 24 de julio de 2019 06:23 p. m. *Para:* Ying-Chun Liu (PaulLiu) paul.liu@linaro.org; tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org *CC:* Ying-Chun Liu (PaulLiu) paulliu@debian.org *Asunto:* Raspberry Pi 4 ATF port
Hi,
(BCC:ing Antonio as well)
not sure if someone gets notified, but I pushed a patch set to add Raspberry Pi 4 support to Trusted Firmware: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1629
This port is quite a departure from the existing RPi3 port, that's why I wanted to start a discussion about it here.
I originally started by copying files. But for the sake of simplicity, also to get away without a BL33 loader, it turned into just a BL31-only port (for now?). This ties more into the existing RPi Foundation boot style, as the resulting bl31.bin is a drop-in replacement for the existing armstub8.bin. So you put your AArch64 kernel into kernel8.img and copy bl31.bin to armstub8.bin (or use the respective config.txt options to point to any other filename), and it should work (TM). The code will pick up the actual kernel and DTB load address from the GPU firmware, patch the DT to use PSCI instead of spin tables, then will drop into EL2 at the kernel load address. There could (should?) be U-Boot or EDK-II there as well, or any other kernel, for that matter. The only thing Linux specific we do is to put the DTB address into x0. I guess this doesn't hurt, even if the BL33 payload does not use this information.
I would be grateful to hear some opinions about this approach.
Does that sound sensible? Is the split of the platform directory (plat/rpi3 -> plat/rpi/rpi[34]) reasonable? Shall we add this design as a build option to RPi3 as well? Shall we add the "full featured" RPi3 design to RPi4 also?
Looking forward to any feedback!
Cheers, Andre.
tf-a@lists.trustedfirmware.org
-
Andre Przywara -
Antonio Niño Díaz -
PaulLiu