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

Re: nslu2 startup with automatic fat-slug detection



On Tue, Jun 26, 2007 at 09:07:16PM -0600, Gordon Farquharson wrote:
> Hi Marc
> 
> On 6/26/07, Marc Singer <elf@buici.com> wrote:
> 
> >I recall that there was a thread of discussion about automatically
> >upgrading APEX when a new package is installed.  Was this resolved?
> >In order for me to install a new APEX, I had to take the
> >/boot/apex.flash image, byte swap it, and then put the sercomm header
> >on it.  I can also put a copy of apex with all of those steps already
> >taken into /boot so that it is really easy to upgrade (or downgrade
> >for that matter).
> 
> A while ago, I submitted a patch to flash-kernel [1] which will write
> apex to mtdblock2 as part of the flash-kernel script. As I mentioned
> in my response to #421359, it is easy to make this a separate script.

Sounds good.  I was thinking that it would be handy to have a script
that can do this in one go, but it looks like all of the necessary plumbing is available in flash-kernel.

In reading your script, I noticed a couple of things.  You really
don't need to restore the environment if you don't erase it.  It's at
the end of the block and should be out of the way.  APEX is good about
maintaining compatibility with previous versions of the environment,
so nothing to worry about there.

It also seems to me that you are best off setting the sercomm_header
length to the length of APEX and not the length of the whole block.
In this way, you only need to write the extent of APEX plus the size
of the sercomm header.  I know that the kernel will perform a complete
write in any case, but it more precise to pass the sercomm header with
the APEX length.

Cheers.

P.S.  It is interesting (to me) to see how you use the *= notation to
eliminate default variable contents.  :-)



Reply to: