Re: apex-1.3.31 and sercomm flash header
On Mon, Aug 07, 2006 at 01:17:05PM +0200, Martin Michlmayr wrote:
> * Rod Whitby <rod@whitby.id.au> [2006-08-07 16:19]:
> > Let's work out the finer details of (b) for all the tools in the
> > chain (e.g. upslug2, manual loading via tftp and any other debian
> > tools) to make sure there are no other gotcha's ...
>
> upslug2: using the --image parameter it would just work since
> slugimage would do the real work. You can also pass a separate
> kernel, ramdisk etc to upslug2 but this currently doesn't support a
> 2nd stage boot loader anyway, so we could just require the use of
> slugimage before upslug2 to create an image in that case.
>
> manual loading via tftp: the raw kernel file would not contain the
> sercomm header so it should be possible to simply load it via tftp.
> If slugimage knows about the "skip" field, it can also correctly
> unpack a kernel from an image.
Or, it could use the kernel1 and kernel2 partitions to reassemble the
kernel. We'd have to do this under any of our schemes.
> Debian tools: I need to implement some new scripts anyway to handle
> the APEX situation, and while all the proposed options need different
> code, there doesn't appear to be one that is much harder than the
> other. Option (b) will be slightly more messy than (a) though since
> neither /proc/mtd nor sysfs contains the offset of a MTD partition so
> I'll have to hardcode things. (I need to know where the kernel
> partition starts in order to compute where to put the sercomm header.
> But given that slugimage hardcodes this I suppose I can do the same.)
This is why I like the scheme I just proposed. We only need to
compute the SKIP descriptor for the composite kernel partition. All
of the rest of the work can go on with two component partitions.
Does this make it easier for you?
> --
> Martin Michlmayr
> http://www.cyrius.com/
Reply to: