I was under the impression that flash-kernel, as a subordinate of update-initramfs or at the very least kernel postinst.d hook, is ALWAYS called with a version (in fact, standards state that it passes the kernel version as $1 AND $2 for some funky reason). There's very very little reason to call it with no version, and even if it was, shouldn't it pull "uname -r"? Otherwise it would have absolutely no idea which kernel to work on, and so far as I have seen after about a gazillion kernel installs, removes and replacements, the "vmlinux" and "initrd.img" symlinks either in /boot or / are some magic which doesn't always happen.

However, vmlinux-$kvers and initrd.img-$kvers are always going to be there. Imagine for a second that flash-kernel is a bootloader helper tool like grub-install and it needs to know which kernels to pick out and handle. It's not useful to leave a kernel file in there "unversioned".

Case in point: it never broke before, and the flash-kernel code we adapted for Efika MX we "stole" from the Dove support in the existing script. It supported appending the version to the file. We merged in a few cute tweaks from OMAP too.. it was a mix of what was already there, done a little bit better.

~

As for the kernel "mx51" subarch, mx5 is a possibility too (although an upstream seems to have kicked out MX51 and MX53 both working at the same time in the same kernel) - but so are many other combinationsm possibly Cortex-A9 support for the MX6 on top. As always the subarch is specific to the distribution and if it's not upstream, most certainly vendor-specific. Ours is "efikamx" and we used to have "efikasb" to differentiate between the two different compiles (there were horrible hacks which made them not build together, which are now gone). As it stands we can stick to "efikamx" right now. Probably the best subarch to go for would be "imx", which is almost too generic.. but it would work considering the restrictions of the distribution (armv7-a, Thumb2..). The suffix and therefore subarch is a distribution thing not a kernel mainline thing.

~

Mainline doesn't support Smarttop nearly well enough (unless you enjoy having no display, good luck!) and Smartbook is even worse. We have customer support to engage with 2.6.35 BSP kernels, and then we will make the jump to mainline. Far, far too much needs changing in mainline right now to make it an effort we can engage in, and still get adequate platform support for the board given it's feature set (proper EDID parsing for HDMI sinks (omap team committed some horrible code, and it's crashy!), proper coordination between transmitter and ASoC for HDMI audio, rt2800usb has been broken for about 2 years, we need extra features for power_supply class to support the battery in a board-agnostic manner, and many noticeable shortfalls in the machine files, not to mention actual multimedia support and the Flash 10.2 plugin). We are skipping ahead as soon as our customers are happy that 2.6.35 will work for them for the time being. Until then, and even then, it'll stay "efikamx" from Genesi, and even stay that way when we get an MX53 board.

Parsing kernel configs doesn't work to identify the running board. After all, a config file can have many boards in it. How do you parse the config file and THEN determine if you're running on the right system? You may as well skip looking in the config. What needs to be checked, without being too clever for it's own good is

* /proc/cpuinfo Machine: line
* suffix to the kernel version (-efikamx, -omap4, -igloo)

Which define the subarch precisely, and the machine precisely, unless the vendor changes the name of the board halfway through. Flash-kernel already does exactly as needed here.

I have a patch right here but I need to test it. It puts back the efikamx subarch and makes our kernels versioned. I'm still a little confused about the deleting of kernel files though. update-initramfs called from postrm.d removes the initrd.img-$kvers itself - but how does it know it is a removal task? It never gets passed more than two identical kernel versions (the one it is being told to do something with). If update-initramfs can do it, flash-kernel can clean up uImage-$kvers and uInitrd-$kvers (and any backups of those versions) the same way. Is it an environment variable being looked for? I couldn't read through the code without getting eye strain but I will check into it.

I really think flash-kernel should not be a update-initramfs-called script, but a seperate postinst/postrm hook of it's own. It should run after update-initramfs (if needed) and before update-notifier is called. In this case, there is a fatal flaw in the Debian kernel postinst/rm scripts which is that these things are executed in filesystem order. udev and sysctl and other rules-based systems manage to use numbers (with certain subsets of numbers being reserved for system components and others for vendor or user additions before or after - the man pages for sysctl.d are very good for example in explaining this). postinst scripts have to manage to use "zz-update-grub" to force a script to run last. This is quite braindead.. no scripts should depend on the current local sorting method, the only way around it is to use numbers to prefix the script names.. I already reported a bug for this (#669151 and as a corollary #669158) and it was discounted because flash-kernel is run by update-initramfs which is quite weird (why would the ramdisk tool call a subordinate script to create a bootable *KERNEL*? There was a rumor Natty was going to ditch initramfs in order to speed boot times. Maybe the Natty+1 will actually do it... in which case this is a very strange order)

~

I read through the FlashKernelRework wiki page and I am really confused by the "support for booting from SD card". This is absolutely weird - I have never, ever had any problem booting my Beagleboard, MX51 or MX53 dev boards and absolutely certainly not the Efika systems from SD card with the current flash-kernel.

What I think flash-kernel needs is for each board to be supported by flash-kernel using basically an architecture where flash-kernel is a big case statement with some helper functions. Each board can then be detected and a script included and then a function run to "do the right thing" based on passed arguments. That way, /var/lib/flash-kernel/boards/efikamx.sh can do the right thing, ./omap4.sh can do the right thing. Those board files can then include and call any subarchitecture quirks they need. No "database" just hardcode the values in those scripts. Databases are VERY hard for people to maintain and update (especially people like me, who have to code the platform support). Many, many parts of Debian and Ubuntu are chained scripts and it works well if well designed up front.

Ideally every kernel would know what it's load address is meant to be. As an example the load address on Efika MX hardcoded into U-Boot is then hardcoded into the uImage anyway - it doesn't need both. It might be different for other boards, but you basically can't just change the boot address anyway. Perhaps this is something a device tree would solve, but device trees are nearly always loaded AFTER kernels in bootloaders, and certainly parsing the DTB in userspace to pick out the load address would be really quite ugly. Eventually you're going to have to hack it into a file to solve all cases (DTB or not DTB, that is the question, it's entirely possible a real OF or UEFI-based device tree will appear in the near future which will screw up the idea of parsing the device tree from a precompiled binary file shipped with the kernel)

~

BTW I found another bug: someone, I don't recall who, whether it was one of us or it leaked into the code from flash-kernel for dove or omap which we borrowed from, is setting -C gzip on the uInitrd file. This is both pointless and redundant - initrd.img is compressed as per the kernel features required to support that compression method (presence of gzip, lzo, bzip2, lzma compression built-in). Compressing it AGAIN with gzip means booting has a double-decompression to do (decompress gzip uInitrd to RAM, Linux then unpacks it on boot). This is soaking time in the bootloader for no reason. Especially true that gzip will never get better compression by recompression on top of ANY of those methods above, and only in the very rare (in fact almost impossible to create, update-initramfs assumes gzip by default) situations would the initrd.img be uncompressed.

~

And a curiosity, where on earth did the boot.script file come from? When I installed Natty, it did not exist. Is it now part of new kernels or a package that the kernel must depend on?

Let's make some quick decisions, fix some bugs :D