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

[Ryan Harkin]

Hi Tom,

On 5 December 2016 at 17:13, Tom Rini <trini at 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 at arm.com>.
>>
>> Signed-off-by: Ryan Harkin <ryan.harkin at 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_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 ?

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