[U-Boot] [RFC] implementation of generic distro configs

[U-Boot] [RFC] implementation of generic distro configs

[Dennis Gilmore]

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

[U-Boot] [PATCH 1/5] add a generic set of configs to enable Distros to more easier support u-boot based systems

[Dennis Gilmore]

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 */
-- 
1.8.4.2

[U-Boot] [PATCH 1/5] add a generic set of configs to enable Distros to more easier support u-boot based systems

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Philosophy:  A route of many roads leading from nowhere to nothing.
- Ambrose Bierce

[U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Dennis Gilmore]

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

[U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Robert Nelson]

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,

-- 
Robert Nelson
http://www.rcn-ee.com/

[U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Dennis Gilmore]

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

[U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Dennis Gilmore]

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

[U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Robert Nelson]

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

-- 
Robert Nelson
http://www.rcn-ee.com/

[U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Robert Nelson]

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,

-- 
Robert Nelson
http://www.rcn-ee.com/

[U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"There are three principal ways to lose money: wine, women,  and  en-
gineers.  While  the first two are more pleasant, the third is by far
the more certain."                      -- Baron Rothschild, ca. 1800

[U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Dennis Gilmore]

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

[U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
How does a project get to be a year late?      ... One day at a time.

[U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Tom Rini]

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.

-- 
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/20131206/55eae480/attachment.pgp>

[U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The important thing about being a leader is not being right or wrong,
but being *certain*.                    - Terry Pratchett, _Truckers_

[U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Tom Rini]

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.

-- 
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/20131206/3fcd675d/attachment.pgp>

[U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The use of COBOL cripples the mind; its teaching  should,  therefore,
be regarded as a criminal offense.                   - E. W. Dijkstra

[U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Dennis Gilmore]

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

[U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
My play was a complete success.  The audience was a failure.

[U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Dennis Gilmore]

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

[U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Mistakes are often the stepping stones to utter failure.

[U-Boot] [PATCH 3/5] port omap4 based devices to use generic distro configs

[Dennis Gilmore]

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 " \
-- 
1.8.4.2

[U-Boot] [PATCH 4/5] port beagleboard to use generic distro configs

[Dennis Gilmore]

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 " \
-- 
1.8.4.2

[U-Boot] [PATCH 5/5] port beaglebones to use generic distro configs

[Dennis Gilmore]

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; " \
-- 
1.8.4.2

[U-Boot] [PATCH 5/5] port beaglebones to use generic distro configs

[Dennis Gilmore]

> 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; " \

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

[U-Boot] [RFC] implementation of generic distro configs

[Tom Rini]

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

-- 
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/20131206/1de73ded/attachment.pgp>