[U-Boot] [PATCH 00/11] vexpress64 FVP and Juno configuration updates
This patch series updates the default configuration of the vexpress64 FVP and Juno platforms to allow it to work on a variety of setups without modification by the user.
[PATCH 01/11] vexpress64: fix checkpatch warnings [PATCH 02/11] vexpress64: Kconfig: tidy up [PATCH 03/11] Kconfig: add CONFIG_SYS_BOOTM_LEN [PATCH 04/11] vexpress64: Kconfig: add CONFIG_SYS_BOOTM_LEN [PATCH 05/11] vexpress64: fvp dram: add DRAM configuration [PATCH 06/11] vexpress64: juno: add androidboot.hardware=juno [PATCH 07/11] common/armflash: add command to check if image exists [PATCH 08/11] common/armflash: load_image returns success or failure [PATCH 09/11] vexpress64: juno: add optional initrd [PATCH 10/11] vexpress64: juno: add alternate kernel and device tree [PATCH 11/11] vexpress64: juno: use /dev/sda2
Kconfig | 7 +++++++ arch/arm/Kconfig | 4 ++++ board/armltd/vexpress64/Kconfig | 18 ++---------------- common/cmd_armflash.c | 31 ++++++++++++++++++++++++++----- configs/vexpress_aemv8a_dram_defconfig | 19 +++++++++++++++++++ include/configs/vexpress_aemv8a.h | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++-------- 6 files changed, 109 insertions(+), 29 deletions(-)
This patch fixes a couple of checkpatch warnings on the vexpress64 config.
Signed-off-by: Ryan Harkin ryan.harkin@linaro.org CC: David Feng fenghua@phytium.com.cn CC: Bhupesh Sharma bhupesh.sharma@freescale.com CC: Linus Walleij linus.walleij@linaro.org --- include/configs/vexpress_aemv8a.h | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h index 6107c64..53b0f74 100644 --- a/include/configs/vexpress_aemv8a.h +++ b/include/configs/vexpress_aemv8a.h @@ -194,7 +194,8 @@ #define CONFIG_BOOTARGS "console=ttyAMA0,115200n8 " \ "root=/dev/sda1 rw " \ "rootwait "\ - "earlyprintk=pl011,0x7ff80000 debug user_debug=31 "\ + "earlyprintk=pl011,0x7ff80000 debug "\ + "user_debug=31 "\ "loglevel=9"
/* Copy the kernel and FDT to DRAM memory and boot */ @@ -222,7 +223,8 @@
#define CONFIG_BOOTCOMMAND "smhload ${kernel_name} ${kernel_addr}; " \ "smhload ${fdt_name} ${fdt_addr}; " \ - "smhload ${initrd_name} ${initrd_addr} initrd_end; " \ + "smhload ${initrd_name} ${initrd_addr} "\ + "initrd_end; " \ "fdt addr ${fdt_addr}; fdt resize; " \ "fdt chosen ${initrd_addr} ${initrd_end}; " \ "booti $kernel_addr - $fdt_addr"
The FVP and Juno settings were identical, but duplicated, so I removed the duplication with this patch.
Signed-off-by: Ryan Harkin ryan.harkin@linaro.org Reviewed-by: Linus Walleij linus.walleij@linaro.org CC: David Feng fenghua@phytium.com.cn CC: Bhupesh Sharma bhupesh.sharma@freescale.com CC: Linus Walleij linus.walleij@linaro.org --- board/armltd/vexpress64/Kconfig | 17 ----------------- 1 file changed, 17 deletions(-)
diff --git a/board/armltd/vexpress64/Kconfig b/board/armltd/vexpress64/Kconfig index f5693ae..8da3bec 100644 --- a/board/armltd/vexpress64/Kconfig +++ b/board/armltd/vexpress64/Kconfig @@ -1,5 +1,3 @@ -if TARGET_VEXPRESS64_BASE_FVP - config SYS_BOARD default "vexpress64"
@@ -8,18 +6,3 @@ config SYS_VENDOR
config SYS_CONFIG_NAME default "vexpress_aemv8a" - -endif - -if TARGET_VEXPRESS64_JUNO - -config SYS_BOARD - default "vexpress64" - -config SYS_VENDOR - default "armltd" - -config SYS_CONFIG_NAME - default "vexpress_aemv8a" - -endif
As config migrates from board config files to Kconfig, when adding CONFIG_SYS_BOOTM_LEN to a platform, I decided to add Kconfig support for CONFIG_SYS_BOOTM_LEN.
Signed-off-by: Ryan Harkin ryan.harkin@linaro.org Reviewed-by: Linus Walleij linus.walleij@linaro.org CC: Masahiro Yamada yamada.m@jp.panasonic.com CC: Simon Glass sjg@chromium.org CC: Linus Walleij linus.walleij@linaro.org --- Kconfig | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/Kconfig b/Kconfig index 05a34f7..7783a13 100644 --- a/Kconfig +++ b/Kconfig @@ -190,6 +190,13 @@ config SYS_CLK_FREQ help TODO: Move CONFIG_SYS_CLK_FREQ for all the architecture
+config CONFIG_SYS_BOOTM_LEN + hex "Max uImage length" + help + Normally compressed uImages are limited to an uncompressed size of + 8 MBytes. If this is not enough, you can define CONFIG_SYS_BOOTM_LEN + to adjust this setting to your needs. + endmenu # Boot images
source "common/Kconfig"
On Wed, Sep 23, 2015 at 10:25:35AM -0700, Ryan Harkin wrote:
As config migrates from board config files to Kconfig, when adding CONFIG_SYS_BOOTM_LEN to a platform, I decided to add Kconfig support for CONFIG_SYS_BOOTM_LEN.
Signed-off-by: Ryan Harkin ryan.harkin@linaro.org Reviewed-by: Linus Walleij linus.walleij@linaro.org CC: Masahiro Yamada yamada.m@jp.panasonic.com CC: Simon Glass sjg@chromium.org CC: Linus Walleij linus.walleij@linaro.org
Thanks for trying to do this. The problem however is that you need to use tools/moveconfig.py so that all of the other boards (which is a lot) get updated too, otherwise they fail to build.
Since that's kind of a big thing, can you split this series into a v2 of things which really should be in before the release, and then nice cleanups like this which can go in once the merge window is open again? Thanks!
Thanks Tom.
On 28 September 2015 at 16:10, Tom Rini trini@konsulko.com wrote:
On Wed, Sep 23, 2015 at 10:25:35AM -0700, Ryan Harkin wrote:
As config migrates from board config files to Kconfig, when adding CONFIG_SYS_BOOTM_LEN to a platform, I decided to add Kconfig support for CONFIG_SYS_BOOTM_LEN.
Signed-off-by: Ryan Harkin ryan.harkin@linaro.org Reviewed-by: Linus Walleij linus.walleij@linaro.org CC: Masahiro Yamada yamada.m@jp.panasonic.com CC: Simon Glass sjg@chromium.org CC: Linus Walleij linus.walleij@linaro.org
Thanks for trying to do this. The problem however is that you need to use tools/moveconfig.py so that all of the other boards (which is a lot) get updated too, otherwise they fail to build.
Yes, I just read another email on the list about using moveconfig.py. That's a big job, as you say.
Since that's kind of a big thing, can you split this series into a v2 of things which really should be in before the release, and then nice cleanups like this which can go in once the merge window is open again?
Thanks!
So I should post a v2 that uses CONFIG_SYS_BOOTM_LEN like all the other boards for now? Then submit a new series to use moveconfig.py to Kconfig?
I already tried using moveconfig.py for this and it fails on every instance, from what I can tell. I think the other board configs using the shift operation makes this tricky.
I guess there are two options: make Kconfig support complex values (eg. to allow << operators, etc.) or convert all the other boards to use absolute values. Of course, another option is to leave it alone.
-- Tom
On Mon, Sep 28, 2015 at 04:35:09PM +0100, Ryan Harkin wrote:
Thanks Tom.
On 28 September 2015 at 16:10, Tom Rini trini@konsulko.com wrote:
On Wed, Sep 23, 2015 at 10:25:35AM -0700, Ryan Harkin wrote:
As config migrates from board config files to Kconfig, when adding CONFIG_SYS_BOOTM_LEN to a platform, I decided to add Kconfig support for CONFIG_SYS_BOOTM_LEN.
Signed-off-by: Ryan Harkin ryan.harkin@linaro.org Reviewed-by: Linus Walleij linus.walleij@linaro.org CC: Masahiro Yamada yamada.m@jp.panasonic.com CC: Simon Glass sjg@chromium.org CC: Linus Walleij linus.walleij@linaro.org
Thanks for trying to do this. The problem however is that you need to use tools/moveconfig.py so that all of the other boards (which is a lot) get updated too, otherwise they fail to build.
Yes, I just read another email on the list about using moveconfig.py. That's a big job, as you say.
Since that's kind of a big thing, can you split this series into a v2 of things which really should be in before the release, and then nice cleanups like this which can go in once the merge window is open again?
Thanks!
So I should post a v2 that uses CONFIG_SYS_BOOTM_LEN like all the other boards for now? Then submit a new series to use moveconfig.py to Kconfig?
Yeah, for this release at least.
I already tried using moveconfig.py for this and it fails on every instance, from what I can tell. I think the other board configs using the shift operation makes this tricky.
I guess there are two options: make Kconfig support complex values (eg. to allow << operators, etc.) or convert all the other boards to use absolute values. Of course, another option is to leave it alone.
Well, if you can convince the Kconfig folks to take shift operations as valid values on numeric inputs I bet other projects would appreciate it. But it might be easier to start with a "simple" script that finds all of the configs that define it to a shifted value and use printf to convert it to hex. Then moveconfig.py should be able to convert.
Hi,
On 28-09-15 17:10, Tom Rini wrote:
On Wed, Sep 23, 2015 at 10:25:35AM -0700, Ryan Harkin wrote:
As config migrates from board config files to Kconfig, when adding CONFIG_SYS_BOOTM_LEN to a platform, I decided to add Kconfig support for CONFIG_SYS_BOOTM_LEN.
Signed-off-by: Ryan Harkin ryan.harkin@linaro.org Reviewed-by: Linus Walleij linus.walleij@linaro.org CC: Masahiro Yamada yamada.m@jp.panasonic.com CC: Simon Glass sjg@chromium.org CC: Linus Walleij linus.walleij@linaro.org
Thanks for trying to do this. The problem however is that you need to use tools/moveconfig.py so that all of the other boards (which is a lot) get updated too, otherwise they fail to build.
No, just no, not more polluting of defconfig files with things which really belong in a per SoC file not a per board file.
I think we can fix the "make savedefconfig" warnings by doing something like this in a per SoC Kconfig file:
if ARCH_SUNXI
defconfig SYS_BOOTM_LEN default 0x0f000000 if ARCH_SUNXI
endif
The second "if ARCH_SUNXI" is necessary to stop the script calling "make savedefconfig" for all boards to clean the defconfig files from complaining.
Please let set per SoC defaults this way rather then turning the defconfig files in a mixture of board / soc settings where as they should really only select the SoC and then contain board specific settings on top of that.
Regards,
Hans
On Mon, Sep 28, 2015 at 09:22:35PM +0200, Hans de Goede wrote:
Hi,
On 28-09-15 17:10, Tom Rini wrote:
On Wed, Sep 23, 2015 at 10:25:35AM -0700, Ryan Harkin wrote:
As config migrates from board config files to Kconfig, when adding CONFIG_SYS_BOOTM_LEN to a platform, I decided to add Kconfig support for CONFIG_SYS_BOOTM_LEN.
Signed-off-by: Ryan Harkin ryan.harkin@linaro.org Reviewed-by: Linus Walleij linus.walleij@linaro.org CC: Masahiro Yamada yamada.m@jp.panasonic.com CC: Simon Glass sjg@chromium.org CC: Linus Walleij linus.walleij@linaro.org
Thanks for trying to do this. The problem however is that you need to use tools/moveconfig.py so that all of the other boards (which is a lot) get updated too, otherwise they fail to build.
No, just no, not more polluting of defconfig files with things which really belong in a per SoC file not a per board file.
Well, we should be putting SoC/arch-specific stuff into the defaults and also using this as a chance to look at places where defaults differ pointlessly.
But, I also hear your concern. I see Masahiro has been working with merge_config.sh from the kernel in the kernel. How crazy would it be to re-work things (in some cases..) to have a merge in the config process so that there could be a sunxi-common config fragment. Or can/should we really just use default foo if Y in more places.
Hi,
On 28-09-15 23:12, Tom Rini wrote:
On Mon, Sep 28, 2015 at 09:22:35PM +0200, Hans de Goede wrote:
Hi,
On 28-09-15 17:10, Tom Rini wrote:
On Wed, Sep 23, 2015 at 10:25:35AM -0700, Ryan Harkin wrote:
As config migrates from board config files to Kconfig, when adding CONFIG_SYS_BOOTM_LEN to a platform, I decided to add Kconfig support for CONFIG_SYS_BOOTM_LEN.
Signed-off-by: Ryan Harkin ryan.harkin@linaro.org Reviewed-by: Linus Walleij linus.walleij@linaro.org CC: Masahiro Yamada yamada.m@jp.panasonic.com CC: Simon Glass sjg@chromium.org CC: Linus Walleij linus.walleij@linaro.org
Thanks for trying to do this. The problem however is that you need to use tools/moveconfig.py so that all of the other boards (which is a lot) get updated too, otherwise they fail to build.
No, just no, not more polluting of defconfig files with things which really belong in a per SoC file not a per board file.
Well, we should be putting SoC/arch-specific stuff into the defaults
Agreed, but where, do we add a long list of:
default FOO if ARCH_BAR
To the Kconfig file where the actual CONFIG_SOMETHING gets defined, or do we add it to board/bar/Kconfig ? Currently we've a bit of a mix, I personally prefer the board/bar/Kconfig version as that puts everything for one SoC(-family) in one place and it helps avoiding merge conflicts.
and also using this as a chance to look at places where defaults differ pointlessly.
But, I also hear your concern. I see Masahiro has been working with merge_config.sh from the kernel in the kernel. How crazy would it be to re-work things (in some cases..) to have a merge in the config process so that there could be a sunxi-common config fragment.
Either we then ask the user to take an extra step during building (not a good idea IMHO), or we somehow need to automate this, which is hard because figuring out which foo_common_config fragment belongs to which board_defconfig file is going to be hard and / or will involve a long list of hardcoded values in a Makefile or some such.
Or can/should we really just use default foo if Y in more places.
I believe that this is the better option, currently board/sunxi/Kconfig already has:
config SYS_CLK_FREQ default 912000000 if MACH_SUN7I default 1008000000 if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I || MACH_SUN8I
config SYS_CONFIG_NAME default "sun4i" if MACH_SUN4I default "sun5i" if MACH_SUN5I default "sun6i" if MACH_SUN6I default "sun7i" if MACH_SUN7I default "sun8i" if MACH_SUN8I default "sun9i" if MACH_SUN9I
Apparently these are not a problem for the script which is used to rewrite all the defconfig-s, where as in the past having:
config CMD_FOO default y
in board/sunxi/Kconfig was a problem (it caused the script to emit a ton of warnings IIRC) so I guess that doing something like:
config FOO default bar if ARCH_SUNXI
Will workaround the script issuing all kind of warnings, and then we can keep per SoC(-family) defaults in board/foo/Kconfig.
Regards,
Hans
vexpress64 kernels are usually over 8 MBytes in length, so setting the max uImage length to 0x4000000 (64 Mbytes) should give us plenty of scope for expansion.
I mostly chose this length to match other board configs that use "(64 << 20)", however, Kconfig doesn't allow arithmetic operations.
Signed-off-by: Ryan Harkin ryan.harkin@linaro.org Reviewed-by: Linus Walleij linus.walleij@linaro.org CC: Masahiro Yamada <yamada.m@jp.panasonic.com CC: Linus Walleij linus.walleij@linaro.org --- board/armltd/vexpress64/Kconfig | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/board/armltd/vexpress64/Kconfig b/board/armltd/vexpress64/Kconfig index 8da3bec..72679be 100644 --- a/board/armltd/vexpress64/Kconfig +++ b/board/armltd/vexpress64/Kconfig @@ -1,3 +1,6 @@ +config CONFIG_SYS_BOOTM_LEN + default 0x4000000 + config SYS_BOARD default "vexpress64"
On Wed, Sep 23, 2015 at 10:25:36AM -0700, Ryan Harkin wrote:
vexpress64 kernels are usually over 8 MBytes in length, so setting the max uImage length to 0x4000000 (64 Mbytes) should give us plenty of scope for expansion.
I mostly chose this length to match other board configs that use "(64 << 20)", however, Kconfig doesn't allow arithmetic operations.
Signed-off-by: Ryan Harkin ryan.harkin@linaro.org Reviewed-by: Linus Walleij linus.walleij@linaro.org CC: Masahiro Yamada <yamada.m@jp.panasonic.com CC: Linus Walleij linus.walleij@linaro.org
board/armltd/vexpress64/Kconfig | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/board/armltd/vexpress64/Kconfig b/board/armltd/vexpress64/Kconfig index 8da3bec..72679be 100644 --- a/board/armltd/vexpress64/Kconfig +++ b/board/armltd/vexpress64/Kconfig @@ -1,3 +1,6 @@ +config CONFIG_SYS_BOOTM_LEN
- default 0x4000000
config SYS_BOARD default "vexpress64"
First, this is a typo (should be SYS_BOOTM_LEN, not CONFIG_SYS_BOOTM_LEN) and second, this sounds more like it should be set as the default for say aarch64 when adding the option to Kconfig. Or maybe a more broad default even. moveconfig.py will help make it clearer how many boards use what.
Create an additional FVP configuration to boot images pre-loaded into DRAM.
Sometimes it's preferential to boot the model by loading the files directly into DRAM via model parameters, rather than using SemiHosting.
An example of model parmaters that are used to pre-load the files into DRAM: --data cluster0.cpu0=Image@0x80080000 \ --data cluster0.cpu0=fvp-base-gicv2-psci.dtb@0x83000000 \ --data cluster0.cpu0=uInitrd@0x84000000
Signedoff-by: Ryan Harkin ryan.harkin@linaro.org Reviewed-by: Linus Walleij linus.walleij@linaro.org CC: David Feng fenghua@phytium.com.cn CC: Bhupesh Sharma bhupesh.sharma@freescale.com CC: Linus Walleij linus.walleij@linaro.org --- arch/arm/Kconfig | 4 ++++ configs/vexpress_aemv8a_dram_defconfig | 19 +++++++++++++++++++ include/configs/vexpress_aemv8a.h | 25 +++++++++++++++++++++++-- 3 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index c4371c7..c62c3de 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -563,6 +563,10 @@ config TARGET_VEXPRESS64_BASE_FVP select ARM64 select SEMIHOSTING
+config TARGET_VEXPRESS64_BASE_FVP_DRAM + bool "Support Versatile Express ARMv8a FVP BASE model booting from DRAM" + select ARM64 + config TARGET_VEXPRESS64_JUNO bool "Support Versatile Express Juno Development Platform" select ARM64 diff --git a/configs/vexpress_aemv8a_dram_defconfig b/configs/vexpress_aemv8a_dram_defconfig new file mode 100644 index 0000000..e9fc870 --- /dev/null +++ b/configs/vexpress_aemv8a_dram_defconfig @@ -0,0 +1,19 @@ +CONFIG_ARM=y +CONFIG_TARGET_VEXPRESS64_BASE_FVP_DRAM=y +CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_DEFAULT_DEVICE_TREE="vexpress64" +# 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_LOADS is not set +# CONFIG_CMD_FLASH is not set +# CONFIG_CMD_FPGA is not set +# CONFIG_CMD_ITEST is not set +# CONFIG_CMD_SETEXPR is not set +# CONFIG_CMD_NFS is not set +# CONFIG_CMD_MISC is not set +CONFIG_DM=y +CONFIG_DM_SERIAL=y +CONFIG_SYS_PROMPT="VExpress64# " diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h index 53b0f74..0228732 100644 --- a/include/configs/vexpress_aemv8a.h +++ b/include/configs/vexpress_aemv8a.h @@ -30,7 +30,8 @@ #define CONFIG_BOOTP_VCI_STRING "U-boot.armv8.vexpress_aemv8a"
/* Link Definitions */ -#ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP +#if defined(CONFIG_TARGET_VEXPRESS64_BASE_FVP) || \ + defined(CONFIG_TARGET_VEXPRESS64_BASE_FVP_DRAM) /* 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) @@ -101,7 +102,8 @@ #define GICR_BASE (0x2f100000) #else
-#ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP +#if defined(CONFIG_TARGET_VEXPRESS64_BASE_FVP) || \ + defined(CONFIG_TARGET_VEXPRESS64_BASE_FVP_DRAM) #define GICD_BASE (0x2f000000) #define GICC_BASE (0x2c000000) #elif CONFIG_TARGET_VEXPRESS64_JUNO @@ -231,6 +233,25 @@
#define CONFIG_BOOTDELAY 1
+#elif CONFIG_TARGET_VEXPRESS64_BASE_FVP_DRAM +#define CONFIG_EXTRA_ENV_SETTINGS \ + "kernel_addr=0x80080000\0" \ + "initrd_addr=0x84000000\0" \ + "fdt_addr=0x83000000\0" \ + "fdt_high=0xffffffffffffffff\0" \ + "initrd_high=0xffffffffffffffff\0" + +#define CONFIG_BOOTARGS "console=ttyAMA0 earlyprintk=pl011,"\ + "0x1c090000 debug user_debug=31 "\ + "androidboot.hardware=fvpbase "\ + "root=/dev/vda2 rw "\ + "rootwait "\ + "loglevel=9" + +#define CONFIG_BOOTCOMMAND "booti $kernel_addr $initrd_addr $fdt_addr" + +#define CONFIG_BOOTDELAY 1 + #else #error "Unknown board variant" #endif
On Wed, Sep 23, 2015 at 10:25:37AM -0700, Ryan Harkin wrote:
Create an additional FVP configuration to boot images pre-loaded into DRAM.
Sometimes it's preferential to boot the model by loading the files directly into DRAM via model parameters, rather than using SemiHosting.
An example of model parmaters that are used to pre-load the files into DRAM: --data cluster0.cpu0=Image@0x80080000 \ --data cluster0.cpu0=fvp-base-gicv2-psci.dtb@0x83000000 \ --data cluster0.cpu0=uInitrd@0x84000000
Signedoff-by: Ryan Harkin ryan.harkin@linaro.org Reviewed-by: Linus Walleij linus.walleij@linaro.org CC: David Feng fenghua@phytium.com.cn CC: Bhupesh Sharma bhupesh.sharma@freescale.com CC: Linus Walleij linus.walleij@linaro.org
arch/arm/Kconfig | 4 ++++ configs/vexpress_aemv8a_dram_defconfig | 19 +++++++++++++++++++
Make sure you add an entry to board/armltd/vexpress64/MAINTAINERS for this board too so buildman doesn't warn about a missing maintainer. Thanks!
On 28 September 2015 at 16:14, Tom Rini trini@konsulko.com wrote:
On Wed, Sep 23, 2015 at 10:25:37AM -0700, Ryan Harkin wrote:
Create an additional FVP configuration to boot images pre-loaded into DRAM.
Sometimes it's preferential to boot the model by loading the files directly into DRAM via model parameters, rather than using SemiHosting.
An example of model parmaters that are used to pre-load the files into DRAM: --data cluster0.cpu0=Image@0x80080000 \ --data cluster0.cpu0=fvp-base-gicv2-psci.dtb@0x83000000 \ --data cluster0.cpu0=uInitrd@0x84000000
Signedoff-by: Ryan Harkin ryan.harkin@linaro.org Reviewed-by: Linus Walleij linus.walleij@linaro.org CC: David Feng fenghua@phytium.com.cn CC: Bhupesh Sharma bhupesh.sharma@freescale.com CC: Linus Walleij linus.walleij@linaro.org
arch/arm/Kconfig | 4 ++++ configs/vexpress_aemv8a_dram_defconfig | 19 +++++++++++++++++++
Make sure you add an entry to board/armltd/vexpress64/MAINTAINERS for this board too so buildman doesn't warn about a missing maintainer. Thanks!
Good point, thanks. I'll do it for v2.
-- Tom
Linaro's Juno Android builds requires the androidboot.hardware parameter be set to a know board name.
Non-Android kernels ignore this extra parameter because they don't contain code to parse it.
Signed-off-by: Ryan Harkin ryan.harkin@linaro.org Reviewed-by: Linus Walleij linus.walleij@linaro.org CC: David Feng fenghua@phytium.com.cn CC: Bhupesh Sharma bhupesh.sharma@freescale.com CC: Linus Walleij linus.walleij@linaro.org --- include/configs/vexpress_aemv8a.h | 1 + 1 file changed, 1 insertion(+)
diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h index 0228732..5198b32 100644 --- a/include/configs/vexpress_aemv8a.h +++ b/include/configs/vexpress_aemv8a.h @@ -198,6 +198,7 @@ "rootwait "\ "earlyprintk=pl011,0x7ff80000 debug "\ "user_debug=31 "\ + "androidboot.hardware=juno "\ "loglevel=9"
/* Copy the kernel and FDT to DRAM memory and boot */
Add a command to the ARM flash support to check if an image exists or not.
If the image is found, it will return CMD_RET_SUCCESS, else CMD_RET_FAILURE. This allows hush scripts to conditionally load images.
A simple example:
if afs exists ${kernel_name}; then echo found; else echo \ not found; fi
Signed-off-by: Ryan Harkin ryan.harkin@linaro.org Reviewed-by: Linus Walleij linus.walleij@linaro.org CC: David Feng fenghua@phytium.com.cn CC: Bhupesh Sharma bhupesh.sharma@freescale.com CC: Linus Walleij linus.walleij@linaro.org --- common/cmd_armflash.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/common/cmd_armflash.c b/common/cmd_armflash.c index 1db92b0..a37f5c4 100644 --- a/common/cmd_armflash.c +++ b/common/cmd_armflash.c @@ -251,10 +251,28 @@ static void print_images(void) } }
+static int exists(const char * const name) +{ + int i; + + parse_flash(); + for (i = 0; i < num_afs_images; i++) { + struct afs_image *afi = &afs_images[i]; + + if (strcmp(afi->name, name) == 0) + return CMD_RET_SUCCESS; + } + return CMD_RET_FAILURE; +} + static int do_afs(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) { + int ret = CMD_RET_SUCCESS; + if (argc == 1) { print_images(); + } else if (argc == 3 && !strcmp(argv[1], "exists")) { + ret = exists(argv[2]); } else if (argc == 3 && !strcmp(argv[1], "load")) { load_image(argv[2], 0x0); } else if (argc == 4 && !strcmp(argv[1], "load")) { @@ -266,12 +284,14 @@ static int do_afs(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) return CMD_RET_USAGE; }
- return 0; + return ret; }
U_BOOT_CMD(afs, 4, 0, do_afs, "show AFS partitions", "no arguments\n" " - list images in flash\n" + "exists <image>\n" + " - returns 1 if an image exists, else 0\n" "load <image>\n" " - load an image to the location indicated in the header\n" "load <image> 0x<address>\n"
Change the load_image so that it returns success or failure of the command (using CMD_RET_SUCCESS or CMD_RET_FAILURE).
This way, hush scripts can optionally load different files depending upon the system configuration.
A simple example:
if afs load ${kernel_name} ${kernel_addr}; then echo loaded; else echo \ not loaded; fi
Signed-off-by: Ryan Harkin ryan.harkin@linaro.org Reviewed-by: Linus Walleij linus.walleij@linaro.org CC: Linus Walleij linus.walleij@linaro.org --- common/cmd_armflash.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/common/cmd_armflash.c b/common/cmd_armflash.c index a37f5c4..02b7fee 100644 --- a/common/cmd_armflash.c +++ b/common/cmd_armflash.c @@ -175,7 +175,7 @@ static void parse_flash(void) parse_bank(bank); }
-static void load_image(const char * const name, const ulong address) +static int load_image(const char * const name, const ulong address) { struct afs_image *afi = NULL; int i; @@ -191,7 +191,7 @@ static void load_image(const char * const name, const ulong address) } if (!afi) { printf("image "%s" not found in flash\n", name); - return; + return CMD_RET_FAILURE; }
for (i = 0; i < afi->region_count; i++) { @@ -215,6 +215,7 @@ static void load_image(const char * const name, const ulong address) to, afi->regions[i].size); } + return CMD_RET_SUCCESS; }
static void print_images(void) @@ -274,12 +275,12 @@ static int do_afs(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) } else if (argc == 3 && !strcmp(argv[1], "exists")) { ret = exists(argv[2]); } else if (argc == 3 && !strcmp(argv[1], "load")) { - load_image(argv[2], 0x0); + ret = load_image(argv[2], 0x0); } else if (argc == 4 && !strcmp(argv[1], "load")) { ulong load_addr;
load_addr = simple_strtoul(argv[3], NULL, 16); - load_image(argv[2], load_addr); + ret = load_image(argv[2], load_addr); } else { return CMD_RET_USAGE; }
Some OS images require an initrd on Juno.
If the file ramdisk.img exists in NOR flash, then we load it and pass the address to the kernel. Otherwise, we pass the "-" parameter as before.
Signed-off-by: Ryan Harkin ryan.harkin@linaro.org Reviewed-by: Linus Walleij linus.walleij@linaro.org CC: David Feng fenghua@phytium.com.cn CC: Bhupesh Sharma bhupesh.sharma@freescale.com CC: Linus Walleij linus.walleij@linaro.org --- include/configs/vexpress_aemv8a.h | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h index 5198b32..c62c3ac 100644 --- a/include/configs/vexpress_aemv8a.h +++ b/include/configs/vexpress_aemv8a.h @@ -187,6 +187,8 @@ #define CONFIG_EXTRA_ENV_SETTINGS \ "kernel_name=Image\0" \ "kernel_addr=0x80000000\0" \ + "initrd_name=ramdisk.img\0" \ + "initrd_addr=0x84000000\0" \ "fdt_name=juno\0" \ "fdt_addr=0x83000000\0" \ "fdt_high=0xffffffffffffffff\0" \ @@ -205,7 +207,12 @@ #define CONFIG_BOOTCOMMAND "afs load ${kernel_name} ${kernel_addr} ; " \ "afs load ${fdt_name} ${fdt_addr} ; " \ "fdt addr ${fdt_addr}; fdt resize; " \ - "booti ${kernel_addr} - ${fdt_addr}" + "if afs load ${initrd_name} ${initrd_addr} ; "\ + "then "\ + " setenv initrd_param ${initrd_addr}; "\ + " else setenv initrd_param -; "\ + "fi ; " \ + "booti ${kernel_addr} ${initrd_param} ${fdt_addr}"
#define CONFIG_BOOTDELAY 1
The default Juno firmware has renamed the kernel and device tree filenames to norkern and board.dtb.
Rather than change the default configuration to use the new names, breaking those with the old firmware, attempt to load the existing filename first. If that fails, attempt to load the alternate filename.
I've echo'd that we are loading the alternate file to counter the output from "afs load" when the first load attempt fails. For example, I see this output on my Juno board:
image "Image" not found in flash Loading norkern instead of Image loaded region 0 from 08500000 to 80000000, 00AB6318 bytes image "juno" not found in flash Loading board.dtb instead of juno loaded region 0 from 0A000000 to 83000000, 00003188 bytes
Signed-off-by: Ryan Harkin ryan.harkin@linaro.org Reviewed-by: Linus Walleij linus.walleij@linaro.org CC: David Feng fenghua@phytium.com.cn CC: Bhupesh Sharma bhupesh.sharma@freescale.com CC: Linus Walleij linus.walleij@linaro.org --- include/configs/vexpress_aemv8a.h | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h index c62c3ac..192568a 100644 --- a/include/configs/vexpress_aemv8a.h +++ b/include/configs/vexpress_aemv8a.h @@ -185,11 +185,13 @@ * be copied into DRAM */ #define CONFIG_EXTRA_ENV_SETTINGS \ - "kernel_name=Image\0" \ + "kernel_name=norkern\0" \ + "kernel_alt_name=Image\0" \ "kernel_addr=0x80000000\0" \ "initrd_name=ramdisk.img\0" \ "initrd_addr=0x84000000\0" \ - "fdt_name=juno\0" \ + "fdt_name=board.dtb\0" \ + "fdt_alt_name=juno\0" \ "fdt_addr=0x83000000\0" \ "fdt_high=0xffffffffffffffff\0" \ "initrd_high=0xffffffffffffffff\0" \ @@ -205,7 +207,17 @@
/* Copy the kernel and FDT to DRAM memory and boot */ #define CONFIG_BOOTCOMMAND "afs load ${kernel_name} ${kernel_addr} ; " \ + "if test $? -eq 1; then "\ + " echo Loading ${kernel_alt_name} instead of "\ + "${kernel_name}; "\ + " afs load ${kernel_alt_name} ${kernel_addr};"\ + "fi ; "\ "afs load ${fdt_name} ${fdt_addr} ; " \ + "if test $? -eq 1; then "\ + " echo Loading ${fdt_alt_name} instead of "\ + "${fdt_name}; "\ + " afs load ${fdt_alt_name} ${fdt_addr}; "\ + "fi ; "\ "fdt addr ${fdt_addr}; fdt resize; " \ "if afs load ${initrd_name} ${initrd_addr} ; "\ "then "\
This patch changes the default "root=" parameter to "/dev/sda2".
Many linux based distros use /dev/sda1 for their boot partition; this is often not a rootfs that can be used by the "root=" parameter.
Linaro images use /dev/sda1 as a boot partition, although this of a different nature to a distro image. Linaro uses /dev/sda2 for the rootfs partition.
Signed-off-by: Ryan Harkin ryan.harkin@linaro.org Reviewed-by: Linus Walleij linus.walleij@linaro.org CC: David Feng fenghua@phytium.com.cn CC: Bhupesh Sharma bhupesh.sharma@freescale.com CC: Linus Walleij linus.walleij@linaro.org --- include/configs/vexpress_aemv8a.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h index 192568a..4054f58 100644 --- a/include/configs/vexpress_aemv8a.h +++ b/include/configs/vexpress_aemv8a.h @@ -198,7 +198,7 @@
/* Assume we boot with root on the first partition of a USB stick */ #define CONFIG_BOOTARGS "console=ttyAMA0,115200n8 " \ - "root=/dev/sda1 rw " \ + "root=/dev/sda2 rw " \ "rootwait "\ "earlyprintk=pl011,0x7ff80000 debug "\ "user_debug=31 "\
[+CC Linus]
On 23 September 2015 at 18:25, Ryan Harkin ryan.harkin@linaro.org wrote:
This patch series updates the default configuration of the vexpress64 FVP and Juno platforms to allow it to work on a variety of setups without modification by the user.
[PATCH 01/11] vexpress64: fix checkpatch warnings [PATCH 02/11] vexpress64: Kconfig: tidy up [PATCH 03/11] Kconfig: add CONFIG_SYS_BOOTM_LEN [PATCH 04/11] vexpress64: Kconfig: add CONFIG_SYS_BOOTM_LEN [PATCH 05/11] vexpress64: fvp dram: add DRAM configuration [PATCH 06/11] vexpress64: juno: add androidboot.hardware=juno [PATCH 07/11] common/armflash: add command to check if image exists [PATCH 08/11] common/armflash: load_image returns success or failure [PATCH 09/11] vexpress64: juno: add optional initrd [PATCH 10/11] vexpress64: juno: add alternate kernel and device tree [PATCH 11/11] vexpress64: juno: use /dev/sda2
Kconfig | 7 +++++++ arch/arm/Kconfig | 4 ++++ board/armltd/vexpress64/Kconfig | 18 ++---------------- common/cmd_armflash.c | 31 ++++++++++++++++++++++++++----- configs/vexpress_aemv8a_dram_defconfig | 19 +++++++++++++++++++ include/configs/vexpress_aemv8a.h | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++-------- 6 files changed, 109 insertions(+), 29 deletions(-)
On Wed, Sep 23, 2015 at 10:25 AM, Ryan Harkin ryan.harkin@linaro.org wrote:
This patch series updates the default configuration of the vexpress64 FVP and Juno platforms to allow it to work on a variety of setups without modification by the user.
[PATCH 01/11] vexpress64: fix checkpatch warnings [PATCH 02/11] vexpress64: Kconfig: tidy up [PATCH 03/11] Kconfig: add CONFIG_SYS_BOOTM_LEN [PATCH 04/11] vexpress64: Kconfig: add CONFIG_SYS_BOOTM_LEN [PATCH 05/11] vexpress64: fvp dram: add DRAM configuration [PATCH 06/11] vexpress64: juno: add androidboot.hardware=juno [PATCH 07/11] common/armflash: add command to check if image exists [PATCH 08/11] common/armflash: load_image returns success or failure [PATCH 09/11] vexpress64: juno: add optional initrd [PATCH 10/11] vexpress64: juno: add alternate kernel and device tree [PATCH 11/11] vexpress64: juno: use /dev/sda2
I've reviewed all these off Ryan's GIT tree and they carry my Reviewed-by so please merge.
Yours, Linus Walleij
participants (4)
-
Hans de Goede -
Linus Walleij -
Ryan Harkin -
Tom Rini