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
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.
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
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.
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.
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.
ideally the devicetree files need to be decoupled from the kernel,
along the lines of what is being discussed in the kernel now[2].
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
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.
longer term being able to edit the boot arguments should also be an
option with the menu functionality.
"""
# 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.
What this gets us in the end is that with a unified kernel, device tree
and u-boot implementing the system specific knowledge, supporting new
ARM systems is along the same lines as supporting new x86 systems. Get
the drivers and platform support in the mainline kernel and as long as
the Distro enables it it will just work in the next OS release. The one
part then that we as Distro's need to do is to ensure we install
u-boot into the disk correctly for the board in question if it is a
system that does not ship with some kind of storage for u-boot. If it
is a system with NOR, Nand, SPI storage for u-boot it is then entirely
in the vendors hand, and assuming that they implement everything, all
distros will be able to simply support them. Giving users and vendors
more choice in what to run on their hardware.
I may not be entirely clear here and there may be things I am missing,
I feel it is a good place to start the discussion.
Regards
Dennis
[1] http://lists.denx.de/pipermail/u-boot/2013-July/159522.html
[2] https://lwn.net/Articles/560523/
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
