[U-Boot] Unified u-boot feature set for simpler distro support

[Dennis Gilmore]

On Mon, 5 Aug 2013 15:01:32 -0400
Tom Rini <trini at ti.com> wrote:

> On Sat, Aug 03, 2013 at 02:11:04AM -0500, Dennis Gilmore wrote:
> 
> > Hi all,
> > 
> > I wanted to start a discussion on defining a unified feature set
> > that makes it simpler for the different distros to support ARM
> > systems using u-boot. I have based a lot of my thoughts on how
> > calxeda ship their systems configured as it works fairly well,
> > recently i sent in a patch implementing most of what I would like
> > to see for the wandboard[1]
> > 
> > right or wrong we want things to be simple for the user and to
> > largely look like a linux system on x86 would. The user and distro
> > should never need to worry about memory locations 
> 
> OK.  But lets remember up front that this is because in x86 land we've
> got a quite long standing fixed memory map.
yes, but omap, tegra, imx etc all know that they need to start at some
address 0x0000800, 0x10008000, 0x4000000 etc so the starting point is
known per soc.

> > so this would mean similar partitioning. i.e. /boot on ext4 root and
> > swap  on lvm or as raw partitions. people should be able to have
> > just / on ext4 also. Down the road xfs /boot support would be a
> > nice to have.
> 
> That's all distro-details, yes.  Support for reading files shoved
> inside filesystems inside containers is "just" a matter of
> developing / leveraging the code from elsewhere, if there's
> sufficient interest and desire.
absolutely, just in for completeness since some systems today don't
have ext4 support for instance.
 
> > pxe boot suport, two reasons, one is to be able to easily network
> > boot the distro installer, the other is to use sysboot support post
> > install with a extlinux.conf file to specify the kernel, initrd and
> > bootargs
> 
> So, CONFIG_CMD_PXE enabled, for part of it.  And someone to develop
> code to parse extlinux.conf which is the same config file PXELINUX
> uses, right, and then shoot up a menu based on it.

yes, the sysboot command that comes with CONFIG_CMD_PXE already does
it. 

> > bootz and raw initrd support. not having to wrap kernels and initrds
> > really is a must. raw initrd support means that its much simpler
> > for a user to rebuild an initramfs if needed and bootz means we do
> > not need to worry about making sure that we specify the correct
> > addresses to load the kernel to when calling mkimage.
> 
> bootz is fine, raw initrd is fine.  I would say that "updating the
> initramfs" is done by the distro scripts anyhow and not by hand from
> memory.
for the most part yes, its built at rpm install time. sometimes a user
decides to rebuild for different reasons. 
> 
> > when it comes to memory addressing a distro and user shouldn't need
> > to know anything. Ideally u-boot will auto allocate addresses based
> > on the size of loaded objects. starting with a base address
> > internal to u-boot you load a kernel, when loading an initramfs
> > u-boot automatically calculates an address that ensures it does not
> > overlap with the kernel. same for a fdt if loaded. I say auto
> > calculated because what we think today will be enough room may not
> > be tomorrow, dynamically calculating gives the flexibility for
> > whatever may come.
> 
> Well, how does this happen on x86, specifically for dealing with the
> kernel?
I'm not entirely sure dynamically assigned may not be feasible. just
trying to avoid unexpected boot failure in the future because we didnt
make sure there was enough room for something.

> > fdt will be automatically loaded and provided fedora ships dtbs
> > in /boot/dtb-<kernelver>/ I am not sure where other distros provide
> > them, however u-boot should automatically load dtb and provide
> > access to a fdt in a ${fdt_addr} variable that can be used by
> > pxe_cmd but still allows the user to specify their own in
> > extlinux.conf if desired.
> 
> I know Ubuntu shoves them under /lib, so this is an area where the
> distro-policy side of things will have to do some of the work.  U-Boot
> can say what the base-name is, but we need to be given the directory
> path.  I would also suggest at first that we don't want the user
> providing us memory locations to write this/that/something else to.

I totally agree distros need to come together here and agree on
something like we did with the hardware floating point linker location.
and memory locations need to be not provided.

> > ideally the devicetree files need to be decoupled from the kernel,
> > along the lines of what is being discussed in the kernel now[2].
> 
> Ideally, yes.  And for everyones sake I hope that when this does
> happen, some thought is given about how vendors should store things
> on the device.

> > Distros should agree on a single location for the dtbs to be
> > placed. /boot/dtb/ or /boot/dtbs/ are probably good locations.
> > u-boot can then look in the path with and without /boot
> 
> Yes, this is something the distros need to have a chat about and
> coordinate on.
> 
> > output and input should happen on all possible devices and not just
> > the serial console. If a user has a trimslice with only a HDMI
> > monitor and usb keyboard they should be able to see the menu
> > listing their possible kernels and be able to choose which one they
> > want to boot.
> 
> Sure, I believe this works today, for some values of boards with
> supported displays and USB keyboards.
> 
> > longer term being able to edit the boot arguments should also be an
> > option with the menu functionality.
> 
> Sure.
> 
> > 
> > """
> > # extlinux.conf generated by anaconda
> > 
> > ui menu.c32
> > 
> > menu autoboot Welcome to Fedora. Automatic boot in # second{,s}.
> > Press a key for options. menu title Fedora Boot Options.
> > menu hidden
> > 
> > timeout 60
> > #totaltimeout 9000
> > 
> > 
> > label Fedora (3.9.9-302.fc19.armv7hl) 19 (Schr??dinger???s Cat)
> > 	kernel /vmlinuz-3.9.9-302.fc19.armv7hl
> > 	append console=ttyAMA0,115200
> > root=UUID=04f8c4be-2890-4d26-bb79-e5555060a142 ro rhgb quiet
> > LANG=en_US.UTF-8 initrd /initramfs-3.9.9-302.fc19.armv7hl.img
> > 
> > label Fedora (3.9.4-301.fc19.armv7hl) 19 (Schr??dinger???s Cat)
> > 	kernel /vmlinuz-3.9.4-301.fc19.armv7hl
> > 	append console=ttyAMA0,115200
> > root=UUID=04f8c4be-2890-4d26-bb79-e5555060a142 ro rhgb quiet
> > LANG=en_US.UTF-8 initrd /initramfs-3.9.4-301.fc19.armv7hl.img """
> > the above is an example of a extlinux.conf file on a fedora 19
> > system that works with the u-boot as shipped by calxeda on thier
> > highbank energy cards. some of the valid extlinux options written
> > out by anaconda cause noise on ARM as they are not implemented
> > longer term it would be good to deal with them correctly.
> > """
> > Ignoring unknown command: ui
> > Ignoring malformed menu command:  autoboot
> > Ignoring malformed menu command:  hidden
> > Fedora Boot Options.
> > 1:	Fedora (3.9.9-302.fc19.armv7hl) 19 (Schr??dinger???s Cat)
> > 2:	Fedora (3.9.4-301.fc19.armv7hl) 19 (Schr??dinger???s Cat)
> > Enter choice: 
> > """
> > is the output on boot, the user can then enter 1 or 2 to select a
> > kernel to boot. if nothing is selected the first option is booted
> > after the timeout expires.
> 
> Sure.
> 
> Now, I'd like to make some, or at least one suggestion.  Distros
> should make use of falcon mode (SPL boots Linux directly), or at
> least offer it to the user.  Similar to how I can configure, in the
> distro, a grub menu to show up, timeout and boot a default, or just
> boot the default unless I'm spamming escape during boot-up.

If that's an option absolutely. I didn't mention it because I did not
think it was an option and I do not see it as necessary to unify
things. but it is a great usability option to have for users. how is it
configured?
 
> Now, since most of what you ask for exists today, can you write up
> what config options you'd want enabled and what a default environment
> looks like, for highbank or wandboard so that it works for generic
> distros, and we can start talking about what fallbacks would be
> needed so they can still be used in other contexts just as easily?
> 
> And when I say "Sure" above, I mean patches will be reviewed, if
> submitted.
> 
> Thanks!
> 
Thanks for the feedback. Most of what I want is there today and just
needs to be enabled.