[U-Boot] [RFC] implementation of generic distro configs
As a followup to http://lists.denx.de/pipermail/u-boot/2013-August/160080.html ive put together what i Think is a reasonable starting point for defining a unified set of features and options.
There are some things that really need some more work yet. mostly to do with austomatically loading of the dtb. All of these patches are currently enabled in Fedora's u-boot builds.
the wandboard in particular has received a lot of testing using sysboot command to load a extlinux.conf file. which did pick up bugs in teh pxe.c code early on. I would appreciate some feedback from a wider audience as we move to making this be a default configuration.
Dennis
Signed-off-by: Dennis Gilmore dennis@ausil.us --- include/common.h | 5 +++++ include/config_distro_default.h | 49 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 54 insertions(+) create mode 100644 include/config_distro_default.h
diff --git a/include/common.h b/include/common.h index 8ca67f6..c558422 100644 --- a/include/common.h +++ b/include/common.h @@ -99,6 +99,11 @@ typedef volatile unsigned char vu_char; #include <flash.h> #include <image.h>
+/* use generic distro config */ +#ifdef DISTRO_DEFAULTS +#include <config_distro_default.h> +#endif + #ifdef DEBUG #define _DEBUG 1 #else diff --git a/include/config_distro_default.h b/include/config_distro_default.h new file mode 100644 index 0000000..bd9b4a0 --- /dev/null +++ b/include/config_distro_default.h @@ -0,0 +1,49 @@ +/* + * Copyright 2013 Red Hat, Inc. + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#ifndef _CONFIG_CMD_DISTRO_DEFAULT_H +#define _CONFIG_CMD_DISTRO_DEFAULT_H + +/* + * List of all commands and options that when defined enables support for features + * required by distros to support boards in a standardised and consitant manner. + */ + +#define CONFIG_BOOTP_BOOTPATH +#define CONFIG_BOOTP_DNS +#define CONFIG_BOOTP_GATEWAY +#define CONFIG_BOOTP_HOSTNAME +#define CONFIG_BOOTP_PXE +#define CONFIG_BOOTP_SUBNETMASK + +#if defined(__arm__) +#define CONFIG_BOOTP_PXE_CLIENTARCH 0x100 +#define CONFIG_BOOTP_VCI_STRING "U-boot.armv7" +#endif + +#define CONFIG_OF_LIBFDT + +#define CONFIG_CMD_BOOTZ +#define CONFIG_CMD_DHCP +#define CONFIG_CMD_ELF +#define CONFIG_CMD_EXT2 +#define CONFIG_CMD_FAT +#define CONFIG_CMD_MII +#define CONFIG_CMD_NET +#define CONFIG_CMD_PING +#define CONFIG_CMD_PXE + +#define CONFIG_CMDLINE_EDITING +#define CONFIG_AUTO_COMPLETE +#define CONFIG_BOOTDELAY 2 +#define CONFIG_SYS_LONGHELP +#define CONFIG_MENU +#define CONFIG_DOS_PARTITION +#define CONFIG_EFI_PARTITION +#define CONFIG_SUPPORT_RAW_INITRD +#define CONFIG_SYS_HUSH_PARSER + +#endif /* _CONFIG_CMD_DISTRO_DEFAULT_H */
Dear Dennis Gilmore,
In message 1386296295-28658-2-git-send-email-dennis@ausil.us you wrote:
+#if defined(__arm__) +#define CONFIG_BOOTP_PXE_CLIENTARCH 0x100 +#define CONFIG_BOOTP_VCI_STRING "U-boot.armv7" +#endif
This cannot be right. Not all the world is an ARMv7.
Please also note that the correct spelling (when using capitalization) is "U-Boot" (i. e. with a capital 'B').
Best regards,
Wolfgang Denk
Signed-off-by: Dennis Gilmore dennis@ausil.us --- include/configs/wandboard.h | 40 +++++++++++++++++++++++++++++++++++----- 1 file changed, 35 insertions(+), 5 deletions(-)
diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h index e9c7e64..02d8968 100644 --- a/include/configs/wandboard.h +++ b/include/configs/wandboard.h @@ -40,6 +40,9 @@ #define CONFIG_CONS_INDEX 1 #define CONFIG_BAUDRATE 115200
+/* enable generic distro config */ +#define DISTRO_DEFAULTS 1 + /* Command definition */ #include <config_cmd_default.h>
@@ -48,7 +51,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) @@ -65,6 +67,9 @@ #define CONFIG_CMD_MMC #define CONFIG_GENERIC_MMC #define CONFIG_BOUNCE_BUFFER + +#define CONFIG_BOOTDELAY 5 + #define CONFIG_CMD_EXT2 #define CONFIG_CMD_FAT #define CONFIG_DOS_PARTITION @@ -74,6 +79,11 @@ #define CONFIG_CMD_DHCP #define CONFIG_CMD_MII #define CONFIG_CMD_NET + +#define CONFIG_OF_LIBFDT +#define CONFIG_CMD_BOOTZ + +/* Ethernet Configuration */ #define CONFIG_FEC_MXC #define CONFIG_MII #define IMX_FEC_BASE ENET_BASE_ADDR @@ -113,8 +123,30 @@ "fdt_high=0xffffffff\0" \ "initrd_high=0xffffffff\0" \ "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \ - "fdt_addr=0x11000000\0" \ + "fdt_addr=0x11100000\0" \ + "fdt_addr_r=0x11200000\0" \ + "pxefile_addr_r=0x11300000\0" \ + "scr_addr_r=0x11400000\0" \ + "kernel_addr_r=0x11500000\0" \ + "ramdisk_addr_r=0x13500000\0" \ "boot_fdt=try\0" \ + "bootcmd_setup=mmc rescan\0" \ + "bootcmd_pxe=setenv bootfile "" ;dhcp; tftp ${fdt_addr} /dtb/${fdt_file}; pxe get; pxe boot\0" \ + "bootcmd_disk_scr=ext2load ${boot_ifc} ${bootdevice} ${scr_addr_r} boot.scr && source ${scr_addr_r}\0" \ + "bootcmd_disk_sysboot1=setenv bootfile /boot/extlinux/extlinux.conf; sysboot ${boot_ifc} ${bootdevice} ext2\0" \ + "bootcmd_disk_sysboot2=setenv bootfile /extlinux/extlinux.conf; sysboot ${boot_ifc} ${bootdevice} ext2\0" \ + "bootcmd_disk_uenv=ext2load ${boot_ifc} ${bootdevice} ${uenv_addr_r} uEnv.txt; env import -t ${uenv_addr_r} ${filesize}; run bootcmd_uenv\0" \ + "bootcmd_disk_kernel=ext2load ${boot_ifc} ${bootdevice} ${kernel_addr_r} vmlinuz && ext2load ${boot_ifc} ${bootdevice} ${ramdisk_addr_r} initrd.img && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr}\0" \ + "bootcmd_disk=ext2load ${boot_ifc} ${bootdevice} ${fdt_addr} /boot/dtb/${fdt_file}; ext2load ${boot_ifc} ${bootdevice} ${fdt_addr} /dtb/${fdt_file};run bootcmd_disk_sysboot1; run bootcmd_disk_sysboot2; run bootcmd_disk_uenv; run bootcmd_disk_scr; run bootcmd_disk_kernel\0" \ + "bootcmd_sata=setenv boot_ifc scsi; scsi scan && run bootcmd_disk\0" \ + "bootcmd_mmc=setenv boot_ifc mmc; mmc rescan && run bootcmd_disk\0" \ + "bootcmd_default=run bootcmd_mmc; run bootcmd_sata; run bootcmd_pxe\0" \ + "localcmd=run bootcmd_mmc\0" \ + "bootdevice=0\0" \ + "bootargs=console=ttymxc0 root=LABEL=rootfs\0" \ + "bootdelay=2\0" \ + "bootretry=90\0" \ + "netretry=once\0" \ "ip_dyn=yes\0" \ "mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \ "mmcpart=1\0" \ @@ -183,6 +215,7 @@
#define CONFIG_BOOTCOMMAND \ "mmc dev ${mmcdev}; if mmc rescan; then " \ + "run bootcmd_default; " \ "if run loadbootscript; then " \ "run bootscript; " \ "else " \ @@ -230,9 +263,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
On Thu, Dec 5, 2013 at 8:18 PM, Dennis Gilmore dennis@ausil.us wrote:
Signed-off-by: Dennis Gilmore dennis@ausil.us
include/configs/wandboard.h | 40 +++++++++++++++++++++++++++++++++++----- 1 file changed, 35 insertions(+), 5 deletions(-)
diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h index e9c7e64..02d8968 100644 --- a/include/configs/wandboard.h +++ b/include/configs/wandboard.h @@ -40,6 +40,9 @@ #define CONFIG_CONS_INDEX 1 #define CONFIG_BAUDRATE 115200
+/* enable generic distro config */ +#define DISTRO_DEFAULTS 1
/* Command definition */ #include <config_cmd_default.h>
@@ -48,7 +51,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) @@ -65,6 +67,9 @@ #define CONFIG_CMD_MMC #define CONFIG_GENERIC_MMC #define CONFIG_BOUNCE_BUFFER
+#define CONFIG_BOOTDELAY 5
#define CONFIG_CMD_EXT2 #define CONFIG_CMD_FAT #define CONFIG_DOS_PARTITION @@ -74,6 +79,11 @@ #define CONFIG_CMD_DHCP #define CONFIG_CMD_MII #define CONFIG_CMD_NET
+#define CONFIG_OF_LIBFDT +#define CONFIG_CMD_BOOTZ
+/* Ethernet Configuration */ #define CONFIG_FEC_MXC #define CONFIG_MII #define IMX_FEC_BASE ENET_BASE_ADDR @@ -113,8 +123,30 @@ "fdt_high=0xffffffff\0" \ "initrd_high=0xffffffff\0" \ "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \
"fdt_addr=0x11000000\0" \
"fdt_addr=0x11100000\0" \"fdt_addr_r=0x11200000\0" \"pxefile_addr_r=0x11300000\0" \"scr_addr_r=0x11400000\0" \"kernel_addr_r=0x11500000\0" \"ramdisk_addr_r=0x13500000\0" \ "boot_fdt=try\0" \"bootcmd_setup=mmc rescan\0" \"bootcmd_pxe=setenv bootfile \"\" ;dhcp; tftp ${fdt_addr} /dtb/${fdt_file}; pxe get; pxe boot\0" \"bootcmd_disk_scr=ext2load ${boot_ifc} ${bootdevice} ${scr_addr_r} boot.scr &&
Why all the non-generic "ext2load"'s? use just "load", then it'll work with both fat, ext2/3/4 & btrfs...
Regards,
El Thu, 5 Dec 2013 21:47:43 -0600 Robert Nelson robertcnelson@gmail.com escribió:
On Thu, Dec 5, 2013 at 8:18 PM, Dennis Gilmore dennis@ausil.us wrote:
Signed-off-by: Dennis Gilmore dennis@ausil.us
include/configs/wandboard.h | 40 +++++++++++++++++++++++++++++++++++----- 1 file changed, 35 insertions(+), 5 deletions(-)
diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h index e9c7e64..02d8968 100644 --- a/include/configs/wandboard.h +++ b/include/configs/wandboard.h @@ -40,6 +40,9 @@ #define CONFIG_CONS_INDEX 1 #define CONFIG_BAUDRATE 115200
+/* enable generic distro config */ +#define DISTRO_DEFAULTS 1
/* Command definition */ #include <config_cmd_default.h>
@@ -48,7 +51,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) @@ -65,6 +67,9 @@ #define CONFIG_CMD_MMC #define CONFIG_GENERIC_MMC #define CONFIG_BOUNCE_BUFFER
+#define CONFIG_BOOTDELAY 5
#define CONFIG_CMD_EXT2 #define CONFIG_CMD_FAT #define CONFIG_DOS_PARTITION @@ -74,6 +79,11 @@ #define CONFIG_CMD_DHCP #define CONFIG_CMD_MII #define CONFIG_CMD_NET
+#define CONFIG_OF_LIBFDT +#define CONFIG_CMD_BOOTZ
+/* Ethernet Configuration */ #define CONFIG_FEC_MXC #define CONFIG_MII #define IMX_FEC_BASE ENET_BASE_ADDR @@ -113,8 +123,30 @@ "fdt_high=0xffffffff\0" \ "initrd_high=0xffffffff\0" \ "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \
"fdt_addr=0x11000000\0" \
"fdt_addr=0x11100000\0" \"fdt_addr_r=0x11200000\0" \"pxefile_addr_r=0x11300000\0" \"scr_addr_r=0x11400000\0" \"kernel_addr_r=0x11500000\0" \"ramdisk_addr_r=0x13500000\0" \ "boot_fdt=try\0" \"bootcmd_setup=mmc rescan\0" \"bootcmd_pxe=setenv bootfile \"\" ;dhcp; tftp${fdt_addr} /dtb/${fdt_file}; pxe get; pxe boot\0" \
"bootcmd_disk_scr=ext2load ${boot_ifc} ${bootdevice}${scr_addr_r} boot.scr &&
Why all the non-generic "ext2load"'s? use just "load", then it'll work with both fat, ext2/3/4 & btrfs...
Regards,
the pxe code requires you specify the filesystem for the sysboot command, and as /boot needs to be ext ive kept it consistent. Ive also not narrowed down the option to enable load to work, in my testing it did not work.
Dennis
El Thu, 5 Dec 2013 23:01:13 -0600 Dennis Gilmore dennis@ausil.us escribió:
El Thu, 5 Dec 2013 21:47:43 -0600 Robert Nelson robertcnelson@gmail.com escribió:
On Thu, Dec 5, 2013 at 8:18 PM, Dennis Gilmore dennis@ausil.us wrote:
Signed-off-by: Dennis Gilmore dennis@ausil.us
include/configs/wandboard.h | 40 +++++++++++++++++++++++++++++++++++----- 1 file changed, 35 insertions(+), 5 deletions(-)
diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h index e9c7e64..02d8968 100644 --- a/include/configs/wandboard.h +++ b/include/configs/wandboard.h @@ -40,6 +40,9 @@ #define CONFIG_CONS_INDEX 1 #define CONFIG_BAUDRATE 115200
+/* enable generic distro config */ +#define DISTRO_DEFAULTS 1
/* Command definition */ #include <config_cmd_default.h>
@@ -48,7 +51,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) @@ -65,6 +67,9 @@
#define CONFIG_CMD_MMC #define CONFIG_GENERIC_MMC #define CONFIG_BOUNCE_BUFFER
+#define CONFIG_BOOTDELAY 5
#define CONFIG_CMD_EXT2 #define CONFIG_CMD_FAT #define CONFIG_DOS_PARTITION @@ -74,6 +79,11 @@ #define CONFIG_CMD_DHCP #define CONFIG_CMD_MII #define CONFIG_CMD_NET
+#define CONFIG_OF_LIBFDT +#define CONFIG_CMD_BOOTZ
+/* Ethernet Configuration */ #define CONFIG_FEC_MXC #define CONFIG_MII #define IMX_FEC_BASE ENET_BASE_ADDR @@ -113,8 +123,30 @@ "fdt_high=0xffffffff\0" \ "initrd_high=0xffffffff\0" \ "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \
"fdt_addr=0x11000000\0" \
"fdt_addr=0x11100000\0" \"fdt_addr_r=0x11200000\0" \"pxefile_addr_r=0x11300000\0" \"scr_addr_r=0x11400000\0" \"kernel_addr_r=0x11500000\0" \"ramdisk_addr_r=0x13500000\0" \ "boot_fdt=try\0" \"bootcmd_setup=mmc rescan\0" \"bootcmd_pxe=setenv bootfile \"\" ;dhcp; tftp${fdt_addr} /dtb/${fdt_file}; pxe get; pxe boot\0" \
"bootcmd_disk_scr=ext2load ${boot_ifc} ${bootdevice}${scr_addr_r} boot.scr &&
Why all the non-generic "ext2load"'s? use just "load", then it'll work with both fat, ext2/3/4 & btrfs...
Regards,
the pxe code requires you specify the filesystem for the sysboot command, and as /boot needs to be ext ive kept it consistent. Ive also not narrowed down the option to enable load to work, in my testing it did not work.
having said that I just found CONFIG_CMD_FS_GENERIC which is not set, though cmd_pxe.c will need some patching to not require specifying a filesystem
Dennis
Dennis
Why all the non-generic "ext2load"'s? use just "load", then it'll work with both fat, ext2/3/4 & btrfs...
Regards,
the pxe code requires you specify the filesystem for the sysboot command, and as /boot needs to be ext ive kept it consistent. Ive also not narrowed down the option to enable load to work, in my testing it did not work.
having said that I just found CONFIG_CMD_FS_GENERIC which is not set, though cmd_pxe.c will need some patching to not require specifying a filesystem
I can see fixing cmd_pxe.c could be done later. But as just a generic uEnv.txt user, I do like the idea of having a consistent variable naming setup for a bunch of boards. So i can easily convert my stuff to this setup, but the ext2load vs a generic load was the one big issue it was missing.
Regards,
On Thu, Dec 5, 2013 at 11:01 PM, Dennis Gilmore dennis@ausil.us wrote:
El Thu, 5 Dec 2013 21:47:43 -0600 Robert Nelson robertcnelson@gmail.com escribió:
On Thu, Dec 5, 2013 at 8:18 PM, Dennis Gilmore dennis@ausil.us wrote:
Signed-off-by: Dennis Gilmore dennis@ausil.us
include/configs/wandboard.h | 40 +++++++++++++++++++++++++++++++++++----- 1 file changed, 35 insertions(+), 5 deletions(-)
diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h index e9c7e64..02d8968 100644 --- a/include/configs/wandboard.h +++ b/include/configs/wandboard.h @@ -40,6 +40,9 @@ #define CONFIG_CONS_INDEX 1 #define CONFIG_BAUDRATE 115200
+/* enable generic distro config */ +#define DISTRO_DEFAULTS 1
/* Command definition */ #include <config_cmd_default.h>
@@ -48,7 +51,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) @@ -65,6 +67,9 @@ #define CONFIG_CMD_MMC #define CONFIG_GENERIC_MMC #define CONFIG_BOUNCE_BUFFER
+#define CONFIG_BOOTDELAY 5
#define CONFIG_CMD_EXT2 #define CONFIG_CMD_FAT #define CONFIG_DOS_PARTITION @@ -74,6 +79,11 @@ #define CONFIG_CMD_DHCP #define CONFIG_CMD_MII #define CONFIG_CMD_NET
+#define CONFIG_OF_LIBFDT +#define CONFIG_CMD_BOOTZ
+/* Ethernet Configuration */ #define CONFIG_FEC_MXC #define CONFIG_MII #define IMX_FEC_BASE ENET_BASE_ADDR @@ -113,8 +123,30 @@ "fdt_high=0xffffffff\0" \ "initrd_high=0xffffffff\0" \ "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \
"fdt_addr=0x11000000\0" \
"fdt_addr=0x11100000\0" \"fdt_addr_r=0x11200000\0" \"pxefile_addr_r=0x11300000\0" \"scr_addr_r=0x11400000\0" \"kernel_addr_r=0x11500000\0" \"ramdisk_addr_r=0x13500000\0" \ "boot_fdt=try\0" \"bootcmd_setup=mmc rescan\0" \"bootcmd_pxe=setenv bootfile \"\" ;dhcp; tftp${fdt_addr} /dtb/${fdt_file}; pxe get; pxe boot\0" \
"bootcmd_disk_scr=ext2load ${boot_ifc} ${bootdevice}${scr_addr_r} boot.scr &&
Why all the non-generic "ext2load"'s? use just "load", then it'll work with both fat, ext2/3/4 & btrfs...
Regards,
the pxe code requires you specify the filesystem for the sysboot command, and as /boot needs to be ext ive kept it consistent. Ive also not narrowed down the option to enable load to work, in my testing it did not work.
Ah, i see the issue, "#define CONFIG_CMD_FS_GENERIC" isn't defined yet for the wandboard in mainline u-boot, as you don't set it either in your patch, so of course a generic "load" won't work..
So if you add:
#define CONFIG_CMD_EXT4 #define CONFIG_CMD_FS_GENERIC
after: #define CONFIG_CMD_EXT2
in your patch you can drop all the ext2load non-sense for generic loads.
I've been shipping ubuntu/debian images with '#define CONFIG_CMD_FS_GENERIC' and 'load' for the wand since v2013.07 with no issues..
Regards,
Dear Dennis Gilmore,
In message 1386296295-28658-3-git-send-email-dennis@ausil.us you wrote:
- "fdt_addr=0x11000000\0" \
- "fdt_addr=0x11100000\0" \
- "fdt_addr_r=0x11200000\0" \
Why would you need fdt_addr and fdt_addr_r ? This makes no sense. Two different values would only be needed if there was NOR flash available where we could read the FDT from without loading it to RAM first. AFAIK ther ewill never be variants of the Wandboard with NOR flash, so you will always have to load the FDT to RAM first - thus the destinction makes no sense.
Best regards,
Wolfgang Denk
El Fri, 06 Dec 2013 11:59:05 +0100 Wolfgang Denk wd@denx.de escribió:
Dear Dennis Gilmore,
In message 1386296295-28658-3-git-send-email-dennis@ausil.us you wrote:
- "fdt_addr=0x11000000\0" \
- "fdt_addr=0x11100000\0" \
- "fdt_addr_r=0x11200000\0" \
Why would you need fdt_addr and fdt_addr_r ? This makes no sense. Two different values would only be needed if there was NOR flash available where we could read the FDT from without loading it to RAM first. AFAIK ther ewill never be variants of the Wandboard with NOR flash, so you will always have to load the FDT to RAM first - thus the destinction makes no sense.
please go and read the cmd_pxe.c file it specifies the use of the two variables. one is for a system provided dtb and the other is for a user provided dtb
Dennis
Dear Dennis Gilmore,
In message 20131206084854.0e0da0cd@adria.ausil.us you wrote:
Wolfgang Denk wd@denx.de escribi=F3:
Dear Dennis Gilmore, =20 In message 1386296295-28658-3-git-send-email-dennis@ausil.us you wrote:
- "fdt_addr=0x11000000\0" \
- "fdt_addr=0x11100000\0" \
- "fdt_addr_r=0x11200000\0" \
Why would you need fdt_addr and fdt_addr_r ? This makes no sense. Two different values would only be needed if there was NOR flash available where we could read the FDT from without loading it to RAM first. AFAIK ther ewill never be variants of the Wandboard with NOR flash, so you will always have to load the FDT to RAM first - thus the destinction makes no sense.
please go and read the cmd_pxe.c file it specifies the use of the two variables. one is for a system provided dtb and the other is for a user provided dtb
But this is crap. The meaning of these variables has been wel-defined for a long, long time. "fdt_addr" is the FDT address in NOR flash (or similar memory except system RAM); "fdt_addr_r" is the FDT address when loaded to system RAM (hence the "_r" in the variable name).
Arbitariry redefining this meaning is counterproductive and confusing.
If cmd_pxe.c uses incorrect names, then please fix the bug there.
Best regards,
Wolfgang Denk
On Fri, Dec 06, 2013 at 04:26:51PM +0100, Wolfgang Denk wrote:
Dear Dennis Gilmore,
In message 20131206084854.0e0da0cd@adria.ausil.us you wrote:
Wolfgang Denk wd@denx.de escribi=F3:
Dear Dennis Gilmore, =20 In message 1386296295-28658-3-git-send-email-dennis@ausil.us you wrote:
- "fdt_addr=0x11000000\0" \
- "fdt_addr=0x11100000\0" \
- "fdt_addr_r=0x11200000\0" \
Why would you need fdt_addr and fdt_addr_r ? This makes no sense. Two different values would only be needed if there was NOR flash available where we could read the FDT from without loading it to RAM first. AFAIK ther ewill never be variants of the Wandboard with NOR flash, so you will always have to load the FDT to RAM first - thus the destinction makes no sense.
please go and read the cmd_pxe.c file it specifies the use of the two variables. one is for a system provided dtb and the other is for a user provided dtb
But this is crap. The meaning of these variables has been wel-defined for a long, long time. "fdt_addr" is the FDT address in NOR flash (or similar memory except system RAM); "fdt_addr_r" is the FDT address when loaded to system RAM (hence the "_r" in the variable name).
It's a well defined and widely ignored in ARM convention then. We've got lots of 'fdt_addr' meaning RAM and no 'fdt_addr_r' and then in both ARM and PowerPC 'fdtaddr' being presumably RAM.
Arbitariry redefining this meaning is counterproductive and confusing.
If cmd_pxe.c uses incorrect names, then please fix the bug there.
I would say that 'fdt_addr' being the system provided DT, even when not found on memory-mapped flash and 'fdt_addr_r' being the user provided one is a logical extension.
If we want to set some new rules on these variables we're going to live with for a long while and really document and enforce (see above about fdt_addr/fdt_addr_r/fdtaddr current usage), OK, sure.
Dear Tom,
In message 20131206162854.GX420@bill-the-cat you wrote:
But this is crap. The meaning of these variables has been wel-defined for a long, long time. "fdt_addr" is the FDT address in NOR flash (or similar memory except system RAM); "fdt_addr_r" is the FDT address when loaded to system RAM (hence the "_r" in the variable name).
It's a well defined and widely ignored in ARM convention then. We've got lots of 'fdt_addr' meaning RAM and no 'fdt_addr_r' and then in both ARM and PowerPC 'fdtaddr' being presumably RAM.
I think it's actually OK to omit the "_r" in NOR-less systems. The number of devices with actual NOT flash is decreasing, and if you can be sure that there is no such memory device available, then it is just overhead to always carry the "_r" suffice around, knowing all the time that there will never be any other option than RAM to store that data.
I do not complain if such systems use a simplified setup without the "_r".
What I don't like to see is to have "fdt_addr_r" and "fdt_addr" used with a new, totally different meaning.
I don't know where the spelling "fdtaddr" is coming from; I would consider it one of the many "non-standard" variants (assuming we agree that there is actually something like a "standard"). Note that there is no "fdtaddr_r" anywhere.
I would say that 'fdt_addr' being the system provided DT, even when not found on memory-mapped flash and 'fdt_addr_r' being the user provided one is a logical extension.
Um... you enter completely new terms here - "system provided" and "user provided". I cannot see how a "user provided" DTB in NOR flash would fit in such a concept, nor how this would work on systems with NOR if a "system provided" DTB gets loaded into RAM from a DHCP server.
I understand that you are trying to give the old names a new definition that would magically cover the suggested use, but this is extremely thin ice. I recommend not to try that.
Best regards,
Wolfgang Denk
On Fri, Dec 06, 2013 at 09:37:59PM +0100, Wolfgang Denk wrote:
Dear Tom,
In message 20131206162854.GX420@bill-the-cat you wrote:
But this is crap. The meaning of these variables has been wel-defined for a long, long time. "fdt_addr" is the FDT address in NOR flash (or similar memory except system RAM); "fdt_addr_r" is the FDT address when loaded to system RAM (hence the "_r" in the variable name).
It's a well defined and widely ignored in ARM convention then. We've got lots of 'fdt_addr' meaning RAM and no 'fdt_addr_r' and then in both ARM and PowerPC 'fdtaddr' being presumably RAM.
I think it's actually OK to omit the "_r" in NOR-less systems. The number of devices with actual NOT flash is decreasing, and if you can be sure that there is no such memory device available, then it is just overhead to always carry the "_r" suffice around, knowing all the time that there will never be any other option than RAM to store that data.
Right. So the rule is "fdt_addr means the [shipped] DT in NOR, if present. fdt_addr_r means the [shipped] DT in system RAM."
I do not complain if such systems use a simplified setup without the "_r".
What I don't like to see is to have "fdt_addr_r" and "fdt_addr" used with a new, totally different meaning.
Well, "fdt_addr" still means the shipped DT and "fdt_addr_r" still means a DT loaded into system RAM. The only change is that fdt_addr may also be a system RAM address.
I don't know where the spelling "fdtaddr" is coming from; I would consider it one of the many "non-standard" variants (assuming we agree that there is actually something like a "standard"). Note that there is no "fdtaddr_r" anywhere.
"fdtaddr" comes from somewhere along the line someone not going "Hey, you forgot a _ in your env" since it means what fdt_addr_r means or fdt_addr means when you lack NOR/similar flash for a DT.
I would say that 'fdt_addr' being the system provided DT, even when not found on memory-mapped flash and 'fdt_addr_r' being the user provided one is a logical extension.
Um... you enter completely new terms here - "system provided" and "user provided". I cannot see how a "user provided" DTB in NOR flash would fit in such a concept, nor how this would work on systems with NOR if a "system provided" DTB gets loaded into RAM from a DHCP server.
"system provided" or "shipped" or what have you for the vendor provided DT, which previously would have been in NOR, for fdt_addr when you also have fdt_addr_r. And I believe the answer to the second question is that yes, the shipped or system provided DTB would end up in fdt_addr, so long as whatever "grab the provided default DT" puts it there.
I understand that you are trying to give the old names a new definition that would magically cover the suggested use, but this is extremely thin ice. I recommend not to try that.
Well, lets see if we can't convince you around. Or get some better names to use for these use cases.
Dear Tom,
In message 20131206221307.GD420@bill-the-cat you wrote:
I think it's actually OK to omit the "_r" in NOR-less systems. The number of devices with actual NOT flash is decreasing, and if you can be sure that there is no such memory device available, then it is just overhead to always carry the "_r" suffice around, knowing all the time that there will never be any other option than RAM to store that data.
Right. So the rule is "fdt_addr means the [shipped] DT in NOR, if present. fdt_addr_r means the [shipped] DT in system RAM."
No. NAK. Delete this "[shipped]" stuff here. This is some new interpretation which you are trying to sneak in here, but there has never been any such notion before. It's just an address, and we don't care where the actual data came from or who put it there.
Well, "fdt_addr" still means the shipped DT and "fdt_addr_r" still means a DT loaded into system RAM. The only change is that fdt_addr may also be a system RAM address.
Stop. There is no such thing as a "shipped DT".
Um... you enter completely new terms here - "system provided" and "user provided". I cannot see how a "user provided" DTB in NOR flash would fit in such a concept, nor how this would work on systems with NOR if a "system provided" DTB gets loaded into RAM from a DHCP server.
"system provided" or "shipped" or what have you for the vendor provided DT, which previously would have been in NOR, for fdt_addr when you also
NAK. We have never been using any such terms before. You are trying to insert completely new meaning here, and I do not agree with such interpretation. A DT is a DT is a DT, no matter who provided it or where it is coming from or who installed it where.
Well, lets see if we can't convince you around. Or get some better names to use for these use cases.
No chance. This is the first time ever such terms come up, and we've been using DTs for a long, long time before.
Best regards,
Wolfgang Denk
Hi Wolfgang,
El Fri, 06 Dec 2013 21:37:59 +0100 Wolfgang Denk wd@denx.de escribió:
Dear Tom,
In message 20131206162854.GX420@bill-the-cat you wrote:
But this is crap. The meaning of these variables has been wel-defined for a long, long time. "fdt_addr" is the FDT address in NOR flash (or similar memory except system RAM); "fdt_addr_r" is the FDT address when loaded to system RAM (hence the "_r" in the variable name).
It's a well defined and widely ignored in ARM convention then. We've got lots of 'fdt_addr' meaning RAM and no 'fdt_addr_r' and then in both ARM and PowerPC 'fdtaddr' being presumably RAM.
I think it's actually OK to omit the "_r" in NOR-less systems. The number of devices with actual NOT flash is decreasing, and if you can be sure that there is no such memory device available, then it is just overhead to always carry the "_r" suffice around, knowing all the time that there will never be any other option than RAM to store that data.
I do not complain if such systems use a simplified setup without the "_r".
What I don't like to see is to have "fdt_addr_r" and "fdt_addr" used with a new, totally different meaning.
I don't know where the spelling "fdtaddr" is coming from; I would consider it one of the many "non-standard" variants (assuming we agree that there is actually something like a "standard"). Note that there is no "fdtaddr_r" anywhere.
fdtaddr is highly prevalent in the configs
grep -r fdtaddr include/configs/|wc -l 390
more so than fdt_addr
grep -r fdt_addr include/configs/|wc -l 278
those counts are in my git tree with the proposed patches applied that converted soem systems from fdtaddr to fdt_addr. One of the problems right or wrong is that u-boot is seen as not having any kind of standard, which is what I am trying to fix, at least for use in the generic distro world where we need to have an standardised documented interface.
I would say that 'fdt_addr' being the system provided DT, even when not found on memory-mapped flash and 'fdt_addr_r' being the user provided one is a logical extension.
Um... you enter completely new terms here - "system provided" and "user provided". I cannot see how a "user provided" DTB in NOR flash would fit in such a concept, nor how this would work on systems with NOR if a "system provided" DTB gets loaded into RAM from a DHCP server.
I understand that you are trying to give the old names a new definition that would magically cover the suggested use, but this is extremely thin ice. I recommend not to try that.
greping through the doc directory of git I am unable to find any reference to this convention you speak of.
The only references i found was in README.falcon README.pxe and README.commands.spl based on your description it would mean falcon mode could not be implemented on any system not having nand.
cmd_pxe.c clearly specifies what it thinks the addresses are for
fdt_addr_r - location in RAM at which 'pxe boot' will store the fdt blob it retrieves from tftp. The retrieval is possible if 'fdt' label is defined in pxe file and 'fdt_addr_r' is set. If retrieval is possible, 'fdt_addr_r' will be passed to bootm command to boot the kernel.
fdt_addr - the location of a fdt blob. 'fdt_addr' will be passed to bootm command if it is set and 'fdt_addr_r' is not passed to bootm command.
Which i read as fdt_addr is a system provided dtb, and fdt_addr_r is a user provided one. there is no mention of where exactly they come from.
when pxe booting or installing on an arm system we do not want to put a fdt line in the config file, because we do not want to have to have the knowledge in the installer to work out what dtb file we want. that really is a job for u-boot to provide, but we do have the option to if its needed for some reason.
I was purely working with what is in front of me.
Dennis
Dear Dennis,
In message 20131206164420.36e5f593@adria.ausil.us you wrote:
fdtaddr is highly prevalent in the configs
Yes, it appears some vendors favoured this name. I'm temptted to add that these very vendors often tend to define thier own ways without caring what the community has been using before ;-)
That doesn't make it any better, though...
those counts are in my git tree with the proposed patches applied that converted soem systems from fdtaddr to fdt_addr. One of the problems right or wrong is that u-boot is seen as not having any kind of standard, which is what I am trying to fix, at least for use in the generic distro world where we need to have an standardised documented interface.
Even if you feel differntly, I do appreciate your efforts. But I'd also like to see things done in a consistent way. And the whole idea of using the "_r" names was to show clearly which of the addresses are supposed to be in system RAM (with "_r"), and which are not (without).
This parallels function names like board_init_f() ["_f" standing for "running from [NOR] flash"] and board_init_r() ["_r" = running from system RAM].
greping through the doc directory of git I am unable to find any reference to this convention you speak of.
Agreed. Noone wrote a document about this, yet.
The only references i found was in README.falcon README.pxe and README.commands.spl based on your description it would mean falcon mode could not be implemented on any system not having nand.
I lost you here. What makes you think so?
cmd_pxe.c clearly specifies what it thinks the addresses are for
Yes, it does. But this is confused or incorrect, misusing existing names for other purposes. This should be fixed.
Which i read as fdt_addr is a system provided dtb, and fdt_addr_r is a user provided one. there is no mention of where exactly they come from.
Stop. There has never been any such notion like "system provided" or "user provided" before. You cannot just put new meanings over existing terms. Actually, to me such terms don't even make much sense.
Best regards,
Wolfgang Denk
Hi Wolfgang,
El Sat, 07 Dec 2013 00:16:16 +0100 Wolfgang Denk wd@denx.de escribió:
Dear Dennis,
In message 20131206164420.36e5f593@adria.ausil.us you wrote:
fdtaddr is highly prevalent in the configs
Yes, it appears some vendors favoured this name. I'm temptted to add that these very vendors often tend to define thier own ways without caring what the community has been using before ;-)
That doesn't make it any better, though...
Not saying that it does, just pointing out the inconsistency in the tree today. something we likely should fix.
those counts are in my git tree with the proposed patches applied that converted soem systems from fdtaddr to fdt_addr. One of the problems right or wrong is that u-boot is seen as not having any kind of standard, which is what I am trying to fix, at least for use in the generic distro world where we need to have an standardised documented interface.
Even if you feel differntly, I do appreciate your efforts. But I'd also like to see things done in a consistent way. And the whole idea of using the "_r" names was to show clearly which of the addresses are supposed to be in system RAM (with "_r"), and which are not (without).
Thankyou I'm trying to be consistent in the interface between u-boot and the operating system.
This parallels function names like board_init_f() ["_f" standing for "running from [NOR] flash"] and board_init_r() ["_r" = running from system RAM].
which makes some sense in the code, but the config is defining the interface to kernel/userland and needs to be consistent regardless of what is underneath
greping through the doc directory of git I am unable to find any reference to this convention you speak of.
Agreed. Noone wrote a document about this, yet.
The only references i found was in README.falcon README.pxe and README.commands.spl based on your description it would mean falcon mode could not be implemented on any system not having nand.
I lost you here. What makes you think so?
Usage:
spl export <img=atags|fdt> [kernel_addr] [initrd_addr] [fdt_addr ]
which to me based on what you said means everything needs to be in nand
cmd_pxe.c clearly specifies what it thinks the addresses are for
Yes, it does. But this is confused or incorrect, misusing existing names for other purposes. This should be fixed.
I actually think it is spot on and is how it should be.
Which i read as fdt_addr is a system provided dtb, and fdt_addr_r is a user provided one. there is no mention of where exactly they come from.
Stop. There has never been any such notion like "system provided" or "user provided" before. You cannot just put new meanings over existing terms. Actually, to me such terms don't even make much sense.
from u-boot itself there is not this notion. But from a Distro perspective its always there and is a really big thing. It really is important. in 99% of cases we want to have u-boot use a provided dtb without the need to say so and to have it work.
Dennis
Dennis
Dear Dennis,
In message 20131206180955.32ba9f0b@adria.ausil.us you wrote:
Yes, it appears some vendors favoured this name. I'm temptted to add that these very vendors often tend to define thier own ways without caring what the community has been using before ;-)
That doesn't make it any better, though...
Not saying that it does, just pointing out the inconsistency in the tree today. something we likely should fix.
Agreed, it would be nice, but it might turn out to be difficult. I think a large number of such systems is alreay out in the field, and introducing such chnges to the user interface is often just impossible or inacceptable.
We should keep in mind that - until not so long ago - no attempts have been made to try to standardize these things, so we have now the results of uncontrolled growth over 13 years or so. Even though there are a number of configuratios some of us would recommend as archetypes, but again there are several "schools" of these, each with their own approaches and names.
Even if you feel differntly, I do appreciate your efforts. But I'd also like to see things done in a consistent way. And the whole idea of using the "_r" names was to show clearly which of the addresses are supposed to be in system RAM (with "_r"), and which are not (without).
...
which makes some sense in the code, but the config is defining the interface to kernel/userland and needs to be consistent regardless of what is underneath
This is no contradiction, right?
The only references i found was in README.falcon README.pxe and README.commands.spl based on your description it would mean falcon mode could not be implemented on any system not having nand.
I lost you here. What makes you think so?
Usage:
spl export <img=atags|fdt> [kernel_addr] [initrd_addr] [fdt_addr ]
which to me based on what you said means everything needs to be in nand
No. First, SPL booting is not restricted to NAND. We use this also (at least on some systems) to boot from SDCard, and even to boot from NOR flash.
Second, the "spl export" step is a pretty specific thing, that does not really reflect the normal steps of booting a system - it makes preparations to do so, but this is a different task.
cmd_pxe.c clearly specifies what it thinks the addresses are for
Yes, it does. But this is confused or incorrect, misusing existing names for other purposes. This should be fixed.
I actually think it is spot on and is how it should be.
I continue to disagree. The use of "fdt_addr" and "fdt_addr_r" in the same context should stick with exising practice, and as I explained before, "fdt_addr_r" then refers to an address in ROM (usually NOR flash).
Stop. There has never been any such notion like "system provided" or "user provided" before. You cannot just put new meanings over existing terms. Actually, to me such terms don't even make much sense.
from u-boot itself there is not this notion. But from a Distro perspective its always there and is a really big thing. It really is important. in 99% of cases we want to have u-boot use a provided dtb without the need to say so and to have it work.
When introducing new terms into a new environment, you should make sure to actually define the meaning of these terms, so everybody speaks the same language. Actually you would pprobably have to start with defining "system" (I feel you might actually mean "distro" instead?) and "user". There is a number of situations, which may (or may not) result in differing usage modes. In addition to "user" and "distro" terms like "vendor" (or "manufacturer") or "developer" might play a role here - each will probably result in specific expectations and experiences about "good practices".
So please, define your terms, and as exact as possibvle, so we avoid confusion when discussing them.
Best regards,
Wolfgang Denk
Signed-off-by: Dennis Gilmore dennis@ausil.us --- include/configs/omap4_common.h | 30 +++++++++++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h index ea56eeb..fcf934d 100644 --- a/include/configs/omap4_common.h +++ b/include/configs/omap4_common.h @@ -55,6 +55,9 @@
#include <configs/ti_armv7_common.h>
+/* enable generic distro config */ +#define DISTRO_DEFAULTS 1 + /* * Hardware drivers */ @@ -88,9 +91,13 @@ */ #define CONFIG_EXTRA_ENV_SETTINGS \ "loadaddr=0x82000000\0" \ + "pxefile_addr_r=0x82000000\0" \ + "kernel_addr_r=0x84000000\0" \ + "ramdisk_addr_r=0x90000000\0" \ + "fdt_addr_r=0x83000000\0" \ "console=ttyO2,115200n8\0" \ "fdt_high=0xffffffff\0" \ - "fdtaddr=0x80f80000\0" \ + "fdt_addr=0x80f80000\0" \ "fdtfile=undefined\0" \ "bootpart=0:2\0" \ "bootdir=/boot\0" \ @@ -104,6 +111,22 @@ "vram=${vram} " \ "root=${mmcroot} " \ "rootfstype=${mmcrootfstype}\0" \ + "bootcmd_setup=mmc rescan\0" \ + "bootcmd_pxe=setenv bootfile "" ;dhcp; pxe get; pxe boot\0" \ + "bootcmd_disk_scr=ext2load ${boot_ifc} ${bootdevice} ${scr_addr_r} boot.scr && source ${scr_addr_r}\0" \ + "bootcmd_disk_sysboot1=setenv bootfile /boot/extlinux/extlinux.conf; sysboot ${boot_ifc} ${bootdevice} ext2\0" \ + "bootcmd_disk_sysboot2=setenv bootfile /extlinux/extlinux.conf; sysboot ${boot_ifc} ${bootdevice} ext2\0" \ + "bootcmd_disk_uenv=ext2load ${boot_ifc} ${bootdevice} ${uenv_addr_r} uEnv.txt; env import -t ${uenv_addr_r} ${filesize}; run bootcmd_uenv\0" \ + "bootcmd_disk_kernel=ext2load ${boot_ifc} ${bootdevice} ${kernel_addr_r} vmlinuz && ext2load ${boot_ifc} ${bootdevice} ${ramdisk_addr_r} initrd.img && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr}\0" \ + "bootcmd_disk=run bootcmd_disk_sysboot1; run bootcmd_disk_sysboot2; run bootcmd_disk_uenv; run bootcmd_disk_scr; run bootcmd_disk_kernel\0" \ + "bootcmd_mmc=setenv boot_ifc mmc; mmc rescan && run bootcmd_disk\0" \ + "bootcmd_default=run bootcmd_mmc; run bootcmd_pxe\0" \ + "localcmd=run bootcmd_mmc\0" \ + "bootdevice=0\0" \ + "bootargs=console=${console} root=LABEL=rootfs\0" \ + "bootdelay=2\0" \ + "bootretry=90\0" \ + "netretry=once\0" \ "loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \ "bootscript=echo Running bootscript from mmc${mmcdev} ...; " \ "source ${loadaddr}\0" \ @@ -113,7 +136,7 @@ "loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \ "mmcboot=echo Booting from mmc${mmcdev} ...; " \ "run mmcargs; " \ - "bootz ${loadaddr} - ${fdtaddr}\0" \ + "bootz ${loadaddr} - ${fdt_addr}\0" \ "findfdt="\ "if test $board_name = sdp4430; then " \ "setenv fdtfile omap4-sdp.dtb; fi; " \ @@ -125,12 +148,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} ${bootdir}/${fdtfile}\0" \
#define CONFIG_BOOTCOMMAND \ "run findfdt; " \ "mmc dev ${mmcdev}; if mmc rescan; then " \ "echo SD/MMC found on device ${mmcdev};" \ + "run bootcmd_default; " \ "if run loadbootscript; then " \ "run bootscript; " \ "else " \
Signed-off-by: Dennis Gilmore dennis@ausil.us --- include/configs/omap3_beagle.h | 30 +++++++++++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 9eab190..fe39540 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -130,6 +130,9 @@ /* commands to include */ #include <config_cmd_default.h>
+/* enable generic distro config */ +#define DISTRO_DEFAULTS 1 + #define CONFIG_CMD_ASKENV
#define CONFIG_CMD_CACHE @@ -193,9 +196,13 @@
#define CONFIG_EXTRA_ENV_SETTINGS \ "loadaddr=0x80200000\0" \ + "pxefile_addr_r=0x82000000\0" \ + "kernel_addr_r=0x84000000\0" \ + "ramdisk_addr_r=0x90000000\0" \ + "fdt_addr_r=0x83000000\0" \ "rdaddr=0x81000000\0" \ "fdt_high=0xffffffff\0" \ - "fdtaddr=0x80f80000\0" \ + "fdt_addr=0x80f80000\0" \ "usbtty=cdc_acm\0" \ "bootfile=uImage\0" \ "ramdisk=ramdisk.gz\0" \ @@ -247,6 +254,22 @@ "setenv fdtfile omap3-beagle-xm.dtb; fi; " \ "if test $fdtfile = undefined; then " \ "echo WARNING: Could not determine device tree to use; fi; \0" \ + "bootcmd_setup=mmc rescan\0" \ + "bootcmd_pxe=setenv bootfile "" ;dhcp; pxe get; pxe boot\0" \ + "bootcmd_disk_scr=ext2load ${boot_ifc} ${bootdevice} ${scr_addr_r} boot.scr && source ${scr_addr_r}\0" \ + "bootcmd_disk_sysboot1=setenv bootfile /boot/extlinux/extlinux.conf; sysboot ${boot_ifc} ${bootdevice} ext2\0" \ + "bootcmd_disk_sysboot2=setenv bootfile /extlinux/extlinux.conf; sysboot ${boot_ifc} ${bootdevice} ext2\0" \ + "bootcmd_disk_uenv=ext2load ${boot_ifc} ${bootdevice} ${uenv_addr_r} uEnv.txt; env import -t ${uenv_addr_r} ${filesize}; run bootcmd_uenv\0" \ + "bootcmd_disk_kernel=ext2load ${boot_ifc} ${bootdevice} ${kernel_addr_r} vmlinuz && ext2load ${boot_ifc} ${bootdevice} ${ramdisk_addr_r} initrd.img && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr}\0" \ + "bootcmd_disk=run bootcmd_disk_sysboot1; run bootcmd_disk_sysboot2; run bootcmd_disk_uenv; run bootcmd_disk_scr; run bootcmd_disk_kernel\0" \ + "bootcmd_mmc=setenv boot_ifc mmc; mmc rescan && run bootcmd_disk\0" \ + "bootcmd_default=run bootcmd_mmc; run bootcmd_pxe\0" \ + "localcmd=run bootcmd_mmc\0" \ + "bootdevice=0\0" \ + "bootargs=console=${console} root=LABEL=rootfs\0" \ + "bootdelay=2\0" \ + "bootretry=90\0" \ + "netretry=once\0" \ "bootenv=uEnv.txt\0" \ "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \ "importbootenv=echo Importing environment from mmc ...; " \ @@ -262,13 +285,13 @@ "rootfstype=${ramrootfstype}\0" \ "loadramdisk=load mmc ${bootpart} ${rdaddr} ${bootdir}/${ramdisk}\0" \ "loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \ - "loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \ + "loadfdt=load mmc ${bootpart} ${fdt_addr} ${bootdir}/${fdtfile}\0" \ "mmcboot=echo Booting from mmc ...; " \ "run mmcargs; " \ "bootm ${loadaddr}\0" \ "mmcbootz=echo Booting with DT from mmc${mmcdev} ...; " \ "run mmcargs; " \ - "bootz ${loadaddr} - ${fdtaddr}\0" \ + "bootz ${loadaddr} - ${fdt_addr}\0" \ "nandboot=echo Booting from nand ...; " \ "run nandargs; " \ "nand read ${loadaddr} 280000 400000; " \ @@ -284,6 +307,7 @@ #define CONFIG_BOOTCOMMAND \ "run findfdt; " \ "mmc dev ${mmcdev}; if mmc rescan; then " \ + "run bootcmd_default; " \ "if run userbutton; then " \ "setenv bootenv uEnv.txt;" \ "else " \
Signed-off-by: Dennis Gilmore dennis@ausil.us --- include/configs/am335x_evm.h | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index d75df92..86623b1 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -56,11 +56,14 @@
#ifndef CONFIG_SPL_BUILD #define CONFIG_EXTRA_ENV_SETTINGS \ - "loadaddr=0x80200000\0" \ - "fdtaddr=0x80F80000\0" \ + "loadaddr=0x81000000\0" \ + "pxefile_addr_r=0x81300000\0" \ + "kernel_addr_r=0x81400000\0" \ + "ramdisk_addr_r=0x83400000\0" \ + "fdt_addr_r=0x81100000\0" \ + "fdt_addr=0x81200000\0" \ "fdt_high=0xffffffff\0" \ "boot_fdt=try\0" \ - "rdaddr=0x81000000\0" \ "bootpart=0:2\0" \ "bootdir=/boot\0" \ "bootfile=zImage\0" \ @@ -76,7 +79,7 @@ "nfsopts=nolock\0" \ "static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}" \ "::off\0" \ - "ramroot=/dev/ram0 rw ramdisk_size=65536 initrd=${rdaddr},64M\0" \ + "ramroot=/dev/ram0 rw ramdisk_size=65536 initrd=${ramdisk_addr_r},64M\0" \ "ramrootfstype=ext2\0" \ "mmcargs=setenv bootargs console=${console} " \ "${optargs} " \ @@ -105,13 +108,13 @@ "${optargs} " \ "root=${ramroot} " \ "rootfstype=${ramrootfstype}\0" \ - "loadramdisk=load mmc ${mmcdev} ${rdaddr} ramdisk.gz\0" \ + "loadramdisk=load mmc ${mmcdev} ${ramdisk_addr_r} ramdisk.gz\0" \ "loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \ - "loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \ + "loadfdt=load mmc ${bootpart} ${fdt_addr_r} ${bootdir}/${fdtfile}\0" \ "mmcloados=run mmcargs; " \ "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \ "if run loadfdt; then " \ - "bootz ${loadaddr} - ${fdtaddr}; " \ + "bootz ${loadaddr} - ${fdt_addr_r}; " \ "else " \ "if test ${boot_fdt} = try; then " \ "bootz; " \ @@ -146,12 +149,12 @@ "setenv autoload no; " \ "dhcp; " \ "tftp ${loadaddr} ${bootfile}; " \ - "tftp ${fdtaddr} ${fdtfile}; " \ + "tftp ${fdt_addr_r} ${fdtfile}; " \ "run netargs; " \ - "bootz ${loadaddr} - ${fdtaddr}\0" \ + "bootz ${loadaddr} - ${fdt_addr_r}\0" \ "ramboot=echo Booting from ramdisk ...; " \ "run ramargs; " \ - "bootz ${loadaddr} ${rdaddr} ${fdtaddr}\0" \ + "bootz ${loadaddr} ${ramdisk_addr_r} ${fdt_addr_r}\0" \ "findfdt="\ "if test $board_name = A335BONE; then " \ "setenv fdtfile am335x-bone.dtb; fi; " \
Signed-off-by: Dennis Gilmore dennis@ausil.us
include/configs/am335x_evm.h | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index d75df92..86623b1 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -56,11 +56,14 @@
#ifndef CONFIG_SPL_BUILD #define CONFIG_EXTRA_ENV_SETTINGS \
- "loadaddr=0x80200000\0" \
- "fdtaddr=0x80F80000\0" \
- "loadaddr=0x81000000\0" \
- "pxefile_addr_r=0x81300000\0" \
- "kernel_addr_r=0x81400000\0" \
- "ramdisk_addr_r=0x83400000\0" \
- "fdt_addr_r=0x81100000\0" \
- "fdt_addr=0x81200000\0" \ "fdt_high=0xffffffff\0" \ "boot_fdt=try\0" \
- "rdaddr=0x81000000\0" \ "bootpart=0:2\0" \ "bootdir=/boot\0" \ "bootfile=zImage\0" \
@@ -76,7 +79,7 @@ "nfsopts=nolock\0" \ "static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}" \ "::off\0" \
- "ramroot=/dev/ram0 rw ramdisk_size=65536
initrd=${rdaddr},64M\0" \
- "ramroot=/dev/ram0 rw ramdisk_size=65536
initrd=${ramdisk_addr_r},64M\0" \ "ramrootfstype=ext2\0" \ "mmcargs=setenv bootargs console=${console} " \ "${optargs} " \ @@ -105,13 +108,13 @@ "${optargs} " \ "root=${ramroot} " \ "rootfstype=${ramrootfstype}\0" \
- "loadramdisk=load mmc ${mmcdev} ${rdaddr} ramdisk.gz\0" \
- "loadramdisk=load mmc ${mmcdev} ${ramdisk_addr_r}
ramdisk.gz\0" \ "loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
- "loadfdt=load mmc ${bootpart} ${fdtaddr}
${bootdir}/${fdtfile}\0" \
- "loadfdt=load mmc ${bootpart} ${fdt_addr_r}
${bootdir}/${fdtfile}\0" \ "mmcloados=run mmcargs; " \ "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \ "if run loadfdt; then " \
"bootz ${loadaddr} - ${fdtaddr}; " \
"bootz ${loadaddr} - ${fdt_addr_r};" \ "else " \ "if test ${boot_fdt} = try; then " \ "bootz; " \ @@ -146,12 +149,12 @@ "setenv autoload no; " \ "dhcp; " \ "tftp ${loadaddr} ${bootfile}; " \
"tftp ${fdtaddr} ${fdtfile}; " \
"tftp ${fdt_addr_r} ${fdtfile}; " \
"bootz ${loadaddr} - ${fdtaddr}\0" \
"bootz ${loadaddr} - ${fdt_addr_r}\0" \
"bootz ${loadaddr} ${rdaddr} ${fdtaddr}\0" \
"bootz ${loadaddr} ${ramdisk_addr_r}${fdt_addr_r}\0" \ "findfdt="\ "if test $board_name = A335BONE; then " \ "setenv fdtfile am335x-bone.dtb; fi; " \
we are not enabling extlinux here right now because of how we have to do partitioning. though it is a solvable problem. Because the MLO only reads from fat we have a 20M fat partition that holds MLO u-boot.img and a uEnv.txt file. what I really want to do is teach the MLO to load u-boot.img from either ext2 or fat and use raw space for the MLO so then we can just go to standard partitioning.
Dennis
On Thu, Dec 05, 2013 at 08:18:10PM -0600, Dennis Gilmore wrote:
As a followup to http://lists.denx.de/pipermail/u-boot/2013-August/160080.html ive put together what i Think is a reasonable starting point for defining a unified set of features and options.
There are some things that really need some more work yet. mostly to do with austomatically loading of the dtb. All of these patches are currently enabled in Fedora's u-boot builds.
the wandboard in particular has received a lot of testing using sysboot command to load a extlinux.conf file. which did pick up bugs in teh pxe.c code early on. I would appreciate some feedback from a wider audience as we move to making this be a default configuration.
I think you've got the breakdown in relative locations wrong. And, per the email I sent out after this, I think we should start using fdt_high at least for its intended purpose, moving the DT out of the way of what we know about.
The breakdown I see in your series is (or similar):
- "fdt_addr_r=0x81100000\0" \
- "fdt_addr=0x81200000\0" \
- "pxefile_addr_r=0x81300000\0" \
- "kernel_addr_r=0x81400000\0" \
- "ramdisk_addr_r=0x83400000\0" \
Now the issues we have to deal with are: 1) zImage running into ramdisk. There's 32MiB here, so that's unlikely, hopefully, for a while at least. 2) When the zImage runs, it will unpack the kernel to top of memory and then BSS follows. You've only left ~17MiB for that, and that's iffy. When you start enabling function tracing and some other stuff, that's close, on a single platform image. I bet a multi-platform runs into the DT.
#2 is why the defaults on these platforms place the DT in memory after the kernel image, before the ramdisk. I think we can get a better situation out of this by saying the u-boot used parts (pxefile) are as low as we can (start of memory), throw in the reasonable size, then place the kernel, 32MiB gap, 1MiB gap for each DT (which I really hope is more than enough..), then the ramdisk.
This just leaves the worry of 32MiB for a kernel + BSS being an uncaught conflict. One could stop worrying about this, largely I think, if we set fdt_high to memory base + 512MiB and then do some corner case testing to make sure that we do not relocate on top of the end of a large ramdisk, and that the only cases which simply do not work are the cases where you flat out do not have enough memory for what you're trying to load (giant kernel + giant ramdisk on a nowadays-small 128MiB DDR system for example).
participants (4)
-
Dennis Gilmore -
Robert Nelson -
Tom Rini -
Wolfgang Denk