Bug#510271: installation-report: Lenny on a Slug - eventual success after a few tries and some fixups
Martin Michlmayr wrote:
> * Rick Thomas <rbthomas55@pobox.com> [2009-01-13 10:05]:
>>> Sorry, I was wrong here. Yeah, this sounds like an interesting
>>> approach.
>> I don't think regenerating the image should be necessary. If "--payload"
>
> Yes, as I said, I was wrong. You can just specify --payload with an
> existing image when uploading to the NSLU2.
>
>> can be used along with the image you provide, then there could be code in
>> the image that looks to see if the "payload" area has something that looks
>> like a preseed (maybe a "magic number" or checksum or timestamp or
>> something else to be reasonably sure we're not being fooled by random data
>> or by stuff left-over from the last d-i.) If there is, it can use it, if
>> not, it can ignore it.
>>
>> Or am I missing something? I don't know much about the internals of the
>> upslug2 process, so I'm sure there's plenty I could be missing. Is there
>> documentation beyond the upslug2 man page I could look at? In particular,
>> I gather that the program on the slug end of the upslug2 process is called
>> "redboot" -- is that correct? Is there a Linksys manual or technical
>> paper describing redboot?
>
> The boot loader on the NSLU2 is RedBoot, but I don't think this
> payload has anything to do with RedBoot per se. I think the payload
> features simply writes the data to a location in flash that isn't used
> for anything.
>
> But I don't know any details myself about this feature. I've copied
> Rod Whitby who should be able to point to more documentation (if it
> exists) or give us more information.
Source code for the upgrade protocol in the Linksys (written by SerComm)
version of RedBoot is available.
The --payload switch to upslug2 is probably not used by anyone in the
world at the moment (we certainly haven't used it in the nslu2-linux
project, nor in the NSLU2 Debian work).
All it does is overwrite an area in the FIS directory partition when
uploading an image. It's exactly equivalent to overwriting the bytes in
the image before calling upslug2 - there is no special upgrade protocol
support used or required.
So nothing uses that area today (we were considering using it for IXP
microcode storage, but decided to put it in the rootfs instead), and no
Linksys software touches that area (which is why we originally thought
of using it, and added support for that in the tools). However, it will
be overwritten by each flash of the NSLU2, so is different from the
SysConf area (which is currently used for preseeding network settings)
in that respect.
-- Rod
Reply to: