I’m amazed by the waste of time spent shrinking the kernel and complaining how bad the sharp bootloader is and I appreciate very much the efforts for alternatives ways (kexecs+initramfs) but is hard for me to think nobody want invest a couple of hours to fix once for all u-boot.

We can not forget about using kernel partition as Sharp bootloader load kernel from it. Repartition of flash would require another kernel change — Sharp bootloader do not provide sensible kernel commandline — we hardcode own one and also hardcode flash partition scheme.

Busybox for this initramfs will be quite small (most of functionality will be removed). During last attempt I was able to nearly reach limit. When I will get my c7x0 working again (batteries starts to show age) I will try how does it works. Of course final version should be small binary which just parse file from flash rootfs and “kexec” kernel.

And Zaurus does not have to care about NFS root support I think — we have stable on-device storage.

1. Give up on those 1.2Mb is preserving vendor’s ancient layout is important.

2. Repartition flash.

3. Write an adhoc bootloader tools in C to save on busybox size in initramfs.

But is seems that besides there 3 choices, there’s 4th weighs as Sword of Damocles: “our Zaurus hackers usually moves to newer platforms now …”. Hacking out and maintaining userspace tools are obviously easier than LAB, but maybe you don’t want to carry burden of maintaining some adhoc solution after all? How will it boot from NFS for example?

IMHO, that’s how community-driven open-source projects should work: provide general solution which is easy to support and maintain. It may be not optimal however: that’s what vendors are good at, focusing on specific solution for specific time span. Trying to do other party’s job is IMHO wasting resources. Individuals and device interest groups of course may chose to provide device-optimized solution. But as optimization, not as the only, adhoc, timespan-limited way to handle the task.

As for LAB, it’s apparently doomed now IMHO. It was interesting solution when there was no other choice, while it offered “just works right now” feature. With maturing of initramfs-uniboot (image of which initramfs-bootmenu-image builds), LAB is out of my personal list of things, even if it twice as big (with kernel) than LAB and would push poor h3600′s flash to extreme. At least bootloading for it will work, and will work at least as long as for other devices.

We will not use LAB because it is handhelds.org product which is not accepted in mainline kernel. Due to that it would add extra work for us to maintain it.

Other bootloader was discussed already — there is a patch for U-Boot which adds c7x0 and akita/spitz support. But this would also require teaching our users how to use it and we know how much problems pdaX users had when that distro switched to U-Boot.

Fully modular kernel is other problem — our current Zaurus kernels are currently stripped from most of things. We supports two methods of booting now: Flash or SD (microdrive or SD for Spitz line). It is hard to find another parts to remove.

Looks like minimal kernel with initramfs (containing kexec mainly) is a way to go.

• Making a kernel fully modular, opening up opportunity for single kernel binary for all devices of the same arch (I know, I know, it “can’t” be done, but only because of ARM Linux/core Linux issues).

• Choosing a new bootloader, hopefully with the similar requirement – to support any device, to break vicious cycle of every device porting community to reinvent the wheel. APEX looks more favorable as it allows really slim builds (~30K).

As for early-userpace initramfs which allows to boot rootfs in various ways, it’s already in OE, “bitbake initramfs-bootmenu-image” is a quick way to get start with it.