[U-Boot] [RFC PACH v2 1/1] Add vexpress_aemv8a_aarch32 variant
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
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 */
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-ridesthe default config to allow the user to load the images directly intoDRAM using model parameters rather than by using semi-hosting to loadthe 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?
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_V7helpThis target is derived from TARGET_VEXPRESS64_BASE_FVP and over-ridesthe default config to allow the user to load the images directly intoDRAM using model parameters rather than by using semi-hosting to loadthe 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
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.
participants (2)
-
Ryan Harkin -
Tom Rini