[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Tom Rini]

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

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140219/7cc59b49/attachment.pgp>