Sharp Zaurus palmtops have separate flash ‘partition’ for keeping kernel. The problem is that it is only ~1.2 megabyte… It was good enough for 2.4.18 kernel which was used by vendor but with 2.6 kernel maintained by OE community it is really hard to fit there.
We started to remove some features from kernel. With 2.6.23 release we were forced to choose: SD/MMC support or PCMCIA/CF support goes into kernel. As many people keep rootfs on SD cards we moved CF into modules. To get 2.6.24 fit I had to choose another parts…
In near future we will probably end with a kernel which will be stripped from everything possible. This will leave only framebuffer and rootfs access support — Everything other moved to modules.
Other solution is to change a way of booting device. There are few solutions:
- Use kernel space for really minimal kernel + initramfs which will use “kexec” functionality to boot kernel stored in rootfs.
- Change Sharp bootloader into something more sane — like U-Boot, Apex or RedBoot.
First one require some patching to get rid of everything other then MTD + JFFS2 or CF + ext2 (for spitz). Then adding simple initramfs which will contain tool which will check rootfs for kernel and parameters. Then load/execute new kernel with “kexec”.
Second way… this one is more tricky as it also change a way of updating device to newer kernel/rootfs. We can get more space as Sharp “rescue” system used for updating can be replaced with much smaller one but this also require work. There is a patch from pdaXrom which adds c7x0 and akita/spitz support for 1.1.4 U-Boot. After few tweaks it applies to current version but need updating configuration and also adding some code for Flash operations. But this does not help for Tosa/Poodle devices as they would need more work.
Which way to choose… For now we will rather stick with removing all what can be removed. All other options require more work which require developers. But our Zaurus hackers usually moves to newer platforms now…