Network copy-nand: Difference between revisions
(Added firmware flashing info and more DNS stuff.) |
(Added debug-net suggestion and removed wireless-only stipulation) |
||
Line 15: | Line 15: | ||
== Assumptions == |
== Assumptions == |
||
⚫ | |||
* You are using the wireless LAN. A wired USB Ethernet interface probably works too (omit the "wifi" line), but hasn't been tested. |
|||
⚫ | |||
== Procedure == |
== Procedure == |
||
wifi media lab 802.11 |
ok wifi media lab 802.11 |
||
patch noop ?open-crcs copy-nand |
ok patch noop ?open-crcs copy-nand |
||
copy-nand http:\\www.mydomain\images\nand505.img |
ok copy-nand http:\\www.mydomain\images\nand505.img |
||
== Discussion == |
== Discussion == |
||
Line 39: | Line 38: | ||
A similar procedure works for the "flash" command, except that the patch is unnecessary. |
A similar procedure works for the "flash" command, except that the patch is unnecessary. |
||
wifi media lab 802.11 |
ok wifi media lab 802.11 |
||
flash http:\\dev.laptop.org\~wmb\q2c18b.rom |
ok flash http:\\dev.laptop.org\~wmb\q2c18b.rom |
||
== Debugging == |
|||
If you have trouble with OFW networking, you can often debug the problem by typing "debug-net" before the command that accesses the network. That will dump a lot of information about what OFW is doing and the responses. For example: |
|||
ok debug-net |
|||
ok ping dev.laptop.org |
|||
<lots of output elided - hopefully it is self-explanatory> |
|||
== Disclaimer == |
== Disclaimer == |
Revision as of 04:18, 13 July 2007
Introduction
This is a recipe for using copy-nand over the network, so you can replace your OS image without having to copy stuff onto a USB key. I have tested it only with Q2C18 firmware, but it probably works with a few other older versions.
It has some limitations:
- It doesn't use the .CRC file to check the data (this is because of a deficiency in the firmware HTTP implementation that doesn't let you have two streams open at the same time; that could be worked around at some point by changing copy-nand to pre-read the CRC file into a buffer).
- It isn't as fast as doing copy-nand from a USB key, but it probably compares favorably to the total process of downloading first to the key, then copying from the key to NAND.
Assumptions
- There is a DHCP server on your network
Procedure
ok wifi media lab 802.11 ok patch noop ?open-crcs copy-nand ok copy-nand http:\\www.mydomain\images\nand505.img
Discussion
The "wifi" line above sets the SSID of the access point. That line isn't necessary if you are using a wired network interface. The default SSID is "OLPCOFW", so if you are setting up a special wireless network for firmware testing, you can use that SSID name to save some typing.
The "patch" line disables CRC checking, as a workaround for a problem described in the introduction section.
The URL in the copy-nand line must use backslashes instead of forward slashes. Long URLs like the following will also work, if you can manage to type the whole thing without making a mistake.
http:\\olpc.download.redhat.com\olpc\streams\development\LATEST\devel_jffs2\olpc-redhat-stream-development-devel_jffs2.img
Caveat: The last time I tried using OFW networking in the OLPC offices, DNS name resolution didn't work. I don't know why. But DNS in OFW is working just fine on my home network as I am writing this. If you have trouble with DNS, try using the dotted decimal address (IPv4).
Reflashing the firmware over the network
A similar procedure works for the "flash" command, except that the patch is unnecessary.
ok wifi media lab 802.11 ok flash http:\\dev.laptop.org\~wmb\q2c18b.rom
Debugging
If you have trouble with OFW networking, you can often debug the problem by typing "debug-net" before the command that accesses the network. That will dump a lot of information about what OFW is doing and the responses. For example:
ok debug-net ok ping dev.laptop.org <lots of output elided - hopefully it is self-explanatory>
Disclaimer
This is a quick hack procedure provided in the hope that it might be useful, but is not currently supported officially (because I have too many other critical-path issues). If you should choose to file any trac tickets against it, expect to have them reassigned back to you.