Zaurus bootloader starts to be a real PITA

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:

  1. Use kernel space for really minimal kernel + initramfs which will use “kexec” functionality to boot kernel stored in rootfs.
  2. 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

17 thoughts on “Zaurus bootloader starts to be a real PITA

  1. jpmatrix

    “As many people keep rootfs on SD cards…” : hmm not! don’t forget the C3000 ! we also want a kernel for our device ;)

  2. Koen

    Marcin: Luckily mickey and I patched uboot to work with an EABI toolchain :) Although I still think uboot should for arm-elf instead of using the defaults.

  3. Marcin Juszkiewicz

    jpmatrix: spitz line is simpler as pcmcia + ext2/3 are smaller then mtd + jffs2 so it is easier to fit in flash.

    Koen: I know, but EABI U-Boot is unsupported upstream. Patches which makes U-Boot buildable with EABI toolchain appear from time to time and they always refuse them (from what I heard).

  4. CoreDump

    Think about the possibilities of a fully working u-boot (console on-screen). True dual booting is only the beginning. No more problems with overly large kernels. No more cutting out stuff so it fits into 1.2Mb of flash….

    Long-term, u-boot is indeed the way to go. The conversion of the patch from u-boot 1.1.4* to u-boot head is probably pretty trivial for an experienced u-boot hacker. Also – to my eyes at least – the eabi patches applied by OM are very small and should be maintainable even if upstreamm does not accept them.

  5. Marcin Juszkiewicz

    CoreDump: forget about U-Boot with console screen on Zaurus. Chipset used in c7x0 (ati w100) would require writing display driver and I do not think that we will get someone for it. PXA framebuffer used in Cxx00 line is also not supported.

    I think that we do not need console in U-Boot. Checking keycodes on bootloader start and calling one of options would be enough. Options would be:

    • normal boot
    • system update
    • rescue system shell

    Where “normal boot” means “default way of booting as configured in U-Boot env”. This setting can be changed in few ways:

    • during “system update”
    • manually usign uboot-utils
    • directly in U-Boot (via serial console)

    This way we do not have users playing with bootloader too much (they usually do not have serial cables) and total control over environment used for booting (until user will play with it using uboot-utils).

  6. Richard Purdie

    Personally I think uboot would be a lot of work and that there are better ways to approach the problem. Making the kernel small is a worthwhile aim since the loaded kernel takes up valuable RAM, the bigger kernel, the more RAM used before you have applications. Fitting modern kernels  into 1.2MB is a challenge but I’d like to see the problem reported upstream and some analysis done to fine out where the bloat is coming from and hopefully seeing some of it removed. Failing that you may as well just use a cut down kernel as a second stage bootloader…

  7. Paul Sokolovsky

    Hopefully, it will be done in both directions:

    • 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.

  8. Marcin Juszkiewicz

    Paul: I looked at “initramfs-bootmenu-image” but this is not solution for Zaurus problem. It is good when you do not have limit on kernel size (which is true for ipaq devices due to kernel in rootfs). Our initramfs way will be more like LAB – kernel small enough to read kernel and params from real rootfs and then “kexec” into it.

    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.

  9. Paul Sokolovsky

    If you’re trying to solve problem of what to do with 1.2Mb leftover partition in vendor’s flash partitioning, then indeed something with shell interpreter in initramfs won’t help you to get use of it. So can imagine following choices:

    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.

  10. Paul Sokolovsky

    P.S. Other choice of cutting down size of initramfs-bootmenu-image (built with uclibc, ~500k w/o NFS support, ~700k with NFS support) would be to use klibc. Alas, it seems that it doesn’t support AEABI ;-\

  11. Marcin Juszkiewicz

    Paul: 1st and 2nd way are not a solution.

    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.

  12. Andrea Adami

    Hi,

    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.

  13. espi

    I’ve been reading about the Zaurus all day after JUST NOW discovering it and it seems great. I wouldn’t know which OS ROM to settle on for everyday use (HQ PDF reading, torrents, web, office, notes) and would certainly want to multiboot. I plan on getting a Zaurus next month and multiboot. Much kudos to all the contributors.

Comments are closed.

No Trackbacks.