RFC unified boot environment
Hi All,
The attached patches build on the work for generic distro config, as well as Stephen Warrens implementation for tegra.
I have added a header to be included that will allow all boards to boot in the same way and I have ported over two boards to use it. One thought I have had is to move the environment into the same header as the generic config.
I am also working on writing a README.distro file to document everything that needs to be set for everything to just work. Along with information on how to best choose memory locations.
Dennis
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
--- include/config_distro_bootcmd.h | 172 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 172 insertions(+) create mode 100644 include/config_distro_bootcmd.h
include/config_distro_bootcmd.h new file +172 -0
@@ -0,0 +1,172 @@ +/* +* (C) Copyright 2014 +* NVIDIA Corporation <www.nvidia.com> +* +* Copyright 2014 Red Hat, Inc. +* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H +#define _CONFIG_CMD_DISTRO_BOOTCMD_H + + +#ifdef CONFIG_CMD_MMC +#define BOOTCMDS_MMC \ + "mmc_boot=" \ + "setenv devtype mmc; " \ + "if mmc dev ${devnum}; then " \ + "run scan_boot; " \ + "fi\0" \ + "bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \ + "bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0" +#define BOOT_TARGETS_MMC "mmc1 mmc0" +#else +#define BOOTCMDS_MMC "" +#define BOOT_TARGETS_MMC "" +#endif + +#ifdef CONFIG_CMD_USB +#define BOOTCMD_INIT_USB "run usb_init; " +#define BOOTCMDS_USB \ + "usb_init=" \ + "if ${usb_need_init}; then " \ + "set usb_need_init false; " \ + "usb start 0; " \ + "fi\0" \ + \ + "usb_boot=" \ + "setenv devtype usb; " \ + BOOTCMD_INIT_USB \ + "if usb dev ${devnum}; then " \ + "run scan_boot; " \ + "fi\0" \ + \ + "bootcmd_usb0=setenv devnum 0; run usb_boot;\0" +#define BOOT_TARGETS_USB "usb0" +#else +#define BOOTCMD_INIT_USB "" +#define BOOTCMDS_USB "" +#define BOOT_TARGETS_USB "" +#endif + +#ifdef CONFIG_CMD_SATA +#define BOOTCMDS_SATA \ + "sata_boot=" \ + "setenv devtype sata; " \ + "if sata dev ${devnum}; then " \ + "run scan_boot; " \ + "fi\0" \ + \ + "bootcmd_sata0=setenv devnum 0; run sata_boot;\0" + "bootcmd_sata1=setenv devnum 1; run sata_boot;\0" +#define BOOT_TARGETS_USB "sata0 sata1" +#else +#define BOOTCMDS_SATA "" +#define BOOT_TARGETS_SATA "" +#endif + +#ifdef CONFIG_CMD_DHCP +#define BOOTCMDS_DHCP \ + "bootcmd_dhcp=" \ + BOOTCMD_INIT_USB \ + "if dhcp ${scriptaddr} boot.scr.uimg; then "\ + "source ${scriptaddr}; " \ + "fi\0" +#define BOOT_TARGETS_DHCP "dhcp" +#else +#define BOOTCMDS_DHCP "" +#define BOOT_TARGETS_DHCP "" +#endif + +#if defined(CONFIG_CMD_DHCP ) && defined(CONFIG_CMD_PXE ) +#define BOOTCMDS_PXE \ + "bootcmd_pxe=" \ + BOOTCMD_INIT_USB \ + "dhcp; " \ + "if pxe get; then " \ + "pxe boot; " \ + "fi\0" +#define BOOT_TARGETS_PXE "pxe" +#else +#define BOOTCMDS_PXE "" +#define BOOT_TARGETS_PXE "" +#endif + +#define BOOTCMDS_COMMON \ + "rootpart=1\0" \ + \ + "do_envimport=" \ + "load ${devtype} ${devnum}:${rootpart} ${loadaddr} " \ + "${environment}\0" \ + "env import -t ${loadaddr} $filesize\0" \ + \ + "envimport=" \ + "for environment in ${boot_envs}; do " \ + "if test -e ${devtype} ${devnum}:${rootpart} " \ + "${prefix}${environment}; then " \ + "echo Found U-Boot environment " \ + "${prefix}${environment}; " \ + "run do_envimport;" \ + "echo Import FAILED; continuing...; " \ + "fi; " \ + "done\0" \ + \ + "do_script_boot=" \ + "load ${devtype} ${devnum}:${rootpart} " \ + "${scriptaddr} ${prefix}${script}; " \ + "source ${scriptaddr}\0" \ + \ + "script_boot=" \ + "for script in ${boot_scripts}; do " \ + "if test -e ${devtype} ${devnum}:${rootpart} " \ + "${prefix}${script}; then " \ + "echo Found U-Boot script " \ + "${prefix}${script}; " \ + "run do_script_boot;" \ + "echo SCRIPT FAILED; continuing...; " \ + "fi; " \ + "done\0" \ + \ + "do_sysboot_boot=" \ + "sysboot ${devtype} ${devnum}:${rootpart} any " \ + "${scriptaddr} ${prefix}extlinux/extlinux.conf\0" \ + \ + "sysboot_boot=" \ + "if test -e ${devtype} ${devnum}:${rootpart} " \ + "${prefix}extlinux/extlinux.conf; then " \ + "echo Found extlinux config " \ + "${prefix}extlinux/extlinux.conf; " \ + "run do_sysboot_boot;" \ + "echo SYSBOOT FAILED; continuing...; " \ + "fi\0" \ + \ + "scan_boot=" \ + "echo Scanning ${devtype} ${devnum}...; " \ + "for prefix in ${boot_prefixes}; do " \ + "run sysboot_boot; " \ + "run envimport; " \ + "run script_boot; " \ + "done\0" \ + \ + "boot_targets=" \ + BOOT_TARGETS_MMC " " \ + BOOT_TARGETS_USB " " \ + BOOT_TARGETS_SATA " " \ + BOOT_TARGETS_PXE " " \ + BOOT_TARGETS_DHCP " " \ + "\0" \ + \ + "boot_prefixes=/ /boot/\0" \ + \ + "boot_scripts=boot.scr.uimg boot.scr\0" \ + \ + "boot_envs=uEnv.txt\0" \ + \ + BOOTCMDS_MMC \ + BOOTCMDS_USB \ + BOOTCMDS_SATA \ + BOOTCMDS_DHCP \ + BOOTCMDS_PXE + +#endif /* _CONFIG_CMD_DISTRO_BOOTCMD_H */
Signature · 1 line
1.8.5.3
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 1 line · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>
[snip]
include/config_distro_bootcmd.h line 35
Quoted 3 lines
include/config_distro_bootcmd.h new file +3
-0+"if ${usb_need_init}; then " \ +"set usb_need_init false; " \ +"usb start 0; " \
Checking common/cmd_usb.c, 'start' doesn't take arguments.
include/config_distro_bootcmd.h line 63
Quoted 11 lines
include/config_distro_bootcmd.h new file +11
-0+#ifdef CONFIG_CMD_SATA +#define BOOTCMDS_SATA \ + "sata_boot=" \ + "setenv devtype sata; " \ + "if sata dev ${devnum}; then " \ + "run scan_boot; " \ + "fi\0" \ + \ + "bootcmd_sata0=setenv devnum 0; run sata_boot;\0" +"bootcmd_sata1=setenv devnum 1; run sata_boot;\0" +#define BOOT_TARGETS_USB "sata0 sata1"
Typo, s/USB/SATA/
include/config_distro_bootcmd.h line 72
Quoted 4 lines
include/config_distro_bootcmd.h new file +4
-0+#ifdef CONFIG_CMD_DHCP +#define BOOTCMDS_DHCP \ + "bootcmd_dhcp=" \ + BOOTCMD_INIT_USB \
Why BOOTCMD_INIT_USB here? For USB based networking? If so, add some comments please.
include/config_distro_bootcmd.h line 75
Quoted 3 lines
include/config_distro_bootcmd.h new file +3
-0+"if dhcp ${scriptaddr} boot.scr.uimg; then " \ +"source ${scriptaddr}; " \ +"fi\0"
This relies on autoload being true, so we should set that.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140219/94d8d906/attachment.pgp>
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 9 lines · On Wed, 19 Feb 2014 08:42:57 -0500 Tom Rini <[email protected]> wrote:
Quoted 1 line · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>[snip]
include/config_distro_bootcmd.h line 35
Quoted 3 lines
include/config_distro_bootcmd.h new file +3
-0+"if ${usb_need_init}; then " \ +"set usb_need_init false; " \ +"usb start 0; " \Checking
common/cmd_usb.c, 'start' doesn't take arguments.
Copied from tegra-common-post.h as is, will fix it up
Quoted 5 lines
Quoted 5 lines
include/config_distro_bootcmd.h new file +5
-0+#ifdef CONFIG_CMD_SATA +#define BOOTCMDS_SATA \ + "sata_boot=" \ + "setenv devtype sata; " \ + "if sata dev ${devnum}; then " \
Quoted 8 lines
include/config_distro_bootcmd.h line 63
Quoted 6 lines
include/config_distro_bootcmd.h new file +6
-0+"run scan_boot; " \ +"fi\0" \ + \ +"bootcmd_sata0=setenv devnum 0; run sata_boot;\0" +"bootcmd_sata1=setenv devnum 1; run sata_boot;\0" +#define BOOT_TARGETS_USB "sata0 sata1"Typo, s/USB/SATA/
will fix
Quoted 7 lines
include/config_distro_bootcmd.h line 72
Quoted 4 lines
include/config_distro_bootcmd.h new file +4
-0+#ifdef CONFIG_CMD_DHCP +#define BOOTCMDS_DHCP \ + "bootcmd_dhcp=" \ + BOOTCMD_INIT_USB \Why
BOOTCMD_INIT_USBhere? For USB based networking? If so, add some comments please.
It was Copied from tegra-common-post.h im assuming that it to support booting from a usb attached nic
Quoted 5 lines
include/config_distro_bootcmd.h line 75
Quoted 3 lines
include/config_distro_bootcmd.h new file +3
-0+"if dhcp ${scriptaddr} boot.scr.uimg; then " \ +"source ${scriptaddr}; " \ +"fi\0" This relies on autoload being true, so we should set that.
okay, will fix it up.
Thanks
Dennis
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
In reply to Dennis GilmoreQuoted 17 lines · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>--- include/config_distro_bootcmd.h | 172 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 172 insertions(+) create mode 100644 include/config_distro_bootcmd.h(quoted diff) +0
-0
b/include/config_distro_bootcmd.hnew file mode 100644 index 0000000..d32dc12include/config_distro_bootcmd.h new file +5
-0@@ -0,0 +1,172 @@ +/* +* (C) Copyright 2014 +* NVIDIA Corporation <www.nvidia.com> +* +* Copyright 2014 Red Hat, Inc.
include/config_distro_bootcmd.h line 15
Quoted 10 lines
include/config_distro_bootcmd.h new file +10
-0+* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H +#define _CONFIG_CMD_DISTRO_BOOTCMD_H + + +#ifdef CONFIG_CMD_MMC +#define BOOTCMDS_MMC \
You might want to #undef all this temporary stuff so it's not propagated into the U-Boot further.
Best regards,
Marek Vasut
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 23 lines · Marek Vasut
Quoted 22 lines · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>--- include/config_distro_bootcmd.h | 172 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 172 insertions(+) create mode 100644 include/config_distro_bootcmd.h(quoted diff) +0
-0
b/include/config_distro_bootcmd.hnew file mode 100644 index 0000000..d32dc12include/config_distro_bootcmd.h new file +10
-0@@ -0,0 +1,172 @@ +/* +* (C) Copyright 2014 +* NVIDIA Corporation <www.nvidia.com> +* +* Copyright 2014 Red Hat, Inc. +* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
Quoted 8 lines
include/config_distro_bootcmd.h line 15
Quoted 5 lines
include/config_distro_bootcmd.h new file +5
-0+#define _CONFIG_CMD_DISTRO_BOOTCMD_H + + +#ifdef CONFIG_CMD_MMC +#define BOOTCMDS_MMC \You might want to #undef all this temporary stuff so it's not propagated into the U-Boot further.
I don't understand. What temporary stuff are you referring to?
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 37 lines · Stephen Warren
Quoted 27 lines · Marek Vasut
Quoted 26 lines · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>---
include/config_distro_bootcmd.h | 172++++++++++++++++++++++++++++++++++++++++ 1 file changed, 172 insertions(+)
create mode 100644 include/config_distro_bootcmd.h(quoted diff) +0
-0
b/include/config_distro_bootcmd.hnew file mode 100644 index 0000000..d32dc12include/config_distro_bootcmd.h new file +10
-0@@ -0,0 +1,172 @@ +/* +* (C) Copyright 2014 +* NVIDIA Corporation <www.nvidia.com> +* +* Copyright 2014 Red Hat, Inc. +* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_HQuoted 8 lines
include/config_distro_bootcmd.h line 15
Quoted 5 lines
include/config_distro_bootcmd.h new file +5
-0+#define _CONFIG_CMD_DISTRO_BOOTCMD_H + + +#ifdef CONFIG_CMD_MMC +#define BOOTCMDS_MMC \You might want to #undef all this temporary stuff so it's not propagated into the U-Boot further.
Quoted 1 line
I don't understand. What temporary stuff are you referring to?
BOOTCMDS_MMC for example. This certainly doesn't need to propagate into the rest of the U-Boot build, does it ?
Best regards,
Marek Vasut
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 38 lines · Marek Vasut
Quoted 37 lines · Stephen Warren
Quoted 35 lines · Marek Vasut
Quoted 21 lines · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>---
include/config_distro_bootcmd.h | 172++++++++++++++++++++++++++++++++++++++++ 1 file changed, 172 insertions(+)
create mode 100644 include/config_distro_bootcmd.h(quoted diff) +0
-0
b/include/config_distro_bootcmd.hnew file mode 100644 index 0000000..d32dc12include/config_distro_bootcmd.h new file +5
-0@@ -0,0 +1,172 @@ +/* +* (C) Copyright 2014 +* NVIDIA Corporation <www.nvidia.com> +* +* Copyright 2014 Red Hat, Inc. include/config_distro_bootcmd.h line 15
Quoted 10 lines
include/config_distro_bootcmd.h new file +10
-0+* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H +#define _CONFIG_CMD_DISTRO_BOOTCMD_H + + +#ifdef CONFIG_CMD_MMC +#define BOOTCMDS_MMC \You might want to #undef all this temporary stuff so it's not propagated into the U-Boot further.
Quoted 4 lines
Quoted 1 line
I don't understand. What temporary stuff are you referring to?
BOOTCMDS_MMCfor example. This certainly doesn't need to propagate into the rest of the U-Boot build, does it ?
Oh, you mean #undef it at the end of the file? That would probably work. I thought you meant something else, although I wasn't sure what.
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 39 lines · Stephen Warren
Quoted 38 lines · Marek Vasut
Quoted 37 lines · Stephen Warren
Quoted 35 lines · Marek Vasut
Quoted 21 lines · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>---
include/config_distro_bootcmd.h | 172++++++++++++++++++++++++++++++++++++++++ 1 file changed, 172 insertions(+)
create mode 100644 include/config_distro_bootcmd.h(quoted diff) +0
-0
b/include/config_distro_bootcmd.hnew file mode 100644 index 0000000..d32dc12include/config_distro_bootcmd.h new file +5
-0@@ -0,0 +1,172 @@ +/* +* (C) Copyright 2014 +* NVIDIA Corporation <www.nvidia.com> +* +* Copyright 2014 Red Hat, Inc. include/config_distro_bootcmd.h line 15
Quoted 10 lines
include/config_distro_bootcmd.h new file +10
-0+* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H +#define _CONFIG_CMD_DISTRO_BOOTCMD_H + + +#ifdef CONFIG_CMD_MMC +#define BOOTCMDS_MMC \You might want to #undef all this temporary stuff so it's not propagated into the U-Boot further.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
I don't understand. What temporary stuff are you referring to?
BOOTCMDS_MMCfor example. This certainly doesn't need to propagate into the rest of the U-Boot build, does it ?Oh, you mean #undef it at the end of the file? That would probably work. I thought you meant something else, although I wasn't sure what.
That's what I meant, sorry.
Best regards,
Marek Vasut
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
In reply to Dennis GilmoreQuoted 1 line · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>
Patch description?
include/config_distro_bootcmd.h line 13
Quoted 6 lines
include/config_distro_bootcmd.h +4
-0+#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H +#define _CONFIG_CMD_DISTRO_BOOTCMD_H + +
Is there a need for 2 blank lines there?
include/config_distro_bootcmd.h line 97
Quoted 2 lines
include/config_distro_bootcmd.h +2
-0+#define BOOTCMDS_COMMON \ + "rootpart=1\0" \
We should really stop hard-coding that. I meant to (but evidently never got around to) re-write the commands so that they could automatically determine which partition to use, based on the MBR bootable flag or GPT partition flags.
Still, we can probably make that enhancement separately later.
Quoted 1 line
+#define
BOOT_TARGETS_MMC"mmc1 mmc0"
We really ought to make the order of multiple MMC devices in BOOT_TARGETS configurable. For example, we may have 2 boards that both want to boot from SD card if present, else fall back to internal eMMC, yet one has mmc0=eMMC,mmc1=SD, and the other mmc0=SD,mmc1=eMMC. On Tegra, we're just lucky that hasn't been an issue yet. Equally, not all boards have 2 eMMC devices.
include/config_distro_bootcmd.h line 149
Quoted 6 lines
include/config_distro_bootcmd.h +6
-0+"scan_boot=" \ +"echo Scanning ${devtype} ${devnum}...; " \ +"for prefix in ${boot_prefixes}; do " \ +"run sysboot_boot; " \ +"run envimport; " \ +"run script_boot; " \
This isn't quite right for the Raspberry Pi at least.
What I wanted was for uEnv.txt to *always* be loaded from SD card before any other boot activity. The SD card is known to exist on this platform, since it's the only place the SoC's boot ROM can load the initial binary firmware from.
The idea is that since the Pi has nowhere to store any environment, and the default environment's boot_targets is hard-coded in the U-Boot binary, we need some way for the user to configure the value of boot_targets to e.g. force network or USB boot. We want to do this before executing bootcmd, so that bootcmd looks at the user's desired boot_targets, rather than part way through executing bootcmd, which is far too late.
Now, on the Pi, this all happens via CONFIG_PREBOOT, so it will still work even with the "run envimport" as above. However, I think we want to make the "run envimport" within scan_boot optional, so it doesn't get repeated.
I wouldn't be surprised if other platforms ought to be working in the exact same way?
include/config_distro_bootcmd.h line 158
Quoted 7 lines
include/config_distro_bootcmd.h +7
-0+"boot_targets=" \ +BOOT_TARGETS_MMC " " \ +BOOT_TARGETS_USB " " \ +BOOT_TARGETS_SATA " " \ +BOOT_TARGETS_PXE " " \ +BOOT_TARGETS_DHCP " " \ +"\0" \
I'd be tempted to require the board-specific config to set boot_targets, so that appropriate customization can be applied?
include/config_distro_bootcmd.h line 164
Quoted 1 line
include/config_distro_bootcmd.h +1
-0+"boot_envs=uEnv.txt\0" \
I wonder if boards want to customize that for backwards-compatibility?
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 4 lines · On Wed, 19 Feb 2014 10:40:15 -0700 Stephen Warren <[email protected]> wrote:
Quoted 1 line · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>Patch description?
I failed in my rush to get it out for feedback.
Quoted 9 lines
include/config_distro_bootcmd.h line 13
Quoted 7 lines
include/config_distro_bootcmd.h +4
-0+#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H +#define _CONFIG_CMD_DISTRO_BOOTCMD_H + +Is there a need for 2 blank lines there?
no, will clean it up
Quoted 9 lines
include/config_distro_bootcmd.h line 97
Quoted 2 lines
include/config_distro_bootcmd.h +2
-0+#define BOOTCMDS_COMMON \ + "rootpart=1\0" \We should really stop hard-coding that. I meant to (but evidently never got around to) re-write the commands so that they could automatically determine which partition to use, based on the MBR bootable flag or GPT partition flags.
Still, we can probably make that enhancement separately later.
I fully agree, we should be able to work it out later. I also renamed it to bootpart since it is where we will boot from, which may or may not be the root filesystem
Quoted 8 lines
Quoted 1 line
+#define
BOOT_TARGETS_MMC"mmc1 mmc0"We really ought to make the order of multiple MMC devices in
BOOT_TARGETSconfigurable. For example, we may have 2 boards that both want to boot from SD card if present, else fall back to internal eMMC, yet one has mmc0=eMMC,mmc1=SD, and the other mmc0=SD,mmc1=eMMC. On Tegra, we're just lucky that hasn't been an issue yet. Equally, not all boards have 2 eMMC devices.
I did wonder if that was better being left out here and something that the board set.
Quoted 15 lines
Quoted 11 lines
include/config_distro_bootcmd.h +1
-0+"scan_boot=" \
include/config_distro_bootcmd.h +1
-0+ "echo Scanning ${devtype} ${devnum}...;" \
include/config_distro_bootcmd.h +1
-0+ "for prefix in ${boot_prefixes}; do" \
include/config_distro_bootcmd.h +1
-0+ "run sysboot_boot;" \
include/config_distro_bootcmd.h +1
-0+ "run envimport;" \
include/config_distro_bootcmd.h +1
-0+ "run script_boot;Quoted 1 line
" \
This isn't quite right for the Raspberry Pi at least.
Quoted 4 lines
What I wanted was for uEnv.txt to *always* be loaded from SD card before any other boot activity. The SD card is known to exist on this platform, since it's the only place the SoC's boot ROM can load the initial binary firmware from.
I know some distros use commands in uEnv.txt to boot, or at the least they set variables and load a boot.scr I was trying to make sure we cover those people. The definition of what uEnv.txt is and how it should be used is pretty murky to me. I have seen it used in a few different ways. I know some people really want them. So probably best to work out a better way to support it.
http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-uEnv.txtbasedbootscript
for instance specifies all the boot commands in uEnv.txt really I would rather people just use a extlinux.conf file, I just do not want to take away the option to use something people see as valuable.
Quoted 16 lines
The idea is that since the Pi has nowhere to store any environment, and the default environment's
boot_targetsis hard-coded in the U-Boot binary, we need some way for the user to configure the value ofboot_targetsto e.g. force network or USB boot. We want to do this before executing bootcmd, so that bootcmd looks at the user's desiredboot_targets, rather than part way through executing bootcmd, which is far too late.Now, on the Pi, this all happens via
CONFIG_PREBOOT, so it will still work even with the "run envimport" as above. However, I think we want to make the "run envimport" withinscan_bootoptional, so it doesn't get repeated.I wouldn't be surprised if other platforms ought to be working in the exact same way?
Quoted 10 lines
include/config_distro_bootcmd.h line 158
Quoted 7 lines
include/config_distro_bootcmd.h +7
-0+"boot_targets=" \ +BOOT_TARGETS_MMC " " \ +BOOT_TARGETS_USB " " \ +BOOT_TARGETS_SATA " " \ +BOOT_TARGETS_PXE " " \ +BOOT_TARGETS_DHCP " " \ +"\0" \I'd be tempted to require the board-specific config to set
boot_targets, so that appropriate customization can be applied?
sure, Ideally its something that can be changed on the fly and we just ship a suggested ordering. That is probably something for down the road though.
Quoted 3 lines
include/config_distro_bootcmd.h line 164
Quoted 1 line
include/config_distro_bootcmd.h +1
-0+"boot_envs=uEnv.txt\0" \I wonder if boards want to customize that for backwards-compatibility?
Perhaps.
Might need to redo some of this. I've since added SCSI and IDE and they are things I have seen in the wild also. Maybe we can simplify things somehow so that adding new hardware types is really simple.
Dennis
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 13 lines · Dennis Gilmore
Quoted 12 lines · On Wed, 19 Feb 2014 10:40:15 -0700 Stephen Warren <[email protected]> wrote:
include/config_distro_bootcmd.h line 97
Quoted 4 lines · Dennis Gilmore
include/config_distro_bootcmd.h new file +2
-0+#define BOOTCMDS_COMMON \ + "rootpart=1\0" \We should really stop hard-coding that. I meant to (but evidently never got around to) re-write the commands so that they could automatically determine which partition to use, based on the MBR bootable flag or GPT partition flags.
Quoted 5 lines
Quoted 1 line
Still, we can probably make that enhancement separately later.
I fully agree, we should be able to work it out later. I also renamed it to bootpart since it is where we will boot from, which may or may not be the root filesystem
Just as some history, when I first wrote these boot scripts for Tegra, I was actually using that variable both inside the environment scripts to find/load boot.scr, and within boot.scr to set the kernel root= command-line option. More recently, I've moved to using root=PARTUUID= or root=UUID= on the kernel command-line, so rootpart has become less relevant, and indeed renaming it bootpart does make a lot more sense, as you say.
Quoted 20 lines
Quoted 15 lines
Quoted 11 lines
(quoted diff) +1
-0+ "scan_boot="\
(quoted diff) +1
-0+ "echo Scanning ${devtype} ${devnum}...;" \
(quoted diff) +1
-0+ "for prefix in ${boot_prefixes}; do" \
(quoted diff) +1
-0+ "run sysboot_boot;" \
(quoted diff) +1
-0+ "run envimport;" \
(quoted diff) +1
-0+ "run script_boot;Quoted 1 line
" \
This isn't quite right for the Raspberry Pi at least.
Quoted 4 lines
What I wanted was for uEnv.txt to *always* be loaded from SD card before any other boot activity. The SD card is known to exist on this platform, since it's the only place the SoC's boot ROM can load the initial binary firmware from.
Quoted 10 lines
I know some distros use commands in uEnv.txt to boot, or at the least they set variables and load a boot.scr I was trying to make sure we cover those people. The definition of what uEnv.txt is and how it should be used is pretty murky to me. I have seen it used in a few different ways. I know some people really want them. So probably best to work out a better way to support it.
http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-uEnv.txtbasedbootscript
for instance specifies all the boot commands in uEnv.txt really I would rather people just use a extlinux.conf file, I just do not want to take away the option to use something people see as valuable.
I'd suggest not touching uEnv.txt in config_distro_bootcmd.h, since it's really not a part of the new standard we want to create. Instead, have each board define CONFIG_PREBOOT to load it if they want it. I assume that a very small number of boards will need uEnv.txt once we've switched to this new scheme; just those that have nowhere to store a persistent environment.
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 1 line · Stephen Warren
On 02/22/2014 01:20 AM, Dennis Gilmore wrote:
[snip]
Quoted 11 lines
Quoted 3 lines
I fully agree, we should be able to work it out later. I also renamed it to bootpart since it is where we will boot from, which may or may not be the root filesystem
Just as some history, when I first wrote these boot scripts for Tegra, I was actually using that variable both inside the environment scripts to find/load boot.scr, and within boot.scr to set the kernel root= command-line option. More recently, I've moved to using root=PARTUUID= or root=UUID= on the kernel command-line, so rootpart has become less relevant, and indeed renaming it bootpart does make a lot more sense, as you say.
For distro, this, oh my yes, this, is pretty nearly a must. This dislodged something in my brain which reminded me of a pain point we have on some TI parts, which is which MMC device will the kernel have as mmc0 vs mmc1 as because of regulartors, deferred probing and all of that, it's board design dependent. But passing in root=UUID= like commodity distros have done for ages makes this irrelevant. We need to do this such that either can be used, probably as root= being something that's given to us, rather than assumed by us. But I would be sad if everyone stopped using root=UUID= and started using /dev/mmcblk* names in the commodity distro area.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140224/a255a03f/attachment.pgp>
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
In reply to Dennis GilmoreQuoted 43 lines · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>--- include/config_distro_bootcmd.h | 172 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 172 insertions(+) create mode 100644 include/config_distro_bootcmd.hinclude/config_distro_bootcmd.h new file +31
-0@@ -0,0 +1,172 @@ +/* +* (C) Copyright 2014 +* NVIDIA Corporation <www.nvidia.com> +* +* Copyright 2014 Red Hat, Inc. +* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H +#define _CONFIG_CMD_DISTRO_BOOTCMD_H + + +#ifdef CONFIG_CMD_MMC +#define BOOTCMDS_MMC \ + "mmc_boot=" \ + "setenv devtype mmc; " \ + "if mmc dev ${devnum}; then " \ + "run scan_boot; " \ + "fi\0" \ + "bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \ + "bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0" +#define BOOT_TARGETS_MMC "mmc1 mmc0" +#else +#define BOOTCMDS_MMC "" +#define BOOT_TARGETS_MMC "" +#endif + +#ifdef CONFIG_CMD_USB +#define BOOTCMD_INIT_USB "run usb_init; " +#define BOOTCMDS_USB \
include/config_distro_bootcmd.h line 41
Quoted 10 lines
include/config_distro_bootcmd.h new file +10
-0+"usb_init=" \ +"if ${usb_need_init}; then " \ +"set usb_need_init false; " \ +"usb start 0; " \ +"fi\0" \ + \ +"usb_boot=" \ +"setenv devtype usb; " \ +BOOTCMD_INIT_USB \ +"if usb dev ${devnum}; then " \
This may have already been highlighted but I don't see where the kernel command line arguments can be set. If you have the file system on the USB stick won't you need to direct the root to the stick?
Maybe I don't want to have a uEnv.txt file.
This is what I had to do when I did the similar implementation on the TI common file
Quoted 7 lines
include/config_distro_bootcmd.h new file +7
-0+"run scan_boot; " \ +"fi\0" \ + \ + "bootcmd_usb0=setenv devnum 0; run usb_boot;\0" +#define BOOT_TARGETS_USB "usb0" +#else +#define BOOTCMD_INIT_USB ""
include/config_distro_bootcmd.h line 58
Quoted 10 lines
include/config_distro_bootcmd.h new file +10
-0+#define BOOTCMDS_USB "" +#define BOOT_TARGETS_USB "" +#endif + +#ifdef CONFIG_CMD_SATA +#define BOOTCMDS_SATA \ + "sata_boot=" \ + "setenv devtype sata; " \ + "if sata dev ${devnum}; then " \ + "run scan_boot; " \
Same as above
Quoted 38 lines
include/config_distro_bootcmd.h new file +37
-0+"fi\0" \ + \ +"bootcmd_sata0=setenv devnum 0; run sata_boot;\0" + "bootcmd_sata1=setenv devnum 1; run sata_boot;\0" +#define BOOT_TARGETS_USB "sata0 sata1" +#else +#define BOOTCMDS_SATA "" +#define BOOT_TARGETS_SATA "" +#endif + +#ifdef CONFIG_CMD_DHCP +#define BOOTCMDS_DHCP \ + "bootcmd_dhcp=" \ + BOOTCMD_INIT_USB \ + "if dhcp ${scriptaddr} boot.scr.uimg; then "\ + "source ${scriptaddr}; " \ + "fi\0" +#define BOOT_TARGETS_DHCP "dhcp" +#else +#define BOOTCMDS_DHCP "" +#define BOOT_TARGETS_DHCP "" +#endif + +#if defined(CONFIG_CMD_DHCP ) && defined(CONFIG_CMD_PXE ) +#define BOOTCMDS_PXE \ + "bootcmd_pxe=" \ + BOOTCMD_INIT_USB \ + "dhcp; " \ + "if pxe get; then " \ + "pxe boot; " \ + "fi\0" +#define BOOT_TARGETS_PXE "pxe" +#else +#define BOOTCMDS_PXE "" +#define BOOT_TARGETS_PXE "" +#endif +
Signature · 2 lines
------------------ Dan Murphy
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 5 lines · Dan Murphy
Quoted 3 lines · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>include/config_distro_bootcmd.h +0
-0
Quoted 16 lines
include/config_distro_bootcmd.h line 41
Quoted 13 lines
include/config_distro_bootcmd.h +13
-0+#ifdef CONFIG_CMD_USB +#define BOOTCMD_INIT_USB "run usb_init; " +#define BOOTCMDS_USB \ + "usb_init=" \ + "if ${usb_need_init}; then " \ + "set usb_need_init false; " \ + "usb start 0; " \ + "fi\0" \ + \ + "usb_boot=" \ + "setenv devtype usb; " \ + BOOTCMD_INIT_USB \ + "if usb dev ${devnum}; then " \This may have already been highlighted but I don't see where the kernel command line arguments can be set. If you have the file system on the USB stick won't you need to direct the root to the stick?
They would be set in boot.scr or extlinux.cfg on the disk that the system boots from; the kernel cmdline is part of the OS that's installed there, not part of U-Boot. This is why these boot scripts load a script/config-file from the disk which in turn defines which kernel/DTB/cmdline to use, rather than directly loading a kernel and DTB. This approach should even be suitable for booting a non-Linux-OS, with suitable commands in boot.scr.
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 19 lines · Stephen Warren
Quoted 10 lines · Dan Murphy
Quoted 9 lines · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>include/config_distro_bootcmd.h +7
-0+#ifdef CONFIG_CMD_USB +#define BOOTCMD_INIT_USB "run usb_init; " +#define BOOTCMDS_USB \ + "usb_init=" \ + "if ${usb_need_init}; then " \ + "set usb_need_init false; " \ + "usb start 0; " \Quoted 8 lines
include/config_distro_bootcmd.h line 41
Quoted 6 lines
include/config_distro_bootcmd.h +6
-0+"fi\0" \ + \ +"usb_boot=" \ +"setenv devtype usb; " \ +BOOTCMD_INIT_USB \ +"if usb dev ${devnum}; then " \This may have already been highlighted but I don't see where the kernel command line arguments can be set. If you have the file system on the USB stick won't you need to direct the root to the stick?
Quoted 7 lines
They would be set in boot.scr or extlinux.cfg on the disk that the system boots from; the kernel cmdline is part of the OS that's installed there, not part of U-Boot. This is why these boot scripts load a script/config-file from the disk which in turn defines which
kernel/DTB/cmdlineto use, rather than directly loading a kernel and DTB. This approach should even be suitable for booting a non-Linux-OS, with suitable commands in boot.scr.
But shouldn't the config file just be an override?
I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot.
If no config file exists should we not try to default to a known good default tested case?
Dan
Signature · 2 lines
------------------ Dan Murphy
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 28 lines · Dan Murphy
Quoted 19 lines · Stephen Warren
Quoted 10 lines · Dan Murphy
Quoted 9 lines · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>include/config_distro_bootcmd.h +7
-0+#ifdef CONFIG_CMD_USB +#define BOOTCMD_INIT_USB "run usb_init; " +#define BOOTCMDS_USB \ + "usb_init=" \ + "if ${usb_need_init}; then " \ + "set usb_need_init false; " \ + "usb start 0; " \Quoted 8 lines
include/config_distro_bootcmd.h line 41
Quoted 6 lines
include/config_distro_bootcmd.h +6
-0+"fi\0" \ + \ +"usb_boot=" \ +"setenv devtype usb; " \ +BOOTCMD_INIT_USB \ +"if usb dev ${devnum}; then " \This may have already been highlighted but I don't see where the kernel command line arguments can be set. If you have the file system on the USB stick won't you need to direct the root to the stick?
Quoted 7 lines
They would be set in boot.scr or extlinux.cfg on the disk that the system boots from; the kernel cmdline is part of the OS that's installed there, not part of U-Boot. This is why these boot scripts load a script/config-file from the disk which in turn defines which
kernel/DTB/cmdlineto use, rather than directly loading a kernel and DTB. This approach should even be suitable for booting a non-Linux-OS, with suitable commands in boot.scr.
Quoted 5 lines
But shouldn't the config file just be an override?
I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot.
If no config file exists should we not try to default to a known good default tested case?
I believe always loading a script/config-file is the simplest and most flexible approach, for a *distro* *oriented* boot process.
Now, specific U-Boot board configs can always add extra stuff on the end (or start?) of bootcmd in order to do some custom fallbacks or backwards-compatibility if they want, but I'm certainly not planning on doing anything like that for Tegra or Raspberry Pi, for example.
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 32 lines · Stephen Warren
Quoted 31 lines · Dan Murphy
Quoted 19 lines · Stephen Warren
Quoted 10 lines · Dan Murphy
Quoted 9 lines · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>include/config_distro_bootcmd.h +7
-0+#ifdef CONFIG_CMD_USB +#define BOOTCMD_INIT_USB "run usb_init; " +#define BOOTCMDS_USB \ + "usb_init=" \ + "if ${usb_need_init}; then " \ + "set usb_need_init false; " \ + "usb start 0; " \Quoted 8 lines
include/config_distro_bootcmd.h line 41
Quoted 6 lines
include/config_distro_bootcmd.h +6
-0+"fi\0" \ + \ +"usb_boot=" \ +"setenv devtype usb; " \ +BOOTCMD_INIT_USB \ +"if usb dev ${devnum}; then " \This may have already been highlighted but I don't see where the kernel command line arguments can be set. If you have the file system on the USB stick won't you need to direct the root to the stick?
Quoted 7 lines
They would be set in boot.scr or extlinux.cfg on the disk that the system boots from; the kernel cmdline is part of the OS that's installed there, not part of U-Boot. This is why these boot scripts load a script/config-file from the disk which in turn defines which
kernel/DTB/cmdlineto use, rather than directly loading a kernel and DTB. This approach should even be suitable for booting a non-Linux-OS, with suitable commands in boot.scr.But shouldn't the config file just be an override?
I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot.
Quoted 8 lines
Quoted 1 line
If no config file exists should we not try to default to a known good default tested case?
I believe always loading a script/config-file is the simplest and most flexible approach, for a *distro* *oriented* boot process.
Now, specific U-Boot board configs can always add extra stuff on the end (or start?) of bootcmd in order to do some custom fallbacks or backwards-compatibility if they want, but I'm certainly not planning on doing anything like that for Tegra or Raspberry Pi, for example.
Yeah I am not seeing how the board config can do that if there is no provisions in the common file.
On another note there is no support in here for NAND. Was there a plan to pull that in as well?
Dan
Signature · 2 lines
------------------ Dan Murphy
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 37 lines · Dan Murphy
Quoted 36 lines · Stephen Warren
Quoted 27 lines · Dan Murphy
Quoted 19 lines · Stephen Warren
Quoted 10 lines · Dan Murphy
Quoted 9 lines · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>include/config_distro_bootcmd.h +7
-0+#ifdef CONFIG_CMD_USB +#define BOOTCMD_INIT_USB "run usb_init; " +#define BOOTCMDS_USB \ + "usb_init=" \ + "if ${usb_need_init}; then " \ + "set usb_need_init false; " \ + "usb start 0; " \Quoted 8 lines
include/config_distro_bootcmd.h line 41
Quoted 6 lines
include/config_distro_bootcmd.h +6
-0+"fi\0" \ + \ +"usb_boot=" \ +"setenv devtype usb; " \ +BOOTCMD_INIT_USB \ +"if usb dev ${devnum}; then " \This may have already been highlighted but I don't see where the kernel command line arguments can be set. If you have the file system on the USB stick won't you need to direct the root to the stick?
Quoted 7 lines
They would be set in boot.scr or extlinux.cfg on the disk that the system boots from; the kernel cmdline is part of the OS that's installed there, not part of U-Boot. This is why these boot scripts load a script/config-file from the disk which in turn defines which
kernel/DTB/cmdlineto use, rather than directly loading a kernel and DTB. This approach should even be suitable for booting a non-Linux-OS, with suitable commands in boot.scr.Quoted 5 lines
But shouldn't the config file just be an override?
I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot.
If no config file exists should we not try to default to a known good default tested case?
I believe always loading a script/config-file is the simplest and most flexible approach, for a *distro* *oriented* boot process.
Quoted 6 lines
Quoted 4 lines
Now, specific U-Boot board configs can always add extra stuff on the end (or start?) of bootcmd in order to do some custom fallbacks or backwards-compatibility if they want, but I'm certainly not planning on doing anything like that for Tegra or Raspberry Pi, for example.
Yeah I am not seeing how the board config can do that if there is no provisions in the common file.
Presumably all it needs is an extra hook/variable that is added to the start/end of bootcmd. Should be pretty easy to add in a future patch rev, or followon patch.
Quoted 1 line
On another note there is no support in here for NAND. Was there a plan to pull that in as well?
A generic Linux distro wouldn't be installing a kernel to NAND, but would rather put it into the /boot filesystem. NAND boot is something that'd be best supported by the custom hook we discussed above.
The commit description for this commit should have set the scene that this series is all about providing a way for a generic Linux distro to create a generic installable media set that boots the same way across n different boards with U-Boot, and similarly also to set up the installed distro filesystem in a single generic way that can boot on any board it gets installed to. It's all about avoiding board-specific boot options such as NAND, and hence may well not be applicable to boards that primarily/only boot from NAND; they would still need custom distro install media and hooks to set up the installed filesystem.
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 49 lines · Stephen Warren
Quoted 37 lines · Dan Murphy
Quoted 36 lines · Stephen Warren
Quoted 27 lines · Dan Murphy
Quoted 19 lines · Stephen Warren
Quoted 10 lines · Dan Murphy
Quoted 9 lines · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>include/config_distro_bootcmd.h +7
-0+#ifdef CONFIG_CMD_USB +#define BOOTCMD_INIT_USB "run usb_init; " +#define BOOTCMDS_USB \ + "usb_init=" \ + "if ${usb_need_init}; then " \ + "set usb_need_init false; " \ + "usb start 0; " \Quoted 8 lines
include/config_distro_bootcmd.h
Quoted 6 lines
include/config_distro_bootcmd.h +6
-0+"fi\0" \ + \ +"usb_boot=" \ +"setenv devtype usb; " \ +BOOTCMD_INIT_USB \ +"if usb dev ${devnum}; then " \This may have already been highlighted but I don't see where the kernel command line arguments can be set. If you have the file system on the USB stick won't you need to direct the root to the stick?
Quoted 7 lines
They would be set in boot.scr or extlinux.cfg on the disk that the system boots from; the kernel cmdline is part of the OS that's installed there, not part of U-Boot. This is why these boot scripts load a script/config-file from the disk which in turn defines which
kernel/DTB/cmdlineto use, rather than directly loading a kernel and DTB. This approach should even be suitable for booting a non-Linux-OS, with suitable commands in boot.scr.Quoted 5 lines
But shouldn't the config file just be an override?
I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot.
If no config file exists should we not try to default to a known good default tested case?
I believe always loading a script/config-file is the simplest and most flexible approach, for a *distro* *oriented* boot process.
Quoted 6 lines
Quoted 4 lines
Now, specific U-Boot board configs can always add extra stuff on the end (or start?) of bootcmd in order to do some custom fallbacks or backwards-compatibility if they want, but I'm certainly not planning on doing anything like that for Tegra or Raspberry Pi, for example.
Yeah I am not seeing how the board config can do that if there is no provisions in the common file.
Presumably all it needs is an extra hook/variable that is added to the start/end of bootcmd. Should be pretty easy to add in a future patch rev, or followon patch.
Quoted 5 lines
Quoted 1 line
On another note there is no support in here for NAND. Was there a plan to pull that in as well?
A generic Linux distro wouldn't be installing a kernel to NAND, but would rather put it into the /boot filesystem. NAND boot is something that'd be best supported by the custom hook we discussed above.
Wait, why would a generic Linux distro be installing to eMMC but not to NAND ? Not that this series needs to be the final point in the discussion and all.
Quoted 9 lines
The commit description for this commit should have set the scene that this series is all about providing a way for a generic Linux distro to create a generic installable media set that boots the same way across n different boards with U-Boot, and similarly also to set up the installed distro filesystem in a single generic way that can boot on any board it gets installed to. It's all about avoiding board-specific boot options such as NAND, and hence may well not be applicable to boards that primarily/only boot from NAND; they would still need custom distro install media and hooks to set up the installed filesystem.
Why is NAND special but SATA not, other than desktops often have SATA exposed but not NAND? Even more so when you consider that from the Linux side of things, dealing with NAND is dealing with NAND and it's not board specific.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140219/7cc59b49/attachment.pgp>
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On 02/19/2014 12:10 PM, Tom Rini wrote:
...
Quoted 7 lines
Quoted 3 lines
A generic Linux distro wouldn't be installing a kernel to NAND, but would rather put it into the /boot filesystem. NAND boot is something that'd be best supported by the custom hook we discussed above.
Wait, why would a generic Linux distro be installing to eMMC but not to NAND ? Not that this series needs to be the final point in the discussion and all.
I should point out that I was talking about raw NAND MTD partitions rather than a NAND device with a regular partition table and normal filesystems within it.
If the NAND is exposed as a regular block device with a regular filesystem, then it'd look just like any other block device to a generic distro installer, and hence it could put /boot there, and this patch (or future enhancement) could certainly usefully contain a generic bootcmd_nand that used it.
However, if the NAND has hard-coded MTD partitions, and/or the partitions have no filesystem but rather contain e.g. a raw zImage/uImage, then that would require board-/SoC-specific support in the distro kernel and installer, and hence we wouldn't be talking about a *generic* installer/distro, and *generic* installers/distros are what this patch series is all about.
Quoted 14 lines
Quoted 9 lines
The commit description for this commit should have set the scene that this series is all about providing a way for a generic Linux distro to create a generic installable media set that boots the same way across n different boards with U-Boot, and similarly also to set up the installed distro filesystem in a single generic way that can boot on any board it gets installed to. It's all about avoiding board-specific boot options such as NAND, and hence may well not be applicable to boards that primarily/only boot from NAND; they would still need custom distro install media and hooks to set up the installed filesystem.
Why is NAND special but SATA not, other than desktops often have SATA exposed but not NAND? Even more so when you consider that from the Linux side of things, dealing with NAND is dealing with NAND and it's not board specific.
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 20 lines · Stephen Warren
On 02/19/2014 12:10 PM, Tom Rini wrote:
...Quoted 7 lines
Quoted 3 lines
A generic Linux distro wouldn't be installing a kernel to NAND, but would rather put it into the /boot filesystem. NAND boot is something that'd be best supported by the custom hook we discussed above.
Wait, why would a generic Linux distro be installing to eMMC but not to NAND ? Not that this series needs to be the final point in the discussion and all.
I should point out that I was talking about raw NAND MTD partitions rather than a NAND device with a regular partition table and normal filesystems within it.
If the NAND is exposed as a regular block device with a regular filesystem, then it'd look just like any other block device to a generic distro installer, and hence it could put /boot there, and this patch (or future enhancement) could certainly usefully contain a generic
bootcmd_nandthat used it.
Quoted 6 lines
However, if the NAND has hard-coded MTD partitions, and/or the partitions have no filesystem but rather contain e.g. a raw zImage/uImage, then that would require board-/SoC-specific support in the distro kernel and installer, and hence we wouldn't be talking about a *generic* installer/distro, and *generic* installers/distros are what this patch series is all about.
I would put a generic distro knowing how to deal, genericially at least, with NAND on par with knowing how to deal with HW RAID or other not too uncommon desktop features. If /dev/mtdblockN then offer UBI or a few other choices, else if /dev/sd* then offer ext* or btrfs or a few other choices. But I think that's also getting off-topic for us at least (and yes, am335x is doing raw kernel storage today, fixing that is on my list).
One thing this series does have to cope with, some way or another, is to be able to say "Oh, you have other boot devices too, we must handle them somehow". With my TI custodian hat on, it would be quite handy for Beaglebone to use this and have Fedora/SuSE/etc/etc "just work" but it's going to make me quite grumpy if I can't also easily support AM335x GP EVM and its NAND and I start to worry if QSPI, which I have a feeling is going to take off like eMMC did, is going to just get ignored and when Rasberry Cream Pi or Beaglebone Metalic Purple comes out with QSPI on-board we don't start kicking ourselves again.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140219/e806f0e7/attachment.pgp>
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On 02/19/2014 12:36 PM, Tom Rini wrote:
...
Quoted 4 lines
I would put a generic distro knowing how to deal, genericially at least, with NAND on par with knowing how to deal with HW RAID or other not too uncommon desktop features. If
/dev/mtdblockNthen offer UBI or a few other choices, else if/dev/sd*then offer ext* or btrfs or a few other
But how do /dev/mtdblockN get into existence? MTD partitions have historically been defined on the kernel command-line haven't they, and hence it'd require a board-specific cmdline to support that. Hmmm. Perhaps they can be specified in DT nowadays? If so, then NAND should indeed be pretty easy to deal with.
Quoted 9 lines
One thing this series does have to cope with, some way or another, is to be able to say "Oh, you have other boot devices too, we must handle them somehow". With my TI custodian hat on, it would be quite handy for Beaglebone to use this and have Fedora/SuSE/etc/etc "just work" but it's going to make me quite grumpy if I can't also easily support AM335x GP EVM and its NAND and I start to worry if QSPI, which I have a feeling is going to take off like eMMC did, is going to just get ignored and when Rasberry Cream Pi or Beaglebone Metalic Purple comes out with QSPI on-board we don't start kicking ourselves again.
I assume QSPI would be just the system boot flash, and not for filesystem storage? As a general rule, I assert that distros shouldn't have to know anything about installing/updating bootloaders; that should be something that happens before you attempt to use a distro installer, and most likely uses board-/SoC-specific tools. If QSPI is filesystem storage, then assuming it shows up like any other block device, it should work out just like NAND as we discussed above.
Exceptions might be e.g. the Raspberry Pi and some of the Beagle* boards which require the firmware in a partition on the SD card, since there's no other storage device. Still, hopefully that's as simple as detecting the specific board based on DT compatible value, and installing a particular extra package for it.
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 7 lines · Stephen Warren
On 02/19/2014 12:36 PM, Tom Rini wrote:
...Quoted 4 lines
I would put a generic distro knowing how to deal, genericially at least, with NAND on par with knowing how to deal with HW RAID or other not too uncommon desktop features. If
/dev/mtdblockNthen offer UBI or a few other choices, else if/dev/sd*then offer ext* or btrfs or a few other
Quoted 5 lines
But how do
/dev/mtdblockNget into existence? MTD partitions have historically been defined on the kernel command-line haven't they, and hence it'd require a board-specific cmdline to support that. Hmmm. Perhaps they can be specified in DT nowadays? If so, then NAND should indeed be pretty easy to deal with.
They've been in the device tree since before ARM started converting :)
Quoted 10 lines
Quoted 9 lines
One thing this series does have to cope with, some way or another, is to be able to say "Oh, you have other boot devices too, we must handle them somehow". With my TI custodian hat on, it would be quite handy for Beaglebone to use this and have Fedora/SuSE/etc/etc "just work" but it's going to make me quite grumpy if I can't also easily support AM335x GP EVM and its NAND and I start to worry if QSPI, which I have a feeling is going to take off like eMMC did, is going to just get ignored and when Rasberry Cream Pi or Beaglebone Metalic Purple comes out with QSPI on-board we don't start kicking ourselves again.
Quoted 7 lines
I assume QSPI would be just the system boot flash, and not for filesystem storage? As a general rule, I assert that distros shouldn't have to know anything about installing/updating bootloaders; that should be something that happens before you attempt to use a distro installer, and most likely uses board-/SoC-specific tools. If QSPI is filesystem storage, then assuming it shows up like any other block device, it should work out just like NAND as we discussed above.
QSPI is another MTD block device, and can be of "reasonable" size.
My point being that we don't want to say that the only use cases for "generic distro" are SD/SATA/"network". If we say from the outset that we won't even try and expose $FOO because it's not something they deal with today, people certainly won't.
Quoted 5 lines
Exceptions might be e.g. the Raspberry Pi and some of the Beagle* boards which require the firmware in a partition on the SD card, since there's no other storage device. Still, hopefully that's as simple as detecting the specific board based on DT compatible value, and installing a particular extra package for it.
What I'm saying is that while Beaglebone Black ships with eMMC today (and oh, hey, duh, Beagleboard not-xM ships with NAND), tomorrows hot commodity board quite well include a different on-baord storage, but one we can worry about a bit today.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140219/c71ba159/attachment.pgp>
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
In reply to Stephen WarrenQuoted 33 lines · On Wed, 19 Feb 2014 12:43:49 -0700 Stephen Warren <[email protected]> wrote:
On 02/19/2014 12:36 PM, Tom Rini wrote:
...Quoted 5 lines
I would put a generic distro knowing how to deal, genericially at least, with NAND on par with knowing how to deal with HW RAID or other not too uncommon desktop features. If
/dev/mtdblockNthen offer UBI or a few other choices, else if/dev/sd*then offer ext* or btrfs or a few otherBut how do
/dev/mtdblockNget into existence? MTD partitions have historically been defined on the kernel command-line haven't they, and hence it'd require a board-specific cmdline to support that. Hmmm. Perhaps they can be specified in DT nowadays? If so, then NAND should indeed be pretty easy to deal with.Quoted 10 lines
One thing this series does have to cope with, some way or another, is to be able to say "Oh, you have other boot devices too, we must handle them somehow". With my TI custodian hat on, it would be quite handy for Beaglebone to use this and have Fedora/SuSE/etc/etc "just work" but it's going to make me quite grumpy if I can't also easily support AM335x GP EVM and its NAND and I start to worry if QSPI, which I have a feeling is going to take off like eMMC did, is going to just get ignored and when Rasberry Cream Pi or Beaglebone Metalic Purple comes out with QSPI on-board we don't start kicking ourselves again.
I assume QSPI would be just the system boot flash, and not for filesystem storage? As a general rule, I assert that distros shouldn't have to know anything about installing/updating bootloaders; that should be something that happens before you attempt to use a distro installer, and most likely uses board-/SoC-specific tools. If QSPI is filesystem storage, then assuming it shows up like any other block device, it should work out just like NAND as we discussed above.
Quoted 5 lines
Exceptions might be e.g. the Raspberry Pi and some of the Beagle* boards which require the firmware in a partition on the SD card, since there's no other storage device. Still, hopefully that's as simple as detecting the specific board based on DT compatible value, and installing a particular extra package for it.
I'm actually going to use raw space for the MLO and u-boot.img, in Fedora 21, its easier and doesn't require special partitioning. I assume that when a device with QSPI comes along we will write things in a way that it can easily be extended to support and boards will ship day one with working support. That is assuming that there is QSPI chips with enough size to be useful are readily available.
Dennis
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
In reply to Stephen WarrenQuoted 38 lines · Stephen Warren
Quoted 37 lines · Dan Murphy
Quoted 36 lines · Stephen Warren
Quoted 27 lines · Dan Murphy
Quoted 19 lines · Stephen Warren
Quoted 10 lines · Dan Murphy
Quoted 9 lines · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>include/config_distro_bootcmd.h +7
-0+#ifdef CONFIG_CMD_USB +#define BOOTCMD_INIT_USB "run usb_init; " +#define BOOTCMDS_USB \ + "usb_init=" \ + "if ${usb_need_init}; then " \ + "set usb_need_init false; " \ + "usb start 0; " \Quoted 8 lines
include/config_distro_bootcmd.h
Quoted 6 lines
include/config_distro_bootcmd.h +6
-0+"fi\0" \ + \ +"usb_boot=" \ +"setenv devtype usb; " \ +BOOTCMD_INIT_USB \ +"if usb dev ${devnum}; then " \This may have already been highlighted but I don't see where the kernel command line arguments can be set. If you have the file system on the USB stick won't you need to direct the root to the stick?
Quoted 7 lines
They would be set in boot.scr or extlinux.cfg on the disk that the system boots from; the kernel cmdline is part of the OS that's installed there, not part of U-Boot. This is why these boot scripts load a script/config-file from the disk which in turn defines which
kernel/DTB/cmdlineto use, rather than directly loading a kernel and DTB. This approach should even be suitable for booting a non-Linux-OS, with suitable commands in boot.scr.Quoted 5 lines
But shouldn't the config file just be an override?
I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot.
If no config file exists should we not try to default to a known good default tested case?
I believe always loading a script/config-file is the simplest and most flexible approach, for a *distro* *oriented* boot process.
Quoted 8 lines
Quoted 5 lines
Quoted 4 lines
Now, specific U-Boot board configs can always add extra stuff on the end (or start?) of bootcmd in order to do some custom fallbacks or backwards-compatibility if they want, but I'm certainly not planning on doing anything like that for Tegra or Raspberry Pi, for example.
Yeah I am not seeing how the board config can do that if there is no provisions in the common file.
Presumably all it needs is an extra hook/variable that is added to the start/end of bootcmd. Should be pretty easy to add in a future patch rev, or followon patch.
<snip>
I am not sure it is that simple. Once you are in the BOOTCMD macro's if you end up back at the board file macros you kinda have to repeat the load steps again just to get the args or specifics set.
When the loading of the ENV file fails but the loading of the other images succeeds maybe something as simple as
"run board_cfg" Which can be a fall back to a board file specific configuration macro for whatever you want.
If you don't need it then it is NULL
Dan
Signature · 2 lines
------------------ Dan Murphy
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 4 lines · Dan Murphy
Quoted 3 lines · Stephen Warren
Quoted 2 lines · Dan Murphy
Quoted 1 line · Stephen Warren
On 02/19/2014 11:52 AM, Dan Murphy wrote:
...
Quoted 17 lines
Quoted 15 lines
Quoted 11 lines
Quoted 9 lines
Quoted 1 line
If no config file exists should we not try to default to a known good default tested case?
I believe always loading a script/config-file is the simplest and most flexible approach, for a *distro* *oriented* boot process.
Now, specific U-Boot board configs can always add extra stuff on the end (or start?) of bootcmd in order to do some custom fallbacks or backwards-compatibility if they want, but I'm certainly not planning on doing anything like that for Tegra or Raspberry Pi, for example.
Yeah I am not seeing how the board config can do that if there is no provisions in the common file.
Presumably all it needs is an extra hook/variable that is added to the start/end of bootcmd. Should be pretty easy to add in a future patch rev, or followon patch.
<snip>
Quoted 8 lines
I am not sure it is that simple. Once you are in the BOOTCMD macro's if you end up back at the board file macros you kinda have to repeat the load steps again just to get the args or specifics set.
When the loading of the ENV file fails but the loading of the other images succeeds maybe something as simple as
"run
board_cfg" Which can be a fall back to a board file specific configuration macro for whatever you want.If you don't need it then it is NULL
If the value of bootcmd was customizable, then you could easily add e.g. "nand_custom" as the last entry in it, and that could do whatever was appropriate (it would translate to run bootcmd_nand_custom, which the board would define). That'd work very consistently with all the other options.
Eventually, I'd love to have a BIOS-like (runtime) config menu, where any variable named bootcmd_* would show up in the list, and provide an interactive way to re-order and enable/disable all the options, i.e. an interactive menu-driven editor for the value of $bootcmd. If custom options get implemented the same way as the standard options, then the custom options would integrate very well into that scheme.
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 25 lines · Stephen Warren
Quoted 4 lines · Dan Murphy
Quoted 3 lines · Stephen Warren
Quoted 2 lines · Dan Murphy
Quoted 1 line · Stephen Warren
On 02/19/2014 11:52 AM, Dan Murphy wrote:
...
Quoted 19 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
If no config file exists should we not try to default to a known good default tested case?
I believe always loading a script/config-file is the simplest and most flexible approach, for a *distro* *oriented* boot process.
Quoted 8 lines
Quoted 5 lines
Quoted 4 lines
Now, specific U-Boot board configs can always add extra stuff on the end (or start?) of bootcmd in order to do some custom fallbacks or backwards-compatibility if they want, but I'm certainly not planning on doing anything like that for Tegra or Raspberry Pi, for example.
Yeah I am not seeing how the board config can do that if there is no provisions in the common file.
Presumably all it needs is an extra hook/variable that is added to the start/end of bootcmd. Should be pretty easy to add in a future patch rev, or followon patch.
<snip>
I am not sure it is that simple. Once you are in the BOOTCMD macro's if you end up back at the board file macros you kinda have to repeat the load steps again just to get the args or specifics set.
When the loading of the ENV file fails but the loading of the other images succeeds maybe something as simple as
Quoted 8 lines
Quoted 3 lines
"run
board_cfg" Which can be a fall back to a board file specific configuration macro for whatever you want.If you don't need it then it is NULL
If the value of bootcmd was customizable, then you could easily add e.g. "
nand_custom" as the last entry in it, and that could do whatever was appropriate (it would translate to runbootcmd_nand_custom, which the board would define). That'd work very consistently with all the other options.
Well is this not what the BB patch does is calls upon the common boot_cmd and if that fails then comes back to the board config to run nand_boot?
This does not really solve any of my issue of not having (or realizing I need) a script for boot on the boot partition. No default case here to rely on as an in tree solution.
Dan
Quoted 6 lines
Eventually, I'd love to have a BIOS-like (runtime) config menu, where any variable named bootcmd_* would show up in the list, and provide an interactive way to re-order and enable/disable all the options, i.e. an interactive menu-driven editor for the value of $bootcmd. If custom options get implemented the same way as the standard options, then the custom options would integrate very well into that scheme.
Signature · 2 lines
------------------ Dan Murphy
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
In reply to Stephen WarrenQuoted 29 lines · Stephen Warren
Quoted 28 lines · Dan Murphy
Quoted 26 lines · Stephen Warren
Quoted 10 lines · Dan Murphy
Quoted 9 lines · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>include/config_distro_bootcmd.h +7
-0+#ifdef CONFIG_CMD_USB +#define BOOTCMD_INIT_USB "run usb_init; " +#define BOOTCMDS_USB \ + "usb_init=" \ + "if ${usb_need_init}; then " \ + "set usb_need_init false; " \ + "usb start 0; " \Quoted 8 lines
include/config_distro_bootcmd.h line 41
Quoted 6 lines
include/config_distro_bootcmd.h +6
-0+"fi\0" \ + \ +"usb_boot=" \ +"setenv devtype usb; " \ +BOOTCMD_INIT_USB \ +"if usb dev ${devnum}; then " \This may have already been highlighted but I don't see where the kernel command line arguments can be set. If you have the file system on the USB stick won't you need to direct the root to the stick?
They would be set in boot.scr or extlinux.cfg on the disk that the system boots from; the kernel cmdline is part of the OS that's installed there, not part of U-Boot. This is why these boot scripts load a script/config-file from the disk which in turn defines which
kernel/DTB/cmdlineto use, rather than directly loading a kernel and DTB. This approach should even be suitable for booting a non-Linux-OS, with suitable commands in boot.scr.
Quoted 8 lines
Quoted 5 lines
But shouldn't the config file just be an override?
I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot.
If no config file exists should we not try to default to a known good default tested case?
I believe always loading a script/config-file is the simplest and most flexible approach, for a *distro* *oriented* boot process.
+1
Scripts have the benefit of putting everything into a relatively easy-to-read form that only uses documented U-Boot commands, not board-specific constructs.
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 36 lines · Eric Nelson
Quoted 35 lines · Stephen Warren
Quoted 33 lines · Dan Murphy
Quoted 19 lines · Stephen Warren
Quoted 10 lines · Dan Murphy
Quoted 9 lines · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>include/config_distro_bootcmd.h +7
-0+#ifdef CONFIG_CMD_USB +#define BOOTCMD_INIT_USB "run usb_init; " +#define BOOTCMDS_USB \ + "usb_init=" \ + "if ${usb_need_init}; then " \ + "set usb_need_init false; " \ + "usb start 0; " \Quoted 8 lines
include/config_distro_bootcmd.h line 41
Quoted 6 lines
include/config_distro_bootcmd.h +6
-0+"fi\0" \ + \ +"usb_boot=" \ +"setenv devtype usb; " \ +BOOTCMD_INIT_USB \ +"if usb dev ${devnum}; then " \This may have already been highlighted but I don't see where the kernel command line arguments can be set. If you have the file system on the USB stick won't you need to direct the root to the stick?
Quoted 7 lines
They would be set in boot.scr or extlinux.cfg on the disk that the system boots from; the kernel cmdline is part of the OS that's installed there, not part of U-Boot. This is why these boot scripts load a script/config-file from the disk which in turn defines which
kernel/DTB/cmdlineto use, rather than directly loading a kernel and DTB. This approach should even be suitable for booting a non-Linux-OS, with suitable commands in boot.scr.But shouldn't the config file just be an override?
I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot.
If no config file exists should we not try to default to a known good default tested case?
Quoted 9 lines
Quoted 2 lines
I believe always loading a script/config-file is the simplest and most flexible approach, for a *distro* *oriented* boot process.
+1
Scripts have the benefit of putting everything into a relatively easy-to-read form that only uses documented U-Boot commands, not board-specific constructs.
Oh don't get me wrong I agree with having the scripts.
Just sayin we should not rely on the scripts being there and mandating their usage. We may want to have a fall back to a known good tested configuration.
Dan
Signature · 2 lines
------------------ Dan Murphy
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 47 lines · Dan Murphy
Quoted 36 lines · Eric Nelson
Quoted 35 lines · Stephen Warren
Quoted 33 lines · Dan Murphy
Quoted 19 lines · Stephen Warren
Quoted 10 lines · Dan Murphy
Quoted 9 lines · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>include/config_distro_bootcmd.h +7
-0+#ifdef CONFIG_CMD_USB +#define BOOTCMD_INIT_USB "run usb_init; " +#define BOOTCMDS_USB \ + "usb_init=" \ + "if ${usb_need_init}; then " \ + "set usb_need_init false; " \ + "usb start 0; " \Quoted 8 lines
include/config_distro_bootcmd.h
Quoted 6 lines
include/config_distro_bootcmd.h +6
-0+"fi\0" \ + \ +"usb_boot=" \ +"setenv devtype usb; " \ +BOOTCMD_INIT_USB \ +"if usb dev ${devnum}; then " \This may have already been highlighted but I don't see where the kernel command line arguments can be set. If you have the file system on the USB stick won't you need to direct the root to the stick?
Quoted 7 lines
They would be set in boot.scr or extlinux.cfg on the disk that the system boots from; the kernel cmdline is part of the OS that's installed there, not part of U-Boot. This is why these boot scripts load a script/config-file from the disk which in turn defines which
kernel/DTB/cmdlineto use, rather than directly loading a kernel and DTB. This approach should even be suitable for booting a non-Linux-OS, with suitable commands in boot.scr.But shouldn't the config file just be an override?
I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot.
If no config file exists should we not try to default to a known good default tested case?
Quoted 9 lines
Quoted 2 lines
I believe always loading a script/config-file is the simplest and most flexible approach, for a *distro* *oriented* boot process.
+1
Scripts have the benefit of putting everything into a relatively easy-to-read form that only uses documented U-Boot commands, not board-specific constructs.
Quoted 5 lines
Oh don't get me wrong I agree with having the scripts.
Just sayin we should not rely on the scripts being there and mandating their usage.
We may want to have a fall back to a known good tested configuration.
I think I see where you're coming from, but it's already expected that you're passing in a good device tree too, so it would be making sure that you also have a useful env file to get loaded in the DHCP or PXE case.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140219/0661c2bd/attachment.pgp>
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 46 lines · Tom Rini
Quoted 45 lines · Dan Murphy
Quoted 33 lines · Eric Nelson
Quoted 32 lines · Stephen Warren
Quoted 31 lines · Dan Murphy
Quoted 19 lines · Stephen Warren
Quoted 10 lines · Dan Murphy
Quoted 9 lines · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>include/config_distro_bootcmd.h +7
-0+#ifdef CONFIG_CMD_USB +#define BOOTCMD_INIT_USB "run usb_init; " +#define BOOTCMDS_USB \ + "usb_init=" \ + "if ${usb_need_init}; then " \ + "set usb_need_init false; " \ + "usb start 0; " \Quoted 8 lines
include/config_distro_bootcmd.h
Quoted 6 lines
include/config_distro_bootcmd.h +6
-0+"fi\0" \ + \ +"usb_boot=" \ +"setenv devtype usb; " \ +BOOTCMD_INIT_USB \ +"if usb dev ${devnum}; then " \This may have already been highlighted but I don't see where the kernel command line arguments can be set. If you have the file system on the USB stick won't you need to direct the root to the stick?
Quoted 7 lines
They would be set in boot.scr or extlinux.cfg on the disk that the system boots from; the kernel cmdline is part of the OS that's installed there, not part of U-Boot. This is why these boot scripts load a script/config-file from the disk which in turn defines which
kernel/DTB/cmdlineto use, rather than directly loading a kernel and DTB. This approach should even be suitable for booting a non-Linux-OS, with suitable commands in boot.scr.But shouldn't the config file just be an override?
I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot.
Quoted 9 lines
Quoted 3 lines
Quoted 1 line
If no config file exists should we not try to default to a known good default tested case?
I believe always loading a script/config-file is the simplest and most flexible approach, for a *distro* *oriented* boot process.
+1
Scripts have the benefit of putting everything into a relatively easy-to-read form that only uses documented U-Boot commands, not board-specific constructs.
Oh don't get me wrong I agree with having the scripts.
Quoted 8 lines
Quoted 3 lines
Just sayin we should not rely on the scripts being there and mandating their usage.
We may want to have a fall back to a known good tested configuration.I think I see where you're coming from, but it's already expected that you're passing in a good device tree too, so it would be making sure that you also have a useful env file to get loaded in the DHCP or PXE case.
Do we have a directory where default scripts exist for each board? Or at least samples for each board?
I could not find them. If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory
Maybe this would be something that helps defined the known good config that the community can base their changes on.
Dan
Signature · 2 lines
------------------ Dan Murphy
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On 02/19/2014 12:24 PM, Dan Murphy wrote:
...
Quoted 5 lines
Do we have a directory where default scripts exist for each board? Or at least samples for each board?
I could not find them. If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory
Maybe this would be something that helps defined the known good config that the community can base their changes on.
For Tegra, I have created:
https://github.com/NVIDIA/tegra-uboot-scripts
I imagine those scripts would work on most boards that use the U-Boot config in this patch series. I've certainly used almost identical scripts on the Raspberry Pi.
I should perhaps put an example extlinux.conf into that repo too.
I imagine (well, it's pretty much the whole point) that distro installers (e.g. Anaconda) will soon (or already do) support spitting out extlinux.conf that'll work on ARM U-Boot too.
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Stephen
Quoted 15 lines · Stephen Warren
On 02/19/2014 12:24 PM, Dan Murphy wrote:
...Quoted 5 lines
Do we have a directory where default scripts exist for each board? Or at least samples for each board?
I could not find them. If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory
Maybe this would be something that helps defined the known good config that the community can base their changes on.
For Tegra, I have created:
https://github.com/NVIDIA/tegra-uboot-scripts
I imagine those scripts would work on most boards that use the U-Boot config in this patch series. I've certainly used almost identical scripts on the Raspberry Pi.
Quoted 5 lines
I should perhaps put an example extlinux.conf into that repo too.
I imagine (well, it's pretty much the whole point) that distro installers (e.g. Anaconda) will soon (or already do) support spitting out extlinux.conf that'll work on ARM U-Boot too.
That's nice! Real time script building if you can find the repo you pointed to.
But I was looking for something that was in tree though as a default. Then maybe overridden by a board uEnv.txt file.
Just something that can be used to get a basic boot from whatever the board manufacturer wants to make their default storage.
Dan
Signature · 2 lines
------------------ Dan Murphy
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 24 lines · Dan Murphy
Stephen
Quoted 15 lines · Stephen Warren
On 02/19/2014 12:24 PM, Dan Murphy wrote:
...Quoted 5 lines
Do we have a directory where default scripts exist for each board? Or at least samples for each board?
I could not find them. If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory
Maybe this would be something that helps defined the known good config that the community can base their changes on.
For Tegra, I have created:
https://github.com/NVIDIA/tegra-uboot-scripts
I imagine those scripts would work on most boards that use the U-Boot config in this patch series. I've certainly used almost identical scripts on the Raspberry Pi.
Quoted 5 lines
I should perhaps put an example extlinux.conf into that repo too.
I imagine (well, it's pretty much the whole point) that distro installers (e.g. Anaconda) will soon (or already do) support spitting out extlinux.conf that'll work on ARM U-Boot too.
Quoted 6 lines
That's nice! Real time script building if you can find the repo you pointed to.
But I was looking for something that was in tree though as a default. Then maybe overridden by a board uEnv.txt file.
Just something that can be used to get a basic boot from whatever the board manufacturer wants to make their default storage.
Yes, for the next go-round we need examples too perhaps, either directly or at least mentioned in board/.../README
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140219/0d917d7c/attachment.pgp>
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
In reply to Stephen WarrenQuoted 16 lines · Stephen Warren
On 02/19/2014 12:24 PM, Dan Murphy wrote:
...Quoted 5 lines
Do we have a directory where default scripts exist for each board? Or at least samples for each board?
I could not find them. If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory
Maybe this would be something that helps defined the known good config that the community can base their changes on.
For Tegra, I have created:
https://github.com/NVIDIA/tegra-uboot-scripts
I imagine those scripts would work on most boards that use the U-Boot config in this patch series. I've certainly used almost identical scripts on the Raspberry Pi.
Quoted 5 lines
I should perhaps put an example extlinux.conf into that repo too.
I imagine (well, it's pretty much the whole point) that distro installers (e.g. Anaconda) will soon (or already do) support spitting out extlinux.conf that'll work on ARM U-Boot too.
Hey Otavio, is OpenEmbedded doing this yet? I know there's syslinux.conf support in since ages ago...
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140219/220c9565/attachment.pgp>
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 20 lines · Tom Rini
Quoted 19 lines · Stephen Warren
On 02/19/2014 12:24 PM, Dan Murphy wrote:
...Quoted 8 lines
Do we have a directory where default scripts exist for each board? Or at least samples for each board?
I could not find them. If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory
Maybe this would be something that helps defined the known good config that the community can base their changes on.
For Tegra, I have created:
https://github.com/NVIDIA/tegra-uboot-scripts
I imagine those scripts would work on most boards that use the U-Boot config in this patch series. I've certainly used almost identical scripts on the Raspberry Pi.
Quoted 8 lines
Quoted 5 lines
I should perhaps put an example extlinux.conf into that repo too.
I imagine (well, it's pretty much the whole point) that distro installers (e.g. Anaconda) will soon (or already do) support spitting out extlinux.conf that'll work on ARM U-Boot too.
Hey Otavio, is OpenEmbedded doing this yet? I know there's syslinux.conf support in since ages ago...
It certainly is possible to do the same in OE. The process wasn't unified enough across the platforms in order to do that, though...
Signature · 1 line
Denys
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
In reply to Tom RiniHello Tom,
Quoted 17 lines · Tom Rini
Quoted 16 lines · Stephen Warren
On 02/19/2014 12:24 PM, Dan Murphy wrote:
...Quoted 5 lines
Do we have a directory where default scripts exist for each board? Or at least samples for each board?
I could not find them. If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory
Maybe this would be something that helps defined the known good config that the community can base their changes on.
For Tegra, I have created:
https://github.com/NVIDIA/tegra-uboot-scripts
I imagine those scripts would work on most boards that use the U-Boot config in this patch series. I've certainly used almost identical scripts on the Raspberry Pi.
Quoted 8 lines
Quoted 5 lines
I should perhaps put an example extlinux.conf into that repo too.
I imagine (well, it's pretty much the whole point) that distro installers (e.g. Anaconda) will soon (or already do) support spitting out extlinux.conf that'll work on ARM U-Boot too.
Hey Otavio, is OpenEmbedded doing this yet? I know there's syslinux.conf support in since ages ago...
As Denys said it is not yet supported but should be easily doable. :-)
Signature · 3 lines
Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Quoted 22 lines · Otavio Salvador
Hello Tom,
Quoted 19 lines · Tom Rini
Quoted 18 lines · Stephen Warren
On 02/19/2014 12:24 PM, Dan Murphy wrote:
...Quoted 5 lines
Do we have a directory where default scripts exist for each board? Or at least samples for each board?
I could not find them. If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory
Maybe this would be something that helps defined the known good config that the community can base their changes on.
For Tegra, I have created:
https://github.com/NVIDIA/tegra-uboot-scripts
I imagine those scripts would work on most boards that use the U-Boot config in this patch series. I've certainly used almost identical scripts on the Raspberry Pi.
I should perhaps put an example extlinux.conf into that repo too.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
I imagine (well, it's pretty much the whole point) that distro installers (e.g. Anaconda) will soon (or already do) support spitting out extlinux.conf that'll work on ARM U-Boot too.
Hey Otavio, is OpenEmbedded doing this yet? I know there's syslinux.conf support in since ages ago...
As Denys said it is not yet supported but should be easily doable. :-)
Well, can I suggest / beg that we get started? :) I'd love to see OE be ready when this is out in the next release.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140220/d7995586/attachment.pgp>
RFC PATCH 1/3 add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Hello Tom,
Quoted 27 lines · Tom Rini
Quoted 26 lines · Otavio Salvador
Hello Tom,
Quoted 23 lines · Tom Rini
Quoted 21 lines · Stephen Warren
On 02/19/2014 12:24 PM, Dan Murphy wrote:
...Quoted 5 lines
Do we have a directory where default scripts exist for each board? Or at least samples for each board?
I could not find them. If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory
Maybe this would be something that helps defined the known good config that the community can base their changes on.
For Tegra, I have created:
https://github.com/NVIDIA/tegra-uboot-scripts
I imagine those scripts would work on most boards that use the U-Boot config in this patch series. I've certainly used almost identical scripts on the Raspberry Pi.
I should perhaps put an example extlinux.conf into that repo too.
I imagine (well, it's pretty much the whole point) that distro installers (e.g. Anaconda) will soon (or already do) support spitting out extlinux.conf that'll work on ARM U-Boot too.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
Hey Otavio, is OpenEmbedded doing this yet? I know there's syslinux.conf support in since ages ago...
As Denys said it is not yet supported but should be easily doable. :-)
Well, can I suggest / beg that we get started? :) I'd love to see OE be ready when this is out in the next release.
Yes; I will start looking how to integrate it.
Signature · 3 lines
Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
RFC PATCH 2/3 move the beaglebones over to the generic configs
In reply to Dennis Gilmore--- include/configs/am335x_evm.h | 109 ++++---------------------------------- include/configs/ti_armv7_common.h | 28 ++-------- 2 files changed, 16 insertions(+), 121 deletions(-)
include/configs/am335x_evm.h +11 -98
@@ -43,9 +43,9 @@"nandrootfstype=ubifs rootwait=1\0" \"nandboot=echo Booting from nand ...; " \"run nandargs; " \ -"nand read ${fdtaddr} u-boot-spl-os; " \ +"nand read ${fdt_addr} u-boot-spl-os; " \"nand read ${loadaddr} kernel; " \ - "bootz ${loadaddr} - ${fdtaddr}\0" + "bootz ${loadaddr} - ${fdt_addr}\0"#else #define NANDARGS ""#endif
@@ -55,98 +55,13 @@#ifndef CONFIG_SPL_BUILD #define CONFIG_EXTRA_ENV_SETTINGS \ "loadaddr=0x80200000\0" \ - "fdtaddr=0x80F80000\0" \ + "fdt_addr=0x80F80000\0" \ + "fdt_addr_r=0x80F80000\0" \ "fdt_high=0xffffffff\0" \ - "boot_fdt=try\0" \ - "rdaddr=0x81000000\0" \ - "bootpart=0:2\0" \ - "bootdir=/boot\0" \ - "bootfile=zImage\0" \ - "fdtfile=undefined\0" \ - "console=ttyO0,115200n8\0" \ - "optargs=\0" \ - "mmcdev=0\0" \ - "mmcroot=/dev/mmcblk0p2 ro\0" \ - "mmcrootfstype=ext4 rootwait\0" \ - "rootpath=/export/rootfs\0" \ - "nfsopts=nolock\0" \ - "static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}" \ - "::off\0" \ - "ramroot=/dev/ram0 rw ramdisk_size=65536 initrd=${rdaddr},64M\0" \ - "ramrootfstype=ext2\0" \ - "mmcargs=setenv bootargs console=${console} " \ - "${optargs} " \ - "root=${mmcroot} " \ - "rootfstype=${mmcrootfstype}\0" \ - "spiroot=/dev/mtdblock4 rw\0" \ - "spirootfstype=jffs2\0" \ - "spisrcaddr=0xe0000\0" \ - "spiimgsize=0x362000\0" \ - "spibusno=0\0" \ - "spiargs=setenv bootargs console=${console} " \ - "${optargs} " \ - "root=${spiroot} " \ - "rootfstype=${spirootfstype}\0" \ - "netargs=setenv bootargs console=${console} " \ - "${optargs} " \ - "root=/dev/nfs " \ - "nfsroot=${serverip}:${rootpath},${nfsopts} rw " \ - "ip=dhcp\0" \ - "bootenv=uEnv.txt\0" \ - "loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \ - "importbootenv=echo Importing environment from mmc ...; " \ - "env import -t $loadaddr $filesize\0" \ - "ramargs=setenv bootargs console=${console} " \ - "${optargs} " \ - "root=${ramroot} " \ - "rootfstype=${ramrootfstype}\0" \ - "loadramdisk=load mmc ${mmcdev} ${rdaddr} ramdisk.gz\0" \ - "loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \ - "loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \ - "mmcloados=run mmcargs; " \ - "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \ - "if run loadfdt; then " \ - "bootz ${loadaddr} - ${fdtaddr}; " \ - "else " \ - "if test ${boot_fdt} = try; then " \ - "bootz; " \ - "else " \ - "echo WARN: Cannot load the DT; " \ - "fi; " \ - "fi; " \ - "else " \ - "bootz; " \ - "fi;\0" \ - "mmcboot=mmc dev ${mmcdev}; " \ - "if mmc rescan; then " \ - "echo SD/MMC found on device ${mmcdev};" \ - "if run loadbootenv; then " \ - "echo Loaded environment from ${bootenv};" \ - "run importbootenv;" \ - "fi;" \ - "if test -n $uenvcmd; then " \ - "echo Running uenvcmd ...;" \ - "run uenvcmd;" \ - "fi;" \ - "if run loadimage; then " \ - "run mmcloados;" \ - "fi;" \ - "fi;\0" \ - "spiboot=echo Booting from spi ...; " \ - "run spiargs; " \ - "sf probe ${spibusno}:0; " \ - "sf read ${loadaddr} ${spisrcaddr} ${spiimgsize}; " \ - "bootz ${loadaddr}\0" \ - "netboot=echo Booting from network ...; " \ - "setenv autoload no; " \ - "dhcp; " \ - "tftp ${loadaddr} ${bootfile}; " \ - "tftp ${fdtaddr} ${fdtfile}; " \ - "run netargs; " \ - "bootz ${loadaddr} - ${fdtaddr}\0" \ - "ramboot=echo Booting from ramdisk ...; " \ - "run ramargs; " \ - "bootz ${loadaddr} ${rdaddr} ${fdtaddr}\0" \ + "ramdisk_addr_r=0x81000000\0" \ + "kernel_addr_r=0x80200000\0" \ + "pxe_addr_r=0x80000000\0" \ + "scriptaddr=0x80000000\0" \ "findfdt="\ "if test $board_name = A335BONE; then " \ "setenv fdtfile am335x-bone.dtb; fi; " \
@@ -159,15 +74,13 @@"if test $fdtfile = undefined; then " \"echo WARNING: Could not determine device tree to use; fi; \0" \NANDARGS \ - DFUARGS +DFUARGS \ + BOOTCMDS_COMMON#endif #define CONFIG_BOOTCOMMAND \ "run findfdt; " \ - "run mmcboot;" \ - "setenv mmcdev 1; " \ - "setenv bootpart 1:2; " \ - "run mmcboot;" \ + "for target in ${boot_targets}; do run bootcmd_${target}; done" \ "run nandboot;"/* NS16550 Configuration */
include/configs/ti_armv7_common.h +5 -23
@@ -28,7 +28,6 @@#define CONFIG_SYS_NO_FLASH /* Support both device trees and ATAGs. */ -#define CONFIG_OF_LIBFDT #define CONFIG_CMDLINE_TAG #define CONFIG_SETUP_MEMORY_TAGS #define CONFIG_INITRD_TAG
@@ -40,11 +39,6 @@#define CONFIG_SYS_LOAD_ADDR 0x80000000/* -* Default to a quick boot delay. -*/ -#define CONFIG_BOOTDELAY 1 - -/* * DDR information. We say (for simplicity) that we have 1 bank, * always, even when we have more. We always start at 0x80000000, * and we place the initial stack pointer in our SRAM.
@@ -101,19 +95,12 @@* console baudrate of 115200 and use the default baud rate table. */ #define CONFIG_SYS_MALLOC_LEN (1024 << 10) -#define CONFIG_SYS_HUSH_PARSER #define CONFIG_SYS_PROMPT "U-Boot# "#define CONFIG_SYS_CONSOLE_INFO_QUIET #define CONFIG_BAUDRATE 115200#define CONFIG_ENV_VARS_UBOOT_CONFIG /* Strongly encouraged */ #define CONFIG_ENV_OVERWRITE /* Overwrite ethaddr / serial# */ -/* As stated above, the following choices are optional. */ -#define CONFIG_SYS_LONGHELP -#define CONFIG_AUTO_COMPLETE -#define CONFIG_CMDLINE_EDITING -#define CONFIG_VERSION_VARIABLE -/* We set the max number of command args high to avoid HUSH bugs. */ #define CONFIG_SYS_MAXARGS 64
@@ -146,19 +133,14 @@#include <config_cmd_default.h> #define CONFIG_CMD_ASKENV #define CONFIG_CMD_ECHO -#define CONFIG_CMD_BOOTZ /* -* Common filesystems support. When we have removable storage we -* enabled a number of useful commands and support. +* Include the generic config options and boot environment when not +* building our SPL */ -#if defined(CONFIG_MMC ) || defined(CONFIG_USB_STORAGE ) -#define CONFIG_DOS_PARTITION -#define CONFIG_CMD_FAT -#define CONFIG_FAT_WRITE -#define CONFIG_CMD_EXT2 -#define CONFIG_CMD_EXT4 -#define CONFIG_CMD_FS_GENERIC +#ifndef CONFIG_SPL_BUILD +#include <config_distro_defaults.h> +#include <config_distro_bootcmd.h> #endif /*
Signature · 1 line
1.8.5.3
RFC PATCH 2/3 move the beaglebones over to the generic configs
On Mon, Feb 17, 2014 at 11:56:37AM -0600, Dennis Gilmore wrote:
[snip]
include/configs/am335x_evm.h line 48
Quoted 5 lines
include/configs/am335x_evm.h +2
-2-"nand read ${fdtaddr} u-boot-spl-os; " \ +"nand read ${fdt_addr} u-boot-spl-os; " \"nand read ${loadaddr} kernel; " \ -"bootz ${loadaddr} - ${fdtaddr}\0" +"bootz ${loadaddr} - ${fdt_addr}\0"
In all of these conversions you should switch loadaddr to kernel_addr_r too.
[snip]
include/configs/am335x_evm.h line 65
Quoted 1 line
include/configs/am335x_evm.h +0
-1-"fdtfile=undefined\0" \
That's a problem. Need this for 'findfdt' to work.
Quoted 4 lines
include/configs/am335x_evm.h +0
-4-"rootpath=/export/rootfs\0" \ -"nfsopts=nolock\0" \ -"static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}" \ -"::off\0" \
[snip]
Quoted 14 lines
include/configs/am335x_evm.h +0
-14-"spiroot=/dev/mtdblock4 rw\0" \ -"spirootfstype=jffs2\0" \ -"spisrcaddr=0xe0000\0" \ -"spiimgsize=0x362000\0" \ -"spibusno=0\0" \ -"spiargs=setenv bootargs console=${console} " \ -"${optargs} " \ -"root=${spiroot} " \ -"rootfstype=${spirootfstype}\0" \ -"netargs=setenv bootargs console=${console} " \ -"${optargs} " \ -"root=/dev/nfs " \ -"nfsroot=${serverip}:${rootpath},${nfsopts} rw " \ -"ip=dhcp\0" \
[snip]
Quoted 5 lines
include/configs/am335x_evm.h +0
-5-"spiboot=echo Booting from spi ...; " \ -"run spiargs; " \ -"sf probe ${spibusno}:0; " \ -"sf read ${loadaddr} ${spisrcaddr} ${spiimgsize}; " \ -"bootz ${loadaddr}\0" \
include/configs/am335x_evm.h line 149
Quoted 10 lines
include/configs/am335x_evm.h +0
-10-"netboot=echo Booting from network ...; " \ -"setenv autoload no; " \ -"dhcp; " \ -"tftp ${loadaddr} ${bootfile}; " \ -"tftp ${fdtaddr} ${fdtfile}; " \ -"run netargs; " \ -"bootz ${loadaddr} - ${fdtaddr}\0" \ -"ramboot=echo Booting from ramdisk ...; " \ -"run ramargs; " \ -"bootz ${loadaddr} ${rdaddr} ${fdtaddr}\0" \
And this is functionality I don't see in the generic distro config that we still need.
[snip]
Quoted 7 lines
/*
- * Common filesystems support. When we have removable storage we
- * enabled a number of useful commands and support.
+ * Include the generic config options and boot environment when not
+ * building our SPL
*/include/configs/ti_armv7_common.h +0
-1-#if defined(CONFIG_MMC ) || defined(CONFIG_USB_STORAGE )
include/configs/ti_armv7_common.h line 144
Quoted 10 lines
include/configs/ti_armv7_common.h +3
-6-#define CONFIG_DOS_PARTITION -#define CONFIG_CMD_FAT -#define CONFIG_FAT_WRITE -#define CONFIG_CMD_EXT2 -#define CONFIG_CMD_EXT4 -#define CONFIG_CMD_FS_GENERIC +#ifndef CONFIG_SPL_BUILD +#include <config_distro_defaults.h> +#include <config_distro_bootcmd.h> #endif
This is fine, for now, but I'll have to shuffle things around later as some of the good feedback I'd gotten off-list about ti_armv7_common.h is that it's not as useful for non-Linux targets, so I need to adjust the contents a bit more.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140219/f3188ae9/attachment.pgp>
RFC PATCH 2/3 move the beaglebones over to the generic configs
In reply to Dennis GilmoreQuoted 1 line · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>
Patch description?
include/configs/am335x_evm.h line 59
Quoted 7 lines
include/configs/am335x_evm.h +2
-1#define CONFIG_EXTRA_ENV_SETTINGS \ "loadaddr=0x80200000\0" \ - "fdtaddr=0x80F80000\0" \ + "fdt_addr=0x80F80000\0" \ + "fdt_addr_r=0x80F80000\0" \
Why set both? Surely only fdt_addr_r is required/useful?
include/configs/am335x_evm.h line 69
Quoted 1 line
include/configs/am335x_evm.h +0
-1-"mmcroot=/dev/mmcblk0p2 ro\0" \
That implies that rootpart=1 in config_distro_bootcmd.h isn't correct for this board?
Quoted 14 lines
include/configs/am335x_evm.h +0
-14-"rootpath=/export/rootfs\0" \ -"nfsopts=nolock\0" \ -"static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}" \ -"::off\0" \ -"ramroot=/dev/ram0 rw ramdisk_size=65536 initrd=${rdaddr},64M\0" \ -"ramrootfstype=ext2\0" \ -"mmcargs=setenv bootargs console=${console} " \ -"${optargs} " \ -"root=${mmcroot} " \ -"rootfstype=${mmcrootfstype}\0" \ -"spiroot=/dev/mtdblock4 rw\0" \ -"spirootfstype=jffs2\0" \ -"spisrcaddr=0xe0000\0" \ -"spiimgsize=0x362000\0" \
include/configs/am335x_evm.h line 94
Quoted 10 lines
include/configs/am335x_evm.h +0
-10-"spibusno=0\0" \ -"spiargs=setenv bootargs console=${console} " \ -"${optargs} " \ -"root=${spiroot} " \ -"rootfstype=${spirootfstype}\0" \ -"netargs=setenv bootargs console=${console} " \ -"${optargs} " \ -"root=/dev/nfs " \ -"nfsroot=${serverip}:${rootpath},${nfsopts} rw " \ -"ip=dhcp\0" \
I'm not at all familiar with this board, but this seems to be removing NFS and SPI boot capabilities, maybe others too?
RFC PATCH 2/3 move the beaglebones over to the generic configs
In reply to Dennis GilmoreQuoted 201 lines · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>--- include/configs/am335x_evm.h | 109 ++++---------------------------------- include/configs/ti_armv7_common.h | 28 ++-------- 2 files changed, 16 insertions(+), 121 deletions(-)include/configs/am335x_evm.h +11
-98@@ -43,9 +43,9 @@"nandrootfstype=ubifs rootwait=1\0" \"nandboot=echo Booting from nand ...; " \"run nandargs; " \ -"nand read ${fdtaddr} u-boot-spl-os; " \ +"nand read ${fdt_addr} u-boot-spl-os; " \"nand read ${loadaddr} kernel; " \ - "bootz ${loadaddr} - ${fdtaddr}\0" + "bootz ${loadaddr} - ${fdt_addr}\0"#else #define NANDARGS ""#endif @@ -55,98 +55,13 @@#ifndef CONFIG_SPL_BUILD #define CONFIG_EXTRA_ENV_SETTINGS \ "loadaddr=0x80200000\0" \ - "fdtaddr=0x80F80000\0" \ + "fdt_addr=0x80F80000\0" \ + "fdt_addr_r=0x80F80000\0" \ "fdt_high=0xffffffff\0" \ - "boot_fdt=try\0" \ - "rdaddr=0x81000000\0" \ - "bootpart=0:2\0" \ - "bootdir=/boot\0" \ - "bootfile=zImage\0" \ - "fdtfile=undefined\0" \ - "console=ttyO0,115200n8\0" \ - "optargs=\0" \ - "mmcdev=0\0" \ - "mmcroot=/dev/mmcblk0p2 ro\0" \ - "mmcrootfstype=ext4 rootwait\0" \ - "rootpath=/export/rootfs\0" \ - "nfsopts=nolock\0" \ - "static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}" \ - "::off\0" \ - "ramroot=/dev/ram0 rw ramdisk_size=65536 initrd=${rdaddr},64M\0" \ - "ramrootfstype=ext2\0" \ - "mmcargs=setenv bootargs console=${console} " \ - "${optargs} " \ - "root=${mmcroot} " \ - "rootfstype=${mmcrootfstype}\0" \ - "spiroot=/dev/mtdblock4 rw\0" \ - "spirootfstype=jffs2\0" \ - "spisrcaddr=0xe0000\0" \ - "spiimgsize=0x362000\0" \ - "spibusno=0\0" \ - "spiargs=setenv bootargs console=${console} " \ - "${optargs} " \ - "root=${spiroot} " \ - "rootfstype=${spirootfstype}\0" \ - "netargs=setenv bootargs console=${console} " \ - "${optargs} " \ - "root=/dev/nfs " \ - "nfsroot=${serverip}:${rootpath},${nfsopts} rw " \ - "ip=dhcp\0" \ - "bootenv=uEnv.txt\0" \ - "loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \ - "importbootenv=echo Importing environment from mmc ...; " \ - "env import -t $loadaddr $filesize\0" \ - "ramargs=setenv bootargs console=${console} " \ - "${optargs} " \ - "root=${ramroot} " \ - "rootfstype=${ramrootfstype}\0" \ - "loadramdisk=load mmc ${mmcdev} ${rdaddr} ramdisk.gz\0" \ - "loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \ - "loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \ - "mmcloados=run mmcargs; " \ - "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \ - "if run loadfdt; then " \ - "bootz ${loadaddr} - ${fdtaddr}; " \ - "else " \ - "if test ${boot_fdt} = try; then " \ - "bootz; " \ - "else " \ - "echo WARN: Cannot load the DT; " \ - "fi; " \ - "fi; " \ - "else " \ - "bootz; " \ - "fi;\0" \ - "mmcboot=mmc dev ${mmcdev}; " \ - "if mmc rescan; then " \ - "echo SD/MMC found on device ${mmcdev};" \ - "if run loadbootenv; then " \ - "echo Loaded environment from ${bootenv};" \ - "run importbootenv;" \ - "fi;" \ - "if test -n $uenvcmd; then " \ - "echo Running uenvcmd ...;" \ - "run uenvcmd;" \ - "fi;" \ - "if run loadimage; then " \ - "run mmcloados;" \ - "fi;" \ - "fi;\0" \ - "spiboot=echo Booting from spi ...; " \ - "run spiargs; " \ - "sf probe ${spibusno}:0; " \ - "sf read ${loadaddr} ${spisrcaddr} ${spiimgsize}; " \ - "bootz ${loadaddr}\0" \ - "netboot=echo Booting from network ...; " \ - "setenv autoload no; " \ - "dhcp; " \ - "tftp ${loadaddr} ${bootfile}; " \ - "tftp ${fdtaddr} ${fdtfile}; " \ - "run netargs; " \ - "bootz ${loadaddr} - ${fdtaddr}\0" \ - "ramboot=echo Booting from ramdisk ...; " \ - "run ramargs; " \ - "bootz ${loadaddr} ${rdaddr} ${fdtaddr}\0" \ + "ramdisk_addr_r=0x81000000\0" \ + "kernel_addr_r=0x80200000\0" \ + "pxe_addr_r=0x80000000\0" \ + "scriptaddr=0x80000000\0" \ "findfdt="\ "if test $board_name = A335BONE; then " \ "setenv fdtfile am335x-bone.dtb; fi; " \@@ -159,15 +74,13 @@"if test $fdtfile = undefined; then " \"echo WARNING: Could not determine device tree to use; fi; \0" \NANDARGS \ - DFUARGS +DFUARGS \ + BOOTCMDS_COMMON#endif #define CONFIG_BOOTCOMMAND \ "run findfdt; " \ - "run mmcboot;" \ - "setenv mmcdev 1; " \ - "setenv bootpart 1:2; " \ - "run mmcboot;" \ + "for target in ${boot_targets}; do run bootcmd_${target}; done" \ "run nandboot;"/* NS16550 Configuration */ include/configs/ti_armv7_common.h +2
-16@@ -28,7 +28,6 @@#define CONFIG_SYS_NO_FLASH /* Support both device trees and ATAGs. */ -#define CONFIG_OF_LIBFDT #define CONFIG_CMDLINE_TAG #define CONFIG_SETUP_MEMORY_TAGS #define CONFIG_INITRD_TAG @@ -40,11 +39,6 @@#define CONFIG_SYS_LOAD_ADDR 0x80000000/* -* Default to a quick boot delay. -*/ -#define CONFIG_BOOTDELAY 1 - -/* * DDR information. We say (for simplicity) that we have 1 bank, * always, even when we have more. We always start at 0x80000000, * and we place the initial stack pointer in our SRAM. @@ -101,19 +95,12 @@* console baudrate of 115200 and use the default baud rate table. */ #define CONFIG_SYS_MALLOC_LEN (1024 << 10) -#define CONFIG_SYS_HUSH_PARSER #define CONFIG_SYS_PROMPT "U-Boot# "#define CONFIG_SYS_CONSOLE_INFO_QUIET #define CONFIG_BAUDRATE 115200#define CONFIG_ENV_VARS_UBOOT_CONFIG /* Strongly encouraged */ #define CONFIG_ENV_OVERWRITE /* Overwrite ethaddr / serial# */ -/* As stated above, the following choices are optional. */ -#define CONFIG_SYS_LONGHELP -#define CONFIG_AUTO_COMPLETE -#define CONFIG_CMDLINE_EDITING -#define CONFIG_VERSION_VARIABLE -/* We set the max number of command args high to avoid HUSH bugs. */ #define CONFIG_SYS_MAXARGS 64@@ -146,19 +133,14 @@#include <config_cmd_default.h> #define CONFIG_CMD_ASKENV #define CONFIG_CMD_ECHO -#define CONFIG_CMD_BOOTZ /* -* Common filesystems support. When we have removable storage we -* enabled a number of useful commands and support. +* Include the generic config options and boot environment when not +* building our SPL
include/configs/ti_armv7_common.h line 142
Quoted 10 lines
include/configs/ti_armv7_common.h +2
-7*/ -#if defined(CONFIG_MMC ) || defined(CONFIG_USB_STORAGE ) -#define CONFIG_DOS_PARTITION -#define CONFIG_CMD_FAT -#define CONFIG_FAT_WRITE -#define CONFIG_CMD_EXT2 -#define CONFIG_CMD_EXT4 -#define CONFIG_CMD_FS_GENERIC +#ifndef CONFIG_SPL_BUILD +#include <config_distro_defaults.h>
I did not see the patchset for this.
Should this header and the removal the extra configs be a different patch? Or be part of the series that introduces the distro defaults
Quoted 4 lines
include/configs/ti_armv7_common.h +1
-0+#include <config_distro_bootcmd.h> #endif /*
Signature · 2 lines
------------------ Dan Murphy
RFC PATCH 2/3 move the beaglebones over to the generic configs
Quoted 1 line · Dan Murphy
On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
Missing commit log as well
Quoted 6 lines
Quoted 6 lines
Signed-off-by Dennis Gilmore <[email protected]>--- include/configs/am335x_evm.h | 109 ++++---------------------------------- include/configs/ti_armv7_common.h | 28 ++-------- 2 files changed, 16 insertions(+), 121 deletions(-)
<snip>
Signature · 2 lines
------------------ Dan Murphy
RFC PATCH 2/3 move the beaglebones over to the generic configs
In reply to Dan MurphyQuoted 1 line · Dan Murphy
On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
...
Quoted 7 lines
include/configs/ti_armv7_common.h line 142
Quoted 2 lines
include/configs/ti_armv7_common.h +2
-0+#ifndef CONFIG_SPL_BUILD +#include <config_distro_defaults.h> I did not see the patchset for this.
Should this header and the removal the extra configs be a different patch? Or be part of the series that introduces the distro defaults
The following is already in u-boot/master:13a49c3a739b config: add config_distro_defaults.h
I've sent patches to convert Tegra and RPi to use it, although they aren't applied yet.
RFC PATCH 2/3 move the beaglebones over to the generic configs
Quoted 7 lines · Stephen Warren
Quoted 1 line · Dan Murphy
On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
...
Quoted 4 lines
include/configs/ti_armv7_common.h line 142
Quoted 2 lines
include/configs/ti_armv7_common.h +2
-0+#ifndef CONFIG_SPL_BUILD +#include <config_distro_defaults.h> I did not see the patchset for this.
Quoted 7 lines
Quoted 2 lines
Should this header and the removal the extra configs be a different patch? Or be part of the series that introduces the distro defaults
The following is already in u-boot/master:
13a49c3a739bconfig: addconfig_distro_defaults.hI've sent patches to convert Tegra and RPi to use it, although they aren't applied yet.
Great! So why did this change come in as part of the RFC and not a patch for review and merge?
Dan
Signature · 2 lines
------------------ Dan Murphy
RFC PATCH 2/3 move the beaglebones over to the generic configs
Quoted 10 lines · Dan Murphy
Quoted 9 lines · Stephen Warren
Quoted 1 line · Dan Murphy
On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
...
Quoted 6 lines
include/configs/ti_armv7_common.h line 142
Quoted 2 lines
include/configs/ti_armv7_common.h +2
-0+#ifndef CONFIG_SPL_BUILD +#include <config_distro_defaults.h> I did not see the patchset for this.
Should this header and the removal the extra configs be a different patch? Or be part of the series that introduces the distro defaults
Quoted 7 lines
Quoted 5 lines
The following is already in u-boot/master:
13a49c3a739bconfig: addconfig_distro_defaults.hI've sent patches to convert Tegra and RPi to use it, although they aren't applied yet.
Great! So why did this change come in as part of the RFC and not a patch for review and merge?
Because it needed discussion/comments from the owners of the affected files perhaps?
RFC PATCH 2/3 move the beaglebones over to the generic configs
Quoted 11 lines · Stephen Warren
Quoted 10 lines · Dan Murphy
Quoted 9 lines · Stephen Warren
Quoted 1 line · Dan Murphy
On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
...
Quoted 6 lines
include/configs/ti_armv7_common.h line 142
Quoted 2 lines
include/configs/ti_armv7_common.h +2
-0+#ifndef CONFIG_SPL_BUILD +#include <config_distro_defaults.h> I did not see the patchset for this.
Should this header and the removal the extra configs be a different patch? Or be part of the series that introduces the distro defaults
Quoted 8 lines
Quoted 6 lines
Quoted 5 lines
The following is already in u-boot/master:
13a49c3a739bconfig: addconfig_distro_defaults.hI've sent patches to convert Tegra and RPi to use it, although they aren't applied yet.
Great! So why did this change come in as part of the RFC and not a patch for review and merge?
Because it needed discussion/comments from the owners of the affected files perhaps?
Agreed to the discussion/comments. But this change is not relevant to converting to a common boot right? And it is kinda buried in this patch and might be over looked.
I guess the same can be said for the wandboard patch.
IMHO These changes should be broken out, reviewed then they can be merged quicker if not part of this RFC.
Dan
Signature · 2 lines
------------------ Dan Murphy
RFC PATCH 2/3 move the beaglebones over to the generic configs
Quoted 18 lines · Dan Murphy
Quoted 17 lines · Stephen Warren
Quoted 16 lines · Dan Murphy
Quoted 7 lines · Stephen Warren
Quoted 1 line · Dan Murphy
On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
...
Quoted 4 lines
include/configs/ti_armv7_common.h line 142
Quoted 2 lines
include/configs/ti_armv7_common.h +2
-0+#ifndef CONFIG_SPL_BUILD +#include <config_distro_defaults.h> I did not see the patchset for this.
Quoted 7 lines
Quoted 2 lines
Should this header and the removal the extra configs be a different patch? Or be part of the series that introduces the distro defaults
The following is already in u-boot/master:
13a49c3a739bconfig: addconfig_distro_defaults.hI've sent patches to convert Tegra and RPi to use it, although they aren't applied yet.
Great! So why did this change come in as part of the RFC and not a patch for review and merge?
Quoted 8 lines
Quoted 2 lines
Because it needed discussion/comments from the owners of the affected files perhaps?
Agreed to the discussion/comments. But this change is not relevant to converting to a common boot right? And it is kinda buried in this patch and might be over looked.
I guess the same can be said for the wandboard patch.IMHO These changes should be broken out, reviewed then they can be merged quicker if not part of this RFC.
??? The whole point of this series is to convert the 2 boards to use the two headers that define a standardized set of U-Boot options (the header for which has already been merged) and a standardized set of U-Boot scripts (the header for which is part of this patch series). Splitting them up makes no sense at all.
RFC PATCH 2/3 move the beaglebones over to the generic configs
Quoted 25 lines · Stephen Warren
Quoted 24 lines · Dan Murphy
Quoted 11 lines · Stephen Warren
Quoted 10 lines · Dan Murphy
Quoted 9 lines · Stephen Warren
Quoted 1 line · Dan Murphy
On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
...
Quoted 6 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+#ifndef CONFIG_SPL_BUILD +#include <config_distro_defaults.h>I did not see the patchset for this.
Should this header and the removal the extra configs be a different patch? Or be part of the series that introduces the distro defaults
Quoted 8 lines
Quoted 6 lines
Quoted 5 lines
The following is already in u-boot/master:
13a49c3a739bconfig: addconfig_distro_defaults.hI've sent patches to convert Tegra and RPi to use it, although they aren't applied yet.
Great! So why did this change come in as part of the RFC and not a patch for review and merge?
Because it needed discussion/comments from the owners of the affected files perhaps?
Agreed to the discussion/comments. But this change is not relevant to converting to a common boot right? And it is kinda buried in this patch and might be over looked.
I guess the same can be said for the wandboard patch.
Quoted 6 lines
Quoted 1 line
IMHO These changes should be broken out, reviewed then they can be merged quicker if not part of this RFC.
??? The whole point of this series is to convert the 2 boards to use the two headers that define a standardized set of U-Boot options (the header for which has already been merged) and a standardized set of U-Boot scripts (the header for which is part of this patch series). Splitting them up makes no sense at all.
Hey it was just my opinion. (I just like functional changes broken out for bissectability when debugging issues)
But that is ultimately up to the maintainer to decide in the end. I will attempt to review it when it comes in as an official patchset.
Dan
Signature · 2 lines
------------------ Dan Murphy
RFC PATCH 2/3 move the beaglebones over to the generic configs
In reply to Dan MurphyQuoted 23 lines · On Wed, 19 Feb 2014 14:31:42 -0600 Dan Murphy <[email protected]> wrote:
Quoted 15 lines · Stephen Warren
Quoted 14 lines · Dan Murphy
Quoted 13 lines · Stephen Warren
Quoted 1 line · Dan Murphy
On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
...
Quoted 7 lines
include/configs/ti_armv7_common.h line 142
Quoted 2 lines
include/configs/ti_armv7_common.h +2
-0+#ifndef CONFIG_SPL_BUILD +#include <config_distro_defaults.h> I did not see the patchset for this.
Should this header and the removal the extra configs be a different patch? Or be part of the series that introduces the distro defaults
The following is already in u-boot/master:
13a49c3a739bconfig: addconfig_distro_defaults.hQuoted 6 lines
Quoted 4 lines
Quoted 2 lines
I've sent patches to convert Tegra and RPi to use it, although they aren't applied yet.
Great! So why did this change come in as part of the RFC and not a patch for review and merge?
Because it needed discussion/comments from the owners of the affected files perhaps?
Quoted 7 lines
Agreed to the discussion/comments. But this change is not relevant to converting to a common boot right? And it is kinda buried in this patch and might be over looked. I guess the same can be said for the wandboard patch.
IMHO These changes should be broken out, reviewed then they can be merged quicker if not part of this RFC.
The main point of them and why I sent them as a RFC is that I felt they provided a solid basis and example of how we can share configs and boot logic across soc families. there is a lot of room for improvement still, putting soc family memory locations into their own files for example. I wanted to judge the acceptance of the idea, There was a thread looking to unify i.MX last week. I would like tegra to drop some of the logic carried in configs/tegra-common-post.h and include config_distro_bootcmd.h instead. I chose these two boards because I have and can test them, I would like for all boards that would like a generic distro to run on them to support a standard environment where adding support for a new board is a much simpler process.
I really like Stephen's idea of making boot ordering being bios like in being able to re-order, enable disable, chose a one off boot target. I would like to get to the point that the pxe/extlinux option shows a menu where you select a kernel with up/down keys and can even edit the boot args on the fly, rather than todays choose 1, 2, or 3, etc to pick the kernel to boot.
Right now I am just trying to take small steps to make things simpler for everyone. I would like to think that the chosen settings will work for everyone, but if you're making a specialised product then you can implement only the bits you need in order to make the boot more streamlined.
Dennis
RFC PATCH 3/3 move wandboard over to use the generic distro configuratin and environment
In reply to Dennis Gilmore--- include/configs/wandboard.h | 87 +++++++-------------------------------------- 1 file changed, 12 insertions(+), 75 deletions(-)
include/configs/wandboard.h +12 -75
@@ -41,6 +41,11 @@#define CONFIG_CONS_INDEX 1#define CONFIG_BAUDRATE 115200 +#ifndef CONFIG_SPL_BUILD +#include <config_distro_defaults.h> +#include <config_distro_bootcmd.h> +#endif +/* Command definition */ #include <config_cmd_default.h>
@@ -49,8 +54,6 @@#define CONFIG_CMD_BMODE #define CONFIG_CMD_SETEXPR -#define CONFIG_BOOTDELAY 5 -#define CONFIG_SYS_MEMTEST_START 0x10000000#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START + 500 * SZ_1M)#define CONFIG_LOADADDR 0x12000000
@@ -66,15 +69,8 @@#define CONFIG_CMD_MMC #define CONFIG_GENERIC_MMC #define CONFIG_BOUNCE_BUFFER -#define CONFIG_CMD_EXT2 -#define CONFIG_CMD_FAT -#define CONFIG_DOS_PARTITION /* Ethernet Configuration */ -#define CONFIG_CMD_PING -#define CONFIG_CMD_DHCP -#define CONFIG_CMD_MII -#define CONFIG_CMD_NET #define CONFIG_FEC_MXC #define CONFIG_MII #define IMX_FEC_BASE ENET_BASE_ADDR
@@ -114,8 +110,12 @@"fdt_high=0xffffffff\0" \"initrd_high=0xffffffff\0" \"fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \ -"fdt_addr=0x18000000\0" \ +"fdt_addr_r=0x18000000\0" \"boot_fdt=try\0" \ +"pxefile_addr_r=0x17e00000\0" \ +"scriptaddr=0x17d00000\0" \ +"kernel_addr_r=0x13000000\0" \ +"ramdisk_addr_r=0x15000000\0" \"ip_dyn=yes\0" \ "mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \"mmcpart=1\0" \
@@ -134,70 +134,12 @@"mmc write ${loadaddr} 0x2 ${fw_sz}; " \"fi; " \"fi\0" \ -"mmcargs=setenv bootargs console=${console},${baudrate} " \ -"root=${mmcroot}\0" \ -"loadbootscript=" \ -"fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \ -"bootscript=echo Running bootscript from mmc ...; " \ -"source\0" \ -"loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \ -"loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \ -"mmcboot=echo Booting from mmc ...; " \ -"run mmcargs; " \ -"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \ -"if run loadfdt; then " \ -"bootz ${loadaddr} - ${fdt_addr}; " \ -"else " \ -"if test ${boot_fdt} = try; then " \ -"bootz; " \ -"else " \ -"echo WARN: Cannot load the DT; " \ -"fi; " \ -"fi; " \ -"else " \ -"bootz; " \ -"fi;\0" \ -"netargs=setenv bootargs console=${console},${baudrate} " \ -"root=/dev/nfs " \ -"ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \ -"netboot=echo Booting from net ...; " \ -"run netargs; " \ -"if test ${ip_dyn} = yes; then " \ -"setenv get_cmd dhcp; " \ -"else " \ -"setenv get_cmd tftp; " \ -"fi; " \ -"${get_cmd} ${image}; " \ -"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \ -"if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \ -"bootz ${loadaddr} - ${fdt_addr}; " \ -"else " \ -"if test ${boot_fdt} = try; then " \ -"bootz; " \ -"else " \ -"echo WARN: Cannot load the DT; " \ -"fi; " \ -"fi; " \ -"else " \ -"bootz; " \ - "fi;\0" + BOOTCMDS_COMMON#define CONFIG_BOOTCOMMAND \ - "mmc dev ${mmcdev}; if mmc rescan; then " \ - "if run loadbootscript; then " \ - "run bootscript; " \ - "else " \ - "if run loadimage; then " \ - "run mmcboot; " \ - "else run netboot; " \ - "fi; " \ - "fi; " \ - "else run netboot; fi" + "for target in ${boot_targets}; do run bootcmd_${target}; done"/* Miscellaneous configurable options */ -#define CONFIG_SYS_LONGHELP -#define CONFIG_SYS_HUSH_PARSER -#define CONFIG_AUTO_COMPLETE #define CONFIG_SYS_CBSIZE 256/* Print Buffer Size */
@@ -207,8 +149,6 @@#define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR -#define CONFIG_CMDLINE_EDITING -/* Physical Memory Map */ #define CONFIG_NR_DRAM_BANKS 1#define PHYS_SDRAM MMDC0_ARB_BASE_ADDR
@@ -231,9 +171,6 @@#define CONFIG_ENV_OFFSET (6 * 64 * 1024)#define CONFIG_SYS_MMC_ENV_DEV 0 -#define CONFIG_OF_LIBFDT -#define CONFIG_CMD_BOOTZ -#ifndef CONFIG_SYS_DCACHE_OFF #define CONFIG_CMD_CACHE #endif
Signature · 1 line
1.8.5.3
RFC PATCH 3/3 move wandboard over to use the generic distro configuratin and environment
Hello Dennis,
the short log should use the standard for the commit logs.
Quoted 47 lines · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>--- include/configs/wandboard.h | 87 +++++++-------------------------------------- 1 file changed, 12 insertions(+), 75 deletions(-)include/configs/wandboard.h +5
-9@@ -41,6 +41,11 @@#define CONFIG_CONS_INDEX 1#define CONFIG_BAUDRATE 115200 +#ifndef CONFIG_SPL_BUILD +#include <config_distro_defaults.h> +#include <config_distro_bootcmd.h> +#endif +/* Command definition */ #include <config_cmd_default.h> @@ -49,8 +54,6 @@#define CONFIG_CMD_BMODE #define CONFIG_CMD_SETEXPR -#define CONFIG_BOOTDELAY 5 -#define CONFIG_SYS_MEMTEST_START 0x10000000#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START + 500 * SZ_1M)#define CONFIG_LOADADDR 0x12000000@@ -66,15 +69,8 @@#define CONFIG_CMD_MMC #define CONFIG_GENERIC_MMC #define CONFIG_BOUNCE_BUFFER -#define CONFIG_CMD_EXT2 -#define CONFIG_CMD_FAT -#define CONFIG_DOS_PARTITION /* Ethernet Configuration */ -#define CONFIG_CMD_PING -#define CONFIG_CMD_DHCP -#define CONFIG_CMD_MII -#define CONFIG_CMD_NET #define CONFIG_FEC_MXC #define CONFIG_MII #define IMX_FEC_BASE ENET_BASE_ADDR
include/configs/wandboard.h line 118
Quoted 10 lines
include/configs/wandboard.h +5
-1@@ -114,8 +110,12 @@"fdt_high=0xffffffff\0" \"initrd_high=0xffffffff\0" \"fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \ -"fdt_addr=0x18000000\0" \ +"fdt_addr_r=0x18000000\0" \"boot_fdt=try\0" \ +"pxefile_addr_r=0x17e00000\0" \ +"scriptaddr=0x17d00000\0" \ +"kernel_addr_r=0x13000000\0" \ +"ramdisk_addr_r=0x15000000\0" \
At least the address that are common to SoCs shouldn't be duplicated here, do it?
Quoted 98 lines
include/configs/wandboard.h +2
-66"ip_dyn=yes\0" \ "mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \"mmcpart=1\0" \@@ -134,70 +134,12 @@"mmc write ${loadaddr} 0x2 ${fw_sz}; " \"fi; " \"fi\0" \ -"mmcargs=setenv bootargs console=${console},${baudrate} " \ -"root=${mmcroot}\0" \ -"loadbootscript=" \ -"fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \ -"bootscript=echo Running bootscript from mmc ...; " \ -"source\0" \ -"loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \ -"loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \ -"mmcboot=echo Booting from mmc ...; " \ -"run mmcargs; " \ -"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \ -"if run loadfdt; then " \ -"bootz ${loadaddr} - ${fdt_addr}; " \ -"else " \ -"if test ${boot_fdt} = try; then " \ -"bootz; " \ -"else " \ -"echo WARN: Cannot load the DT; " \ -"fi; " \ -"fi; " \ -"else " \ -"bootz; " \ -"fi;\0" \ -"netargs=setenv bootargs console=${console},${baudrate} " \ -"root=/dev/nfs " \ -"ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \ -"netboot=echo Booting from net ...; " \ -"run netargs; " \ -"if test ${ip_dyn} = yes; then " \ -"setenv get_cmd dhcp; " \ -"else " \ -"setenv get_cmd tftp; " \ -"fi; " \ -"${get_cmd} ${image}; " \ -"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \ -"if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \ -"bootz ${loadaddr} - ${fdt_addr}; " \ -"else " \ -"if test ${boot_fdt} = try; then " \ -"bootz; " \ -"else " \ -"echo WARN: Cannot load the DT; " \ -"fi; " \ -"fi; " \ -"else " \ -"bootz; " \ - "fi;\0" + BOOTCMDS_COMMON#define CONFIG_BOOTCOMMAND \ - "mmc dev ${mmcdev}; if mmc rescan; then " \ - "if run loadbootscript; then " \ - "run bootscript; " \ - "else " \ - "if run loadimage; then " \ - "run mmcboot; " \ - "else run netboot; " \ - "fi; " \ - "fi; " \ - "else run netboot; fi" + "for target in ${boot_targets}; do run bootcmd_${target}; done"/* Miscellaneous configurable options */ -#define CONFIG_SYS_LONGHELP -#define CONFIG_SYS_HUSH_PARSER -#define CONFIG_AUTO_COMPLETE #define CONFIG_SYS_CBSIZE 256/* Print Buffer Size */ @@ -207,8 +149,6 @@#define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR -#define CONFIG_CMDLINE_EDITING -/* Physical Memory Map */ #define CONFIG_NR_DRAM_BANKS 1#define PHYS_SDRAM MMDC0_ARB_BASE_ADDR@@ -231,9 +171,6 @@#define CONFIG_ENV_OFFSET (6 * 64 * 1024)#define CONFIG_SYS_MMC_ENV_DEV 0 -#define CONFIG_OF_LIBFDT -#define CONFIG_CMD_BOOTZ -#ifndef CONFIG_SYS_DCACHE_OFF #define CONFIG_CMD_CACHE #endif --1.8.5.3
Signature · 3 lines
Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
RFC PATCH 3/3 move wandboard over to use the generic distro configuratin and environment
In reply to Dennis Gilmoreinclude/configs/wandboard.h line 168
Quoted 13 lines · Dennis Gilmore
Signed-off-by Dennis Gilmore <[email protected]>include/configs/wandboard.h +0
-9-"netargs=setenv bootargs console=${console},${baudrate} " \ -"root=/dev/nfs " \ -"ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \ -"netboot=echo Booting from net ...; " \ -"run netargs; " \ -"if test ${ip_dyn} = yes; then " \ -"setenv get_cmd dhcp; " \ -"else " \ -"setenv get_cmd tftp; " \
...
This one also removes nfsroot stuff.
Admittedly I would personally argue that nfsroot setup belong in the boot.scr that comes from some TFTP server, and I wrote the Tegra boot scripts assuming that, but I probably got away with that for Tegra since we never had any nfsroot setup in the default environment. People using these boards might like to keep their working features:-) Perhaps we could persuade people to adapt though?
Hi Dennis,
Quoted 5 lines · Dennis Gilmore
Hi All,
The attached patches build on the work for generic distro config, as well as Stephen Warrens implementation for tegra.
First, thanks to make order on this issue.
Quoted 3 lines
I have added a header to be included that will allow all boards to boot in the same way and I have ported over two boards to use it. One thought I have had is to move the environment into the same header as the generic config.
I think this is currently the best solution.
Quoted 4 lines
I am also working on writing a README.distro file to document everything that needs to be set for everything to just work. Along with information on how to best choose memory locations.
Ok, let's see. This seems quite board-depending, I do not know if we find a common solution. But we can find an agreement about a generic set of variables/scripts, that all boards can reuse.
Regards,
Stefano
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
Quoted 19 lines · On Tue, 18 Feb 2014 11:18:22 +0100 Stefano Babic <[email protected]> wrote:
Hi Dennis,
Quoted 5 lines · Dennis Gilmore
Hi All,
The attached patches build on the work for generic distro config, as well as Stephen Warrens implementation for tegra.
First, thanks to make order on this issue.
Quoted 4 lines
I have added a header to be included that will allow all boards to boot in the same way and I have ported over two boards to use it. One thought I have had is to move the environment into the same header as the generic config.
I think this is currently the best solution.
Quoted 1 line
Quoted 8 lines
Quoted 3 lines
I am also working on writing a README.distro file to document everything that needs to be set for everything to just work. Along with information on how to best choose memory locations.
Ok, let's see. This seems quite board-depending, I do not know if we find a common solution. But we can find an agreement about a generic set of variables/scripts, that all boards can reuse.
There will always be some board specific things like memory locations etc. None of the boot logic is board specific. Some features are hardware specific, i.e. PXE boot support is only configured if the hardware supports it same for SATA.
I'm putting what I have for the documentation so far at the end of this email. I think that soc families should have a common settings file, each board should have its on file and then we have a common set of configurations on how to boot.
Dennis
/*
* (C) Copyright 2014 Red Hat Inc.
*
* SPDX-License-Identifier: GPL-2.0+
*/
Generic distro configuration
configuring
-----------
To configure a board to run the generic distro setup and enable generic distros to easily support your board.
you will need to include a pair of headers to enable the boot environment and configuration options needed. It is best to only include when not doing an SPL build.
#ifndef CONFIG_SPL_BUILD
#include <config_distro_defaults.h>
#include <config_distro_bootcmd.h>
#endif
There is some memory addresses you will need to define in CONFIG_EXTRA_ENV_SETTINGSfdt_addr:
Optional, if specified a dtb to boot the system needs to be available at the address.
fdt_addr_r:
Mandatory, This is the location where the sysboot/pxeboot with load the dtb to, using the fdtdir/devicetreedir or fdt/devicetree options in the pxe/extlinux config file. The location can be anywhere in ram it just needs to not overlap with anything, allowing 1 megabyte seems to be a safe option.
ramdisk_addr_r:
Mandatory, This is the location where the sysboot/pxeboot with load the initramfs to, using the initrd option in the pxe/extlinux config file, the location of the initramfs does not matter, there needs to be enough room to be able to store any image. Making the image the last item stored should allow for any initramfs to fit and not overwrite anything else.
kernel_addr_r:
Mandatory,
pxe_addr_r:
Mandatory, used by the PXE code to hold the pxelinux config file. The location can be anywhere in ram it just needs to not overlap with anything, allowing 1 megabyte seems to be a safe option.
scriptaddr:
Mandatory,
suggested mapping:
16M
make sure you also include BOOTCMDS_COMMON in CONFIG_EXTRA_ENV_SETTINGS
booting your system
-------------------
in the most simplest form CONFIG_BOOTCOMMAND just needs one line
"for target in ${boot_targets}; do run bootcmd_${target}; done"
you can run any setup before going through the targets for example run a command to set "fdtfile" variable for the dtb for your board.
Dennis
Quoted 4 lines · Dennis Gilmore
I'm putting what I have for the documentation so far at the end of this email. I think that soc families should have a common settings file, each board should have its on file and then we have a common set of configurations on how to boot.
For the next round, please put this into doc/ as part of the first patch. Thanks!
[snip]
Quoted 21 lines
fdt_addr_r:
Mandatory, This is the location where the sysboot/pxeboot with load the dtb to, using the fdtdir/devicetreedir or fdt/devicetree options in the pxe/extlinux config file. The location can be anywhere in ram it just needs to not overlap with anything, allowing 1 megabyte seems to be a safe option.
ramdisk_addr_r:
Mandatory, This is the location where the sysboot/pxeboot with load the initramfs to, using the initrd option in the pxe/extlinux config file, the location of the initramfs does not matter, there needs to be enough room to be able to store any image. Making the image the last item stored should allow for any initramfs to fit and not overwrite anything else.
kernel_addr_r:
Mandatory,
pxe_addr_r:
Mandatory, used by the PXE code to hold the pxelinux config file. The location can be anywhere in ram it just needs to not overlap with anything, allowing 1 megabyte seems to be a safe option.
Quoted 5 lines
scriptaddr:
Mandatory,suggested mapping:
16M
We need to talk much more about the suggested mapping as there's a few hard requirements that must be obeyed. The device tree _must_ be placed within kernel accessible low mem and not overwritten by zImage decompression. A reference to Documentation/arm/Booting in the kernel would also be helpful and then summarize saying kernel_addr_r should be above 32MiB and below 128MiB from the base of system ram.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140219/bae05376/attachment.pgp>
cover unified boot environment
In reply to Dennis GilmoreHi All,
The attached patches build on the work for generic distro config, as well as Stephen Warrens implementation for tegra. They depend on Toms Patches to move ti to using DEFAULT_LINUX_BOOT_ENV on TI systems.
There is a README file to describe how to convert a system. I have added a header to be included that will allow all boards to boot in the same way and I have ported over three boards to use it.
Dennis
PATCH 1/6 add README.distro file
Add documentation on how to setup a system to use the generic distro configs and boot commands. This spells out what is needed to make a system conformant, but does not limit the board to only the defaults.
--- doc/README.distro | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 76 insertions(+) create mode 100644 doc/README.distro
doc/README.distro new file +76 -0
@@ -0,0 +1,76 @@ +/* + * (C) Copyright 2014 Red Hat Inc. + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +Generic distro configuration +---------------------------- + +configuring +----------- +To configure a board to run the generic distro setup and enable generic distros +to easily support your board. + +you will need to include a pair of headers to enable the boot environment and +configuration options needed. It is best to only include when not doing an +SPL build. + +#ifndef CONFIG_SPL_BUILD +#include <config_distro_defaults.h> +#include <config_distro_bootcmd.h> +#endif + +There is some memory addresses you will need to define in +CONFIG_EXTRA_ENV_SETTINGS +fdt_addr: +Optional, If specified a dtb to boot the system must be available at the given +address. + +fdt_addr_r: +Mandatory, This is the location where the sysboot/pxeboot with load the dtb to, +using the fdtdir/devicetreedir or fdt/devicetree options in the pxe/extlinux +config file. The location can be anywhere in ram it just needs to not overlap +with anything, allowing 1 megabyte seems to be a safe option. + +ramdisk_addr_r: +Mandatory, This is the location where the sysboot/pxeboot with load the +initramfs to, using the initrd option in the pxe/extlinux config file, the +location of the initramfs does not matter, there needs to be enough room to be +able to store any image. Making the image the last item stored should allow for +any initramfs to fit and not overwrite anything else. + +kernel_addr_r: +Mandatory, This is the location where the sysboot/pxeboot with load the kernel +to,using the kernel option in the pxe/extlinux config file, the location of the +kernel needs to + +pxe_addr_r: +Mandatory, used by the PXE code to hold the pxelinux config file. The location +can be anywhere in ram it just needs to not overlap with anything, allowing 1 +megabyte seems to be a safe option. + +scriptaddr: +Mandatory, used to load boot.scr to The location can be anywhere in ram it just +needs to not overlap with anything, allowing 1 megabyte seems to be a safe +option. + +suggested mapping: +For suggestions on memory locations for arm systems you must follow the +guidelines specified in Documentation/arm/Booting in the Linux kernel tree. +For other architectures you must follow the guidelines for the architecture. + +make sure you also include BOOTCMDS_COMMON in CONFIG_EXTRA_ENV_SETTINGS + +You should not set initrd_high and fdt_high to 0xffffffff as the user should +not need to edit the memory locations having the initramfs and dtb being +relocatable is best to ensure the system will boot in all situations. + +booting your system +------------------- +in the most simplest form CONFIG_BOOTCOMMAND just needs one line + +"for target in ${boot_targets}; do run bootcmd_${target}; done " + +you can run any setup before going through the targets for example run a +command to set "fdtfile" variable for the dtb for your board.
Signature · 1 line
1.9.0
PATCH 1/6 add README.distro file
Quoted 5 lines · Dennis Gilmore
Add documentation on how to setup a system to use the generic distro configs and boot commands. This spells out what is needed to make a system conformant, but does not limit the board to only the defaults.
Signed-off-by Dennis Gilmore <[email protected]>
[snip]
doc/README.distro line 61
Quoted 4 lines
doc/README.distro new file +4
-0+suggested mapping: +For suggestions on memory locations for arm systems you must follow the +guidelines specified in Documentation/arm/Booting in the Linux kernel tree. +For other architectures you must follow the guidelines for the architecture.
Can you add something about what this means? ie below base+128MB for kernel, because of this if possible base+128MB for fdt, fdt+512KB for ramdisk. And mention bootm_size to limit the relocation pool as well.
Thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140321/e8ee6215/attachment.pgp>
PATCH 1/6 add README.distro file
Quoted 9 lines · Tom Rini
Quoted 5 lines · Dennis Gilmore
Add documentation on how to setup a system to use the generic distro configs and boot commands. This spells out what is needed to make a system conformant, but does not limit the board to only the defaults.
Signed-off-by Dennis Gilmore <[email protected]>[snip]
Quoted 8 lines
doc/README.distro line 61
Quoted 4 lines
doc/README.distro new file +4
-0+suggested mapping: +For suggestions on memory locations for arm systems you must follow the +guidelines specified in Documentation/arm/Booting in the Linux kernel tree. +For other architectures you must follow the guidelines for the architecture.Can you add something about what this means? ie below base+128MB for kernel, because of this if possible base+128MB for fdt, fdt+512KB for ramdisk. And mention
bootm_sizeto limit the relocation pool as well.
I'm biased, but I like the explanations in
include/configs/tegraNN-common.h:-)
PATCH 1/6 add README.distro file
In reply to Dennis Gilmoredoc/README.distro line 28
Quoted 11 lines · Dennis Gilmore
Add documentation on how to setup a system to use the generic distro configs and boot commands. This spells out what is needed to make a system conformant, but does not limit the board to only the defaults.
doc/README.distro +5
-0+There is some memory addresses you will need to define in +CONFIG_EXTRA_ENV_SETTINGS +fdt_addr: +Optional, If specified a dtb to boot the system must be available at the given +address.
Perhaps add "when the kernel is booted"? To avoid someone putting it somewhere that will get over-written between when U-Boot starts and the kernel is booted.
doc/README.distro line 31
Quoted 2 lines
doc/README.distro +2
-0+fdt_addr_r: +Mandatory, This is the location where the sysboot/pxeboot with load the dtb to,
s/with/will/ Both here and other place(s).
doc/README.distro line 34
Quoted 3 lines
doc/README.distro +3
-0+using the fdtdir/devicetreedir or fdt/devicetree options in the pxe/extlinux +config file. The location can be anywhere in ram it just needs to not overlap +with anything, allowing 1 megabyte seems to be a safe option.
Related to Tom's comments, I think saying that the location doesn't matter isn't quite true. For example, an ARM zImage assumes it's located with the first 128M of RAM, and will decompress the image to the start of RAM. If the DTB was located in the decompression target region, it would at least need to be moved by the decompressor (wasted effort) or perhaps just get blindly over-written (boot fails).
doc/README.distro line 41
Quoted 6 lines
doc/README.distro +6
-0+ramdisk_addr_r: +Mandatory, This is the location where the sysboot/pxeboot with load the +initramfs to, using the initrd option in the pxe/extlinux config file, the +location of the initramfs does not matter, there needs to be enough room to be +able to store any image. Making the image the last item stored should allow for +any initramfs to fit and not overwrite anything else.
"last item" could refer to time not space. Perhaps s/Making the image the last item stored/Placing the image higher in RAM than any other image/
doc/README.distro line 46
Quoted 4 lines
doc/README.distro +4
-0+kernel_addr_r: +Mandatory, This is the location where the sysboot/pxeboot with load the kernel +to,using the kernel option in the pxe/extlinux config file, the location of the +kernel needs to
That sentence isn't complete.
doc/README.distro line 67
Quoted 3 lines
doc/README.distro +3
-0+You should not set initrd_high and fdt_high to 0xffffffff as the user should +not need to edit the memory locations having the initramfs and dtb being +relocatable is best to ensure the system will boot in all situations.
Perhaps CONFIG_SYS_BOOTMAPSZ is worth a mention too. The commit description for 7f1b767aea94 "ARM: tegra: define CONFIG_SYS_BOOTMAPSZ" might be useful when writing this part of the document.
doc/README.distro line 76
Quoted 8 lines
doc/README.distro +8
-0+booting your system +------------------- +in the most simplest form CONFIG_BOOTCOMMAND just needs one line + +"for target in ${boot_targets}; do run bootcmd_${target}; done " + +you can run any setup before going through the targets for example run a +command to set "fdtfile" variable for the dtb for your board.
Isn't this automatic based on using config_distro_defaults.h? It seems like it should be, and it is were, you wouldn't need this section of this document at all; it's happen automatically.
PATCH 1/6 add README.distro file
Quoted 1 line · Stephen Warren
On 03/20/2014 04:12 PM, Dennis Gilmore wrote:
[snip]
Quoted 7 lines
doc/README.distro line 67
Quoted 3 lines
doc/README.distro new file +3
-0+You should not set initrd_high and fdt_high to 0xffffffff as the user should +not need to edit the memory locations having the initramfs and dtb being +relocatable is best to ensure the system will boot in all situations.Perhaps
CONFIG_SYS_BOOTMAPSZis worth a mention too. The commit description for7f1b767aea94"ARM: tegra: defineCONFIG_SYS_BOOTMAPSZ" might be useful when writing this part of the document.
I would swear (and I just dug up the notes from the last time I was looking at this) that no, CONFIG_SYS_BOOTMAPSZ is not sufficient because it doesn't cover the ramdisk case, which is important for generic distro, unless you also add in initrd_high=top-of-lowmem-value or know it'll be in an always-good spot and set it to 0xffffffff.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140328/d3d54d38/attachment.pgp>
PATCH 1/6 add README.distro file
Quoted 11 lines · Tom Rini
Quoted 1 line · Stephen Warren
On 03/20/2014 04:12 PM, Dennis Gilmore wrote:
[snip]
Quoted 7 lines
doc/README.distro line 67
Quoted 3 lines
doc/README.distro new file +3
-0+You should not set initrd_high and fdt_high to 0xffffffff as the user should +not need to edit the memory locations having the initramfs and dtb being +relocatable is best to ensure the system will boot in all situations.Perhaps
CONFIG_SYS_BOOTMAPSZis worth a mention too. The commit description for7f1b767aea94"ARM: tegra: defineCONFIG_SYS_BOOTMAPSZ" might be useful when writing this part of the document.
Quoted 5 lines
I would swear (and I just dug up the notes from the last time I was looking at this) that no,
CONFIG_SYS_BOOTMAPSZis not sufficient because it doesn't cover the ramdisk case, which is important for generic distro, unless you also add in initrd_high=top-of-lowmem-value or know it'll be in an always-good spot and set it to0xffffffff.
Isn't that a bug? In other words, shouldn't CONFIG_SYS_BOOTMAPSZ affect a ramdisk too?
PATCH 1/6 add README.distro file
Quoted 12 lines · Stephen Warren
Quoted 11 lines · Tom Rini
Quoted 1 line · Stephen Warren
On 03/20/2014 04:12 PM, Dennis Gilmore wrote:
[snip]
Quoted 7 lines
doc/README.distro line 67
Quoted 3 lines
doc/README.distro new file +3
-0+You should not set initrd_high and fdt_high to 0xffffffff as the user should +not need to edit the memory locations having the initramfs and dtb being +relocatable is best to ensure the system will boot in all situations.Perhaps
CONFIG_SYS_BOOTMAPSZis worth a mention too. The commit description for7f1b767aea94"ARM: tegra: defineCONFIG_SYS_BOOTMAPSZ" might be useful when writing this part of the document.
Quoted 8 lines
Quoted 5 lines
I would swear (and I just dug up the notes from the last time I was looking at this) that no,
CONFIG_SYS_BOOTMAPSZis not sufficient because it doesn't cover the ramdisk case, which is important for generic distro, unless you also add in initrd_high=top-of-lowmem-value or know it'll be in an always-good spot and set it to0xffffffff.Isn't that a bug? In other words, shouldn't
CONFIG_SYS_BOOTMAPSZaffect a ramdisk too?
No, because it's a per-arch thing on if you can have a ramdisk in high memory or not (and then the kernel deals with it), iirc. I _think_ this is one of those cases where ARM is much more strict about things than other architectures, but I lack the easy access to other platforms that I used to have.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140328/90355d83/attachment.pgp>
PATCH 2/6 add header with a generic set of boot commands defined.
In reply to Dennis GilmoreAs the next step in a generic config we are introducing a set of generic boot paramaters. Depending on the hardwares configuration, booting from supported hardware will be enabled, mmc, usb, sata, scsi, ide, pxe and dhcp.
There is nothing to stop this being extended to support nand and any other type of storage that comes along. An ideal future enhancement will be to allow the user to dynamically reorder the boot devices, and allow one off boots. for example simply be able to pxe boot to reinstall
--- include/config_distro_bootcmd.h | 208 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 208 insertions(+) create mode 100644 include/config_distro_bootcmd.h
include/config_distro_bootcmd.h new file +208 -0
@@ -0,0 +1,208 @@ +/* +* (C) Copyright 2014 +* NVIDIA Corporation <www.nvidia.com> +* +* Copyright 2014 Red Hat, Inc. +* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H +#define _CONFIG_CMD_DISTRO_BOOTCMD_H + + +#ifdef CONFIG_CMD_MMC +#define BOOTCMDS_MMC \ + "mmc_boot=" \ + "setenv devtype mmc; " \ + "if mmc dev ${devnum}; then " \ + "run scan_boot; " \ + "fi\0" \ + "bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \ + "bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0" +#define BOOT_TARGETS_MMC "mmc1 mmc0" +#else +#define BOOTCMDS_MMC "" +#define BOOT_TARGETS_MMC "" +#endif + +#ifdef CONFIG_CMD_USB +#define BOOTCMD_INIT_USB "run usb_init; " +#define BOOTCMDS_USB \ + "usb_init=" \ + "if ${usb_need_init}; then " \ + "set usb_need_init false; " \ + "usb start 0; " \ + "fi\0" \ + \ + "usb_boot=" \ + "setenv devtype usb; " \ + BOOTCMD_INIT_USB \ + "if usb dev ${devnum}; then " \ + "run scan_boot; " \ + "fi\0" \ + \ + "bootcmd_usb0=setenv devnum 0; run usb_boot;\0" \ + "bootcmd_usb1=setenv devnum 1; run usb_boot;\0" +#define BOOT_TARGETS_USB "usb0 usb1" +#else +#define BOOTCMD_INIT_USB "" +#define BOOTCMDS_USB "" +#define BOOT_TARGETS_USB "" +#endif + +#ifdef CONFIG_CMD_SATA +#define BOOTCMDS_SATA \ + "sata_boot=" \ + "setenv devtype sata; " \ + "if sata dev ${devnum}; then " \ + "run scan_boot; " \ + "fi\0" \ + \ + "bootcmd_sata0=setenv devnum 0; run sata_boot;\0" \ + "bootcmd_sata1=setenv devnum 1; run sata_boot;\0" +#define BOOT_TARGETS_SATA "sata0 sata1" +#else +#define BOOTCMDS_SATA "" +#define BOOT_TARGETS_SATA "" +#endif + +#ifdef CONFIG_CMD_SCSI +#define BOOTCMDS_SCSI \ + "scsi_boot=" \ + "setenv devtype scsi; " \ + "if scsi dev ${devnum}; then " \ + "run scan_boot; " \ + "fi\0" \ + \ + "bootcmd_scsi0=setenv devnum 0; run scsi_boot;\0" \ + "bootcmd_scsi1=setenv devnum 1; run scsi_boot;\0" +#define BOOT_TARGETS_SCSI "scsi0 scsi1" +#else +#define BOOTCMDS_SCSI "" +#define BOOT_TARGETS_SCSI "" +#endif + +#ifdef CONFIG_CMD_IDE +#define BOOTCMDS_IDE \ + "ide_boot=" \ + "setenv devtype ide; " \ + "if ide dev ${devnum}; then " \ + "run scan_boot; " \ + "fi\0" \ + \ + "bootcmd_ide0=setenv devnum 0; run ide_boot;\0" \ + "bootcmd_ide1=setenv devnum 1; run ide_boot;\0" +#define BOOT_TARGETS_IDE "ide0 ide1" +#else +#define BOOTCMDS_IDE "" +#define BOOT_TARGETS_IDE "" +#endif + +#ifdef CONFIG_CMD_DHCP +#define BOOTCMDS_DHCP \ + "bootcmd_dhcp=" \ + BOOTCMD_INIT_USB \ + "if dhcp ${scriptaddr} boot.scr.uimg; then "\ + "source ${scriptaddr}; " \ + "fi\0" +#define BOOT_TARGETS_DHCP "dhcp" +#else +#define BOOTCMDS_DHCP "" +#define BOOT_TARGETS_DHCP "" +#endif + +#if defined(CONFIG_CMD_DHCP ) && defined(CONFIG_CMD_PXE ) +#define BOOTCMDS_PXE \ + "bootcmd_pxe=" \ + BOOTCMD_INIT_USB \ + "dhcp; " \ + "if pxe get; then " \ + "pxe boot; " \ + "fi\0" +#define BOOT_TARGETS_PXE "pxe" +#else +#define BOOTCMDS_PXE "" +#define BOOT_TARGETS_PXE "" +#endif + +#define BOOTCMDS_COMMON \ + "rootpart=1\0" \ + \ + "do_envimport=" \ + "load ${devtype} ${devnum}:${rootpart} ${loadaddr} " \ + "${environment}\0" \ + "env import -t ${loadaddr} $filesize\0" \ + \ + "envimport=" \ + "for environment in ${boot_envs}; do " \ + "if test -e ${devtype} ${devnum}:${rootpart} " \ + "${prefix}${environment}; then " \ + "echo Found U-Boot environment " \ + "${prefix}${environment}; " \ + "run do_envimport;" \ + "echo Import FAILED; continuing...; " \ + "fi; " \ + "done\0" \ + \ + "do_script_boot=" \ + "load ${devtype} ${devnum}:${rootpart} " \ + "${scriptaddr} ${prefix}${script}; " \ + "source ${scriptaddr}\0" \ + \ + "script_boot=" \ + "for script in ${boot_scripts}; do " \ + "if test -e ${devtype} ${devnum}:${rootpart} " \ + "${prefix}${script}; then " \ + "echo Found U-Boot script " \ + "${prefix}${script}; " \ + "run do_script_boot;" \ + "echo SCRIPT FAILED; continuing...; " \ + "fi; " \ + "done\0" \ + \ + "do_sysboot_boot=" \ + "sysboot ${devtype} ${devnum}:${rootpart} any " \ + "${scriptaddr} ${prefix}extlinux/extlinux.conf\0" \ + \ + "sysboot_boot=" \ + "if test -e ${devtype} ${devnum}:${rootpart} " \ + "${prefix}extlinux/extlinux.conf; then " \ + "echo Found extlinux config " \ + "${prefix}extlinux/extlinux.conf; " \ + "run do_sysboot_boot;" \ + "echo SYSBOOT FAILED; continuing...; " \ + "fi\0" \ + \ + "scan_boot=" \ + "echo Scanning ${devtype} ${devnum}...; " \ + "for prefix in ${boot_prefixes}; do " \ + "run sysboot_boot; " \ + "run script_boot; " \ + "done\0" \ + \ + "boot_targets=" \ + BOOT_TARGETS_MMC " " \ + BOOT_TARGETS_USB " " \ + BOOT_TARGETS_SATA " " \ + BOOT_TARGETS_SCSI " " \ + BOOT_TARGETS_IDE " " \ + BOOT_TARGETS_PXE " " \ + BOOT_TARGETS_DHCP " " \ + "\0" \ + \ + "boot_prefixes=/ /boot/\0" \ + \ + "boot_scripts=boot.scr.uimg boot.scr\0" \ + \ + "boot_envs=uEnv.txt\0" \ + \ + BOOTCMDS_MMC \ + BOOTCMDS_USB \ + BOOTCMDS_SATA \ + BOOTCMDS_SCSI \ + BOOTCMDS_IDE \ + BOOTCMDS_DHCP \ + BOOTCMDS_PXE + +#endif /* _CONFIG_CMD_DISTRO_BOOTCMD_H */
Signature · 1 line
1.9.0
PATCH 2/6 add header with a generic set of boot commands defined.
Quoted 29 lines · Dennis Gilmore
As the next step in a generic config we are introducing a set of generic boot paramaters. Depending on the hardwares configuration, booting from supported hardware will be enabled, mmc, usb, sata, scsi, ide, pxe and dhcp.
There is nothing to stop this being extended to support nand and any other type of storage that comes along. An ideal future enhancement will be to allow the user to dynamically reorder the boot devices, and allow one off boots. for example simply be able to pxe boot to reinstall
Signed-off-by Dennis Gilmore <[email protected]>--- include/config_distro_bootcmd.h | 208 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 208 insertions(+) create mode 100644 include/config_distro_bootcmd.h(quoted diff) +0
-0
b/include/config_distro_bootcmd.hnew file mode 100644 index 0000000..0fe94beinclude/config_distro_bootcmd.h new file +7
-0@@ -0,0 +1,208 @@ +/* +* (C) Copyright 2014 +* NVIDIA Corporation <www.nvidia.com> +* +* Copyright 2014 Red Hat, Inc. +* +* SPDX-License-Identifier: GPL-2.0+
include/config_distro_bootcmd.h line 17
Quoted 10 lines
include/config_distro_bootcmd.h new file +10
-0+*/ + +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H +#define _CONFIG_CMD_DISTRO_BOOTCMD_H + + +#ifdef CONFIG_CMD_MMC +#define BOOTCMDS_MMC \ + "mmc_boot=" \ + "setenv devtype mmc; " \
Please use 'env set ...'
include/config_distro_bootcmd.h line 23
Quoted 6 lines
include/config_distro_bootcmd.h new file +6
-0+"if mmc dev ${devnum}; then " \ +"run scan_boot; " \ +"fi\0" \ +"bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \ +"bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0" +#define BOOT_TARGETS_MMC "mmc1 mmc0"
This will not work on a boot with three MMC cards ... this does not scale and needs re-thinking.
include/config_distro_bootcmd.h line 26
Quoted 3 lines
include/config_distro_bootcmd.h new file +3
-0+#else +#define BOOTCMDS_MMC "" +#define BOOT_TARGETS_MMC ""
You need to #undef those after you assembled the env, otherwise you will propagate those throughout the rest of the U-Boot at build time, which is not nice.
[...]
PATCH 2/6 add header with a generic set of boot commands defined.
Quoted 34 lines · Marek Vasut
Quoted 33 lines · Dennis Gilmore
As the next step in a generic config we are introducing a set of generic boot paramaters. Depending on the hardwares configuration, booting from supported hardware will be enabled, mmc, usb, sata, scsi, ide, pxe and dhcp.
There is nothing to stop this being extended to support nand and any other type of storage that comes along. An ideal future enhancement will be to allow the user to dynamically reorder the boot devices, and allow one off boots. for example simply be able to pxe boot to reinstall
Signed-off-by Dennis Gilmore <[email protected]>--- include/config_distro_bootcmd.h | 208 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 208 insertions(+) create mode 100644 include/config_distro_bootcmd.h(quoted diff) +0
-0
b/include/config_distro_bootcmd.hnew file mode 100644 index 0000000..0fe94beinclude/config_distro_bootcmd.h new file +11
-0@@ -0,0 +1,208 @@ +/* +* (C) Copyright 2014 +* NVIDIA Corporation <www.nvidia.com> +* +* Copyright 2014 Red Hat, Inc. +* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H +#define _CONFIG_CMD_DISTRO_BOOTCMD_H
Quoted 8 lines
include/config_distro_bootcmd.h line 17
Quoted 6 lines
include/config_distro_bootcmd.h new file +6
-0+ + +#ifdef CONFIG_CMD_MMC +#define BOOTCMDS_MMC \ + "mmc_boot=" \ + "setenv devtype mmc; " \Please use 'env set ...'
Why? Almost nothing uses that syntax..
Quoted 9 lines
include/config_distro_bootcmd.h line 23
Quoted 6 lines
include/config_distro_bootcmd.h new file +6
-0+"if mmc dev ${devnum}; then " \ +"run scan_boot; " \ +"fi\0" \ +"bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \ +"bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0" +#define BOOT_TARGETS_MMC "mmc1 mmc0"This will not work on a boot with three MMC cards ... this does not scale and needs re-thinking.
Maybe once we have device model and can see how many MMCs have been probed? I'm not worried about a 3 mmc card system (those are "expensive" to add, I'd be surprised about a system with some combination of 3 or more setup for SD/eMMC, rather than saying #3+ is for SDIO type things and more on-board SD slots being via USB where that's cheap).
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140321/cf093058/attachment.pgp>
PATCH 2/6 add header with a generic set of boot commands defined.
Quoted 49 lines · Tom Rini
Quoted 39 lines · Marek Vasut
Quoted 38 lines · Dennis Gilmore
As the next step in a generic config we are introducing a set of generic boot paramaters. Depending on the hardwares configuration, booting from supported hardware will be enabled, mmc, usb, sata, scsi, ide, pxe and dhcp.
There is nothing to stop this being extended to support nand and any other type of storage that comes along. An ideal future enhancement will be to allow the user to dynamically reorder the boot devices, and allow one off boots. for example simply be able to pxe boot to reinstall
Signed-off-by Dennis Gilmore <[email protected]>---
include/config_distro_bootcmd.h | 208++++++++++++++++++++++++++++++++++++++++ 1 file changed, 208 insertions(+)
create mode 100644 include/config_distro_bootcmd.h(quoted diff) +0
-0
b/include/config_distro_bootcmd.hnew file mode 100644 index 0000000..0fe94beinclude/config_distro_bootcmd.h new file +11
-0@@ -0,0 +1,208 @@ +/* +* (C) Copyright 2014 +* NVIDIA Corporation <www.nvidia.com> +* +* Copyright 2014 Red Hat, Inc. +* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H +#define _CONFIG_CMD_DISTRO_BOOTCMD_HQuoted 8 lines
include/config_distro_bootcmd.h line 17
Quoted 6 lines
include/config_distro_bootcmd.h new file +6
-0+ + +#ifdef CONFIG_CMD_MMC +#define BOOTCMDS_MMC \ + "mmc_boot=" \ + "setenv devtype mmc; " \Please use 'env set ...'
Quoted 1 line
Why? Almost nothing uses that syntax..
Because we want to weed out the old/legacy syntax and use the new one . The 'env' command is also more powerful and setenv/saveenv/... should just go away.
Quoted 10 lines
Quoted 9 lines
include/config_distro_bootcmd.h line 23
Quoted 6 lines
include/config_distro_bootcmd.h new file +6
-0+"if mmc dev ${devnum}; then " \ +"run scan_boot; " \ +"fi\0" \ +"bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \ +"bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0" +#define BOOT_TARGETS_MMC "mmc1 mmc0"This will not work on a boot with three MMC cards ... this does not scale and needs re-thinking.
Quoted 4 lines
Maybe once we have device model and can see how many MMCs have been probed? I'm not worried about a 3 mmc card system (those are "expensive" to add, I'd be surprised about a system with some combination of 3 or more setup for SD/eMMC
I have one on my table right now right here. I also have a mutilated M28EVK with three SD cards , so these systems do exist. Oh, but hey, we can of course say "systems with three SD cards are not supported", I saw "someone" from RH take that kind of attitude already ...
Quoted 3 lines
, rather than saying #3+ is for
SDIO type things and more on-board SD slots being via USB where that's cheap).
Best regards,
Marek Vasut
PATCH 2/6 add header with a generic set of boot commands defined.
In reply to Dennis GilmoreQuoted 8 lines · Dennis Gilmore
As the next step in a generic config we are introducing a set of generic boot paramaters. Depending on the hardwares configuration, booting from supported hardware will be enabled, mmc, usb, sata, scsi, ide, pxe and dhcp.
There is nothing to stop this being extended to support nand and any other type of storage that comes along. An ideal future enhancement will be to allow the user to dynamically reorder the boot devices, and allow one off boots. for example simply be able to pxe boot to reinstall
[snip]
include/config_distro_bootcmd.h line 23
Quoted 3 lines
include/config_distro_bootcmd.h new file +3
-0+"bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \ +"bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0" +#define BOOT_TARGETS_MMC "mmc1 mmc0"
This is because we want to prefer eMMC to SD card? Or is mmc1=SD, mmc0=eMMC on Tegra? That's opposite of TI parts so we might need to #ifndef/define/endif that combo at least.
Otherwise:
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140321/ddd66923/attachment.pgp>
PATCH 2/6 add header with a generic set of boot commands defined.
Quoted 10 lines · Tom Rini
Quoted 8 lines · Dennis Gilmore
As the next step in a generic config we are introducing a set of generic boot paramaters. Depending on the hardwares configuration, booting from supported hardware will be enabled, mmc, usb, sata, scsi, ide, pxe and dhcp.
There is nothing to stop this being extended to support nand and any other type of storage that comes along. An ideal future enhancement will be to allow the user to dynamically reorder the boot devices, and allow one off boots. for example simply be able to pxe boot to reinstall
Quoted 8 lines
[snip]
include/config_distro_bootcmd.h line 23
Quoted 3 lines
include/config_distro_bootcmd.h new file +3
-0+"bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \ +"bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0" +#define BOOT_TARGETS_MMC "mmc1 mmc0"This is because we want to prefer eMMC to SD card? Or is mmc1=SD, mmc0=eMMC on Tegra? That's opposite of TI parts so we might need to #ifndef/define/endif that combo at least.
On most (all?) Tegra devices, mmc1 is SD and mmc0 is eMMC. We prefer to try to boot from SD first so that the user can just plug in an SD card to boot from it if they want, but otherwise boot from eMMC (just like floppy vs HDD on a PC) without having to muck with boot order manually.
Well, that and I almost exclusively boot from SD, so it's marginally faster and less noisy:-)
PATCH 2/6 add header with a generic set of boot commands defined.
In reply to Dennis GilmoreQuoted 8 lines · Dennis Gilmore
As the next step in a generic config we are introducing a set of generic boot paramaters. Depending on the hardwares configuration, booting from supported hardware will be enabled, mmc, usb, sata, scsi, ide, pxe and dhcp.
There is nothing to stop this being extended to support nand and any other type of storage that comes along. An ideal future enhancement will be to allow the user to dynamically reorder the boot devices, and allow one off boots. for example simply be able to pxe boot to reinstall
One-off boots can already be performed: "run bootcmd_mmc1" or "run bootcmd_dhcp" work for me.
include/config_distro_bootcmd.h line 13
Quoted 6 lines
include/config_distro_bootcmd.h +4
-0+#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H +#define _CONFIG_CMD_DISTRO_BOOTCMD_H + +
Nit: double blank line there.
include/config_distro_bootcmd.h line 23
Quoted 10 lines
include/config_distro_bootcmd.h +10
-0+#ifdef CONFIG_CMD_MMC +#define BOOTCMDS_MMC \ + "mmc_boot=" \ + "setenv devtype mmc; " \ + "if mmc dev ${devnum}; then " \ + "run scan_boot; " \ + "fi\0" \ + "bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \ + "bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0" +#define BOOT_TARGETS_MMC "mmc1 mmc0"
It would be nice if this required the file that includes this file to define how many MMC devices there are (some only have 1...) and the best default boot order.
Still, that's probably challenging using the C pre-processor. Perhaps a Python script to auto-generate these command could be more flexible. Probably a job for a follow-on patch though.
include/config_distro_bootcmd.h line 135
Quoted 7 lines
include/config_distro_bootcmd.h +7
-0+#define BOOTCMDS_COMMON \ + "rootpart=1\0" \ + \ + "do_envimport=" \ + "load ${devtype} ${devnum}:${rootpart} ${loadaddr} " \ + "${environment}\0" \ + "env import -t ${loadaddr} $filesize\0" \
I think that should be:
if load ....; then
env import ...;
fi
So the script doesn't accidentally import something stale at $loadaddr that wasn't actually loaded.
include/config_distro_bootcmd.h line 147
Quoted 12 lines
include/config_distro_bootcmd.h +12
-0+ \ +"envimport=" \ +"for environment in ${boot_envs}; do " \ +"if test -e ${devtype} ${devnum}:${rootpart} " \ +"${prefix}${environment}; then " \ +"echo Found U-Boot environment " \ +"${prefix}${environment}; " \ +"run do_envimport;" \ +"echo Import FAILED; continuing...; " \ +"fi; " \ +"done\0" \ + \
envimport doesn't actually seem to be used anywhere at least in this patch. Is it really needed? It shouldn't be needed for generic distro support, but more for boards without any non-filesystem-based environment storage, and in those cases, shouldn't they use CONFIG_PREBOOT like rpi_b.h does, so it's well-defined where the environment comes from, before ${boot_targets} is evaluated?
include/config_distro_bootcmd.h line 151
Quoted 4 lines
include/config_distro_bootcmd.h +4
-0+"do_script_boot=" \ +"load ${devtype} ${devnum}:${rootpart} " \ +"${scriptaddr} ${prefix}${script}; " \ +"source ${scriptaddr}\0" \
That should be "if load ; ...; fi" too. Sorry, the Tegra/RPI scripts give bad examples for this.
PATCH 3/6 move wandboard over to use the generic distro configuation and environment
In reply to Dennis Gilmoreport wandboard to use the generic distro configuation. remove duplicated config options, clean up the environment, include new environment.
--- include/configs/wandboard.h | 92 +++++++-------------------------------------- 1 file changed, 14 insertions(+), 78 deletions(-)
include/configs/wandboard.h +14 -78
@@ -49,8 +49,6 @@#define CONFIG_CMD_BMODE #define CONFIG_CMD_SETEXPR -#define CONFIG_BOOTDELAY 5 -#define CONFIG_SYS_MEMTEST_START 0x10000000#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START + 500 * SZ_1M)#define CONFIG_LOADADDR 0x12000000
@@ -66,15 +64,8 @@#define CONFIG_CMD_MMC #define CONFIG_GENERIC_MMC #define CONFIG_BOUNCE_BUFFER -#define CONFIG_CMD_EXT2 -#define CONFIG_CMD_FAT -#define CONFIG_DOS_PARTITION /* Ethernet Configuration */ -#define CONFIG_CMD_PING -#define CONFIG_CMD_DHCP -#define CONFIG_CMD_MII -#define CONFIG_CMD_NET #define CONFIG_FEC_MXC #define CONFIG_MII #define IMX_FEC_BASE ENET_BASE_ADDR
@@ -100,6 +91,11 @@#define CONFIG_IPUV3_CLK 260000000#define CONFIG_IMX_HDMI +#ifndef CONFIG_SPL_BUILD +#include <config_distro_defaults.h> +#include <config_distro_bootcmd.h> +#endif +#if defined(CONFIG_MX6DL ) || defined(CONFIG_MX6S )#define CONFIG_DEFAULT_FDT_FILE "imx6dl-wandboard.dtb"#elif defined(CONFIG_MX6Q )
@@ -111,11 +107,14 @@"image=zImage\0" \"console=ttymxc0\0" \"splashpos=m,m\0" \ -"fdt_high=0xffffffff\0" \ -"initrd_high=0xffffffff\0" \ -"fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \ -"fdt_addr=0x18000000\0" \ +"fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \ +"fdt_addr_r=0x18000000\0" \"boot_fdt=try\0" \ +"pxefile_addr_r=0x17f00000\0" \ +"scriptaddr=0x17e00000\0" \ +"kernel_addr_r=0x11000000\0" \ +"ramdisk_addr_r=0x18100000\0" \ +"bootm_size=0x20000000\0" \"ip_dyn=yes\0" \ "mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \"mmcpart=1\0" \
@@ -134,70 +133,12 @@"mmc write ${loadaddr} 0x2 ${fw_sz}; " \"fi; " \"fi\0" \ -"mmcargs=setenv bootargs console=${console},${baudrate} " \ -"root=${mmcroot}\0" \ -"loadbootscript=" \ -"fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \ -"bootscript=echo Running bootscript from mmc ...; " \ -"source\0" \ -"loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \ -"loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \ -"mmcboot=echo Booting from mmc ...; " \ -"run mmcargs; " \ -"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \ -"if run loadfdt; then " \ -"bootz ${loadaddr} - ${fdt_addr}; " \ -"else " \ -"if test ${boot_fdt} = try; then " \ -"bootz; " \ -"else " \ -"echo WARN: Cannot load the DT; " \ -"fi; " \ -"fi; " \ -"else " \ -"bootz; " \ -"fi;\0" \ -"netargs=setenv bootargs console=${console},${baudrate} " \ -"root=/dev/nfs " \ -"ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \ -"netboot=echo Booting from net ...; " \ -"run netargs; " \ -"if test ${ip_dyn} = yes; then " \ -"setenv get_cmd dhcp; " \ -"else " \ -"setenv get_cmd tftp; " \ -"fi; " \ -"${get_cmd} ${image}; " \ -"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \ -"if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \ -"bootz ${loadaddr} - ${fdt_addr}; " \ -"else " \ -"if test ${boot_fdt} = try; then " \ -"bootz; " \ -"else " \ -"echo WARN: Cannot load the DT; " \ -"fi; " \ -"fi; " \ -"else " \ -"bootz; " \ - "fi;\0" + BOOTCMDS_COMMON#define CONFIG_BOOTCOMMAND \ - "mmc dev ${mmcdev}; if mmc rescan; then " \ - "if run loadbootscript; then " \ - "run bootscript; " \ - "else " \ - "if run loadimage; then " \ - "run mmcboot; " \ - "else run netboot; " \ - "fi; " \ - "fi; " \ - "else run netboot; fi" + "for target in ${boot_targets}; do run bootcmd_${target}; done"/* Miscellaneous configurable options */ -#define CONFIG_SYS_LONGHELP -#define CONFIG_SYS_HUSH_PARSER -#define CONFIG_AUTO_COMPLETE #define CONFIG_SYS_CBSIZE 256/* Print Buffer Size */
@@ -207,8 +148,6 @@#define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR -#define CONFIG_CMDLINE_EDITING -/* Physical Memory Map */ #define CONFIG_NR_DRAM_BANKS 1#define PHYS_SDRAM MMDC0_ARB_BASE_ADDR
@@ -231,9 +170,6 @@#define CONFIG_ENV_OFFSET (6 * 64 * 1024)#define CONFIG_SYS_MMC_ENV_DEV 0 -#define CONFIG_OF_LIBFDT -#define CONFIG_CMD_BOOTZ -#ifndef CONFIG_SYS_DCACHE_OFF #define CONFIG_CMD_CACHE #endif
Signature · 1 line
1.9.0
PATCH 4/6 move beagleboard over to use the generic distro configuation and environment
In reply to Dennis Gilmoreport beagleboard to use the generic distro configuation. remove duplicated config options, clean up the environment, include new environment.
--- include/configs/am335x_evm.h | 62 +++++++++------------------------------ include/configs/ti_armv7_common.h | 32 ++++++-------------- 2 files changed, 23 insertions(+), 71 deletions(-)
include/configs/am335x_evm.h +14 -48
@@ -50,9 +50,9 @@"nandrootfstype=ubifs rootwait=1\0" \"nandboot=echo Booting from nand ...; " \"run nandargs; " \ -"nand read ${fdtaddr} u-boot-spl-os; " \ -"nand read ${loadaddr} kernel; " \ - "bootz ${loadaddr} - ${fdtaddr}\0" +"nand read ${fdt_addr_r} u-boot-spl-os; " \ +"nand read ${kernel_addr_r} kernel; " \ + "bootz ${kernel_addr_r} - ${fdt_addr_r}\0"#else #define NANDARGS ""#endif
@@ -100,60 +100,28 @@"nfsroot=${serverip}:${rootpath},${nfsopts} rw " \"ip=dhcp\0" \"bootenv=uEnv.txt\0" \ -"loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \ +"loadbootenv=load mmc ${mmcdev} ${kernel_addr_r} ${bootenv}\0" \"importbootenv=echo Importing environment from mmc ...; " \ -"env import -t $loadaddr $filesize\0" \ +"env import -t $kernel_addr_r $filesize\0" \"ramargs=setenv bootargs console=${console} " \"${optargs} " \"root=${ramroot} " \"rootfstype=${ramrootfstype}\0" \ -"loadramdisk=load mmc ${mmcdev} ${rdaddr} ramdisk.gz\0" \ -"loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \ -"loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \ -"mmcloados=run mmcargs; " \ -"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \ -"if run loadfdt; then " \ -"bootz ${loadaddr} - ${fdtaddr}; " \ -"else " \ -"if test ${boot_fdt} = try; then " \ -"bootz; " \ -"else " \ -"echo WARN: Cannot load the DT; " \ -"fi; " \ -"fi; " \ -"else " \ -"bootz; " \ -"fi;\0" \ -"mmcboot=mmc dev ${mmcdev}; " \ -"if mmc rescan; then " \ -"echo SD/MMC found on device ${mmcdev};" \ -"if run loadbootenv; then " \ -"echo Loaded environment from ${bootenv};" \ -"run importbootenv;" \ -"fi;" \ -"if test -n $uenvcmd; then " \ -"echo Running uenvcmd ...;" \ -"run uenvcmd;" \ -"fi;" \ -"if run loadimage; then " \ -"run mmcloados;" \ -"fi;" \ -"fi;\0" \"spiboot=echo Booting from spi ...; " \"run spiargs; " \"sf probe ${spibusno}:0; " \ -"sf read ${loadaddr} ${spisrcaddr} ${spiimgsize}; " \ -"bootz ${loadaddr}\0" \ +"sf read ${kernel_addr_r} ${spisrcaddr} ${spiimgsize}; " \ +"bootz ${kernel_addr_r}\0" \"netboot=echo Booting from network ...; " \"setenv autoload no; " \"dhcp; " \ -"tftp ${loadaddr} ${bootfile}; " \ -"tftp ${fdtaddr} ${fdtfile}; " \ +"tftp ${kernel_addr_r} ${bootfile}; " \ +"tftp ${fdt_addr_r} ${fdtfile}; " \"run netargs; " \ -"bootz ${loadaddr} - ${fdtaddr}\0" \ +"bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \"ramboot=echo Booting from ramdisk ...; " \"run ramargs; " \ -"bootz ${loadaddr} ${rdaddr} ${fdtaddr}\0" \ +"bootz ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}\0" \"findfdt=" \"if test $board_name = A335BONE; then " \"setenv fdtfile am335x-bone.dtb; fi; " \
@@ -166,15 +134,13 @@"if test $fdtfile = undefined; then " \"echo WARNING: Could not determine device tree to use; fi; \0" \NANDARGS \ - DFUARGS +DFUARGS \ + BOOTCMDS_COMMON#endif #define CONFIG_BOOTCOMMAND \ "run findfdt; " \ - "run mmcboot;" \ - "setenv mmcdev 1; " \ - "setenv bootpart 1:2; " \ - "run mmcboot;" \ + "for target in ${boot_targets}; do run bootcmd_${target}; done " \ "run nandboot;"/* NS16550 Configuration */
include/configs/ti_armv7_common.h +9 -23
@@ -28,7 +28,6 @@#define CONFIG_SYS_NO_FLASH /* Support both device trees and ATAGs. */ -#define CONFIG_OF_LIBFDT #define CONFIG_CMDLINE_TAG #define CONFIG_SETUP_MEMORY_TAGS #define CONFIG_INITRD_TAG
@@ -53,6 +52,8 @@#define DEFAULT_LINUX_BOOT_ENV \ "loadaddr=0x82000000\0" \ "kernel_addr_r=0x82000000\0" \ + "pxe_addr_r=0x87F00000\0" \ + "scriptaddr=0x87E00000\0" \ "fdtaddr=0x88000000\0" \ "fdt_addr_r=0x88000000\0" \ "rdaddr=0x88080000\0" \
@@ -60,11 +61,6 @@"bootm_size=0x20000000\0" /* -* Default to a quick boot delay. - */ -#define CONFIG_BOOTDELAY 1 - -/* * DDR information. If the CONFIG_NR_DRAM_BANKS is not defined, * we say (for simplicity) that we have 1 bank, always, even when * we have more. We always start at 0x80000000, and we place the
@@ -125,19 +121,12 @@* console baudrate of 115200 and use the default baud rate table. */ #define CONFIG_SYS_MALLOC_LEN (1024 << 10) -#define CONFIG_SYS_HUSH_PARSER #define CONFIG_SYS_PROMPT "U-Boot# "#define CONFIG_SYS_CONSOLE_INFO_QUIET #define CONFIG_BAUDRATE 115200#define CONFIG_ENV_VARS_UBOOT_CONFIG /* Strongly encouraged */ #define CONFIG_ENV_OVERWRITE /* Overwrite ethaddr / serial# */ -/* As stated above, the following choices are optional. */ -#define CONFIG_SYS_LONGHELP -#define CONFIG_AUTO_COMPLETE -#define CONFIG_CMDLINE_EDITING -#define CONFIG_VERSION_VARIABLE -/* We set the max number of command args high to avoid HUSH bugs. */ #define CONFIG_SYS_MAXARGS 64
@@ -170,21 +159,18 @@#include <config_cmd_default.h> #define CONFIG_CMD_ASKENV #define CONFIG_CMD_ECHO -#define CONFIG_CMD_BOOTZ /* -* Common filesystems support. When we have removable storage we -* enabled a number of useful commands and support. +* Include the generic config options and boot environment when not +* building our SPL */ -#if defined(CONFIG_MMC ) || defined(CONFIG_USB_STORAGE ) -#define CONFIG_DOS_PARTITION -#define CONFIG_CMD_FAT -#define CONFIG_FAT_WRITE -#define CONFIG_CMD_EXT2 -#define CONFIG_CMD_EXT4 -#define CONFIG_CMD_FS_GENERIC +#ifndef CONFIG_SPL_BUILD +#include <config_distro_defaults.h> +#include <config_distro_bootcmd.h> #endif +#define CONFIG_CMD_FAT +/* * Our platforms make use of SPL to initalize the hardware (primarily * memory) enough for full U-Boot to be loaded. We also support Falcon
Signature · 1 line
1.9.0
PATCH 4/6 move beagleboard over to use the generic distro configuation and environment
Quoted 8 lines · Dennis Gilmore
port beagleboard to use the generic distro configuation. remove duplicated config options, clean up the environment, include new environment.
Signed-off-by Dennis Gilmore <[email protected]>--- include/configs/am335x_evm.h | 62 +++++++++------------------------------ include/configs/ti_armv7_common.h | 32 ++++++--------------
Changing ti_armv7_common.h changes a ton of other boards which may not want to opt-in here yet / ever. So we need to:
include/configs/am335x_evm.h
Quoted 6 lines
2 files changed, 23 insertions(+), 71 deletions(-)include/configs/am335x_evm.h +0
-0
Add the generic distro includes here.
Quoted 4 lines
include/configs/ti_armv7_common.h +0
-0
[snip]
include/configs/ti_armv7_common.h line 65
Quoted 7 lines
include/configs/ti_armv7_common.h +0
-3@@ -60,11 +61,6 @@"bootm_size=0x20000000\0" /* -* Default to a quick boot delay. - */ -#define CONFIG_BOOTDELAY 1
Change this to 2, and leave the rest of the duplicated enables alone.
Quoted 9 lines
include/configs/ti_armv7_common.h +2
-5/* -* Common filesystems support. When we have removable storage we -* enabled a number of useful commands and support. +* Include the generic config options and boot environment when not +* building our SPL */ -#if defined(CONFIG_MMC ) || defined(CONFIG_USB_STORAGE ) -#define CONFIG_DOS_PARTITION -#define CONFIG_CMD_FAT
include/configs/ti_armv7_common.h line 172
Quoted 10 lines
include/configs/ti_armv7_common.h +4
-4-#define CONFIG_FAT_WRITE -#define CONFIG_CMD_EXT2 -#define CONFIG_CMD_EXT4 -#define CONFIG_CMD_FS_GENERIC +#ifndef CONFIG_SPL_BUILD +#include <config_distro_defaults.h> +#include <config_distro_bootcmd.h> #endif +#define CONFIG_CMD_FAT
And leave this part out as well.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140321/951d0705/attachment.pgp>
PATCH 5/6 move pandaboard over to use the generic distro configuation and environment
In reply to Dennis Gilmoreport pandaboard to use the generic distro configuation. remove duplicated config options, clean up the environment, include new environment.
--- include/configs/omap4_panda.h | 2 -- include/configs/ti_omap4_common.h | 37 +++++++++++-------------------------- 2 files changed, 11 insertions(+), 28 deletions(-)
include/configs/omap4_panda.h +0 -2
@@ -33,8 +33,6 @@#define CONFIG_UBOOT_ENABLE_PADS_ALL -#define CONFIG_CMD_PING -#define CONFIG_CMD_DHCP #include <configs/ti_omap4_common.h> #define CONFIG_CMD_NET
include/configs/ti_omap4_common.h +11 -26
@@ -86,6 +86,7 @@/* * Environment setup */ +#ifndef CONFIG_SPL_BUILD #define CONFIG_EXTRA_ENV_SETTINGS \ DEFAULT_LINUX_BOOT_ENV \ "console=ttyO2,115200n8\0" \
@@ -102,16 +103,16 @@"vram=${vram} " \"root=${mmcroot} " \"rootfstype=${mmcrootfstype}\0" \ -"loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \ +"loadbootscript=load mmc ${mmcdev} ${kernel_addr_r} boot.scr\0" \"bootscript=echo Running bootscript from mmc${mmcdev} ...; " \ -"source ${loadaddr}\0" \ -"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \ +"source ${kernel_addr_r}\0" \ +"loadbootenv=load mmc ${mmcdev} ${kernel_addr_r} uEnv.txt\0" \"importbootenv=echo Importing environment from mmc${mmcdev} ...; " \ -"env import -t ${loadaddr} ${filesize}\0" \ -"loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \ +"env import -t ${kernel_addr_r} ${filesize}\0" \ +"loadimage=load mmc ${bootpart} ${kernel_addr_r} ${bootdir}/${bootfile}\0" \"mmcboot=echo Booting from mmc${mmcdev} ...; " \"run mmcargs; " \ -"bootz ${loadaddr} - ${fdtaddr}\0" \ +"bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \"findfdt=" \"if test $board_name = sdp4430; then " \"setenv fdtfile omap4-sdp.dtb; fi; " \
@@ -123,29 +124,13 @@"setenv fdtfile omap4-panda-es.dtb; fi;" \"if test $fdtfile = undefined; then " \"echo WARNING: Could not determine device tree to use; fi; \0" \ -"loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \ +"loadfdt=load mmc ${bootpart} ${fdt_addr_r} ${bootdir}/${fdtfile}\0" \ + BOOTCMDS_COMMON +#endif #define CONFIG_BOOTCOMMAND \ "run findfdt; " \ -"mmc dev ${mmcdev}; if mmc rescan; then " \ -"echo SD/MMC found on device ${mmcdev};" \ -"if run loadbootscript; then " \ -"run bootscript; " \ -"else " \ -"if run loadbootenv; then " \ -"run importbootenv; " \ -"fi;" \ -"if test -n ${uenvcmd}; then " \ -"echo Running uenvcmd ...;" \ -"run uenvcmd;" \ -"fi;" \ -"fi;" \ -"if run loadimage; then " \ -"run loadfdt;" \ -"run mmcboot; " \ -"fi; " \ -"fi" - + "for target in ${boot_targets}; do run bootcmd_${target}; done "/* * Defines for SPL * It is known that this will break HS devices. Since the current size of
Signature · 1 line
1.9.0
PATCH 5/6 move pandaboard over to use the generic distro configuation and environment
Quoted 3 lines · Dennis Gilmore
port pandaboard to use the generic distro configuation. remove duplicated config options, clean up the environment, include new environment.
[snip]
include/configs/ti_omap4_common.h
Quoted 4 lines
include/configs/ti_omap4_common.h +0
-0
With what I said in 3/6, I'm OK with opting all of omap4 in.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140321/bcd18456/attachment.pgp>
PATCH 6/6 pxe: additionaly check for fdt_file env variable
In reply to Dennis Gilmoresome boards have used fdt_file while others have used fdtfile to define the name of the fdt file. If we do notget a fdtfile environment variable, additionally check for fdt_file.
--- common/cmd_pxe.c | 7 +++++++ 1 file changed, 7 insertions(+)
common/cmd_pxe.c +7 -0
@@ -712,6 +712,13 @@ static int label_boot(cmd_tbl_t *cmdtp, struct pxe_label *label)char *f1, *f2, *f3, *f4, *slash; f1 =getenv ("fdtfile" ); +/* +* some boards have used fdt_file as the environment variable for +* defining the device tree file so lets check for fdt_file also. +*/ +if (!f1) { + f1 =getenv ("fdt_file" ); + }if (f1) { f2 ="" ; f3 ="" ;
Signature · 1 line
1.9.0
PATCH 6/6 pxe: additionaly check for fdt_file env variable
Quoted 14 lines · Dennis Gilmore
some boards have used
fdt_filewhile others have used fdtfile to define the name of the fdt file. If we do notget a fdtfile environment variable, additionally check forfdt_file.Signed-off-by Dennis Gilmore <[email protected]>--- common/cmd_pxe.c | 7 +++++++ 1 file changed, 7 insertions(+)common/cmd_pxe.c +0
-0
common/cmd_pxe.c static int label_boot(cmd_tbl_t *cmdtp, struct pxe_label *label) · line 718
Quoted 7 lines
common/cmd_pxe.c +4
-0@@ -712,6 +712,13 @@ static int label_boot(cmd_tbl_t *cmdtp, struct pxe_label *label)char *f1, *f2, *f3, *f4, *slash; f1 =getenv ("fdtfile" ); +/* +* some boards have used fdt_file as the environment variable for +* defining the device tree file so lets check for fdt_file also. +*/
Correctly wrap this please, thanks.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140321/17808eb4/attachment.pgp>
PATCH 6/6 pxe: additionaly check for fdt_file env variable
In reply to Dennis GilmoreQuoted 3 lines · Dennis Gilmore
some boards have used
fdt_filewhile others have used fdtfile to define the name of the fdt file. If we do notget a fdtfile environment variable, additionally check forfdt_file.
Is this variable typically set by the user or by the default environment? If the default environment, perhaps the variable name could simply be changed?
Still, this change is fine by me,
common/cmd_pxe.c static int label_boot(cmd_tbl_t *cmdtp, struct pxe_label *label) · line 721
Quoted 4 lines
common/cmd_pxe.c +3
-0+if (!f1) { + f1 =getenv ("fdt_file" ); + }
Doesn't checkpatch say to remove the {} there?