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

Mon Aug 5 22:25:45 CEST 2013

On Mon, Aug 05, 2013 at 03:11:20PM -0500, Dennis Gilmore wrote:
> 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:
[snip]
> > > 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. 

Right.  So, lets me ask.  In .deb-based land, I build my own kernels,
and yelling cursing and screaming at the pains of doing things by hand,
I use the 'deb-pkg' target in the kernel as that hooks into all the
right things and I stop having to ^R/^O my history to not break my
system (or look at my own script or whatever).  What's it like in Fedora
land, with initramfses?  Do users do make bzImage/modules/install in the
kernel or expect to use rpm-pkg to get something that hooks in just
right?

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

Well, this is an important thing.  How does this work, or what are the
limits on x86?  If someone can go dig up the maximum uncompressed kernel
size before grub/syslinux/whathaveyou start stomping on ramdisks, we can
document that in whatever comes out of this saying that one must (using
spec language) make sure there's $X between the kernel and ramdisk load
addrs (and perhaps even X+Y so that we can place the device tree in
not-going-to-end-up-in-CONFIG_HIGHMEM-area).

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

See doc/README.falcon and then yes, we would need to say here are how
some parts of that (such as the don't try kernel, do u-boot key) are
set.

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

Good to hear!

-- 
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/cf703aaf/attachment.pgp>