Hi Tom,
On 5 December 2016 at 17:13, Tom Rini trini@konsulko.com wrote:
On Mon, Dec 05, 2016 at 04:11:45PM +0000, Ryan Harkin wrote:
The ARM AEMv8 FVP model can be run in Aarch64 or Aarch32 mode. Aarch32 support is enable per-CPU when launching the model, eg:
-C cluster0.cpu0.CONFIG64=0
This patch adds a new defconfig and some variant specific selections in vexpress_armv8a.h.
This patch is co-authored with Soby Mathew Soby.Mathew@arm.com.
Signed-off-by: Ryan Harkin ryan.harkin@linaro.org
[snip]
Changes since v1: This single patch replaces my earlier RFC series of two patches, where the first modified generic code and the other added a new variant.
After Tom's suggestion that I review the Raspberry PI code, my original [RFC PATCH 1/2] has been dropped completely.
To address the generic problems from the first patch:
- move CONFIG_REMAKE_ELF to CONFIG_ARM64 only builds in vexpress_aemv8a.h
- define CONFIG_SKIP_LOWLEVEL_INIT for non-ARM64 builds (ie. for CPU_V7)
- the ARMv8 MMU code in vexpress64.h becomes conditiononal on CONFIG_ARM64
I'm not sure if the last change is the correct approach, but it works. I suspect that at the very least, a rework of the vexpress code would split this MMU code into an ARM64 specific .c file.
Assuming your plan is to follow this up with a series to unify and correct board/armltd/vexpress*
Yes, I would like to refactor it. I am trying to work out how far I can go based on the rpi example. Currently, I'm thinking that I only need a board/armlt/vexpress and that the vexpress64 stuff can be carried across somehow. Failing that, there is some genuinely common code between vexpress and vexpress64 that can be shared.
Having an upstream 32-bit version would be moderately useful for me, but I'm happy to carry this patch in my own fork until I can sort it out in a more useful way.
then yes, I think this is a logical step forward. And some level of these CONFIG options should be moved to Kconfig as part of that unification.
Yes, taking them out of vexpress_aemv8.h would be a good idea and mean there is less special case logic in there.
[snip]
+config TARGET_VEXPRESS_AEMV8_AARCH32
bool "Support Versatile Express ARMv8a 32-bit FVP BASE model booting from DRAM"select CPU_V7helpThis target is derived from TARGET_VEXPRESS64_BASE_FVP and over-ridesthe default config to allow the user to load the images directly intoDRAM using model parameters rather than by using semi-hosting to loadthe files from the host filesystem.config TARGET_VEXPRESS64_BASE_FVP_DRAM bool "Support Versatile Express ARMv8a FVP BASE model booting from DRAM"
I know neither are "nice" names but why not TARGET_VEXPRESS64_AEMV8_AARCH32_FVP_DRAM ?
I also considered just appending AARCH32 onto the end of the DRAM config it was based on, but...
Or is this just something else that I shouldn't worry about until we're unifying the various options here?
Yes, don't worry about it. I'll look at renaming all the combinations... if I can come up with a scheme that makes sense.
At the moment, the BASE_FVP_DRAM version is a clone of the BASE_FVP code, just with a different bootcmd. Now the AARCH32 is another clone with CPU_V7 and bootz instead of booti.
I'd be interested to know if there is a better way to handle those small variations. A better structured header than vexpress_aemv8a.h would be a good start, of course.
Cheers, Ryan.
-- Tom