| Message ID | 1392659798-1665-2-git-send-email-dennis@ausil.us |
|---|---|
| State | RFC |
| Delegated to: | Tom Rini |
| Headers | show |
On Mon, Feb 17, 2014 at 11:56:36AM -0600, Dennis Gilmore wrote: > Signed-off-by: Dennis Gilmore <dennis@ausil.us> [snip] > + "if ${usb_need_init}; then " \ > + "set usb_need_init false; " \ > + "usb start 0; " \ Checking common/cmd_usb.c, 'start' doesn't take arguments. > +#ifdef CONFIG_CMD_SATA > +#define BOOTCMDS_SATA \ > + "sata_boot=" \ > + "setenv devtype sata; " \ > + "if sata dev ${devnum}; then " \ > + "run scan_boot; " \ > + "fi\0" \ > + \ > + "bootcmd_sata0=setenv devnum 0; run sata_boot;\0" > + "bootcmd_sata1=setenv devnum 1; run sata_boot;\0" > +#define BOOT_TARGETS_USB "sata0 sata1" Typo, s/USB/SATA/ > +#ifdef CONFIG_CMD_DHCP > +#define BOOTCMDS_DHCP \ > + "bootcmd_dhcp=" \ > + BOOTCMD_INIT_USB \ Why BOOTCMD_INIT_USB here? For USB based networking? If so, add some comments please. > + "if dhcp ${scriptaddr} boot.scr.uimg; then "\ > + "source ${scriptaddr}; " \ > + "fi\0" This relies on autoload being true, so we should set that.
On Wed, 19 Feb 2014 08:42:57 -0500 Tom Rini <trini@ti.com> wrote: > On Mon, Feb 17, 2014 at 11:56:36AM -0600, Dennis Gilmore wrote: > > > Signed-off-by: Dennis Gilmore <dennis@ausil.us> > [snip] > > + "if ${usb_need_init}; then " \ > > + "set usb_need_init false; " \ > > + "usb start 0; " \ > > Checking common/cmd_usb.c, 'start' doesn't take arguments. Copied from tegra-common-post.h as is, will fix it up > > +#ifdef CONFIG_CMD_SATA > > +#define BOOTCMDS_SATA \ > > + "sata_boot=" \ > > + "setenv devtype sata; " \ > > + "if sata dev ${devnum}; then " \ > > + "run scan_boot; " \ > > + "fi\0" \ > > + \ > > + "bootcmd_sata0=setenv devnum 0; run sata_boot;\0" > > + "bootcmd_sata1=setenv devnum 1; run sata_boot;\0" > > +#define BOOT_TARGETS_USB "sata0 sata1" > > Typo, s/USB/SATA/ will fix > > +#ifdef CONFIG_CMD_DHCP > > +#define BOOTCMDS_DHCP \ > > + "bootcmd_dhcp=" \ > > + BOOTCMD_INIT_USB \ > > Why BOOTCMD_INIT_USB here? For USB based networking? If so, add some > comments please. It was Copied from tegra-common-post.h im assuming that it to support booting from a usb attached nic > > + "if dhcp ${scriptaddr} boot.scr.uimg; then "\ > > + "source ${scriptaddr}; " \ > > + "fi\0" > > This relies on autoload being true, so we should set that. okay, will fix it up. Thanks Dennis
On Monday, February 17, 2014 at 06:56:36 PM, Dennis Gilmore wrote: > Signed-off-by: Dennis Gilmore <dennis@ausil.us> > --- > include/config_distro_bootcmd.h | 172 > ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 172 insertions(+) > create mode 100644 include/config_distro_bootcmd.h > > diff --git a/include/config_distro_bootcmd.h > b/include/config_distro_bootcmd.h new file mode 100644 > index 0000000..d32dc12 > --- /dev/null > +++ b/include/config_distro_bootcmd.h > @@ -0,0 +1,172 @@ > +/* > + * (C) Copyright 2014 > + * NVIDIA Corporation <www.nvidia.com> > + * > + * Copyright 2014 Red Hat, Inc. > + * > + * SPDX-License-Identifier: GPL-2.0+ > + */ > + > +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H > +#define _CONFIG_CMD_DISTRO_BOOTCMD_H > + > + > +#ifdef CONFIG_CMD_MMC > +#define BOOTCMDS_MMC \ You might want to #undef all this temporary stuff so it's not propagated into the U-Boot further. Best regards, Marek Vasut
On 02/19/2014 08:54 AM, Marek Vasut wrote: > On Monday, February 17, 2014 at 06:56:36 PM, Dennis Gilmore wrote: >> Signed-off-by: Dennis Gilmore <dennis@ausil.us> >> --- >> include/config_distro_bootcmd.h | 172 >> ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 172 insertions(+) >> create mode 100644 include/config_distro_bootcmd.h >> >> diff --git a/include/config_distro_bootcmd.h >> b/include/config_distro_bootcmd.h new file mode 100644 >> index 0000000..d32dc12 >> --- /dev/null >> +++ b/include/config_distro_bootcmd.h >> @@ -0,0 +1,172 @@ >> +/* >> + * (C) Copyright 2014 >> + * NVIDIA Corporation <www.nvidia.com> >> + * >> + * Copyright 2014 Red Hat, Inc. >> + * >> + * SPDX-License-Identifier: GPL-2.0+ >> + */ >> + >> +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H >> +#define _CONFIG_CMD_DISTRO_BOOTCMD_H >> + >> + >> +#ifdef CONFIG_CMD_MMC >> +#define BOOTCMDS_MMC \ > > You might want to #undef all this temporary stuff so it's not propagated into > the U-Boot further. I don't understand. What temporary stuff are you referring to?
On Wednesday, February 19, 2014 at 06:28:39 PM, Stephen Warren wrote: > On 02/19/2014 08:54 AM, Marek Vasut wrote: > > On Monday, February 17, 2014 at 06:56:36 PM, Dennis Gilmore wrote: > >> Signed-off-by: Dennis Gilmore <dennis@ausil.us> > >> --- > >> > >> include/config_distro_bootcmd.h | 172 > >> > >> ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 172 > >> insertions(+) > >> > >> create mode 100644 include/config_distro_bootcmd.h > >> > >> diff --git a/include/config_distro_bootcmd.h > >> b/include/config_distro_bootcmd.h new file mode 100644 > >> index 0000000..d32dc12 > >> --- /dev/null > >> +++ b/include/config_distro_bootcmd.h > >> @@ -0,0 +1,172 @@ > >> +/* > >> + * (C) Copyright 2014 > >> + * NVIDIA Corporation <www.nvidia.com> > >> + * > >> + * Copyright 2014 Red Hat, Inc. > >> + * > >> + * SPDX-License-Identifier: GPL-2.0+ > >> + */ > >> + > >> +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H > >> +#define _CONFIG_CMD_DISTRO_BOOTCMD_H > >> + > >> + > >> +#ifdef CONFIG_CMD_MMC > >> +#define BOOTCMDS_MMC \ > > > > You might want to #undef all this temporary stuff so it's not propagated > > into the U-Boot further. > > I don't understand. What temporary stuff are you referring to? BOOTCMDS_MMC for example. This certainly doesn't need to propagate into the rest of the U-Boot build, does it ? Best regards, Marek Vasut
On 02/17/2014 10:56 AM, Dennis Gilmore wrote: > Signed-off-by: Dennis Gilmore <dennis@ausil.us> Patch description? > diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h > +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H > +#define _CONFIG_CMD_DISTRO_BOOTCMD_H > + > + Is there a need for 2 blank lines there? > +#define BOOTCMDS_COMMON \ > + "rootpart=1\0" \ We should really stop hard-coding that. I meant to (but evidently never got around to) re-write the commands so that they could automatically determine which partition to use, based on the MBR bootable flag or GPT partition flags. Still, we can probably make that enhancement separately later. > +#define BOOT_TARGETS_MMC "mmc1 mmc0" We really ought to make the order of multiple MMC devices in BOOT_TARGETS configurable. For example, we may have 2 boards that both want to boot from SD card if present, else fall back to internal eMMC, yet one has mmc0=eMMC,mmc1=SD, and the other mmc0=SD,mmc1=eMMC. On Tegra, we're just lucky that hasn't been an issue yet. Equally, not all boards have 2 eMMC devices. > + "scan_boot=" \ > + "echo Scanning ${devtype} ${devnum}...; " \ > + "for prefix in ${boot_prefixes}; do " \ > + "run sysboot_boot; " \ > + "run envimport; " \ > + "run script_boot; " \ This isn't quite right for the Raspberry Pi at least. What I wanted was for uEnv.txt to *always* be loaded from SD card before any other boot activity. The SD card is known to exist on this platform, since it's the only place the SoC's boot ROM can load the initial binary firmware from. The idea is that since the Pi has nowhere to store any environment, and the default environment's boot_targets is hard-coded in the U-Boot binary, we need some way for the user to configure the value of boot_targets to e.g. force network or USB boot. We want to do this before executing bootcmd, so that bootcmd looks at the user's desired boot_targets, rather than part way through executing bootcmd, which is far too late. Now, on the Pi, this all happens via CONFIG_PREBOOT, so it will still work even with the "run envimport" as above. However, I think we want to make the "run envimport" within scan_boot optional, so it doesn't get repeated. I wouldn't be surprised if other platforms ought to be working in the exact same way? > + "boot_targets=" \ > + BOOT_TARGETS_MMC " " \ > + BOOT_TARGETS_USB " " \ > + BOOT_TARGETS_SATA " " \ > + BOOT_TARGETS_PXE " " \ > + BOOT_TARGETS_DHCP " " \ > + "\0" \ I'd be tempted to require the board-specific config to set boot_targets, so that appropriate customization can be applied? > + "boot_envs=uEnv.txt\0" \ I wonder if boards want to customize that for backwards-compatibility?
On 02/19/2014 10:30 AM, Marek Vasut wrote: > On Wednesday, February 19, 2014 at 06:28:39 PM, Stephen Warren wrote: >> On 02/19/2014 08:54 AM, Marek Vasut wrote: >>> On Monday, February 17, 2014 at 06:56:36 PM, Dennis Gilmore wrote: >>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us> >>>> --- >>>> >>>> include/config_distro_bootcmd.h | 172 >>>> >>>> ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 172 >>>> insertions(+) >>>> >>>> create mode 100644 include/config_distro_bootcmd.h >>>> >>>> diff --git a/include/config_distro_bootcmd.h >>>> b/include/config_distro_bootcmd.h new file mode 100644 >>>> index 0000000..d32dc12 >>>> --- /dev/null >>>> +++ b/include/config_distro_bootcmd.h >>>> @@ -0,0 +1,172 @@ >>>> +/* >>>> + * (C) Copyright 2014 >>>> + * NVIDIA Corporation <www.nvidia.com> >>>> + * >>>> + * Copyright 2014 Red Hat, Inc. >>>> + * >>>> + * SPDX-License-Identifier: GPL-2.0+ >>>> + */ >>>> + >>>> +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H >>>> +#define _CONFIG_CMD_DISTRO_BOOTCMD_H >>>> + >>>> + >>>> +#ifdef CONFIG_CMD_MMC >>>> +#define BOOTCMDS_MMC \ >>> >>> You might want to #undef all this temporary stuff so it's not propagated >>> into the U-Boot further. >> >> I don't understand. What temporary stuff are you referring to? > > BOOTCMDS_MMC for example. This certainly doesn't need to propagate into the rest > of the U-Boot build, does it ? Oh, you mean #undef it at the end of the file? That would probably work. I thought you meant something else, although I wasn't sure what.
On Wednesday, February 19, 2014 at 06:41:17 PM, Stephen Warren wrote: > On 02/19/2014 10:30 AM, Marek Vasut wrote: > > On Wednesday, February 19, 2014 at 06:28:39 PM, Stephen Warren wrote: > >> On 02/19/2014 08:54 AM, Marek Vasut wrote: > >>> On Monday, February 17, 2014 at 06:56:36 PM, Dennis Gilmore wrote: > >>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us> > >>>> --- > >>>> > >>>> include/config_distro_bootcmd.h | 172 > >>>> > >>>> ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 172 > >>>> insertions(+) > >>>> > >>>> create mode 100644 include/config_distro_bootcmd.h > >>>> > >>>> diff --git a/include/config_distro_bootcmd.h > >>>> b/include/config_distro_bootcmd.h new file mode 100644 > >>>> index 0000000..d32dc12 > >>>> --- /dev/null > >>>> +++ b/include/config_distro_bootcmd.h > >>>> @@ -0,0 +1,172 @@ > >>>> +/* > >>>> + * (C) Copyright 2014 > >>>> + * NVIDIA Corporation <www.nvidia.com> > >>>> + * > >>>> + * Copyright 2014 Red Hat, Inc. > >>>> + * > >>>> + * SPDX-License-Identifier: GPL-2.0+ > >>>> + */ > >>>> + > >>>> +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H > >>>> +#define _CONFIG_CMD_DISTRO_BOOTCMD_H > >>>> + > >>>> + > >>>> +#ifdef CONFIG_CMD_MMC > >>>> +#define BOOTCMDS_MMC \ > >>> > >>> You might want to #undef all this temporary stuff so it's not > >>> propagated into the U-Boot further. > >> > >> I don't understand. What temporary stuff are you referring to? > > > > BOOTCMDS_MMC for example. This certainly doesn't need to propagate into > > the rest of the U-Boot build, does it ? > > Oh, you mean #undef it at the end of the file? That would probably work. > I thought you meant something else, although I wasn't sure what. That's what I meant, sorry. Best regards, Marek Vasut
On 02/17/2014 11:56 AM, Dennis Gilmore wrote: > Signed-off-by: Dennis Gilmore <dennis@ausil.us> > --- > include/config_distro_bootcmd.h | 172 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 172 insertions(+) > create mode 100644 include/config_distro_bootcmd.h > > diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h > new file mode 100644 > index 0000000..d32dc12 > --- /dev/null > +++ b/include/config_distro_bootcmd.h > @@ -0,0 +1,172 @@ > +/* > + * (C) Copyright 2014 > + * NVIDIA Corporation <www.nvidia.com> > + * > + * Copyright 2014 Red Hat, Inc. > + * > + * SPDX-License-Identifier: GPL-2.0+ > + */ > + > +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H > +#define _CONFIG_CMD_DISTRO_BOOTCMD_H > + > + > +#ifdef CONFIG_CMD_MMC > +#define BOOTCMDS_MMC \ > + "mmc_boot=" \ > + "setenv devtype mmc; " \ > + "if mmc dev ${devnum}; then " \ > + "run scan_boot; " \ > + "fi\0" \ > + "bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \ > + "bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0" > +#define BOOT_TARGETS_MMC "mmc1 mmc0" > +#else > +#define BOOTCMDS_MMC "" > +#define BOOT_TARGETS_MMC "" > +#endif > + > +#ifdef CONFIG_CMD_USB > +#define BOOTCMD_INIT_USB "run usb_init; " > +#define BOOTCMDS_USB \ > + "usb_init=" \ > + "if ${usb_need_init}; then " \ > + "set usb_need_init false; " \ > + "usb start 0; " \ > + "fi\0" \ > + \ > + "usb_boot=" \ > + "setenv devtype usb; " \ > + BOOTCMD_INIT_USB \ > + "if usb dev ${devnum}; then " \ This may have already been highlighted but I don't see where the kernel command line arguments can be set. If you have the file system on the USB stick won't you need to direct the root to the stick? Maybe I don't want to have a uEnv.txt file. This is what I had to do when I did the similar implementation on the TI common file http://patchwork.ozlabs.org/patch/292851/ > + "run scan_boot; " \ > + "fi\0" \ > + \ > + "bootcmd_usb0=setenv devnum 0; run usb_boot;\0" > +#define BOOT_TARGETS_USB "usb0" > +#else > +#define BOOTCMD_INIT_USB "" > +#define BOOTCMDS_USB "" > +#define BOOT_TARGETS_USB "" > +#endif > + > +#ifdef CONFIG_CMD_SATA > +#define BOOTCMDS_SATA \ > + "sata_boot=" \ > + "setenv devtype sata; " \ > + "if sata dev ${devnum}; then " \ > + "run scan_boot; " \ Same as above > + "fi\0" \ > + \ > + "bootcmd_sata0=setenv devnum 0; run sata_boot;\0" > + "bootcmd_sata1=setenv devnum 1; run sata_boot;\0" > +#define BOOT_TARGETS_USB "sata0 sata1" > +#else > +#define BOOTCMDS_SATA "" > +#define BOOT_TARGETS_SATA "" > +#endif > + > +#ifdef CONFIG_CMD_DHCP > +#define BOOTCMDS_DHCP \ > + "bootcmd_dhcp=" \ > + BOOTCMD_INIT_USB \ > + "if dhcp ${scriptaddr} boot.scr.uimg; then "\ > + "source ${scriptaddr}; " \ > + "fi\0" > +#define BOOT_TARGETS_DHCP "dhcp" > +#else > +#define BOOTCMDS_DHCP "" > +#define BOOT_TARGETS_DHCP "" > +#endif > + > +#if defined(CONFIG_CMD_DHCP) && defined(CONFIG_CMD_PXE) > +#define BOOTCMDS_PXE \ > + "bootcmd_pxe=" \ > + BOOTCMD_INIT_USB \ > + "dhcp; " \ > + "if pxe get; then " \ > + "pxe boot; " \ > + "fi\0" > +#define BOOT_TARGETS_PXE "pxe" > +#else > +#define BOOTCMDS_PXE "" > +#define BOOT_TARGETS_PXE "" > +#endif > + >
On 02/19/2014 11:44 AM, Dan Murphy wrote: > On 02/17/2014 11:56 AM, Dennis Gilmore wrote: >> Signed-off-by: Dennis Gilmore <dennis@ausil.us> >> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h >> +#ifdef CONFIG_CMD_USB >> +#define BOOTCMD_INIT_USB "run usb_init; " >> +#define BOOTCMDS_USB \ >> + "usb_init=" \ >> + "if ${usb_need_init}; then " \ >> + "set usb_need_init false; " \ >> + "usb start 0; " \ >> + "fi\0" \ >> + \ >> + "usb_boot=" \ >> + "setenv devtype usb; " \ >> + BOOTCMD_INIT_USB \ >> + "if usb dev ${devnum}; then " \ > > This may have already been highlighted but I don't see where the kernel command line arguments can be set. > If you have the file system on the USB stick won't you need to direct the root to the stick? They would be set in boot.scr or extlinux.cfg on the disk that the system boots from; the kernel cmdline is part of the OS that's installed there, not part of U-Boot. This is why these boot scripts load a script/config-file from the disk which in turn defines which kernel/DTB/cmdline to use, rather than directly loading a kernel and DTB. This approach should even be suitable for booting a non-Linux-OS, with suitable commands in boot.scr.
On 02/19/2014 12:48 PM, Stephen Warren wrote: > On 02/19/2014 11:44 AM, Dan Murphy wrote: >> On 02/17/2014 11:56 AM, Dennis Gilmore wrote: >>> Signed-off-by: Dennis Gilmore <dennis@ausil.us> >>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h >>> +#ifdef CONFIG_CMD_USB >>> +#define BOOTCMD_INIT_USB "run usb_init; " >>> +#define BOOTCMDS_USB \ >>> + "usb_init=" \ >>> + "if ${usb_need_init}; then " \ >>> + "set usb_need_init false; " \ >>> + "usb start 0; " \ >>> + "fi\0" \ >>> + \ >>> + "usb_boot=" \ >>> + "setenv devtype usb; " \ >>> + BOOTCMD_INIT_USB \ >>> + "if usb dev ${devnum}; then " \ >> This may have already been highlighted but I don't see where the kernel command line arguments can be set. >> If you have the file system on the USB stick won't you need to direct the root to the stick? > They would be set in boot.scr or extlinux.cfg on the disk that the > system boots from; the kernel cmdline is part of the OS that's installed > there, not part of U-Boot. This is why these boot scripts load a > script/config-file from the disk which in turn defines which > kernel/DTB/cmdline to use, rather than directly loading a kernel and > DTB. This approach should even be suitable for booting a non-Linux-OS, > with suitable commands in boot.scr. But shouldn't the config file just be an override? I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot. If no config file exists should we not try to default to a known good default tested case? Dan
On 02/19/2014 11:52 AM, Dan Murphy wrote: > On 02/19/2014 12:48 PM, Stephen Warren wrote: >> On 02/19/2014 11:44 AM, Dan Murphy wrote: >>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote: >>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us> >>>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h >>>> +#ifdef CONFIG_CMD_USB >>>> +#define BOOTCMD_INIT_USB "run usb_init; " >>>> +#define BOOTCMDS_USB \ >>>> + "usb_init=" \ >>>> + "if ${usb_need_init}; then " \ >>>> + "set usb_need_init false; " \ >>>> + "usb start 0; " \ >>>> + "fi\0" \ >>>> + \ >>>> + "usb_boot=" \ >>>> + "setenv devtype usb; " \ >>>> + BOOTCMD_INIT_USB \ >>>> + "if usb dev ${devnum}; then " \ >>> This may have already been highlighted but I don't see where the kernel command line arguments can be set. >>> If you have the file system on the USB stick won't you need to direct the root to the stick? >> They would be set in boot.scr or extlinux.cfg on the disk that the >> system boots from; the kernel cmdline is part of the OS that's installed >> there, not part of U-Boot. This is why these boot scripts load a >> script/config-file from the disk which in turn defines which >> kernel/DTB/cmdline to use, rather than directly loading a kernel and >> DTB. This approach should even be suitable for booting a non-Linux-OS, >> with suitable commands in boot.scr. > > But shouldn't the config file just be an override? > > I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot. > > If no config file exists should we not try to default to a known good default tested case? I believe always loading a script/config-file is the simplest and most flexible approach, for a *distro* *oriented* boot process. Now, specific U-Boot board configs can always add extra stuff on the end (or start?) of bootcmd in order to do some custom fallbacks or backwards-compatibility if they want, but I'm certainly not planning on doing anything like that for Tegra or Raspberry Pi, for example.
On 02/19/2014 12:57 PM, Stephen Warren wrote: > On 02/19/2014 11:52 AM, Dan Murphy wrote: >> On 02/19/2014 12:48 PM, Stephen Warren wrote: >>> On 02/19/2014 11:44 AM, Dan Murphy wrote: >>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote: >>>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us> >>>>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h >>>>> +#ifdef CONFIG_CMD_USB >>>>> +#define BOOTCMD_INIT_USB "run usb_init; " >>>>> +#define BOOTCMDS_USB \ >>>>> + "usb_init=" \ >>>>> + "if ${usb_need_init}; then " \ >>>>> + "set usb_need_init false; " \ >>>>> + "usb start 0; " \ >>>>> + "fi\0" \ >>>>> + \ >>>>> + "usb_boot=" \ >>>>> + "setenv devtype usb; " \ >>>>> + BOOTCMD_INIT_USB \ >>>>> + "if usb dev ${devnum}; then " \ >>>> This may have already been highlighted but I don't see where the kernel command line arguments can be set. >>>> If you have the file system on the USB stick won't you need to direct the root to the stick? >>> They would be set in boot.scr or extlinux.cfg on the disk that the >>> system boots from; the kernel cmdline is part of the OS that's installed >>> there, not part of U-Boot. This is why these boot scripts load a >>> script/config-file from the disk which in turn defines which >>> kernel/DTB/cmdline to use, rather than directly loading a kernel and >>> DTB. This approach should even be suitable for booting a non-Linux-OS, >>> with suitable commands in boot.scr. >> But shouldn't the config file just be an override? >> >> I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot. >> >> If no config file exists should we not try to default to a known good default tested case? > I believe always loading a script/config-file is the simplest and most > flexible approach, for a *distro* *oriented* boot process. > > Now, specific U-Boot board configs can always add extra stuff on the end > (or start?) of bootcmd in order to do some custom fallbacks or > backwards-compatibility if they want, but I'm certainly not planning on > doing anything like that for Tegra or Raspberry Pi, for example. Yeah I am not seeing how the board config can do that if there is no provisions in the common file. On another note there is no support in here for NAND. Was there a plan to pull that in as well? Dan
On 02/19/2014 11:57 AM, Stephen Warren wrote: > On 02/19/2014 11:52 AM, Dan Murphy wrote: >> On 02/19/2014 12:48 PM, Stephen Warren wrote: >>> On 02/19/2014 11:44 AM, Dan Murphy wrote: >>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote: >>>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us> >>>>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h >>>>> +#ifdef CONFIG_CMD_USB >>>>> +#define BOOTCMD_INIT_USB "run usb_init; " >>>>> +#define BOOTCMDS_USB \ >>>>> + "usb_init=" \ >>>>> + "if ${usb_need_init}; then " \ >>>>> + "set usb_need_init false; " \ >>>>> + "usb start 0; " \ >>>>> + "fi\0" \ >>>>> + \ >>>>> + "usb_boot=" \ >>>>> + "setenv devtype usb; " \ >>>>> + BOOTCMD_INIT_USB \ >>>>> + "if usb dev ${devnum}; then " \ >>>> This may have already been highlighted but I don't see where the kernel command line arguments can be set. >>>> If you have the file system on the USB stick won't you need to direct the root to the stick? >>> They would be set in boot.scr or extlinux.cfg on the disk that the >>> system boots from; the kernel cmdline is part of the OS that's installed >>> there, not part of U-Boot. This is why these boot scripts load a >>> script/config-file from the disk which in turn defines which >>> kernel/DTB/cmdline to use, rather than directly loading a kernel and >>> DTB. This approach should even be suitable for booting a non-Linux-OS, >>> with suitable commands in boot.scr. >> >> But shouldn't the config file just be an override? >> >> I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot. >> >> If no config file exists should we not try to default to a known good default tested case? > > I believe always loading a script/config-file is the simplest and most > flexible approach, for a *distro* *oriented* boot process. +1 Scripts have the benefit of putting everything into a relatively easy-to-read form that only uses documented U-Boot commands, not board-specific constructs.
On 02/19/2014 11:59 AM, Dan Murphy wrote: > On 02/19/2014 12:57 PM, Stephen Warren wrote: >> On 02/19/2014 11:52 AM, Dan Murphy wrote: >>> On 02/19/2014 12:48 PM, Stephen Warren wrote: >>>> On 02/19/2014 11:44 AM, Dan Murphy wrote: >>>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote: >>>>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us> >>>>>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h >>>>>> +#ifdef CONFIG_CMD_USB >>>>>> +#define BOOTCMD_INIT_USB "run usb_init; " >>>>>> +#define BOOTCMDS_USB \ >>>>>> + "usb_init=" \ >>>>>> + "if ${usb_need_init}; then " \ >>>>>> + "set usb_need_init false; " \ >>>>>> + "usb start 0; " \ >>>>>> + "fi\0" \ >>>>>> + \ >>>>>> + "usb_boot=" \ >>>>>> + "setenv devtype usb; " \ >>>>>> + BOOTCMD_INIT_USB \ >>>>>> + "if usb dev ${devnum}; then " \ >>>>> This may have already been highlighted but I don't see where the kernel command line arguments can be set. >>>>> If you have the file system on the USB stick won't you need to direct the root to the stick? >>>> They would be set in boot.scr or extlinux.cfg on the disk that the >>>> system boots from; the kernel cmdline is part of the OS that's installed >>>> there, not part of U-Boot. This is why these boot scripts load a >>>> script/config-file from the disk which in turn defines which >>>> kernel/DTB/cmdline to use, rather than directly loading a kernel and >>>> DTB. This approach should even be suitable for booting a non-Linux-OS, >>>> with suitable commands in boot.scr. >>> But shouldn't the config file just be an override? >>> >>> I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot. >>> >>> If no config file exists should we not try to default to a known good default tested case? >> I believe always loading a script/config-file is the simplest and most >> flexible approach, for a *distro* *oriented* boot process. >> >> Now, specific U-Boot board configs can always add extra stuff on the end >> (or start?) of bootcmd in order to do some custom fallbacks or >> backwards-compatibility if they want, but I'm certainly not planning on >> doing anything like that for Tegra or Raspberry Pi, for example. > > Yeah I am not seeing how the board config can do that if there is no provisions in the common file. Presumably all it needs is an extra hook/variable that is added to the start/end of bootcmd. Should be pretty easy to add in a future patch rev, or followon patch. > On another note there is no support in here for NAND. Was there a plan to pull that in as well? A generic Linux distro wouldn't be installing a kernel to NAND, but would rather put it into the /boot filesystem. NAND boot is something that'd be best supported by the custom hook we discussed above. The commit description for this commit should have set the scene that this series is all about providing a way for a generic Linux distro to create a generic installable media set that boots the same way across n different boards with U-Boot, and similarly also to set up the installed distro filesystem in a single generic way that can boot on any board it gets installed to. It's all about avoiding board-specific boot options such as NAND, and hence may well not be applicable to boards that primarily/only boot from NAND; they would still need custom distro install media and hooks to set up the installed filesystem.
On 02/19/2014 01:02 PM, Eric Nelson wrote: > On 02/19/2014 11:57 AM, Stephen Warren wrote: >> On 02/19/2014 11:52 AM, Dan Murphy wrote: >>> On 02/19/2014 12:48 PM, Stephen Warren wrote: >>>> On 02/19/2014 11:44 AM, Dan Murphy wrote: >>>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote: >>>>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us> >>>>>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h >>>>>> +#ifdef CONFIG_CMD_USB >>>>>> +#define BOOTCMD_INIT_USB "run usb_init; " >>>>>> +#define BOOTCMDS_USB \ >>>>>> + "usb_init=" \ >>>>>> + "if ${usb_need_init}; then " \ >>>>>> + "set usb_need_init false; " \ >>>>>> + "usb start 0; " \ >>>>>> + "fi\0" \ >>>>>> + \ >>>>>> + "usb_boot=" \ >>>>>> + "setenv devtype usb; " \ >>>>>> + BOOTCMD_INIT_USB \ >>>>>> + "if usb dev ${devnum}; then " \ >>>>> This may have already been highlighted but I don't see where the kernel command line arguments can be set. >>>>> If you have the file system on the USB stick won't you need to direct the root to the stick? >>>> They would be set in boot.scr or extlinux.cfg on the disk that the >>>> system boots from; the kernel cmdline is part of the OS that's installed >>>> there, not part of U-Boot. This is why these boot scripts load a >>>> script/config-file from the disk which in turn defines which >>>> kernel/DTB/cmdline to use, rather than directly loading a kernel and >>>> DTB. This approach should even be suitable for booting a non-Linux-OS, >>>> with suitable commands in boot.scr. >>> >>> But shouldn't the config file just be an override? >>> >>> I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot. >>> >>> If no config file exists should we not try to default to a known good default tested case? >> >> I believe always loading a script/config-file is the simplest and most >> flexible approach, for a *distro* *oriented* boot process. > > +1 > > Scripts have the benefit of putting everything into a relatively > easy-to-read form that only uses documented U-Boot commands, not > board-specific constructs. > Oh don't get me wrong I agree with having the scripts. Just sayin we should not rely on the scripts being there and mandating their usage. We may want to have a fall back to a known good tested configuration. Dan
On Wed, Feb 19, 2014 at 12:04:12PM -0700, Stephen Warren wrote: > On 02/19/2014 11:59 AM, Dan Murphy wrote: > > On 02/19/2014 12:57 PM, Stephen Warren wrote: > >> On 02/19/2014 11:52 AM, Dan Murphy wrote: > >>> On 02/19/2014 12:48 PM, Stephen Warren wrote: > >>>> On 02/19/2014 11:44 AM, Dan Murphy wrote: > >>>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote: > >>>>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us> > >>>>>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h > >>>>>> +#ifdef CONFIG_CMD_USB > >>>>>> +#define BOOTCMD_INIT_USB "run usb_init; " > >>>>>> +#define BOOTCMDS_USB \ > >>>>>> + "usb_init=" \ > >>>>>> + "if ${usb_need_init}; then " \ > >>>>>> + "set usb_need_init false; " \ > >>>>>> + "usb start 0; " \ > >>>>>> + "fi\0" \ > >>>>>> + \ > >>>>>> + "usb_boot=" \ > >>>>>> + "setenv devtype usb; " \ > >>>>>> + BOOTCMD_INIT_USB \ > >>>>>> + "if usb dev ${devnum}; then " \ > >>>>> This may have already been highlighted but I don't see where the kernel command line arguments can be set. > >>>>> If you have the file system on the USB stick won't you need to direct the root to the stick? > >>>> They would be set in boot.scr or extlinux.cfg on the disk that the > >>>> system boots from; the kernel cmdline is part of the OS that's installed > >>>> there, not part of U-Boot. This is why these boot scripts load a > >>>> script/config-file from the disk which in turn defines which > >>>> kernel/DTB/cmdline to use, rather than directly loading a kernel and > >>>> DTB. This approach should even be suitable for booting a non-Linux-OS, > >>>> with suitable commands in boot.scr. > >>> But shouldn't the config file just be an override? > >>> > >>> I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot. > >>> > >>> If no config file exists should we not try to default to a known good default tested case? > >> I believe always loading a script/config-file is the simplest and most > >> flexible approach, for a *distro* *oriented* boot process. > >> > >> Now, specific U-Boot board configs can always add extra stuff on the end > >> (or start?) of bootcmd in order to do some custom fallbacks or > >> backwards-compatibility if they want, but I'm certainly not planning on > >> doing anything like that for Tegra or Raspberry Pi, for example. > > > > Yeah I am not seeing how the board config can do that if there is no provisions in the common file. > > Presumably all it needs is an extra hook/variable that is added to the > start/end of bootcmd. Should be pretty easy to add in a future patch > rev, or followon patch. > > > On another note there is no support in here for NAND. Was there a plan to pull that in as well? > > A generic Linux distro wouldn't be installing a kernel to NAND, but > would rather put it into the /boot filesystem. NAND boot is something > that'd be best supported by the custom hook we discussed above. Wait, why would a generic Linux distro be installing to eMMC but not to NAND ? Not that this series needs to be the final point in the discussion and all. > The commit description for this commit should have set the scene that > this series is all about providing a way for a generic Linux distro to > create a generic installable media set that boots the same way across n > different boards with U-Boot, and similarly also to set up the installed > distro filesystem in a single generic way that can boot on any board it > gets installed to. It's all about avoiding board-specific boot options > such as NAND, and hence may well not be applicable to boards that > primarily/only boot from NAND; they would still need custom distro > install media and hooks to set up the installed filesystem. Why is NAND special but SATA not, other than desktops often have SATA exposed but not NAND? Even more so when you consider that from the Linux side of things, dealing with NAND is dealing with NAND and it's not board specific.
On 02/19/2014 12:10 PM, Tom Rini wrote: ... >> A generic Linux distro wouldn't be installing a kernel to NAND, but >> would rather put it into the /boot filesystem. NAND boot is something >> that'd be best supported by the custom hook we discussed above. > > Wait, why would a generic Linux distro be installing to eMMC but not to > NAND ? Not that this series needs to be the final point in the > discussion and all. I should point out that I was talking about raw NAND MTD partitions rather than a NAND device with a regular partition table and normal filesystems within it. If the NAND is exposed as a regular block device with a regular filesystem, then it'd look just like any other block device to a generic distro installer, and hence it could put /boot there, and this patch (or future enhancement) could certainly usefully contain a generic bootcmd_nand that used it. However, if the NAND has hard-coded MTD partitions, and/or the partitions have no filesystem but rather contain e.g. a raw zImage/uImage, then that would require board-/SoC-specific support in the distro kernel and installer, and hence we wouldn't be talking about a *generic* installer/distro, and *generic* installers/distros are what this patch series is all about. >> The commit description for this commit should have set the scene that >> this series is all about providing a way for a generic Linux distro to >> create a generic installable media set that boots the same way across n >> different boards with U-Boot, and similarly also to set up the installed >> distro filesystem in a single generic way that can boot on any board it >> gets installed to. It's all about avoiding board-specific boot options >> such as NAND, and hence may well not be applicable to boards that >> primarily/only boot from NAND; they would still need custom distro >> install media and hooks to set up the installed filesystem. > > Why is NAND special but SATA not, other than desktops often have SATA > exposed but not NAND? Even more so when you consider that from the > Linux side of things, dealing with NAND is dealing with NAND and it's > not board specific.
On Wed, Feb 19, 2014 at 01:05:15PM -0600, Dan Murphy wrote: > On 02/19/2014 01:02 PM, Eric Nelson wrote: > > On 02/19/2014 11:57 AM, Stephen Warren wrote: > >> On 02/19/2014 11:52 AM, Dan Murphy wrote: > >>> On 02/19/2014 12:48 PM, Stephen Warren wrote: > >>>> On 02/19/2014 11:44 AM, Dan Murphy wrote: > >>>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote: > >>>>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us> > >>>>>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h > >>>>>> +#ifdef CONFIG_CMD_USB > >>>>>> +#define BOOTCMD_INIT_USB "run usb_init; " > >>>>>> +#define BOOTCMDS_USB \ > >>>>>> + "usb_init=" \ > >>>>>> + "if ${usb_need_init}; then " \ > >>>>>> + "set usb_need_init false; " \ > >>>>>> + "usb start 0; " \ > >>>>>> + "fi\0" \ > >>>>>> + \ > >>>>>> + "usb_boot=" \ > >>>>>> + "setenv devtype usb; " \ > >>>>>> + BOOTCMD_INIT_USB \ > >>>>>> + "if usb dev ${devnum}; then " \ > >>>>> This may have already been highlighted but I don't see where the kernel command line arguments can be set. > >>>>> If you have the file system on the USB stick won't you need to direct the root to the stick? > >>>> They would be set in boot.scr or extlinux.cfg on the disk that the > >>>> system boots from; the kernel cmdline is part of the OS that's installed > >>>> there, not part of U-Boot. This is why these boot scripts load a > >>>> script/config-file from the disk which in turn defines which > >>>> kernel/DTB/cmdline to use, rather than directly loading a kernel and > >>>> DTB. This approach should even be suitable for booting a non-Linux-OS, > >>>> with suitable commands in boot.scr. > >>> > >>> But shouldn't the config file just be an override? > >>> > >>> I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot. > >>> > >>> If no config file exists should we not try to default to a known good default tested case? > >> > >> I believe always loading a script/config-file is the simplest and most > >> flexible approach, for a *distro* *oriented* boot process. > > > > +1 > > > > Scripts have the benefit of putting everything into a relatively > > easy-to-read form that only uses documented U-Boot commands, not > > board-specific constructs. > > > > Oh don't get me wrong I agree with having the scripts. > > Just sayin we should not rely on the scripts being there and mandating > their usage. > We may want to have a fall back to a known good tested configuration. I think I see where you're coming from, but it's already expected that you're passing in a good device tree too, so it would be making sure that you also have a useful env file to get loaded in the DHCP or PXE case.
On 02/19/2014 01:16 PM, Tom Rini wrote: > On Wed, Feb 19, 2014 at 01:05:15PM -0600, Dan Murphy wrote: >> On 02/19/2014 01:02 PM, Eric Nelson wrote: >>> On 02/19/2014 11:57 AM, Stephen Warren wrote: >>>> On 02/19/2014 11:52 AM, Dan Murphy wrote: >>>>> On 02/19/2014 12:48 PM, Stephen Warren wrote: >>>>>> On 02/19/2014 11:44 AM, Dan Murphy wrote: >>>>>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote: >>>>>>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us> >>>>>>>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h >>>>>>>> +#ifdef CONFIG_CMD_USB >>>>>>>> +#define BOOTCMD_INIT_USB "run usb_init; " >>>>>>>> +#define BOOTCMDS_USB \ >>>>>>>> + "usb_init=" \ >>>>>>>> + "if ${usb_need_init}; then " \ >>>>>>>> + "set usb_need_init false; " \ >>>>>>>> + "usb start 0; " \ >>>>>>>> + "fi\0" \ >>>>>>>> + \ >>>>>>>> + "usb_boot=" \ >>>>>>>> + "setenv devtype usb; " \ >>>>>>>> + BOOTCMD_INIT_USB \ >>>>>>>> + "if usb dev ${devnum}; then " \ >>>>>>> This may have already been highlighted but I don't see where the kernel command line arguments can be set. >>>>>>> If you have the file system on the USB stick won't you need to direct the root to the stick? >>>>>> They would be set in boot.scr or extlinux.cfg on the disk that the >>>>>> system boots from; the kernel cmdline is part of the OS that's installed >>>>>> there, not part of U-Boot. This is why these boot scripts load a >>>>>> script/config-file from the disk which in turn defines which >>>>>> kernel/DTB/cmdline to use, rather than directly loading a kernel and >>>>>> DTB. This approach should even be suitable for booting a non-Linux-OS, >>>>>> with suitable commands in boot.scr. >>>>> But shouldn't the config file just be an override? >>>>> >>>>> I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot. >>>>> >>>>> If no config file exists should we not try to default to a known good default tested case? >>>> I believe always loading a script/config-file is the simplest and most >>>> flexible approach, for a *distro* *oriented* boot process. >>> +1 >>> >>> Scripts have the benefit of putting everything into a relatively >>> easy-to-read form that only uses documented U-Boot commands, not >>> board-specific constructs. >>> >> Oh don't get me wrong I agree with having the scripts. >> >> Just sayin we should not rely on the scripts being there and mandating >> their usage. >> We may want to have a fall back to a known good tested configuration. > I think I see where you're coming from, but it's already expected that > you're passing in a good device tree too, so it would be making sure > that you also have a useful env file to get loaded in the DHCP or PXE > case. > Do we have a directory where default scripts exist for each board? Or at least samples for each board? I could not find them. If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory Maybe this would be something that helps defined the known good config that the community can base their changes on. Dan
On 02/19/2014 12:24 PM, Dan Murphy wrote: ... > Do we have a directory where default scripts exist for each board? Or at least samples for each board? > > I could not find them. If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory > > Maybe this would be something that helps defined the known good config that the community can base their changes on. For Tegra, I have created: https://github.com/NVIDIA/tegra-uboot-scripts I imagine those scripts would work on most boards that use the U-Boot config in this patch series. I've certainly used almost identical scripts on the Raspberry Pi. I should perhaps put an example extlinux.conf into that repo too. I imagine (well, it's pretty much the whole point) that distro installers (e.g. Anaconda) will soon (or already do) support spitting out extlinux.conf that'll work on ARM U-Boot too.
On 02/19/2014 01:04 PM, Stephen Warren wrote: > On 02/19/2014 11:59 AM, Dan Murphy wrote: >> On 02/19/2014 12:57 PM, Stephen Warren wrote: >>> On 02/19/2014 11:52 AM, Dan Murphy wrote: >>>> On 02/19/2014 12:48 PM, Stephen Warren wrote: >>>>> On 02/19/2014 11:44 AM, Dan Murphy wrote: >>>>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote: >>>>>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us> >>>>>>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h >>>>>>> +#ifdef CONFIG_CMD_USB >>>>>>> +#define BOOTCMD_INIT_USB "run usb_init; " >>>>>>> +#define BOOTCMDS_USB \ >>>>>>> + "usb_init=" \ >>>>>>> + "if ${usb_need_init}; then " \ >>>>>>> + "set usb_need_init false; " \ >>>>>>> + "usb start 0; " \ >>>>>>> + "fi\0" \ >>>>>>> + \ >>>>>>> + "usb_boot=" \ >>>>>>> + "setenv devtype usb; " \ >>>>>>> + BOOTCMD_INIT_USB \ >>>>>>> + "if usb dev ${devnum}; then " \ >>>>>> This may have already been highlighted but I don't see where the kernel command line arguments can be set. >>>>>> If you have the file system on the USB stick won't you need to direct the root to the stick? >>>>> They would be set in boot.scr or extlinux.cfg on the disk that the >>>>> system boots from; the kernel cmdline is part of the OS that's installed >>>>> there, not part of U-Boot. This is why these boot scripts load a >>>>> script/config-file from the disk which in turn defines which >>>>> kernel/DTB/cmdline to use, rather than directly loading a kernel and >>>>> DTB. This approach should even be suitable for booting a non-Linux-OS, >>>>> with suitable commands in boot.scr. >>>> But shouldn't the config file just be an override? >>>> >>>> I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot. >>>> >>>> If no config file exists should we not try to default to a known good default tested case? >>> I believe always loading a script/config-file is the simplest and most >>> flexible approach, for a *distro* *oriented* boot process. >>> >>> Now, specific U-Boot board configs can always add extra stuff on the end >>> (or start?) of bootcmd in order to do some custom fallbacks or >>> backwards-compatibility if they want, but I'm certainly not planning on >>> doing anything like that for Tegra or Raspberry Pi, for example. >> Yeah I am not seeing how the board config can do that if there is no provisions in the common file. > Presumably all it needs is an extra hook/variable that is added to the > start/end of bootcmd. Should be pretty easy to add in a future patch > rev, or followon patch. <snip> I am not sure it is that simple. Once you are in the BOOTCMD macro's if you end up back at the board file macros you kinda have to repeat the load steps again just to get the args or specifics set. When the loading of the ENV file fails but the loading of the other images succeeds maybe something as simple as "run board_cfg" Which can be a fall back to a board file specific configuration macro for whatever you want. If you don't need it then it is NULL Dan
On Wed, Feb 19, 2014 at 12:16:13PM -0700, Stephen Warren wrote: > On 02/19/2014 12:10 PM, Tom Rini wrote: > ... > >> A generic Linux distro wouldn't be installing a kernel to NAND, but > >> would rather put it into the /boot filesystem. NAND boot is something > >> that'd be best supported by the custom hook we discussed above. > > > > Wait, why would a generic Linux distro be installing to eMMC but not to > > NAND ? Not that this series needs to be the final point in the > > discussion and all. > > I should point out that I was talking about raw NAND MTD partitions > rather than a NAND device with a regular partition table and normal > filesystems within it. > > If the NAND is exposed as a regular block device with a regular > filesystem, then it'd look just like any other block device to a generic > distro installer, and hence it could put /boot there, and this patch (or > future enhancement) could certainly usefully contain a generic > bootcmd_nand that used it. > > However, if the NAND has hard-coded MTD partitions, and/or the > partitions have no filesystem but rather contain e.g. a raw > zImage/uImage, then that would require board-/SoC-specific support in > the distro kernel and installer, and hence we wouldn't be talking about > a *generic* installer/distro, and *generic* installers/distros are what > this patch series is all about. I would put a generic distro knowing how to deal, genericially at least, with NAND on par with knowing how to deal with HW RAID or other not too uncommon desktop features. If /dev/mtdblockN then offer UBI or a few other choices, else if /dev/sd* then offer ext* or btrfs or a few other choices. But I think that's also getting off-topic for us at least (and yes, am335x is doing raw kernel storage today, fixing that is on my list). One thing this series does have to cope with, some way or another, is to be able to say "Oh, you have other boot devices too, we must handle them somehow". With my TI custodian hat on, it would be quite handy for Beaglebone to use this and have Fedora/SuSE/etc/etc "just work" but it's going to make me quite grumpy if I can't also easily support AM335x GP EVM and its NAND and I start to worry if QSPI, which I have a feeling is going to take off like eMMC did, is going to just get ignored and when Rasberry Cream Pi or Beaglebone Metalic Purple comes out with QSPI on-board we don't start kicking ourselves again.
Stephen On 02/19/2014 01:29 PM, Stephen Warren wrote: > On 02/19/2014 12:24 PM, Dan Murphy wrote: > ... >> Do we have a directory where default scripts exist for each board? Or at least samples for each board? >> >> I could not find them. If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory >> >> Maybe this would be something that helps defined the known good config that the community can base their changes on. > For Tegra, I have created: > > https://github.com/NVIDIA/tegra-uboot-scripts > > I imagine those scripts would work on most boards that use the U-Boot > config in this patch series. I've certainly used almost identical > scripts on the Raspberry Pi. > > I should perhaps put an example extlinux.conf into that repo too. > > I imagine (well, it's pretty much the whole point) that distro > installers (e.g. Anaconda) will soon (or already do) support spitting > out extlinux.conf that'll work on ARM U-Boot too. That's nice! Real time script building if you can find the repo you pointed to. But I was looking for something that was in tree though as a default. Then maybe overridden by a board uEnv.txt file. Just something that can be used to get a basic boot from whatever the board manufacturer wants to make their default storage. Dan
On 02/19/2014 12:32 PM, Dan Murphy wrote: > On 02/19/2014 01:04 PM, Stephen Warren wrote: >> On 02/19/2014 11:59 AM, Dan Murphy wrote: >>> On 02/19/2014 12:57 PM, Stephen Warren wrote: >>>> On 02/19/2014 11:52 AM, Dan Murphy wrote: ... >>>>> If no config file exists should we not try to default to a known good default tested case? >>>> >>>> I believe always loading a script/config-file is the simplest and most >>>> flexible approach, for a *distro* *oriented* boot process. >>>> >>>> Now, specific U-Boot board configs can always add extra stuff on the end >>>> (or start?) of bootcmd in order to do some custom fallbacks or >>>> backwards-compatibility if they want, but I'm certainly not planning on >>>> doing anything like that for Tegra or Raspberry Pi, for example. >>> >>> Yeah I am not seeing how the board config can do that if there is no provisions in the common file. >> >> Presumably all it needs is an extra hook/variable that is added to the >> start/end of bootcmd. Should be pretty easy to add in a future patch >> rev, or followon patch. > <snip> > > I am not sure it is that simple. Once you are in the BOOTCMD macro's if you end up back at the board file macros > you kinda have to repeat the load steps again just to get the args or specifics set. > > When the loading of the ENV file fails but the loading of the other images succeeds maybe something as simple as > > "run board_cfg" Which can be a fall back to a board file specific configuration macro for whatever you want. > > If you don't need it then it is NULL If the value of bootcmd was customizable, then you could easily add e.g. "nand_custom" as the last entry in it, and that could do whatever was appropriate (it would translate to run bootcmd_nand_custom, which the board would define). That'd work very consistently with all the other options. Eventually, I'd love to have a BIOS-like (runtime) config menu, where any variable named bootcmd_* would show up in the list, and provide an interactive way to re-order and enable/disable all the options, i.e. an interactive menu-driven editor for the value of $bootcmd. If custom options get implemented the same way as the standard options, then the custom options would integrate very well into that scheme.
On Wed, Feb 19, 2014 at 12:29:19PM -0700, Stephen Warren wrote: > On 02/19/2014 12:24 PM, Dan Murphy wrote: > ... > > Do we have a directory where default scripts exist for each board? Or at least samples for each board? > > > > I could not find them. If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory > > > > Maybe this would be something that helps defined the known good config that the community can base their changes on. > > For Tegra, I have created: > > https://github.com/NVIDIA/tegra-uboot-scripts > > I imagine those scripts would work on most boards that use the U-Boot > config in this patch series. I've certainly used almost identical > scripts on the Raspberry Pi. > > I should perhaps put an example extlinux.conf into that repo too. > > I imagine (well, it's pretty much the whole point) that distro > installers (e.g. Anaconda) will soon (or already do) support spitting > out extlinux.conf that'll work on ARM U-Boot too. Hey Otavio, is OpenEmbedded doing this yet? I know there's syslinux.conf support in since ages ago...
On Wed, Feb 19, 2014 at 01:37:24PM -0600, Dan Murphy wrote: > Stephen > > On 02/19/2014 01:29 PM, Stephen Warren wrote: > > On 02/19/2014 12:24 PM, Dan Murphy wrote: > > ... > >> Do we have a directory where default scripts exist for each board? Or at least samples for each board? > >> > >> I could not find them. If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory > >> > >> Maybe this would be something that helps defined the known good config that the community can base their changes on. > > For Tegra, I have created: > > > > https://github.com/NVIDIA/tegra-uboot-scripts > > > > I imagine those scripts would work on most boards that use the U-Boot > > config in this patch series. I've certainly used almost identical > > scripts on the Raspberry Pi. > > > > I should perhaps put an example extlinux.conf into that repo too. > > > > I imagine (well, it's pretty much the whole point) that distro > > installers (e.g. Anaconda) will soon (or already do) support spitting > > out extlinux.conf that'll work on ARM U-Boot too. > > That's nice! Real time script building if you can find the repo you pointed to. > > But I was looking for something that was in tree though as a default. Then maybe overridden by a board uEnv.txt file. > > Just something that can be used to get a basic boot from whatever the board manufacturer wants to make their default > storage. Yes, for the next go-round we need examples too perhaps, either directly or at least mentioned in board/.../README
On 02/19/2014 12:36 PM, Tom Rini wrote: ... > I would put a generic distro knowing how to deal, genericially at least, > with NAND on par with knowing how to deal with HW RAID or other not too > uncommon desktop features. If /dev/mtdblockN then offer UBI or a few > other choices, else if /dev/sd* then offer ext* or btrfs or a few other But how do /dev/mtdblockN get into existence? MTD partitions have historically been defined on the kernel command-line haven't they, and hence it'd require a board-specific cmdline to support that. Hmmm. Perhaps they can be specified in DT nowadays? If so, then NAND should indeed be pretty easy to deal with. > One thing this series does have to cope with, some way or another, is to > be able to say "Oh, you have other boot devices too, we must handle them > somehow". With my TI custodian hat on, it would be quite handy for > Beaglebone to use this and have Fedora/SuSE/etc/etc "just work" but it's > going to make me quite grumpy if I can't also easily support AM335x GP > EVM and its NAND and I start to worry if QSPI, which I have a feeling is > going to take off like eMMC did, is going to just get ignored and when > Rasberry Cream Pi or Beaglebone Metalic Purple comes out with QSPI > on-board we don't start kicking ourselves again. I assume QSPI would be just the system boot flash, and not for filesystem storage? As a general rule, I assert that distros shouldn't have to know anything about installing/updating bootloaders; that should be something that happens before you attempt to use a distro installer, and most likely uses board-/SoC-specific tools. If QSPI is filesystem storage, then assuming it shows up like any other block device, it should work out just like NAND as we discussed above. Exceptions might be e.g. the Raspberry Pi and some of the Beagle* boards which require the firmware in a partition on the SD card, since there's no other storage device. Still, hopefully that's as simple as detecting the specific board based on DT compatible value, and installing a particular extra package for it.
On Wed, Feb 19, 2014 at 12:43:49PM -0700, Stephen Warren wrote: > On 02/19/2014 12:36 PM, Tom Rini wrote: > ... > > I would put a generic distro knowing how to deal, genericially at least, > > with NAND on par with knowing how to deal with HW RAID or other not too > > uncommon desktop features. If /dev/mtdblockN then offer UBI or a few > > other choices, else if /dev/sd* then offer ext* or btrfs or a few other > > But how do /dev/mtdblockN get into existence? MTD partitions have > historically been defined on the kernel command-line haven't they, and > hence it'd require a board-specific cmdline to support that. Hmmm. > Perhaps they can be specified in DT nowadays? If so, then NAND should > indeed be pretty easy to deal with. They've been in the device tree since before ARM started converting :) > > One thing this series does have to cope with, some way or another, is to > > be able to say "Oh, you have other boot devices too, we must handle them > > somehow". With my TI custodian hat on, it would be quite handy for > > Beaglebone to use this and have Fedora/SuSE/etc/etc "just work" but it's > > going to make me quite grumpy if I can't also easily support AM335x GP > > EVM and its NAND and I start to worry if QSPI, which I have a feeling is > > going to take off like eMMC did, is going to just get ignored and when > > Rasberry Cream Pi or Beaglebone Metalic Purple comes out with QSPI > > on-board we don't start kicking ourselves again. > > I assume QSPI would be just the system boot flash, and not for > filesystem storage? As a general rule, I assert that distros shouldn't > have to know anything about installing/updating bootloaders; that should > be something that happens before you attempt to use a distro installer, > and most likely uses board-/SoC-specific tools. If QSPI is filesystem > storage, then assuming it shows up like any other block device, it > should work out just like NAND as we discussed above. QSPI is another MTD block device, and can be of "reasonable" size. My point being that we don't want to say that the only use cases for "generic distro" are SD/SATA/"network". If we say from the outset that we won't even try and expose $FOO because it's not something they deal with today, people certainly won't. > Exceptions might be e.g. the Raspberry Pi and some of the Beagle* boards > which require the firmware in a partition on the SD card, since there's > no other storage device. Still, hopefully that's as simple as detecting > the specific board based on DT compatible value, and installing a > particular extra package for it. What I'm saying is that while Beaglebone Black ships with eMMC today (and oh, hey, duh, Beagleboard not-xM ships with NAND), tomorrows hot commodity board quite well include a different on-baord storage, but one we can worry about a bit today.
On 02/19/2014 01:38 PM, Stephen Warren wrote: > On 02/19/2014 12:32 PM, Dan Murphy wrote: >> On 02/19/2014 01:04 PM, Stephen Warren wrote: >>> On 02/19/2014 11:59 AM, Dan Murphy wrote: >>>> On 02/19/2014 12:57 PM, Stephen Warren wrote: >>>>> On 02/19/2014 11:52 AM, Dan Murphy wrote: > ... >>>>>> If no config file exists should we not try to default to a known good default tested case? >>>>> I believe always loading a script/config-file is the simplest and most >>>>> flexible approach, for a *distro* *oriented* boot process. >>>>> >>>>> Now, specific U-Boot board configs can always add extra stuff on the end >>>>> (or start?) of bootcmd in order to do some custom fallbacks or >>>>> backwards-compatibility if they want, but I'm certainly not planning on >>>>> doing anything like that for Tegra or Raspberry Pi, for example. >>>> Yeah I am not seeing how the board config can do that if there is no provisions in the common file. >>> Presumably all it needs is an extra hook/variable that is added to the >>> start/end of bootcmd. Should be pretty easy to add in a future patch >>> rev, or followon patch. >> <snip> >> >> I am not sure it is that simple. Once you are in the BOOTCMD macro's if you end up back at the board file macros >> you kinda have to repeat the load steps again just to get the args or specifics set. >> >> When the loading of the ENV file fails but the loading of the other images succeeds maybe something as simple as >> >> "run board_cfg" Which can be a fall back to a board file specific configuration macro for whatever you want. >> >> If you don't need it then it is NULL > If the value of bootcmd was customizable, then you could easily add e.g. > "nand_custom" as the last entry in it, and that could do whatever was > appropriate (it would translate to run bootcmd_nand_custom, which the > board would define). That'd work very consistently with all the other > options. Well is this not what the BB patch does is calls upon the common boot_cmd and if that fails then comes back to the board config to run nand_boot? This does not really solve any of my issue of not having (or realizing I need) a script for boot on the boot partition. No default case here to rely on as an in tree solution. Dan > Eventually, I'd love to have a BIOS-like (runtime) config menu, where > any variable named bootcmd_* would show up in the list, and provide an > interactive way to re-order and enable/disable all the options, i.e. an > interactive menu-driven editor for the value of $bootcmd. If custom > options get implemented the same way as the standard options, then the > custom options would integrate very well into that scheme.
On Wed, 19 Feb 2014 12:43:49 -0700 Stephen Warren <swarren@wwwdotorg.org> wrote: > On 02/19/2014 12:36 PM, Tom Rini wrote: > ... > > I would put a generic distro knowing how to deal, genericially at > > least, with NAND on par with knowing how to deal with HW RAID or > > other not too uncommon desktop features. If /dev/mtdblockN then > > offer UBI or a few other choices, else if /dev/sd* then offer ext* > > or btrfs or a few other > > But how do /dev/mtdblockN get into existence? MTD partitions have > historically been defined on the kernel command-line haven't they, and > hence it'd require a board-specific cmdline to support that. Hmmm. > Perhaps they can be specified in DT nowadays? If so, then NAND should > indeed be pretty easy to deal with. > > > One thing this series does have to cope with, some way or another, > > is to be able to say "Oh, you have other boot devices too, we must > > handle them somehow". With my TI custodian hat on, it would be > > quite handy for Beaglebone to use this and have Fedora/SuSE/etc/etc > > "just work" but it's going to make me quite grumpy if I can't also > > easily support AM335x GP EVM and its NAND and I start to worry if > > QSPI, which I have a feeling is going to take off like eMMC did, is > > going to just get ignored and when Rasberry Cream Pi or Beaglebone > > Metalic Purple comes out with QSPI on-board we don't start kicking > > ourselves again. > > I assume QSPI would be just the system boot flash, and not for > filesystem storage? As a general rule, I assert that distros shouldn't > have to know anything about installing/updating bootloaders; that > should be something that happens before you attempt to use a distro > installer, and most likely uses board-/SoC-specific tools. If QSPI is > filesystem storage, then assuming it shows up like any other block > device, it should work out just like NAND as we discussed above. > > Exceptions might be e.g. the Raspberry Pi and some of the Beagle* > boards which require the firmware in a partition on the SD card, > since there's no other storage device. Still, hopefully that's as > simple as detecting the specific board based on DT compatible value, > and installing a particular extra package for it. I'm actually going to use raw space for the MLO and u-boot.img, in Fedora 21, its easier and doesn't require special partitioning. I assume that when a device with QSPI comes along we will write things in a way that it can easily be extended to support and boards will ship day one with working support. That is assuming that there is QSPI chips with enough size to be useful are readily available. Dennis
On Wed, Feb 19, 2014 at 02:41:31PM -0500, Tom Rini wrote: > On Wed, Feb 19, 2014 at 12:29:19PM -0700, Stephen Warren wrote: > > On 02/19/2014 12:24 PM, Dan Murphy wrote: > > ... > > > Do we have a directory where default scripts exist for each board? Or > > > at least samples for each board? > > > > > > I could not find them. If they don't exist then we should probably put > > > them in the board dirs and cp them to the respective out directory > > > > > > Maybe this would be something that helps defined the known good config > > > that the community can base their changes on. > > > > For Tegra, I have created: > > > > https://github.com/NVIDIA/tegra-uboot-scripts > > > > I imagine those scripts would work on most boards that use the U-Boot > > config in this patch series. I've certainly used almost identical > > scripts on the Raspberry Pi. > > > > I should perhaps put an example extlinux.conf into that repo too. > > > > I imagine (well, it's pretty much the whole point) that distro > > installers (e.g. Anaconda) will soon (or already do) support spitting > > out extlinux.conf that'll work on ARM U-Boot too. > > Hey Otavio, is OpenEmbedded doing this yet? I know there's > syslinux.conf support in since ages ago... It certainly is possible to do the same in OE. The process wasn't unified enough across the platforms in order to do that, though...
Hello Tom, On Wed, Feb 19, 2014 at 4:41 PM, Tom Rini <trini@ti.com> wrote: > On Wed, Feb 19, 2014 at 12:29:19PM -0700, Stephen Warren wrote: >> On 02/19/2014 12:24 PM, Dan Murphy wrote: >> ... >> > Do we have a directory where default scripts exist for each board? Or at least samples for each board? >> > >> > I could not find them. If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory >> > >> > Maybe this would be something that helps defined the known good config that the community can base their changes on. >> >> For Tegra, I have created: >> >> https://github.com/NVIDIA/tegra-uboot-scripts >> >> I imagine those scripts would work on most boards that use the U-Boot >> config in this patch series. I've certainly used almost identical >> scripts on the Raspberry Pi. >> >> I should perhaps put an example extlinux.conf into that repo too. >> >> I imagine (well, it's pretty much the whole point) that distro >> installers (e.g. Anaconda) will soon (or already do) support spitting >> out extlinux.conf that'll work on ARM U-Boot too. > > Hey Otavio, is OpenEmbedded doing this yet? I know there's > syslinux.conf support in since ages ago... As Denys said it is not yet supported but should be easily doable. :-)
On Thu, Feb 20, 2014 at 09:31:36AM -0300, Otavio Salvador wrote: > Hello Tom, > > On Wed, Feb 19, 2014 at 4:41 PM, Tom Rini <trini@ti.com> wrote: > > On Wed, Feb 19, 2014 at 12:29:19PM -0700, Stephen Warren wrote: > >> On 02/19/2014 12:24 PM, Dan Murphy wrote: > >> ... > >> > Do we have a directory where default scripts exist for each board? Or at least samples for each board? > >> > > >> > I could not find them. If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory > >> > > >> > Maybe this would be something that helps defined the known good config that the community can base their changes on. > >> > >> For Tegra, I have created: > >> > >> https://github.com/NVIDIA/tegra-uboot-scripts > >> > >> I imagine those scripts would work on most boards that use the U-Boot > >> config in this patch series. I've certainly used almost identical > >> scripts on the Raspberry Pi. > >> > >> I should perhaps put an example extlinux.conf into that repo too. > >> > >> I imagine (well, it's pretty much the whole point) that distro > >> installers (e.g. Anaconda) will soon (or already do) support spitting > >> out extlinux.conf that'll work on ARM U-Boot too. > > > > Hey Otavio, is OpenEmbedded doing this yet? I know there's > > syslinux.conf support in since ages ago... > > As Denys said it is not yet supported but should be easily doable. :-) Well, can I suggest / beg that we get started? :) I'd love to see OE be ready when this is out in the next release.
On Wed, 19 Feb 2014 10:40:15 -0700 Stephen Warren <swarren@wwwdotorg.org> wrote: > On 02/17/2014 10:56 AM, Dennis Gilmore wrote: > > Signed-off-by: Dennis Gilmore <dennis@ausil.us> > > Patch description? I failed in my rush to get it out for feedback. > > diff --git a/include/config_distro_bootcmd.h > > b/include/config_distro_bootcmd.h > > > +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H > > +#define _CONFIG_CMD_DISTRO_BOOTCMD_H > > + > > + > > Is there a need for 2 blank lines there? no, will clean it up > > +#define BOOTCMDS_COMMON \ > > + "rootpart=1\0" \ > > We should really stop hard-coding that. I meant to (but evidently > never got around to) re-write the commands so that they could > automatically determine which partition to use, based on the MBR > bootable flag or GPT partition flags. > > Still, we can probably make that enhancement separately later. I fully agree, we should be able to work it out later. I also renamed it to bootpart since it is where we will boot from, which may or may not be the root filesystem > > +#define BOOT_TARGETS_MMC "mmc1 mmc0" > > We really ought to make the order of multiple MMC devices in > BOOT_TARGETS configurable. For example, we may have 2 boards that both > want to boot from SD card if present, else fall back to internal eMMC, > yet one has mmc0=eMMC,mmc1=SD, and the other mmc0=SD,mmc1=eMMC. On > Tegra, we're just lucky that hasn't been an issue yet. Equally, not > all boards have 2 eMMC devices. I did wonder if that was better being left out here and something that the board set. > > + "scan_boot=" > > \ > > + "echo Scanning ${devtype} ${devnum}...; > > " \ > > + "for prefix in ${boot_prefixes}; do > > " \ > > + "run sysboot_boot; > > " \ > > + "run envimport; > > " \ > > + "run script_boot; > > " \ > > This isn't quite right for the Raspberry Pi at least. > > What I wanted was for uEnv.txt to *always* be loaded from SD card > before any other boot activity. The SD card is known to exist on this > platform, since it's the only place the SoC's boot ROM can load the > initial binary firmware from. I know some distros use commands in uEnv.txt to boot, or at the least they set variables and load a boot.scr I was trying to make sure we cover those people. The definition of what uEnv.txt is and how it should be used is pretty murky to me. I have seen it used in a few different ways. I know some people really want them. So probably best to work out a better way to support it. http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-uEnv.txtbasedbootscript for instance specifies all the boot commands in uEnv.txt really I would rather people just use a extlinux.conf file, I just do not want to take away the option to use something people see as valuable. > The idea is that since the Pi has nowhere to store any environment, > and the default environment's boot_targets is hard-coded in the U-Boot > binary, we need some way for the user to configure the value of > boot_targets to e.g. force network or USB boot. We want to do this > before executing bootcmd, so that bootcmd looks at the user's desired > boot_targets, rather than part way through executing bootcmd, which is > far too late. > > Now, on the Pi, this all happens via CONFIG_PREBOOT, so it will still > work even with the "run envimport" as above. However, I think we want > to make the "run envimport" within scan_boot optional, so it doesn't > get repeated. > > I wouldn't be surprised if other platforms ought to be working in the > exact same way? > > > + "boot_targets=" \ > > + BOOT_TARGETS_MMC " " \ > > + BOOT_TARGETS_USB " " \ > > + BOOT_TARGETS_SATA " " \ > > + BOOT_TARGETS_PXE " " \ > > + BOOT_TARGETS_DHCP " " \ > > + "\0" \ > > I'd be tempted to require the board-specific config to set > boot_targets, so that appropriate customization can be applied? sure, Ideally its something that can be changed on the fly and we just ship a suggested ordering. That is probably something for down the road though. > > + "boot_envs=uEnv.txt\0" \ > > I wonder if boards want to customize that for backwards-compatibility? Perhaps. Might need to redo some of this. I've since added SCSI and IDE and they are things I have seen in the wild also. Maybe we can simplify things somehow so that adding new hardware types is really simple. Dennis
Hello Tom, On Thu, Feb 20, 2014 at 10:46 AM, Tom Rini <trini@ti.com> wrote: > On Thu, Feb 20, 2014 at 09:31:36AM -0300, Otavio Salvador wrote: >> Hello Tom, >> >> On Wed, Feb 19, 2014 at 4:41 PM, Tom Rini <trini@ti.com> wrote: >> > On Wed, Feb 19, 2014 at 12:29:19PM -0700, Stephen Warren wrote: >> >> On 02/19/2014 12:24 PM, Dan Murphy wrote: >> >> ... >> >> > Do we have a directory where default scripts exist for each board? Or at least samples for each board? >> >> > >> >> > I could not find them. If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory >> >> > >> >> > Maybe this would be something that helps defined the known good config that the community can base their changes on. >> >> >> >> For Tegra, I have created: >> >> >> >> https://github.com/NVIDIA/tegra-uboot-scripts >> >> >> >> I imagine those scripts would work on most boards that use the U-Boot >> >> config in this patch series. I've certainly used almost identical >> >> scripts on the Raspberry Pi. >> >> >> >> I should perhaps put an example extlinux.conf into that repo too. >> >> >> >> I imagine (well, it's pretty much the whole point) that distro >> >> installers (e.g. Anaconda) will soon (or already do) support spitting >> >> out extlinux.conf that'll work on ARM U-Boot too. >> > >> > Hey Otavio, is OpenEmbedded doing this yet? I know there's >> > syslinux.conf support in since ages ago... >> >> As Denys said it is not yet supported but should be easily doable. :-) > > Well, can I suggest / beg that we get started? :) I'd love to see OE be > ready when this is out in the next release. Yes; I will start looking how to integrate it.
On 02/22/2014 01:20 AM, Dennis Gilmore wrote: > On Wed, 19 Feb 2014 10:40:15 -0700 Stephen Warren <swarren@wwwdotorg.org> wrote: >> On 02/17/2014 10:56 AM, Dennis Gilmore wrote: >>> diff --git a/include/config_distro_bootcmd.h >>> +#define BOOTCMDS_COMMON \ >>> + "rootpart=1\0" \ >> >> We should really stop hard-coding that. I meant to (but evidently >> never got around to) re-write the commands so that they could >> automatically determine which partition to use, based on the MBR >> bootable flag or GPT partition flags. >> >> Still, we can probably make that enhancement separately later. > > I fully agree, we should be able to work it out later. I also renamed > it to bootpart since it is where we will boot from, which may or may > not be the root filesystem Just as some history, when I first wrote these boot scripts for Tegra, I was actually using that variable both inside the environment scripts to find/load boot.scr, and within boot.scr to set the kernel root= command-line option. More recently, I've moved to using root=PARTUUID= or root=UUID= on the kernel command-line, so rootpart has become less relevant, and indeed renaming it bootpart does make a lot more sense, as you say. >>> + "scan_boot=" >>> \ >>> + "echo Scanning ${devtype} ${devnum}...; >>> " \ >>> + "for prefix in ${boot_prefixes}; do >>> " \ >>> + "run sysboot_boot; >>> " \ >>> + "run envimport; >>> " \ >>> + "run script_boot; >>> " \ >> >> This isn't quite right for the Raspberry Pi at least. >> >> What I wanted was for uEnv.txt to *always* be loaded from SD card >> before any other boot activity. The SD card is known to exist on this >> platform, since it's the only place the SoC's boot ROM can load the >> initial binary firmware from. > > I know some distros use commands in uEnv.txt to boot, or at the least > they set variables and load a boot.scr I was trying to make sure we > cover those people. The definition of what uEnv.txt is and how it > should be used is pretty murky to me. I have seen it used in a few > different ways. I know some people really want them. So probably best > to work out a better way to support it. > http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-uEnv.txtbasedbootscript > for instance specifies all the boot commands in uEnv.txt really I would > rather people just use a extlinux.conf file, I just do not want to take > away the option to use something people see as valuable. I'd suggest not touching uEnv.txt in config_distro_bootcmd.h, since it's really not a part of the new standard we want to create. Instead, have each board define CONFIG_PREBOOT to load it if they want it. I assume that a very small number of boards will need uEnv.txt once we've switched to this new scheme; just those that have nowhere to store a persistent environment.
On Mon, Feb 24, 2014 at 11:40:02AM -0700, Stephen Warren wrote: > On 02/22/2014 01:20 AM, Dennis Gilmore wrote: [snip] > > I fully agree, we should be able to work it out later. I also renamed > > it to bootpart since it is where we will boot from, which may or may > > not be the root filesystem > > Just as some history, when I first wrote these boot scripts for Tegra, I > was actually using that variable both inside the environment scripts to > find/load boot.scr, and within boot.scr to set the kernel root= > command-line option. More recently, I've moved to using root=PARTUUID= > or root=UUID= on the kernel command-line, so rootpart has become less > relevant, and indeed renaming it bootpart does make a lot more sense, as > you say. For distro, this, oh my yes, this, is pretty nearly a must. This dislodged something in my brain which reminded me of a pain point we have on some TI parts, which is which MMC device will the kernel have as mmc0 vs mmc1 as because of regulartors, deferred probing and all of that, it's board design dependent. But passing in root=UUID= like commodity distros have done for ages makes this irrelevant. We need to do this such that either can be used, probably as root= being something that's given to us, rather than assumed by us. But I would be sad if everyone stopped using root=UUID= and started using /dev/mmcblk* names in the commodity distro area.
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h new file mode 100644 index 0000000..d32dc12 --- /dev/null +++ b/include/config_distro_bootcmd.h @@ -0,0 +1,172 @@ +/* + * (C) Copyright 2014 + * NVIDIA Corporation <www.nvidia.com> + * + * Copyright 2014 Red Hat, Inc. + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H +#define _CONFIG_CMD_DISTRO_BOOTCMD_H + + +#ifdef CONFIG_CMD_MMC +#define BOOTCMDS_MMC \ + "mmc_boot=" \ + "setenv devtype mmc; " \ + "if mmc dev ${devnum}; then " \ + "run scan_boot; " \ + "fi\0" \ + "bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \ + "bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0" +#define BOOT_TARGETS_MMC "mmc1 mmc0" +#else +#define BOOTCMDS_MMC "" +#define BOOT_TARGETS_MMC "" +#endif + +#ifdef CONFIG_CMD_USB +#define BOOTCMD_INIT_USB "run usb_init; " +#define BOOTCMDS_USB \ + "usb_init=" \ + "if ${usb_need_init}; then " \ + "set usb_need_init false; " \ + "usb start 0; " \ + "fi\0" \ + \ + "usb_boot=" \ + "setenv devtype usb; " \ + BOOTCMD_INIT_USB \ + "if usb dev ${devnum}; then " \ + "run scan_boot; " \ + "fi\0" \ + \ + "bootcmd_usb0=setenv devnum 0; run usb_boot;\0" +#define BOOT_TARGETS_USB "usb0" +#else +#define BOOTCMD_INIT_USB "" +#define BOOTCMDS_USB "" +#define BOOT_TARGETS_USB "" +#endif + +#ifdef CONFIG_CMD_SATA +#define BOOTCMDS_SATA \ + "sata_boot=" \ + "setenv devtype sata; " \ + "if sata dev ${devnum}; then " \ + "run scan_boot; " \ + "fi\0" \ + \ + "bootcmd_sata0=setenv devnum 0; run sata_boot;\0" + "bootcmd_sata1=setenv devnum 1; run sata_boot;\0" +#define BOOT_TARGETS_USB "sata0 sata1" +#else +#define BOOTCMDS_SATA "" +#define BOOT_TARGETS_SATA "" +#endif + +#ifdef CONFIG_CMD_DHCP +#define BOOTCMDS_DHCP \ + "bootcmd_dhcp=" \ + BOOTCMD_INIT_USB \ + "if dhcp ${scriptaddr} boot.scr.uimg; then "\ + "source ${scriptaddr}; " \ + "fi\0" +#define BOOT_TARGETS_DHCP "dhcp" +#else +#define BOOTCMDS_DHCP "" +#define BOOT_TARGETS_DHCP "" +#endif + +#if defined(CONFIG_CMD_DHCP) && defined(CONFIG_CMD_PXE) +#define BOOTCMDS_PXE \ + "bootcmd_pxe=" \ + BOOTCMD_INIT_USB \ + "dhcp; " \ + "if pxe get; then " \ + "pxe boot; " \ + "fi\0" +#define BOOT_TARGETS_PXE "pxe" +#else +#define BOOTCMDS_PXE "" +#define BOOT_TARGETS_PXE "" +#endif + +#define BOOTCMDS_COMMON \ + "rootpart=1\0" \ + \ + "do_envimport=" \ + "load ${devtype} ${devnum}:${rootpart} ${loadaddr} " \ + "${environment}\0" \ + "env import -t ${loadaddr} $filesize\0" \ + \ + "envimport=" \ + "for environment in ${boot_envs}; do " \ + "if test -e ${devtype} ${devnum}:${rootpart} " \ + "${prefix}${environment}; then " \ + "echo Found U-Boot environment " \ + "${prefix}${environment}; " \ + "run do_envimport;" \ + "echo Import FAILED; continuing...; " \ + "fi; " \ + "done\0" \ + \ + "do_script_boot=" \ + "load ${devtype} ${devnum}:${rootpart} " \ + "${scriptaddr} ${prefix}${script}; " \ + "source ${scriptaddr}\0" \ + \ + "script_boot=" \ + "for script in ${boot_scripts}; do " \ + "if test -e ${devtype} ${devnum}:${rootpart} " \ + "${prefix}${script}; then " \ + "echo Found U-Boot script " \ + "${prefix}${script}; " \ + "run do_script_boot;" \ + "echo SCRIPT FAILED; continuing...; " \ + "fi; " \ + "done\0" \ + \ + "do_sysboot_boot=" \ + "sysboot ${devtype} ${devnum}:${rootpart} any " \ + "${scriptaddr} ${prefix}extlinux/extlinux.conf\0" \ + \ + "sysboot_boot=" \ + "if test -e ${devtype} ${devnum}:${rootpart} " \ + "${prefix}extlinux/extlinux.conf; then " \ + "echo Found extlinux config " \ + "${prefix}extlinux/extlinux.conf; " \ + "run do_sysboot_boot;" \ + "echo SYSBOOT FAILED; continuing...; " \ + "fi\0" \ + \ + "scan_boot=" \ + "echo Scanning ${devtype} ${devnum}...; " \ + "for prefix in ${boot_prefixes}; do " \ + "run sysboot_boot; " \ + "run envimport; " \ + "run script_boot; " \ + "done\0" \ + \ + "boot_targets=" \ + BOOT_TARGETS_MMC " " \ + BOOT_TARGETS_USB " " \ + BOOT_TARGETS_SATA " " \ + BOOT_TARGETS_PXE " " \ + BOOT_TARGETS_DHCP " " \ + "\0" \ + \ + "boot_prefixes=/ /boot/\0" \ + \ + "boot_scripts=boot.scr.uimg boot.scr\0" \ + \ + "boot_envs=uEnv.txt\0" \ + \ + BOOTCMDS_MMC \ + BOOTCMDS_USB \ + BOOTCMDS_SATA \ + BOOTCMDS_DHCP \ + BOOTCMDS_PXE + +#endif /* _CONFIG_CMD_DISTRO_BOOTCMD_H */
Signed-off-by: Dennis Gilmore <dennis@ausil.us> --- include/config_distro_bootcmd.h | 172 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 172 insertions(+) create mode 100644 include/config_distro_bootcmd.h