Reflashing over a network
quozl at laptop.org
Thu Aug 29 04:19:38 EDT 2013
Warning: this is a composite reply to many people, with context, so
read to the bottom.
There are several methods to reflash; USB drive, SD card, wireless,
and USB ethernet.
These methods vary in how fast they are, how well they scale, what
equipment is needed, and what expertise is required.
Think about the problem; you have between 512 MB and 1 GB of data to
move from outside the laptop to inside the laptop.
Regardless of where it comes from, it will take about five minutes to
write the data to the internal storage of the laptop. The internal
storage is not as fast as a hard drive.
Now, where does the data come from? An SD card or USB drive is
usually the fastest, hence the typical five minutes. All other
reflash methods _will_ be slower.
Wireless reflash should only be considered if there is wireless
spectrum available (e.g. school's out), and there's some advantage to
doing it (e.g. quantity of laptops much greater than quantity of USB
drives). Not having enough USB drives is a good reason to select
wireless. (e.g. theft, resource limitations).
Wired reflash should only be considered if there is wired access
NANDblaster outperforms HTTP because there is no reverse data channel.
NANDblaster performs poorly in a noisy environment.
On Wed, Aug 28, 2013 at 08:53:33AM -0400, Tim Moody wrote:
> I have been interested in this approach for some time, but was told
> that the XO boot process that looks for a particular network name or
> SSID is not implemented on recent XOs. Bug or design choice, what
> is the likelihood that this will be an option going forward?
It was a bug. It is now fixed. It is 95% likely to be "an option
going forward", but you must upgrade the firmware on XO-1.5, XO-1.75
or XO-4. See below for the upgrade.
On Wed, Aug 28, 2013 at 03:52:46PM +0200, Tony Anderson wrote:
> This is getting interesting but I am still not sure I understand the
> As I understand it, the XO will attempt to download the
> fs.zip (appropriately named)
> and then the
> from 172.18.0.1 using http protocol.
> However, this currently only works for XO-1 because of a bug in the
Yes. The bug number is #12740, and the fixes are available in
> There is an alternative via
> boot net
> which invokes a different firmware process that is working in all XO
> models. This process uses tftp. The server would respond to a tftp
> request from the XO by sending the fs.zip and .img files.
> I am not familiar with tftp. Server-side, I would assume the
> necessary files would be in a known directory (e.g. /library/xo-1.5)
> and the XO would request 'get' on the files.
> Does tftp from the XO also address 172.18.0.1?
No. It addresses the boot server identified by the DHCP server, or if
no boot server is identified it attempts TFTP against the DHCP server.
(Reminder: this is the manual "boot net" scenario, not the automatic
four game key boot scenario).
On Wed, Aug 28, 2013 at 10:46:05AM -0400, Tim Moody wrote:
> Tony Anderson wrote:
> >There is an alternative via
> >boot net
> >which invokes a different firmware process that is working in all
> >XO models. This process uses tftp. The server would respond to a
> >tftp request from the XO by sending the fs.zip and .img files.
> to be clear, this command must be issued by the user after a 4
> button boot lands in the firmware?
> could Jerry's forth module do it?
No point, 'cause the time you waste getting a Forth program into the
laptop is better spent getting the install data into the laptop.
On Wed, Aug 28, 2013 at 11:46:15AM -0500, Jerry Vonau wrote:
> If you use a usb cat 5 network dongle, would that be auto detected
> in place of using wifi?
Yes. It works here, I just tried it with Q4D34JE with the web server
on 172.18.0.1 loaded with 32013o2.zd and fs2.zip.
> I can't seem to find /packages/obp-tftp on dev.laptop.org/git/. I
> suppose if we craft an olpc.fth script to setup the wifi networking
> that could be used in place of the 4 button boot?
I don't understand the question, sorry.
Here's what happens if the four game key boot method is used:
In the absence of USB drive, SD card, or a nearby NANDblaster, the
firmware will open the network, which means one of either:
- initialise the USB ethernet device, or
- associate with either OLPCOFW or the SSID identified by the NN tag,
and then send an HTTP GET to 172.18.0.1 asking for the file fsN.zip,
which it then validates against the security system, before executing
it as normal as if it had been found on USB drive.
On Wed, Aug 28, 2013 at 12:07:46PM -0500, Anna wrote:
> A few years ago, I experimented with flashing an XO-1 over the
> network from my XS 0.6. I named the AP "OLPCOFW" and put the .img
> and fs.zip files in the document root of the webserver,
> It took approximately 45 minutes to flash a single XO-1, when it
> actually worked. It took a few attempts before it was finally
> successful. Packet loss, maybe? And that was just with a single
> unit, no telling what would have happened with attempting to flash
> multiple XO-1s at the same time.
Yes, packet loss with old firmware would have caused this stall.
Since fixed. Still, 45 minutes is _reasonable_ for the method, given
the performance of the wireless card and noise.
> Anyway, my conclusion was that it was way too slow and error prone
> for production use.
Yeah, but what if you don't have a USB drive, don't have an SD card,
don't have a USB ethernet adapter, but have a server, and 100+
You have to appreciate what "production" might mean, and wonder why we
did it. Perhaps we did it because "production" can mean "severe
You who are not so constrained wouldn't like it.
On Wed, Aug 28, 2013 at 07:43:40PM +0200, Tony Anderson wrote:
> My understanding of this is still limited. Generally, the school
> server is configured to provide dhcp, the router is not involved. In
> a normal configuration, the school server is 'schoolserver' and the
> network is 'schoolnet'.
> I assume you used the 'http' version and not the 'tftp' version. If
> the XO sends a predicable url, it should be possible to have Apache
> route the request as needed.
> Your experience is surprising in that I would expect performance
> similar to NandBlast.
You should not expect performance similar to NANDblaster on XO-1.
NANDblaster on XO-1 uses a special configuration of the wireless card,
where there is only one wireless device transmitting. This is done to
use the maximum air time of the environment.
It is not possible to achieve the same usage of air time if you also
add TCP ACKs necessary for HTTP, or the return packets of TFTP. The
air time used by the receiver laptops reduces the performance
I cannot recommend reflash over HTTP for performance reasons, only for
availability and simplicity of operation.
On Wed, Aug 28, 2013 at 01:09:03PM -0500, Anna wrote:
> On Wed, Aug 28, 2013 at 12:43 PM, Tony Anderson wrote:
> > Your experience is surprising in that I would expect performance
> > similar to NandBlast.
> Yes, I was surprised, too. I looked into flashing over the LAN
> because support staff at the schools typically only had one USB
> drive set up for flashing and weren't technically capable enough to
> set up a transmitting NANDBlaster XO. But trying to flash over the
> LAN, between the multiple errors, I finally ended up with a
> successful flash after several hours total. Which, of course, is
> totally unacceptable.
> I'd be interested in testing if flashing over tftp has better
No, it won't. Don't bother.
Could we please move technical discussions on OLPC XO firmware back to
More information about the Devel