Re: [U-Boot] [RFC PACH v2 1/1] Add vexpress_aemv8a_aarch32 variant

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* 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?