Hi Andre,
Am 09.12.19 um 15:17 schrieb Andre Przywara:
On Mon, 9 Dec 2019 13:20:29 +0100 Andreas Färber afaerber@suse.de wrote:
Not seeing any message from Matthias here yet, are you aware that U-Boot has combined rpi3 and rpi4 targets into one? Are you looking into combining the PLAT=rpi{3,4} TF-A targets, too?
Well, technically the two are indeed not too different, it was just that I considered the whole boot approach that the RPi3 was using in TF-A as too complicated, thus went with something easier. The next step would be to also implement this easier approach in RPi3, then it should be much easier to unify them. One question would be what to do with the more involved current RPi3 design, whether to keep this as a build time option, and whether to choose it as the default or not.
I would vote to turn the unnecessary parts off by default. If someone wants to educate themselves about TF-A using the RPi3 as platform, they can be expected to rebuild TF-A with (documented) options.
Maybe initially it might be easiest for them to coexist and get incorporated into your new clean target under a unified name? U-Boot still has rpi_{3,4}_defconfig and added rpi_arm64_defconfig alongside. Whatever we do, we should just avoid duplication between the 3 and 4, whether that means keeping PLAT=rpi4 or not.
I don't have a RPi3 (no GIC! yikes!) at the moment, but it's on my wish list ;-) So long term unification is indeed the goal, but I don't have enough spare cycles to pull this through at the moment.
We're targeting to use a single Linux image for both, so needing two different TF-A binaries would make TF-A adoption more difficult for us.
I see, makes sense. Are you talking about a "SuSE Linux installer image" here? Or some generic firmware image (ATF + UEFI enabled U-Boot)?
I don't think a fully-generic image is possible, but yes, multiple image types currently involving UEFI enabled U-Boot for (open)SUSE that we may want to amend with TF-A for SMCCC (vulnerabilities), PSCI (SMP) and possibly wrapping further VC-facing interfaces into standard interfaces for the benefit of Linux drivers we newly port to mainline.
Long-term, if this is implemented efficiently and shows the benefits, I would also hope for an aarch64 Raspbian to adopt such an approach then.
Cheers, Andreas