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 <[email protected]>. > > Signed-off-by: Ryan Harkin <[email protected]> [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* 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. [snip] > +config TARGET_VEXPRESS_AEMV8_AARCH32 > + bool "Support Versatile Express ARMv8a 32-bit FVP BASE model booting > from DRAM" > + select CPU_V7 > + help > + This target is derived from TARGET_VEXPRESS64_BASE_FVP and over-rides > + the default config to allow the user to load the images directly into > + DRAM using model parameters rather than by using semi-hosting to load > + the 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 ? Or is this just something else that I shouldn't worry about until we're unifying the various options here? -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
