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/