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

[Andre Przywara]

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].
There I provide two defconfigs: one for "armv8" (aka. AArch64) and one
for "armv7" (aka AArch32).
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