[PATCH] arm: Add (back) VExpress boards support

[Andre Przywara]

On Tue, 29 Jun 2021 15:15:52 +0100
Andre Przywara <andre.przywara at arm.com> wrote:

Hi,

> On Tue, 29 Jun 2021 08:11:22 -0400
> Tom Rini <trini at konsulko.com> wrote:
> 
> > On Tue, Jun 29, 2021 at 12:45:55PM +0100, Andre Przywara wrote:
> >   
> > > The v2021.07 merge window saw the removal of the Arm Ltd. Versatile
> > > Express platform, along with their CA5, CA9 and TC2 boards. The trigger
> > > was the missing conversion of the MMC driver.
> > > 
> > > Some folks complained about that internally, so bring those boards back,
> > > but better than ever:
> > > - Use DM and OF_CONTROL for all the boards. Use the .dts files from the
> > >   latest Linux kernel (5.13) for that.
> > > - Move the board selection choice into the platform's Kconfig.
> > > - Clean up some shared config and common definitions.
> > > - Drop obsolete features like ATAGs support.
> > > - Switch to the DM_ETH version of the SMC911X Ethernet driver.
> > > - Drop MMC support.
> > > 
> > > The PL180 MMC driver actually supports DM_MMC, but that requires a
> > > DM_GPIO driver for the card detect GPIO, which we don't have. This
> > > specific GPIO is actually handled via the "sysregs" device, so we would
> > > need a driver for that. QEMU does not emulate this part, also the DT
> > > description is somewhat "special", so this is left for later.
> > > 
> > > This version compiles without any warning for all three boards now.
> > > Tested on QEMU.
> > > 
> > > Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> > > ---
> > > Hi,
> > > 
> > > this relies on the SMC911x driver DT changes, as posted here:
> > > https://lists.denx.de/pipermail/u-boot/2021-June/452989.html
> > > I put a version with the changes broken down here:
> > > https://github.com/Andre-ARM/u-boot/commits/tc2-history
> > > 
> > > This was tested on QEMU, for vexpress_ca15_tc2_defconfig with:
> > > $ qemu-system-arm -M vexpress-a15,secure=on -cpu cortex-a15 -m 1G -smp 1 \
> > >   -drive file=tramp-tc2.bin,if=pflash,format=raw,read-only \
> > >   -device loader,file=u-boot.bin,addr=0x80800000 -nographic
> > > 
> > > Where tramp-tc2.bin is a trampoline replacing the board's firmware:
> > > 00000000  00 00 a0 e3 80 00 48 e3  10 ff 2f e1
> > > (mov r0, #0; movt r0, #0x8080; bx r0)
> > > 
> > > The vexpress_ca9x4_defconfig uses a different memory map, so the runes are:
> > > $ qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -m 1G -smp 1 \
> > >   -drive file=tramp-ca9.bin,if=pflash,format=raw,read-only \
> > >   -device loader,file=u-boot.bin,addr=0x60800000 -nographic
> > > 
> > > tramp-ca9.bin:
> > > 00000000  00 00 a0 e3 80 00 46 e3  10 ff 2f e1
> > > (mov r0, #0; movt r0, #0x6080; bx r0)    
> > 
> > My big question is how do we run this in CI?  Or does it not _need_ that
> > firmware file to really exist?  Or is there a pending change to
> > https://gitlab.denx.de/u-boot/u-boot-test-hooks.git to generate / just
> > have exist those magic empty bins?  Thanks!  
> 
> So from digging into this I see that this loads U-Boot's ELF build, via
> QEMU's -kernel parameter. Which is fine, but not really what is
> happening on real hardware.
> I checked and the v2021.04 version worked with this approach, but my
> build does not.
> I will have a look into this now.

The new build uses OF_CONTROL and OF_SEPARATE, so the DTB gets appended
to the U-Boot *image*. The ELF file is not treated this way, so the
code reads only 0s after the end of the U-Boot code - which makes it
die silently. Manually loading the DTB into DRAM would be fragile at
best, but is also rejected by QEMU, because the LOAD program header
extend for a few dozen bytes beyond U-Boot's "end" symbol, so it
overlaps.

IIRC we don't have position independent code for ARM, so we can't load
U-Boot into flash directly (which also would require some code changes
first).

Anyway I don't think we should change any code to cope with that (by
using another method to find the DTB), so adjusting the QEMU recipe
sounds like a better idea.

Is there a way to add those 12 byte trampoline files to the CI repo? Or
shall they be created on the fly somehow?

Or can you think of another way to get those builds tested?

Cheers,
Andre