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

[Tom Rini]

On Fri, Dec 02, 2016 at 09:40:28PM +0000, Ryan Harkin wrote:
> On 2 Dec 2016 19:20, "Tom Rini" <trini at konsulko.com> 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.  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?
> >
> 
> Thanks, yes, it sounds like a great idea.  I haven't looked at the rpi
> stuff yes, but I'll check it out next week.
> 
> I believe that would only resolve the issues in my 2nd patch, though.
> Wouldn't the generic part of using an ARMv8 CPU with the ARMv7 code still
> need addressing?  I guess reviewing the rpi3 code will tell me more.

I think everything you need is in there somewhere as there's also a
rpi3-as-32bit option.

-- 
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/20161202/90e82b79/attachment.sig>