Jens Schmalzing wrote:
Hi, Benjamin Herrenschmidt writes:U-Boot comes with a tool that does more or less the same as mkvmlinuz, called mkimage (takes in an elf and an optional ramdisk image and outputs a bootable image)That's crap. Fine for embedded maybe, but it should really be able to load a plain vmlinux.Does that include a ramdisk? My understanding was that you need either a bootloader or a bootable image like the one describer above in order to boot an initrd kernel. On sub-architectures that don't have a bootloader, such as PReP or CHRP, this leaves only the bootable image.
It isn't actually a bootable image, it's just the vmlinux (and optional ramdisk) with a header that tells the firmware (U-Boot) how to interpret the data. For instance, what sort of compression has been used, whether or not it includes a ramdisk (or you could have a ramdisk in a separate file, no problem). The resulting file can then be loaded into memory from partition (RDB or PC partition map), network, etc. From memory the file can be booted.
So it looks and feels a lot like PREP to the user, but it is in fact a lot simpler. We're already running mkvmlinuz on our kernels already, I fail to see how another subarch that looks almost like PREP can be considered so bad.
Yes, we are currently lacking a bootloader that understands filesystems AND can load Linux. Which means you can load AmigaOS4 from a filesystem, or you can load Linux from a partition much like on my PReP. The bootloader that is used when booting AmigaOS4 behaves much like the typical x86 bootloaders, in that it has a second stage in the partition map (RDB extension called BRB, "boot record block") which is loaded by a minimal loader in the actual firmware. This second stage then understands the AmigaOS4 filesystem (called FFS2, as in "second fast-filesystem"). so far there has been much talk and little action around the "load file from inside ext2" school of design. Unfortunately I am not the right man for that kind of action.
There is a multitude of boards out there that use U-Boot (it supports ARM, MIPS, PPC and x86 already), so I think support for this will have to come sooner or later anyway. Or is there some rule that says no embedded-like boards are to be supported that I missed? :-)
Here's the source to mkimage.c: http://cvs.sourceforge.net/viewcvs.py/u-boot/u-boot/tools/mkimage.c?rev=1.12&view=autoTo my quick and shifty eyes it seemed quite straightforward, but I'm just in from a long bikeride so will make a SLIGHT reservation on that one.
It has a reference to (#include <image.h> near the top) http://cvs.sourceforge.net/viewcvs.py/u-boot/u-boot/include/image.h?rev=1.9&view=auto and it uses crc32 functions from: http://cvs.sourceforge.net/viewcvs.py/u-boot/u-boot/lib_generic/crc32.c?rev=1.3&view=autoBut since that one includes common.h which again includes almost half of U-Boot I think we'll stop there :-)
-- AmigaOne dev list FAQ (when I say F, I mean F): http://www.samfundet.no/~olegil/amiga/