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

Andre Przywara andre.przywara at arm.com
Wed Jun 30 02:12:44 CEST 2021


On Tue, 29 Jun 2021 14:03:23 -0400
Tom Rini <trini at konsulko.com> wrote:

Hi Tom,

> On Tue, Jun 29, 2021 at 05:52:10PM +0100, Andre Przywara wrote:
> > 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.  
> 
> Can't we pass the device tree to qemu (and in turn through to U-Boot) in
> a clean and out of the box way?  I thought there was a way to do that..

QEMU has a -dtb command, to take a DTB file, and puts that at the
beginning of DRAM (if possible). Also we could load the DTB from the
(emulated) NOR flash, like we do for the Juno board.
But I think this is not the point: we don't really want this U-Boot
port for the *QEMU* vexpress machine, but for the real hardware: and
there is no DTB by default, not on the NOR flash, and certainly
not in DRAM. The previous U-Boot port didn't need any DTBs at all, so
we can't and shouldn't rely on any extra firmware provision.
I think appending the DTBs to the U-Boot image is the right solution,
so we get a self-contained U-Boot binary, acting as a drop-in
replacement for the older port.
Running under QEMU should just be a some easy way of CI testing, not
a goal in itself. Hence I'd rather adapt the CI than the code.

> > 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).  
> 
> Do you mean generate a file to use as the system flash and have U-Boot
> be in the correct spot within that file?  If so
> bin/travis-ci/conf.qemu_mips_na in the test hooks repo might give you
> some hints.

Well yes, this was what I was thinking about, but just for the
trampoline. The actual firmware loads U-Boot into DRAM, so we have to
provide that load address in DRAM when building the image. If we were
position independent (like arm64 is), we could cover both cases with
one build, but this is not the case for ARM, IIUC.

> > 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?  
> 
> If we need to include the trampoline files, however it's easiest is
> fine.

So I can try to provide some recipe for travis-ci, based on what I
see in the repo, but don't really know how to test this. I think I have
a Travis-CI account, but would be glad about some hints or instructions
how to test those u-boot-test-hooks bits easily.

Cheers,
Andre


More information about the U-Boot mailing list