From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Mon, 5 Dec 2016 12:13:04 -0500 Subject: [U-Boot] [RFC PACH v2 1/1] Add vexpress_aemv8a_aarch32 variant In-Reply-To: <1480954305-11770-1-git-send-email-ryan.harkin@linaro.org> References: <1480954305-11770-1-git-send-email-ryan.harkin@linaro.org> Message-ID: <20161205171304.GQ4248@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 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 . > > Signed-off-by: Ryan Harkin [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* 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. [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 ? Or is this just something else that I shouldn't worry about until we're unifying the various options here? -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: