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

[Tom Rini]

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.

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

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

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

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

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

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

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!

-- 
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/20130805/500e580e/attachment.pgp>