>> >> I've been working with Soby Mathew to get U-Boot booting on ARM's >> >> AEMv8 FVP model in Aarch32 mode. >> >> >> >> Soby worked out what needed to be changed and I'm refining the changes >> >> into patches that can be built for both Aarch64 and Aarch32 mode. >> >> >> >> There are two patches for discussion: >> >> >> >> [RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs >> >> [RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant >> >> >> >> I expect the first patch to be controversial. I also don't expect it to >> >> be accepted, but to demonstrate what changes we needed to make to get an >> >> ARMv8 platform to boot in Aarch32 mode when selecting CPU_V7 instead of >> >> ARM64 as the CPU type. This in itself may be the wrong approach. >> >> >> >> It adds an ARMV8_AARCH32 config option and some checks in generic code >> >> for that option to allow the code to differentiate between the two >> >> modes. >> >> >> >> The second patch should be less controversial. It adds support for a >> >> new AEMv8 variant that runs in 32-bit mode. The most awkward part is >> >> that it defines itself not as ARM64, but as CPU_V7. I expect this to >> >> change based on feedback from patch 1/2. >> >> >> >> The Aarch32 code runs on the same AEMv8 model as the Aarch64 code, but >> >> takes an extra per-core model launch parameter to switch the cores into >> >> Aarch32 mode, eg. "-C cluster0.cpu0.CONFIG64=0". >> > >> > So my first and slightly ignorant question is, why isn't this just a new >> > regular ARMv7 board being added rather than a special cased ARMv8? >> > >> >> That's a valid question. >> >> I guess it could be either. At the moment, it's a bit of both. >> arch/arm/Kconfig says it's an ARMv7, but then it's added to >> board/armltd/vexpress64/Kconfig to re-use vexpress_aemv8a.h. >> >> But there's no reason it couldn't be added to >> board/armlt/vexpress/Kconfig and have a copy of vexpress_aemv8a.h that >> isn't special cased at all. That approach seems more copy/paste-y >> than what I've done in this series, though. >> >> I think the whole setup for vexpress/vexpress64 and AEMv8/Juno is >> confused. Really, all of these armlt boards are the same with minor >> variations, even if the minor variation could be ARMv7 vs ARMv8. > > Maybe this gets to the heart of the problem then, and we should > re-structure and fix this. If you look in board/raspberrypi/rpi/ we > support rpi1 2 and 3, and that includes rpi3 in 64bit mode. So if we > want to re-work board/armlt/vexpress/ to support the various ways the > base hardware can be (/ has been over the years), lets. Does that sound > like a plan?
That sounds great to me, I would like to be able to use the vexpress u-boot through qemu but be able to pass through the qemu generated DT so as to get the HW passed through correctly. I'm interested as it makes for a nice means of automation for some of my testing but also for virt based build systems too. Peter _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot