diff mbox

[RFC,PACH,v2,1/1] Add vexpress_aemv8a_aarch32 variant

Message ID 1480954305-11770-1-git-send-email-ryan.harkin@linaro.org
State New
Headers show

Commit Message

Ryan Harkin Dec. 5, 2016, 4:11 p.m. UTC 
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>

---

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.

 arch/arm/Kconfig                          |  9 +++++++++
 board/armltd/vexpress64/Kconfig           |  2 +-
 board/armltd/vexpress64/vexpress64.c      |  4 ++++
 configs/vexpress_aemv8a_aarch32_defconfig | 31 ++++++++++++++++++++++++++++++
 include/configs/vexpress_aemv8a.h         | 32 ++++++++++++++++++++++++++++---
 5 files changed, 74 insertions(+), 4 deletions(-)
 create mode 100644 configs/vexpress_aemv8a_aarch32_defconfig

-- 
1.9.1

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Comments

Tom Rini Dec. 5, 2016, 5:13 p.m. UTC | #1 
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 <Soby.Mathew@arm.com>.

> 

> Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>

[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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Ryan Harkin Dec. 5, 2016, 6:01 p.m. UTC | #2 
Hi Tom,

On 5 December 2016 at 17:13, Tom Rini <trini@konsulko.com> wrote:
> 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 <Soby.Mathew@arm.com>.

>>

>> Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>

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


Yes, I would like to refactor it.  I am trying to work out how far I
can go based on the rpi example.  Currently, I'm thinking that I only
need a board/armlt/vexpress and that the vexpress64 stuff can be
carried across somehow.  Failing that, there is some genuinely common
code between vexpress and vexpress64 that can be shared.

Having an upstream 32-bit version would be moderately useful for me,
but I'm happy to carry this patch in my own fork until I can sort it
out in a more useful way.


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


Yes, taking them out of vexpress_aemv8.h would be a good idea and mean
there is less special case logic in there.


>

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


I also considered just appending AARCH32 onto the end of the DRAM
config it was based on, but...

>  Or is this just something

> else that I shouldn't worry about until we're unifying the various

> options here?

>

Yes, don't worry about it.  I'll look at renaming all the
combinations... if I can come up with a scheme that makes sense.

At the moment, the BASE_FVP_DRAM version is a clone of the BASE_FVP
code, just with a different bootcmd.  Now the AARCH32 is another clone
with CPU_V7 and bootz instead of booti.

I'd be interested to know if there is a better way to handle those
small variations.  A better structured header than vexpress_aemv8a.h
would be a good start, of course.

Cheers,
Ryan.
> --

> Tom

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Tom Rini Dec. 5, 2016, 7 p.m. UTC | #3 
On Mon, Dec 05, 2016 at 06:01:48PM +0000, Ryan Harkin wrote:
> Hi Tom,

> 

[snip]
> At the moment, the BASE_FVP_DRAM version is a clone of the BASE_FVP

> code, just with a different bootcmd.  Now the AARCH32 is another clone

> with CPU_V7 and bootz instead of booti.

> 

> I'd be interested to know if there is a better way to handle those

> small variations.  A better structured header than vexpress_aemv8a.h

> would be a good start, of course.


The very new include/environment/ directory would be the place to put
these various environment bits (probably under armltd/) and then you
could probably do something like:
#ifdef CONFIG_ARM64
#define BOARD_BOOTCMD "booti"
#else
#define BOARD_BOOTCMD "bootz"
#endif

#define BOOTCOMMAND "..." \
                    BOARD_BOOTCMD + " $loadaddr - $fdtaddr"

And add some other choice / bools to board/armltd/vexpress/Kconfig to
enable/disable other environment things as needed.

-- 
Tom
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
diff mbox

Patch

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3d00948..729c31d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -642,6 +642,15 @@  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
+	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/board/armltd/vexpress64/vexpress64.c b/board/armltd/vexpress64/vexpress64.c
index 4ddbff9..c1d608d 100644
--- a/board/armltd/vexpress64/vexpress64.c
+++ b/board/armltd/vexpress64/vexpress64.c
@@ -14,7 +14,9 @@ 
 #include <dm/platdata.h>
 #include <dm/platform_data/serial_pl01x.h>
 #include "pcie.h"
+#ifdef CONFIG_ARM64
 #include <asm/armv8/mmu.h>
+#endif
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -29,6 +31,7 @@  U_BOOT_DEVICE(vexpress_serials) = {
 	.platdata = &serial_platdata,
 };
 
+#ifdef CONFIG_ARM64
 static struct mm_region vexpress64_mem_map[] = {
 	{
 		.virt = 0x0UL,
@@ -50,6 +53,7 @@  static struct mm_region vexpress64_mem_map[] = {
 };
 
 struct mm_region *mem_map = vexpress64_mem_map;
+#endif
 
 /* This function gets replaced by platforms supporting PCIe.
  * The replacement function, eg. on Juno, initialises the PCIe bus.
diff --git a/configs/vexpress_aemv8a_aarch32_defconfig b/configs/vexpress_aemv8a_aarch32_defconfig
new file mode 100644
index 0000000..8eb3c77
--- /dev/null
+++ b/configs/vexpress_aemv8a_aarch32_defconfig
@@ -0,0 +1,31 @@ 
+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_BOOTZ=y
+# 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..0c69e2e 100644
--- a/include/configs/vexpress_aemv8a.h
+++ b/include/configs/vexpress_aemv8a.h
@@ -15,13 +15,19 @@ 
 #define CONFIG_ARMV8_SWITCH_TO_EL1
 #endif
 
-#define CONFIG_REMAKE_ELF
-
 #define CONFIG_SUPPORT_RAW_INITRD
+#ifdef CONFIG_ARM64
+#define CONFIG_REMAKE_ELF
+#else
+#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 +265,26 @@ 
 #define CONFIG_BOOTCOMMAND	"booti $kernel_addr $initrd_addr $fdt_addr"
 
 
+#elif CONFIG_TARGET_VEXPRESS_AEMV8_AARCH32
+#define CONFIG_SKIP_LOWLEVEL_INIT
+#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	"bootz $kernel_addr $initrd_addr $fdt_addr"
+
+
 #endif
 
 /* Monitor Command Prompt */