Dear Dennis Gilmore,
In message 20130803021104.1fecaf5a@adria.ausil.us you wrote:
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
When talking about simplifying and unifying things, you should not start with the mistake of an architecture specific view. ARM may be what you are interested in, and where most of the current development is happening, but it is not the only architecture around.
Also, it may make sense to start with leaning back a bit and looking how other architectures solved some of the issues ARM is having. My feeling is that some of them are actually home-made.
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
Actually it is a horror thought to me that U-Boot could degrade into such a horrible envrionment as the boot loaders (BIOS, UEFI etc.) provide, both to the developer and to the end user.
No, this is definitely NOT where we waht to head for.
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.
This may be interesting for you, but faci it: the majority of boards are not using ext4 based root file systems, nor xfs. Most of them are strictly embedded devices, and the use of JFFS2 (yes, still!) and UBI/UBIFS on NOR and NAND flash is far more common.
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
PXE may be interesting for a very small percentage of applications, but it is nothing to unify on. Existing DHCP / TFTP / NFS support is much more commonly used.
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
Actually this is strictly an ARM issue. No other architecture has such problems. U-Boot images (both the old, legacy uImage format, and much more so the FIT imagesformat) have a large number of advantages, especially for software management on embedded systems.
Also, a pretty common requirement in U-Boot land is boot time optimization. The common approach of standard distros with a multi-stage intialization sequence including booting from an intial ramdisk before mounting the real root file system is usually prohibitive in such szenarios.
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.
Again, this is a problem home-made by ARM Linux. I am not ware of any such issues with other architectures.
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.
This is easy to say, but difficult to impossible to implement in the general case. The problem of dealing with compressed images where you usually don't know in advance how big they will become when uncompressed) has already been mentioned. The property especially of the ARM Linux kernel (in default setup) to copy itself around if it deems fit and some other such issues make things really complicated.
When you talk of unifying, this must be done on both sides - the boot loader cannot solve or fix up all the issues caused elsewhere.
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.
Such a requirement can never be fulfilled. For example, there are many embedded systems which have all kind of devices attached which would go haywire if you start sending console output to them.
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.
You always assume that there is a user, who provides manual input, and such. This is simply not true. Actually this is not even true on x86 systems, and if you ever try running any standard x86 board in a remote-operated way, you will quickly realize what I mean. Yes, there are versions of boot loaders available that support some kind of serial console interface. But then - there are all kinds of PCI cards which require things like pressing "ALT + 3" to enter specific modes. Ever tried that on a serial console?
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
As mentioned before, this requires not only work on the U-Boot side. And you have to keep in mind that your vision is actually for a small sector of the market, for one specific application case, while embedded devices have totally different requirements. And last but not least, let's keep the head up so we can see over the rim of our plate: not all the world's an ARM box, and any such unification should be done in an architecture-independent way.
Best regards,
Wolfgang Denk