Martin Michlmayr wrote: > * Rick Thomas <rbthoma...@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 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org