Re: APEX and Debian

[Marc Singer <elf@buici.com>]

On Fri, Jul 14, 2006 at 10:12:48AM +0200, Martin Michlmayr wrote:
> [ Moving from linux-arm to debian-arm ]
> 
> * Marc Singer <elf@buici.com> [2006-07-13 18:53]:
> > I'd like to use your code, as well, to put an IXP ethernet driver in
> > a bootloader we use on the nslu2's, APEX.
> 
> I've wanted to talk to you for a while now about using APEX in Debian
> as a 2nd stage boot loader on the NSLU2.  Basically, I'm fighting with
> the nslu2's stupid RedBoot default to load the kernel from a location
> that is only 1 MB large.  We now have a specific NSLU2 kernel in
> Debian (which goes against the one kernel per platform idea) and even
> this one always hits the 1 MB limit :/
> 
> My idea was to put APEX in that 1 MB space and use that to load the
> real Linux kernel from another location in flash, in a way that it's
> not limited in 1 MB.  This would allow me to use the generic IXP4xx
> kernel on the NSLU2.  (As a side-effect, it will allow us to support
> FlagSlugs and maybe command line passing.)

I think this is a good idea.
> A couple of questions:
> 
>  - I suppose you've experimented with 2nd boot loading and it just
>    works?

Yep.  That is a common way to use APEX.

>  - What does it take to get APEX for ARM (IXP4xx) into Debian?  I'd
>    need a binary in a .deb that I could Depend on and then flash.

Not much, I think.  It would be easy for me to add a debian/ directory to
APEX and build a .deb package.

>  - If I decide to use APEX this way, are you interested in supporting
>    this effort?  The NSLU2 has caused enough trouble for me and I'm
>    not looking for more, so I'd need a supportive upstream. ;-)

Most certainly.  I'm a DD and I'd be glad to support it directly.

> 
> What do you think?

It sounds like you want to keep the flash layout that Redboot defines.
Sadly, I agree that it would be unwise to replace Redboot until we
have an NPE driver in APEX.  What may be a good solution, however, is
to rework the boot process a little so that we don't waste so much
flash space.

Redboot loads the kernel from 0x60010, IIRC.  What we could do is put
APEX in that flash block and the kernel is the successive blocks and
as many as we want.


>From 

  +-----------+
  | Header    | 0x60000
  +-----------+
  | Kernel    | 0x60010
  |           |
  +-----------+ 0x60010+0xffff0
   ...


To

  +-----------+
  | Header    | 0x60000
  +-----------+
  | APEX      | 0x60010
  +-----------+
  | Kernel    | 0x61000
  |           |
  +-----------+ 0x61000+2M (or whatever)
   ...

Much of this depends on how you want to handle the rest of flash.  I
can support putting the kernel into the region of flash where the
rootfs is normally kept and loading it right from there, from the
JFFS2 partition.  Unfortunately, this isn't very fast since init'ing
the JFFS2 filesystem is slow.  I could probably make this faster by
enabling the cache for reading from flash.

Note that fatslugs will always be a problem.  If a user has put SDRAM
on board of a different organization, APEX cannot initialize it since
it's in SDRAM.  We *can* work around this if we need to through some
shenanigans.  I'd prefer replacing Redboot as the only reason we're
keeping it is the NPE driver and it's flash recovery feature.  We
could support fatslugs where the user has added a second bank of
memory, though I don't have one of these sorts of slugs.

Even if we could work around this, I haven't investigated what it
would take to detect the type of SDRAM that is installed.  APEX may be
able to probe to determine the type of installed memory.  Most
embedded systems have this stuff hard coded since there is little
expectation of field upgrades.  *And* this mode requires that APEX be
running from flash (or cache).

In short, we need to figure out where we want to load the kernel from
and I'll make the .deb that builds APEX for that purpose.  Fatslug
stuff is probably beyond the scope of a first release.

Cheers.