[U-Boot] [RFC PATCH 0/2] ARMv8 Aarch32 support

[Ryan Harkin]

On 5 December 2016 at 15:14, Andre Przywara <andre.przywara at arm.com> wrote:
> Hi,
>
> On 02/12/16 19:20, Tom Rini wrote:
>> On Fri, Dec 02, 2016 at 04:25:37PM +0000, Ryan Harkin wrote:
>>> On 2 December 2016 at 15:41, Tom Rini <trini at konsulko.com> wrote:
>>>> On Fri, Dec 02, 2016 at 11:51:07AM +0000, Ryan Harkin wrote:
>>>>
>>>>> I've been working with Soby Mathew to get U-Boot booting on ARM's
>>>>> AEMv8 FVP model in Aarch32 mode.
>>>>>
>>>>> Soby worked out what needed to be changed and I'm refining the changes
>>>>> into patches that can be built for both Aarch64 and Aarch32 mode.
>>>>>
>>>>> There are two patches for discussion:
>>>>>
>>>>> [RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs
>>>>> [RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant
>>>>>
>>>>> I expect the first patch to be controversial.  I also don't expect it to
>>>>> be accepted, but to demonstrate what changes we needed to make to get an
>>>>> ARMv8 platform to boot in Aarch32 mode when selecting CPU_V7 instead of
>>>>> ARM64 as the CPU type.  This in itself may be the wrong approach.
>>>>>
>>>>> It adds an ARMV8_AARCH32 config option and some checks in generic code
>>>>> for that option to allow the code to differentiate between the two
>>>>> modes.
>>>>>
>>>>> The second patch should be less controversial.  It adds support for a
>>>>> new AEMv8 variant that runs in 32-bit mode.  The most awkward part is
>>>>> that it defines itself not as ARM64, but as CPU_V7.  I expect this to
>>>>> change based on feedback from patch 1/2.
>>>>>
>>>>> The Aarch32 code runs on the same AEMv8 model as the Aarch64 code, but
>>>>> takes an extra per-core model launch parameter to switch the cores into
>>>>> Aarch32 mode, eg. "-C cluster0.cpu0.CONFIG64=0".
>>>>
>>>> So my first and slightly ignorant question is, why isn't this just a new
>>>> regular ARMv7 board being added rather than a special cased ARMv8?
>>>>
>>>
>>> That's a valid question.
>>>
>>> I guess it could be either.  At the moment, it's a bit of both.
>>> arch/arm/Kconfig says it's an ARMv7, but then it's added to
>>> board/armltd/vexpress64/Kconfig to re-use vexpress_aemv8a.h.
>>>
>>> But there's no reason it couldn't be added to
>>> board/armlt/vexpress/Kconfig and have a copy of vexpress_aemv8a.h that
>>> isn't special cased at all.  That approach seems more copy/paste-y
>>> than what I've done in this series, though.
>>>
>>> I think the whole setup for vexpress/vexpress64 and AEMv8/Juno is
>>> confused.  Really, all of these armlt boards are the same with minor
>>> variations, even if the minor variation could be ARMv7 vs ARMv8.
>>
>> Maybe this gets to the heart of the problem then, and we should
>> re-structure and fix this.  If you look in board/raspberrypi/rpi/ we
>> support rpi1 2 and 3, and that includes rpi3 in 64bit mode.
>
> You might also want to take a look at my latest Allwinner A64 series[1].

Thanks, the more ideas the better.

> There I provide two defconfigs: one for "armv8" (aka. AArch64) and one
> for "armv7" (aka AArch32).

I've just reworked my patch based on Tom's feedback and I'm doing
something like this now.  I'll post it for reference as a new RFC.


> The series contains a lot of fixes, but when the code is eventually in
> the correct place, it's merely a matter of "select CPU_V7" vs.
> "select ARM64" to switch between the two architectures [2].
> I think this is mostly due to earlier work from Alex, who moved common
> board support code into arch-agnostic directories[3].
>
> The reason for this exercise in my case is just the SPL, but it actually
> works for the whole of U-Boot: By just changing between the two symbols
> you'll get a complete AArch32 or a complete AArch64 build, which runs on
> the very same board.
>
>> So if we
>> want to re-work board/armlt/vexpress/ to support the various ways the
>> base hardware can be (/ has been over the years), lets.  Does that sound
>> like a plan?
>
> +1, I am very much for cleaning up this slightly convoluted vexpress64 code.
>
> Cheers,
> Andre.
>
> [1] http://lists.denx.de/pipermail/u-boot/2016-December/275288.html
> [2] http://lists.denx.de/pipermail/u-boot/2016-December/275308.html
> [3]
> http://git.denx.de/?p=u-boot.git;a=commitdiff;h=e6e505b93cb3fd264227c65ae1bfc9e4681555d8