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@arm.com wrote:
Hi,
On Tue, 29 Jun 2021 08:11:22 -0400 Tom Rini trini@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@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..
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.
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.