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

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

[Ryan Harkin]

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".

[U-Boot] [RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs

[Ryan Harkin]

This patch hacks some generic code used to allow the ARMv8 platform to
specify if it is booting in Aarch32 mode.

Some ARMv8 CPUs can be run in Aarch32 mode as well as Aarch64.  A good
example of this is ARM's AEMv8 FVP model which models the ARMv8
architecture rather than a specific CPU core.

This patch is co-authored with Soby Mathew <Soby.Mathew@arm.com>.

Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
---
 Makefile                          | 5 +++++
 arch/arm/Kconfig                  | 6 ++++++
 arch/arm/cpu/armv7/virt-v7.c      | 2 ++
 arch/arm/cpu/armv8/u-boot-spl.lds | 5 +++++
 arch/arm/cpu/armv8/u-boot.lds     | 5 +++++
 arch/arm/include/asm/armv8/mmu.h  | 5 +++++
 6 files changed, 28 insertions(+)

diff --git a/Makefile b/Makefile
index 37cbcb2..b923ef7 100644
--- a/Makefile
+++ b/Makefile
@@ -1182,8 +1182,13 @@ u-boot-img-spl-at-end.bin: u-boot.img spl/u-boot-spl.bin FORCE
 # relocation).
 # FIXME refactor dts/Makefile to share target/arch detection
 u-boot.elf: u-boot.bin
+ifeq ($(CONFIG_ARMV8_AARCH32),y)
+	@$(OBJCOPY)  -B arm -I binary -O elf32-littlearm \
+		$< u-boot-elf.o
+else
 	@$(OBJCOPY)  -B aarch64 -I binary -O elf64-littleaarch64 \
 		$< u-boot-elf.o
+endif
 	@$(LD) u-boot-elf.o -o $@ \
 		--defsym=_start=$(CONFIG_SYS_TEXT_BASE) \
 		-Ttext=$(CONFIG_SYS_TEXT_BASE)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d7a9b11..6475a21 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -44,6 +44,12 @@ config CPU_ARM1176
 	select HAS_VBAR
 	select SYS_CACHE_SHIFT_5
 
+
+config ARMV8_AARCH32
+	bool "some help"
+	help
+	  some better help
+
 config CPU_V7
 	bool
 	select HAS_VBAR
diff --git a/arch/arm/cpu/armv7/virt-v7.c b/arch/arm/cpu/armv7/virt-v7.c
index d33e5c6..b0f54e3 100644
--- a/arch/arm/cpu/armv7/virt-v7.c
+++ b/arch/arm/cpu/armv7/virt-v7.c
@@ -131,12 +131,14 @@ int armv7_init_nonsec(void)
 	 * ram, so need to relocate secure section before enabling other
 	 * cores.
 	 */
+#ifndef CONFIG_ARMV8_AARCH32
 	relocate_secure_section();
 
 #ifndef CONFIG_ARMV7_PSCI
 	smp_set_core_boot_addr((unsigned long)secure_ram_addr(_smp_pen), -1);
 	smp_kick_all_cpus();
 #endif
+#endif
 
 	/* call the non-sec switching code on this CPU also */
 	secure_ram_addr(_nonsec_init)();
diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds b/arch/arm/cpu/armv8/u-boot-spl.lds
index cc427c3..bddfbe6 100644
--- a/arch/arm/cpu/armv8/u-boot-spl.lds
+++ b/arch/arm/cpu/armv8/u-boot-spl.lds
@@ -17,8 +17,13 @@ MEMORY { .sram : ORIGIN = CONFIG_SPL_TEXT_BASE,
 MEMORY { .sdram : ORIGIN = CONFIG_SPL_BSS_START_ADDR,
 		LENGTH = CONFIG_SPL_BSS_MAX_SIZE }
 
+#ifdef CONFIG_ARMV8_AARCH32
+OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
+OUTPUT_ARCH(arm)
+#else
 OUTPUT_FORMAT("elf64-littleaarch64", "elf64-littleaarch64", "elf64-littleaarch64")
 OUTPUT_ARCH(aarch64)
+#endif
 ENTRY(_start)
 SECTIONS
 {
diff --git a/arch/arm/cpu/armv8/u-boot.lds b/arch/arm/cpu/armv8/u-boot.lds
index fd15ad5..0543458 100644
--- a/arch/arm/cpu/armv8/u-boot.lds
+++ b/arch/arm/cpu/armv8/u-boot.lds
@@ -8,8 +8,13 @@
  * SPDX-License-Identifier:	GPL-2.0+
  */
 
+#ifdef CONFIG_ARMV8_AARCH32
+OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
+OUTPUT_ARCH(arm)
+#else
 OUTPUT_FORMAT("elf64-littleaarch64", "elf64-littleaarch64", "elf64-littleaarch64")
 OUTPUT_ARCH(aarch64)
+#endif
 ENTRY(_start)
 SECTIONS
 {
diff --git a/arch/arm/include/asm/armv8/mmu.h b/arch/arm/include/asm/armv8/mmu.h
index aa0f3c4..755c517 100644
--- a/arch/arm/include/asm/armv8/mmu.h
+++ b/arch/arm/include/asm/armv8/mmu.h
@@ -77,8 +77,13 @@
 #define PTE_BLOCK_INNER_SHARE	(3 << 8)
 #define PTE_BLOCK_AF		(1 << 10)
 #define PTE_BLOCK_NG		(1 << 11)
+#ifdef CONFIG_ARMV8_AARCH32
+#define PTE_BLOCK_PXN		((1ULL) << 53)
+#define PTE_BLOCK_UXN		((1ULL) << 54)
+#else
 #define PTE_BLOCK_PXN		(UL(1) << 53)
 #define PTE_BLOCK_UXN		(UL(1) << 54)
+#endif
 
 /*
  * AttrIndx[2:0]
-- 
1.9.1

[U-Boot] [RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant

[Ryan Harkin]

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 <Soby.Mathew@arm.com>.

Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
---
 arch/arm/Kconfig                          | 10 ++++++++++
 board/armltd/vexpress64/Kconfig           |  2 +-
 configs/vexpress_aemv8a_aarch32_defconfig | 30 ++++++++++++++++++++++++++++++
 include/configs/vexpress_aemv8a.h         | 28 ++++++++++++++++++++++++++--
 4 files changed, 67 insertions(+), 3 deletions(-)
 create mode 100644 configs/vexpress_aemv8a_aarch32_defconfig

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6475a21..59e22aa 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -647,6 +647,16 @@ config TARGET_VEXPRESS64_BASE_FVP
 	select ARM64
 	select SEMIHOSTING
 
+config TARGET_VEXPRESS_AEMV8_AARCH32
+	bool "Support Versatile Express ARMv8a 32-bit FVP BASE model booting from DRAM"
+	select CPU_V7
+	select ARMV8_AARCH32
+	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"
 	select ARM64
diff --git a/board/armltd/vexpress64/Kconfig b/board/armltd/vexpress64/Kconfig
index e05f353..06c1ce1 100644
--- a/board/armltd/vexpress64/Kconfig
+++ b/board/armltd/vexpress64/Kconfig
@@ -1,4 +1,4 @@
-if TARGET_VEXPRESS64_BASE_FVP || TARGET_VEXPRESS64_JUNO || TARGET_VEXPRESS64_BASE_FVP_DRAM
+if TARGET_VEXPRESS64_BASE_FVP || TARGET_VEXPRESS64_JUNO || TARGET_VEXPRESS64_BASE_FVP_DRAM || TARGET_VEXPRESS_AEMV8_AARCH32
 
 config SYS_BOARD
 	default "vexpress64"
diff --git a/configs/vexpress_aemv8a_aarch32_defconfig b/configs/vexpress_aemv8a_aarch32_defconfig
new file mode 100644
index 0000000..109bae5
--- /dev/null
+++ b/configs/vexpress_aemv8a_aarch32_defconfig
@@ -0,0 +1,30 @@
+CONFIG_ARM=y
+CONFIG_TARGET_VEXPRESS_AEMV8_AARCH32=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_IDENT_STRING=" vexpress_aemv8a"
+CONFIG_BOOTDELAY=1
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_HUSH_PARSER=y
+CONFIG_SYS_PROMPT="VExpress32# "
+# CONFIG_CMD_CONSOLE is not set
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_XIMG is not set
+# CONFIG_CMD_EDITENV is not set
+# CONFIG_CMD_ENV_EXISTS is not set
+CONFIG_CMD_MEMTEST=y
+# CONFIG_CMD_LOADS is not set
+CONFIG_CMD_ARMFLASH=y
+# CONFIG_CMD_FPGA is not set
+# CONFIG_CMD_ITEST is not set
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+# CONFIG_CMD_NFS is not set
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_CACHE=y
+# CONFIG_CMD_MISC is not set
+CONFIG_CMD_FAT=y
+CONFIG_DM=y
+CONFIG_DM_SERIAL=y
+CONFIG_OF_LIBFDT=y
diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h
index c9841cd..5cab39a 100644
--- a/include/configs/vexpress_aemv8a.h
+++ b/include/configs/vexpress_aemv8a.h
@@ -16,12 +16,17 @@
 #endif
 
 #define CONFIG_REMAKE_ELF
-
 #define CONFIG_SUPPORT_RAW_INITRD
+#ifdef CONFIG_ARMV8_AARCH32
+#define CONFIG_SYS_HZ_CLOCK		24000000
+#define CONFIG_SYS_ARCH_TIMER
+#define CONFIG_SKIP_LOWLEVEL_INIT
+#endif
 
 /* Link Definitions */
 #if defined(CONFIG_TARGET_VEXPRESS64_BASE_FVP) || \
-	defined(CONFIG_TARGET_VEXPRESS64_BASE_FVP_DRAM)
+	defined(CONFIG_TARGET_VEXPRESS64_BASE_FVP_DRAM) || \
+	defined(CONFIG_TARGET_VEXPRESS_AEMV8_AARCH32)
 /* ATF loads u-boot here for BASE_FVP model */
 #define CONFIG_SYS_TEXT_BASE		0x88000000
 #define CONFIG_SYS_INIT_SP_ADDR         (CONFIG_SYS_SDRAM_BASE + 0x03f00000)
@@ -259,6 +264,25 @@
 #define CONFIG_BOOTCOMMAND	"booti $kernel_addr $initrd_addr $fdt_addr"
 
 
+#elif CONFIG_TARGET_VEXPRESS_AEMV8_AARCH32
+#define CONFIG_EXTRA_ENV_SETTINGS	\
+				"kernel_addr=0x80080000\0"	\
+				"initrd_addr=0x84000000\0"	\
+				"fdt_addr=0x82000000\0"		\
+				"fdt_high=0xffffffff\0"	\
+				"initrd_high=0xffffffff\0"
+
+#define CONFIG_BOOTARGS		"console=ttyAMA0 earlycon=pl011,"\
+				"0x1c090000 debug user_debug=31 "\
+				"systemd.log_target=null "\
+				"androidboot.hardware=fvpbase "\
+				"root=/dev/vda2 rw "\
+				"rootwait "\
+				"loglevel=9"
+
+#define CONFIG_BOOTCOMMAND	"bootm $kernel_addr $initrd_addr $fdt_addr"
+
+
 #endif
 
 /* Monitor Command Prompt */
-- 
1.9.1

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

[Tom Rini]

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?

-- 
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/fd9d4bc5/attachment.sig>

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

[Ryan Harkin]

On 2 December 2016 at 15:41, Tom Rini <trini@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.

I'd quite like to address that, but I'm unsure how to approach the
problem in the most flexible way.


> --
> Tom

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

[Tom Rini]

On Fri, Dec 02, 2016 at 04:25:37PM +0000, Ryan Harkin wrote:
> On 2 December 2016 at 15:41, Tom Rini <trini@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?

-- 
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/9245447d/attachment.sig>

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

[Ryan Harkin]

On 2 Dec 2016 19:20, "Tom Rini" <trini@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@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.

> --
> Tom

[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@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@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>

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

[Peter Robinson]

>> >> 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?

That sounds great to me, I would like to be able to use the vexpress
u-boot through qemu but be able to pass through the qemu generated DT
so as to get the HW passed through correctly. I'm interested as it
makes for a nice means of automation for some of my testing but also
for virt based build systems too.

Peter

[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@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

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

[Ryan Harkin]

On 5 December 2016 at 15:14, Andre Przywara <andre.przywara@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@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