Re: apex-nslu2-1.4.14
* Rod Whitby <rod@whitby.id.au> [2007-02-05 07:34]:
> >> Assuming this build of apex puts the environment in the same block as
> >> apex itself, are the debian scripts padding that block with FFs or
> >> zeros? If the latter, that would explain it.
I just padded it with FFs on my box and I can now successfully change
the environment. Great work, Marc!
BTW, there's nothing like /dev/zero for FFs. The best way I figured
out to pad the block with FFs is with:
perl -e "print pack('C', 0xff) x $pad"
($pad indicates the number of bytes of padding that are needed)
> Yes, that's true. How often do you think people will be updating apex
> without flashing a new image
That's the typical use scenario imho. People will upgrade their
Debian system, get new kernels, a new APEX and other packages... a new
initramfs is generated and then written to flash together with the new
kernel. This is what's happening already. What's still missing is to
actually update the copy of APEX in flash when the apex-nslu2 package
is upgraded.
> On the other hand, when flashing a new apex, it might be a good idea to
> reset apex environment settings (or at least making the user review
> them) in case there are incompatible changes in the environment format.
I guess if there really was an incompatible changes we could use
debconf to tell the user and get appropriate new values (unless we can
figure out it automatically). But usually, we should simply be able to:
- get the values with "apex-env printenv"
- write a new apex to flash with proper padding
- set the old values
> I wasn't sure whether we'd come up with a final decision or not - we
> were waiting for some proof of concept experiments and the Debian
> input to determine the pros and cons.
OK...
> I'm happy with it going in either spot. I've left room for it after
> the microcode in the FIS directory area - we would just update
> slugimage to use that area.
... I think that the APEX block is the right place for the
environment. Putting it in the FIS directory is a hack and doesn't
seem to gain us terribly much. In other words, I'm happy with the
current implementation. The only thing we need to do in Debian is
write a script that will actually write APEX to flash and pad it
properly (and restore user settings). That shouldn't be too hard but
is material for after etch.
Joey, do you have any thoughts on this?
--
Martin Michlmayr
http://www.cyrius.com/
Reply to: