[Angstrom-devel] Tosa (and maybe some others Zaurii) feature.

[Marcin Juszkiewicz]

Dnia poniedziałek, 19 listopada 2007, Dmitry Baryshkov napisał:

> Tosa has a strong limitation on the size of the kernel. To be able to
> boot current 2.6.23 with some patches, I had to move some stuff to
> modules and even to disable some generic kernel features, like
> ELF_CORE. I still have mmc and cf in-kernel, because sometimes I have
> to use them w/o kernel modules available. I already foresee when I
> would have to disable some other core features.
>
> AFAIU, Tosa isn't the only device where kernel space is very limited

All Zaurus models have that problem. Collie allows 1MB kernel, other 
models allow 1.2MB kernels.

> So I would like to call for discussion about the possibilities for
> solving this problem in a way that can be merged into angstrom.
>
> The best way IMHO would be to dedicate one of MTD's (that don't have
> _that_ strong limitation) for normal kernel and boot it somehow.

> After short discussion on the irc, there were two propositions:
>
> 1) port some existing bootloader to sharp. However most probably then
> we would have to remove original sharp rescue kernel+rootfs that are
> used for kernel updating. Moreover most probably we would have to
> remove original flash dump/restore facility. And I would prefer to
> still have them 'just for the incident'.

Due to Sashz work PdaXrom use U-Boot on sl-cxx00 devices (akita, spitz, 
terrier, borzoi) and maybe on few others too. They removed everything 
from NAND so there is no Sharp 'rescue rootfs/kernel' combo - instead 
they put own 'rescue' one with 2.6 kernel and mtd-utils. Booting scheme 
is like this:

1. NOR bootloader starts (Sharp code)
2. NAND bootloader is loaded/executed (normally Sharp code, now U-Boot)
3. Some keys decide: normal or rescue boot.
4. Kernel is loaded and booted into system.

I do not know status of their U-Boot and how it is integrated with 
upstream (suspect: none) and which exactly parts of hardware they 
supports (NAND, SD/MMC, CF, screen, keyboard).

> 2) Build minimal kernel (just MTD, we can even ommit LCD and most
> other drivers) and initramfs that would just kexec 'normal' kernel.
> 'Pro': easy to deploy at working device. Contra: building two kernels
> can be a bit ... strange? And it would complicate build system a lot.

This one can be nice - but shows other problem. Someone will need to 
create kexec-lite (stripped from anything not required) and make it work 
with klibc. We would also need init and mount. And everything needs to 
fit in 1.2MB :(

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

                Great response time! Was that 5 baud or 10?