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

[Tom Rini <trini@konsulko.com>]

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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161205/f79c136e/attachment.sig>