[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: APEX and Debian



Marc,
Do we want to leave a little more room for future versions of APEX which have more functionality (i.e. Networking support and usb mass storage support, even NFS rootfs support ...) that might take more than the space you currently have allocated?  Is the start location and size of the kernel in flash able to be configurable (e.g. by something in sysconf, or something in the last block)?
Let's also keep the goal of using these things for SlugOS (i.e. outside of Debian scenario) ... everything looks good so far for that, as long as we can access the source from an OpenEmbedded build ...
-- Rod
(Sorry about all this top posting - I'm answering these emails on a Treo650 whilst on holidays, and replying in the proper inline manner is just too inconvenient in this situation).
-----Original Message-----
From: Marc Singer <elf@buici.com>
Date: Wednesday, Jul 19, 2006 7:50 am
Subject: Re: APEX and Debian

On Mon, Jul 17, 2006 at 06:40:19PM +0200, Martin Michlmayr wrote:
 * Marc Singer <elf@buici.com> [2006-07-17 08:52]:
 > I wronte a shim that we can use to push ATAGS into a stock kernel.
 > I've also started building a debian package for apex so that we can
 > use it in armeb debian as a secondary boot loader.  Either of these
 
 arm, not armeb (or, rather, both, but there's no official armeb port
 yet).
 
 > I'll keep you posted about using APEX as a second stage loader.  The
 > package is almost done.
 

I want to make sure we're heading for the same goal.

I've prepared a debian package for APEX.  It builds a deb file called apex-nslu2.  The loader is written to /boot/apex.flash, a binary image of the loader with a prepended SERCOMM header.  The length field in
this header is in big endian mode.  APEX will switch to little endian mode once it begins executing.  The architecture is 'arm'.  It copies the kernel image, starting from 0x80000 for 2MiB to SDRAM and then
jumps to it.

This same package can be built for armeb.  It only difference will be that it will put the processor in big-endian mode when it starts
executing.

Have I missed anything?  Do we want to copy more than 2M of kernel? We could copy 3.5MiB (4MiB - 256KiB - 128KiB - 128KiB) which is
everything except for Redboot, the sysconf block, and APEX.





Reply to: