From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Fri, 2 Dec 2016 14:20:17 -0500 Subject: [U-Boot] [RFC PATCH 0/2] ARMv8 Aarch32 support In-Reply-To: References: <1480679469-27065-1-git-send-email-ryan.harkin@linaro.org> <20161202154150.GP2546@bill-the-cat> Message-ID: <20161202192017.GR2546@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, Dec 02, 2016 at 04:25:37PM +0000, Ryan Harkin wrote: > On 2 December 2016 at 15:41, Tom Rini 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? -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: