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

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.

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

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 02/17/2014 10:56 AM, Dennis Gilmore wrote:

Signed-off-by: Dennis Gilmore dennis@ausil.us

Patch description?

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h

#define CONFIG_EXTRA_ENV_SETTINGS \ "loadaddr=0x80200000\0" \

• "fdtaddr=0x80F80000\0" \

• "fdt_addr=0x80F80000\0" \
• "fdt_addr_r=0x80F80000\0" \

Why set both? Surely only fdt_addr_r is required/useful?

• "mmcroot=/dev/mmcblk0p2 ro\0" \

That implies that rootpart=1 in config_distro_bootcmd.h isn't correct for this board?

• "rootpath=/export/rootfs\0" \
• "nfsopts=nolock\0" \
• "static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}" \

• "::off\0" \
  

• "ramroot=/dev/ram0 rw ramdisk_size=65536 initrd=${rdaddr},64M\0" \
• "ramrootfstype=ext2\0" \
• "mmcargs=setenv bootargs console=${console} " \

• "${optargs} " \
  

• "root=${mmcroot} " \
  

• "rootfstype=${mmcrootfstype}\0" \
  

• "spiroot=/dev/mtdblock4 rw\0" \
• "spirootfstype=jffs2\0" \
• "spisrcaddr=0xe0000\0" \
• "spiimgsize=0x362000\0" \
• "spibusno=0\0" \
• "spiargs=setenv bootargs console=${console} " \

• "${optargs} " \
  

• "root=${spiroot} " \
  

• "rootfstype=${spirootfstype}\0" \
  

• "netargs=setenv bootargs console=${console} " \

• "${optargs} " \
  

• "root=/dev/nfs " \
  

• "nfsroot=${serverip}:${rootpath},${nfsopts} rw " \
  

• "ip=dhcp\0" \
  

I'm not at all familiar with this board, but this seems to be removing NFS and SPI boot capabilities, maybe others too?

On 02/19/2014 01:57 PM, Dan Murphy wrote:

On 02/17/2014 11:56 AM, Dennis Gilmore wrote:

Missing commit log as well

...

Signed-off-by: Dennis Gilmore dennis@ausil.us

include/configs/am335x_evm.h | 109 ++++---------------------------------- include/configs/ti_armv7_common.h | 28 ++-------- 2 files changed, 16 insertions(+), 121 deletions(-)

<snip>

On 02/19/2014 02:05 PM, Stephen Warren wrote:

On 02/19/2014 12:57 PM, Dan Murphy wrote:

...

On 02/17/2014 11:56 AM, Dennis Gilmore wrote:

...

...

...

+#ifndef CONFIG_SPL_BUILD +#include <config_distro_defaults.h>

I did not see the patchset for this.

Should this header and the removal the extra configs be a different patch? Or be part of the series that introduces the distro defaults

The following is already in u-boot/master: 13a49c3a739b config: add config_distro_defaults.h

I've sent patches to convert Tegra and RPi to use it, although they aren't applied yet.

Great! So why did this change come in as part of the RFC and not a patch for review and merge?

Dan

On 02/19/2014 02:22 PM, Stephen Warren wrote:

On 02/19/2014 01:20 PM, Dan Murphy wrote:

...

On 02/19/2014 02:05 PM, Stephen Warren wrote:

...

On 02/19/2014 12:57 PM, Dan Murphy wrote:

...

On 02/17/2014 11:56 AM, Dennis Gilmore wrote:

...

...

...

+#ifndef CONFIG_SPL_BUILD +#include <config_distro_defaults.h>

I did not see the patchset for this.

Should this header and the removal the extra configs be a different patch? Or be part of the series that introduces the distro defaults

The following is already in u-boot/master: 13a49c3a739b config: add config_distro_defaults.h

I've sent patches to convert Tegra and RPi to use it, although they aren't applied yet.

Great! So why did this change come in as part of the RFC and not a patch for review and merge?

Because it needed discussion/comments from the owners of the affected files perhaps?

Agreed to the discussion/comments. But this change is not relevant to converting to a common boot right? And it is kinda buried in this patch and might be over looked. I guess the same can be said for the wandboard patch.

IMHO These changes should be broken out, reviewed then they can be merged quicker if not part of this RFC.

Dan

On 02/19/2014 02:38 PM, Stephen Warren wrote:

On 02/19/2014 01:31 PM, Dan Murphy wrote:

...

On 02/19/2014 02:22 PM, Stephen Warren wrote:

...

On 02/19/2014 01:20 PM, Dan Murphy wrote:

...

On 02/19/2014 02:05 PM, Stephen Warren wrote:

...

On 02/19/2014 12:57 PM, Dan Murphy wrote:

...

On 02/17/2014 11:56 AM, Dennis Gilmore wrote:

...

...

> +#ifndef CONFIG_SPL_BUILD > +#include <config_distro_defaults.h> I did not see the patchset for this.

Should this header and the removal the extra configs be a different patch? Or be part of the series that introduces the distro defaults

The following is already in u-boot/master: 13a49c3a739b config: add config_distro_defaults.h

I've sent patches to convert Tegra and RPi to use it, although they aren't applied yet.

Great! So why did this change come in as part of the RFC and not a patch for review and merge?

Because it needed discussion/comments from the owners of the affected files perhaps?

Agreed to the discussion/comments. But this change is not relevant to converting to a common boot right? And it is kinda buried in this patch and might be over looked. I guess the same can be said for the wandboard patch.

IMHO These changes should be broken out, reviewed then they can be merged quicker if not part of this RFC.

??? The whole point of this series is to convert the 2 boards to use the two headers that define a standardized set of U-Boot options (the header for which has already been merged) and a standardized set of U-Boot scripts (the header for which is part of this patch series). Splitting them up makes no sense at all.

Hey it was just my opinion. (I just like functional changes broken out for bissectability when debugging issues)

But that is ultimately up to the maintainer to decide in the end. I will attempt to review it when it comes in as an official patchset.

Dan

On 02/17/2014 10:56 AM, Dennis Gilmore wrote:

Signed-off-by: Dennis Gilmore dennis@ausil.us

diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h

• "netargs=setenv bootargs console=${console},${baudrate} " \

• "root=/dev/nfs " \
  

• "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \

• "netboot=echo Booting from net ...; " \
  

• "run netargs; " \
  

• "if test ${ip_dyn} = yes; then " \
  

• 	"setenv get_cmd dhcp; " \
  

• "else " \
  

• 	"setenv get_cmd tftp; " \
  

...

This one also removes nfsroot stuff.

Admittedly I would personally argue that nfsroot setup belong in the boot.scr that comes from some TFTP server, and I wrote the Tegra boot scripts assuming that, but I probably got away with that for Tegra since we never had any nfsroot setup in the default environment. People using these boards might like to keep their working features:-) Perhaps we could persuade people to adapt though?

On Tue, 18 Feb 2014 11:18:22 +0100 Stefano Babic sbabic@denx.de wrote:

Hi Dennis,

On 17/02/2014 18:56, Dennis Gilmore wrote:

...

Hi All,

The attached patches build on the work for generic distro config, as well as Stephen Warrens implementation for tegra.

First, thanks to make order on this issue.

...

I have added a header to be included that will allow all boards to boot in the same way and I have ported over two boards to use it. One thought I have had is to move the environment into the same header as the generic config.

I think this is currently the best solution.

...

I am also working on writing a README.distro file to document everything that needs to be set for everything to just work. Along with information on how to best choose memory locations.

Ok, let's see. This seems quite board-depending, I do not know if we find a common solution. But we can find an agreement about a generic set of variables/scripts, that all boards can reuse.

There will always be some board specific things like memory locations etc. None of the boot logic is board specific. Some features are hardware specific, i.e. PXE boot support is only configured if the hardware supports it same for SATA.

I'm putting what I have for the documentation so far at the end of this email. I think that soc families should have a common settings file, each board should have its on file and then we have a common set of configurations on how to boot.

Dennis

/* * (C) Copyright 2014 Red Hat Inc. * * SPDX-License-Identifier: GPL-2.0+ */

Generic distro configuration

configuring ----------- To configure a board to run the generic distro setup and enable generic distros to easily support your board.

you will need to include a pair of headers to enable the boot environment and configuration options needed. It is best to only include when not doing an SPL build.

#ifndef CONFIG_SPL_BUILD #include <config_distro_defaults.h> #include <config_distro_bootcmd.h> #endif

There is some memory addresses you will need to define in CONFIG_EXTRA_ENV_SETTINGS fdt_addr: Optional, if specified a dtb to boot the system needs to be available at the address.

fdt_addr_r: Mandatory, This is the location where the sysboot/pxeboot with load the dtb to, using the fdtdir/devicetreedir or fdt/devicetree options in the pxe/extlinux config file. The location can be anywhere in ram it just needs to not overlap with anything, allowing 1 megabyte seems to be a safe option.

ramdisk_addr_r: Mandatory, This is the location where the sysboot/pxeboot with load the initramfs to, using the initrd option in the pxe/extlinux config file, the location of the initramfs does not matter, there needs to be enough room to be able to store any image. Making the image the last item stored should allow for any initramfs to fit and not overwrite anything else.

kernel_addr_r: Mandatory,

pxe_addr_r: Mandatory, used by the PXE code to hold the pxelinux config file. The location can be anywhere in ram it just needs to not overlap with anything, allowing 1 megabyte seems to be a safe option.

scriptaddr: Mandatory,

suggested mapping: 16M

make sure you also include BOOTCMDS_COMMON in CONFIG_EXTRA_ENV_SETTINGS

booting your system ------------------- in the most simplest form CONFIG_BOOTCOMMAND just needs one line

"for target in ${boot_targets}; do run bootcmd_${target}; done"

you can run any setup before going through the targets for example run a command to set "fdtfile" variable for the dtb for your board.

Dennis

On Thu, Mar 20, 2014 at 05:12:56PM -0500, Dennis Gilmore wrote:

Add documentation on how to setup a system to use the generic distro configs and boot commands. This spells out what is needed to make a system conformant, but does not limit the board to only the defaults.

Signed-off-by: Dennis Gilmore dennis@ausil.us

[snip]

+suggested mapping: +For suggestions on memory locations for arm systems you must follow the +guidelines specified in Documentation/arm/Booting in the Linux kernel tree. +For other architectures you must follow the guidelines for the architecture.

Can you add something about what this means? ie below base+128MB for kernel, because of this if possible base+128MB for fdt, fdt+512KB for ramdisk. And mention bootm_size to limit the relocation pool as well.

Thanks!

On 03/20/2014 04:12 PM, Dennis Gilmore wrote:

Add documentation on how to setup a system to use the generic distro configs and boot commands. This spells out what is needed to make a system conformant, but does not limit the board to only the defaults.

diff --git a/doc/README.distro b/doc/README.distro

+There is some memory addresses you will need to define in +CONFIG_EXTRA_ENV_SETTINGS +fdt_addr: +Optional, If specified a dtb to boot the system must be available at the given +address.

Perhaps add "when the kernel is booted"? To avoid someone putting it somewhere that will get over-written between when U-Boot starts and the kernel is booted.

+fdt_addr_r: +Mandatory, This is the location where the sysboot/pxeboot with load the dtb to,

s/with/will/ Both here and other place(s).

+using the fdtdir/devicetreedir or fdt/devicetree options in the pxe/extlinux +config file. The location can be anywhere in ram it just needs to not overlap +with anything, allowing 1 megabyte seems to be a safe option.

Related to Tom's comments, I think saying that the location doesn't matter isn't quite true. For example, an ARM zImage assumes it's located with the first 128M of RAM, and will decompress the image to the start of RAM. If the DTB was located in the decompression target region, it would at least need to be moved by the decompressor (wasted effort) or perhaps just get blindly over-written (boot fails).

+ramdisk_addr_r: +Mandatory, This is the location where the sysboot/pxeboot with load the +initramfs to, using the initrd option in the pxe/extlinux config file, the +location of the initramfs does not matter, there needs to be enough room to be +able to store any image. Making the image the last item stored should allow for +any initramfs to fit and not overwrite anything else.

"last item" could refer to time not space. Perhaps s/Making the image the last item stored/Placing the image higher in RAM than any other image/

+kernel_addr_r: +Mandatory, This is the location where the sysboot/pxeboot with load the kernel +to,using the kernel option in the pxe/extlinux config file, the location of the +kernel needs to

That sentence isn't complete.

+You should not set initrd_high and fdt_high to 0xffffffff as the user should +not need to edit the memory locations having the initramfs and dtb being +relocatable is best to ensure the system will boot in all situations.

Perhaps CONFIG_SYS_BOOTMAPSZ is worth a mention too. The commit description for 7f1b767aea94 "ARM: tegra: define CONFIG_SYS_BOOTMAPSZ" might be useful when writing this part of the document.

+booting your system +------------------- +in the most simplest form CONFIG_BOOTCOMMAND just needs one line

+"for target in ${boot_targets}; do run bootcmd_${target}; done "

+you can run any setup before going through the targets for example run a +command to set "fdtfile" variable for the dtb for your board.

Isn't this automatic based on using config_distro_defaults.h? It seems like it should be, and it is were, you wouldn't need this section of this document at all; it's happen automatically.

On 03/28/2014 09:42 AM, Tom Rini wrote:

On Tue, Mar 25, 2014 at 02:24:14PM -0600, Stephen Warren wrote:

...

On 03/20/2014 04:12 PM, Dennis Gilmore wrote:

[snip]

...

...

+You should not set initrd_high and fdt_high to 0xffffffff as the user should +not need to edit the memory locations having the initramfs and dtb being +relocatable is best to ensure the system will boot in all situations.

Perhaps CONFIG_SYS_BOOTMAPSZ is worth a mention too. The commit description for 7f1b767aea94 "ARM: tegra: define CONFIG_SYS_BOOTMAPSZ" might be useful when writing this part of the document.

I would swear (and I just dug up the notes from the last time I was looking at this) that no, CONFIG_SYS_BOOTMAPSZ is not sufficient because it doesn't cover the ramdisk case, which is important for generic distro, unless you also add in initrd_high=top-of-lowmem-value or know it'll be in an always-good spot and set it to 0xffffffff.

Isn't that a bug? In other words, shouldn't CONFIG_SYS_BOOTMAPSZ affect a ramdisk too?

On Thu, Mar 20, 2014 at 05:12:57PM -0500, Dennis Gilmore wrote:

As the next step in a generic config we are introducing a set of generic boot paramaters. Depending on the hardwares configuration, booting from supported hardware will be enabled, mmc, usb, sata, scsi, ide, pxe and dhcp.

There is nothing to stop this being extended to support nand and any other type of storage that comes along. An ideal future enhancement will be to allow the user to dynamically reorder the boot devices, and allow one off boots. for example simply be able to pxe boot to reinstall

[snip]

• "bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \
• "bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0"

+#define BOOT_TARGETS_MMC "mmc1 mmc0"

This is because we want to prefer eMMC to SD card? Or is mmc1=SD, mmc0=eMMC on Tegra? That's opposite of TI parts so we might need to #ifndef/define/endif that combo at least.

Otherwise:

Reviewed-by: Tom Rini trini@ti.com

On 03/20/2014 04:12 PM, Dennis Gilmore wrote:

As the next step in a generic config we are introducing a set of generic boot paramaters. Depending on the hardwares configuration, booting from supported hardware will be enabled, mmc, usb, sata, scsi, ide, pxe and dhcp.

There is nothing to stop this being extended to support nand and any other type of storage that comes along. An ideal future enhancement will be to allow the user to dynamically reorder the boot devices, and allow one off boots. for example simply be able to pxe boot to reinstall

One-off boots can already be performed: "run bootcmd_mmc1" or "run bootcmd_dhcp" work for me.

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

Nit: double blank line there.

+#ifdef CONFIG_CMD_MMC +#define BOOTCMDS_MMC \

• "mmc_boot=" \

• "setenv devtype mmc; " \
  

• "if mmc dev ${devnum}; then " \
  

• 	"run scan_boot; " \
  

• "fi\0" \
  

• "bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \
• "bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0"

+#define BOOT_TARGETS_MMC "mmc1 mmc0"

It would be nice if this required the file that includes this file to define how many MMC devices there are (some only have 1...) and the best default boot order.

Still, that's probably challenging using the C pre-processor. Perhaps a Python script to auto-generate these command could be more flexible. Probably a job for a follow-on patch though.

+#define BOOTCMDS_COMMON \

• "rootpart=1\0" \
• \
• "do_envimport=" \

• "load ${devtype} ${devnum}:${rootpart} ${loadaddr} "      \
  

• 	"${environment}\0"                                \
  

• "env import -t ${loadaddr} $filesize\0"                   \
  

I think that should be:

if load ....; then env import ...; fi

So the script doesn't accidentally import something stale at $loadaddr that wasn't actually loaded.

• \
• "envimport=" \

• "for environment in ${boot_envs}; do "                    \
  

• 	"if test -e ${devtype} ${devnum}:${rootpart} "    \
  

• 			"${prefix}${environment}; then "  \
  

• 		"echo Found U-Boot environment "          \
  

• 			"${prefix}${environment}; "       \
  

• 		"run do_envimport;"                       \
  

• 		"echo Import FAILED; continuing...; "     \
  

• 	"fi; "                                            \
  

• "done\0"                                                  \
  

• \

envimport doesn't actually seem to be used anywhere at least in this patch. Is it really needed? It shouldn't be needed for generic distro support, but more for boards without any non-filesystem-based environment storage, and in those cases, shouldn't they use CONFIG_PREBOOT like rpi_b.h does, so it's well-defined where the environment comes from, before ${boot_targets} is evaluated?

• "do_script_boot=" \

• "load ${devtype} ${devnum}:${rootpart} "                  \
  

• 	"${scriptaddr} ${prefix}${script}; "              \
  

• "source ${scriptaddr}\0"                                  \
  

That should be "if load ; ...; fi" too. Sorry, the Tegra/RPI scripts give bad examples for this.

On 03/20/2014 04:13 PM, Dennis Gilmore wrote:

some boards have used fdt_file while others have used fdtfile to define the name of the fdt file. If we do notget a fdtfile environment variable, additionally check for fdt_file.

Is this variable typically set by the user or by the default environment? If the default environment, perhaps the variable name could simply be changed?

Still, this change is fine by me, Acked-by: Stephen Warren <swarren@nvidia.com

diff --git a/common/cmd_pxe.c b/common/cmd_pxe.c

• 	if (!f1) {
  

• 		f1 = getenv("fdt_file");
  

• 	}
  

Doesn't checkpatch say to remove the {} there?