next »

[kbelcher]

I thought I had bricked my machine when I could not boot after an attempt to install from a new, factory formatted 1G Kingston DataTraveler that I bought specifically for this purpose.

I decided this morning to try a different flash (4G PNY Attache) and I am up and running again.

Textually I can not tell these two flash drives apart on Windows XP, at least not from My Computer display.

I DO know that they are different, as XP installed a new driver for the Kingston drives.

Does anyone have a method for telling (under XP) which flash drives will work, which will not?

[kevin_stevens]

I don't know why Windows is installing drivers in the first place.  USB flash drives (and external hard drives) should all be treated as USB spec mass storage devices under the same generic driver.  That's how the XO (and any Linux machine) treats them.

I also don't know why people are having problems with different USB drives and OLPC.  I'm *guessing* (note emphasis) that they are drives that come from the manufacturer with an odd configuration (multiple partitions or non-FAT formatting).  Note that such issues are not really "USB" compatibility - the USB part is working, it's the volume configuration that's the issue.

I can't say further because I haven't seen the problem myself, and people reporting tend to lump multiple symptoms together ("I tried to upgrade using my Lexar drive, but there were multiple files in the root directory and I had the .usb image instead of the .img, and I only held down one button.  So I took the Lexar drive back to the store and bought a Kingston one, and that one worked perfectly!").

Personally, I'd check a flash drive by plugging it into the XO with some files on it.  If they show up in Journal and you can access them, you know the drive, partition, and file system are ok. 

To be sure there aren't partitioning issues, you can go to Terminal and:
su - to root
type  fdisk -l
You should get a list of devices, the flash drive will show under as /dev/sd? as below:

Disk /dev/sda: 4059 MB, 4059561984 bytes
255 heads, 63 sectors/track, 493 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         494     3964369+   b  W95 FAT32

As long as it only shows one partition, and is formatted as FAT32 or FAT16, it should be ok.

That's all I can suggest.

KeS

[kbelcher]

I tried both USB flash sticks. The failing one is FAT16, the successful one is FAT32

in more detail, the 1GB Kingston shows as:

Disk /dev/sda: 999 MB, 999817216 bytes
21 heads, 20 sectors/track, 4649 cylinders
Units = cylinders of 420 * 512 = 215040 bytes

 Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1          4650     976320   6  FAT16

The PNY shows as:

Disk /dev/sda: 4127 MB, 4127195136 bytes
16 heads, 32 sectors/track, 15744 cylinders
Units = cylinders of 512 * 512 = 262144 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         15744   4030448   c  W95 FAT32 (LBA)

The only INTERESTING differences I see are that the Kingston is FAT16, its cylinder count * bytes per cylinder yields a smaller number (999720960 bytes) than the claimed device size (in first line-999817216 bytes) whereas the PNY is exactly the same, and the Kingston's End cylinder shows as 4650 when it only claims to have 4649 cylinders. Perhaps this End cylinder 4650 is the problem, as 4650*215040 = 999936000, which is LARGER than the claimed device capacity of 999817216 bytes. If the usb handling code checked the last block using the End Cylinder number it would be off the end of the device.

But other than that observation I don't know which of the above, if any, would account for the difference.

/proc/bus/usb/devices show the same fundamental information except for different manufacturer and serial number.

[dbirk]

Let's make life easier for end-users. Just develop a list of USB Memory sticks that work for re-flashing the operating system for new builds.  Here's a start:

1. DOES NOT WORK:   Kingston DataTraveler (DT1)  2GB
based on my failed efforts trying to upgrade 650.  Reported also by others on this forum.

2. WORKS:  SanDisk Cruzer micro 1.0GB.
based on my successful efforts for build 653.

I note that the SanDisk identifies compatibility with Linux on the packaging.
It is also high-speed and requires a high-power USB port.   

The CL1 Hardware Design Specification for the XO Laptop points out that, unlike a regular laptop, it provides 5W total power spread among the 3 USB ports, unlike regular laptops with 2.5 Watts per USB.  If other devices are attached, such as a mouse, does the lower power of 1.7 per USB affect performance of some USB memory sticks?

[pgf]

I also don't know why people are having problems with different USB drives and OLPC.

i don't have an XO yet, so forgive a question:  is it a linux kernel that reads the drives during an upgrade, or is there a step done by the firmware?  if the latter, the firmware may have more restrictive usb storage code.

i work on devices similar to the XO laptop, and we've seen USB drives that were just plain buggy -- we had to put in a driver workaround when a supplier sold us a whole batch of drives which simply wouldn't accept an odd bus address, for instance.  the manufacturer verified that they had some bit mask code wrong in the on-drive microcontroller.  the devices worked fine under windows, though, so presumably the Gods in Seattle have put in a more resilient checks in that code path than the linux driver has.  (not surprising -- linux drivers tend to be written to "spec", where windows drivers are written to "market".)

but i agree with the following as being the most likely issue:

I'm *guessing* (note emphasis) that they are drives that come from the manufacturer with an odd configuration (multiple partitions or non-FAT formatting).  Note that such issues are not really "USB" compatibility - the USB part is working, it's the volume configuration that's the issue.

does the XO come with "fdisk" and "mkdosfs" commands, with which to repartition and reformat fresh drives?  this would eliminate some of that variability.(if not solve the problem).

paul

[markhadman]

I successfully upgraded to 653 using my mp3 player -  a Creative 1GB Zen Nano Plus. The nano had updated firmware and may have been reformatted by my Windows machine at some point. Hopefully this will save a couple of people the bother of getting a new USB stick, slightly off-topic but the info should be out there...

What else do people have lying around that might do the job... phones, cameras?

[Ben James Ben]

is it a linux kernel that reads the drives during an upgrade, or is there a step done by the firmware?  if the latter, the firmware may have more restrictive usb storage code.

It's the firmware. In fw.fth the ?fs-update routine is called during the startup routine.

Code:

: ?fs-update  ( -- )
   button-check button-x or  button-o or  button-square or   ( mask )
   game-key-mask =  if  protect-fw try-fs-update  then
;

fsupdate.fth is where try-fs-update is defined. It calls fs-update-from-list which checks each device to see if the firmware files are present. From the code, it appears that the system first checks the USB drive, then an SD card, and finally a certain IP address in the private range (probably added for convenience for the OLPC developers).

[pgf]

It's the firmware.

thanks!  that was fun.  first i had to figure out where the fw source was -- i thought it was linuxbios, but i guess that's history.  so then i had to check out the ofw sources, and build them, just for the heck of it.  good distraction.

but back to the topic -- that certainly means that it's quite possible for a usb storage device to work from a running linux system, and not work from the firmware.

it also, however, means that people can use SD cards instead, which a) tend to be bigger than cheap USB drives, and may be more standard.  (not sure about that, but i wouldn't be surprised.)

paul

[Ben James Ben]

I suspect that the problem is related to USB key drive startup time upon poweron. Performing an Activated Upgrade tonight from a USB key, I note that the XO looked at the USB key almost immediately after the USB key poweron. If the USB key is a bit slow and isn't ready in time, then perhaps it gets missed during an upgrade poweron.

FYI, I used an Imation 1GB "Clip Flash Drive". It worked out of the box, formatted in FAT16 format. I had no problems upgrading from a FAT16 USB key, so it looks like FAT32 is not necessarily required.

[pgf]

do you know whether there's a tracking item open for the issue?  your observation might be a good clue for whoever looks at the problem.

paul

[John_G1G1D1]

Even though OLPC said that the cruzers w/U3 software would not work, I had used it to update 650 to 653, and it worked for 653 to 656.  I didn't feel right deleting the U3, but would have if need be.

[haralds]

It looks like many of the versions of current update.1 and joyrides have serious problems with flash drives and SD cards. This especially effects ext 3 use.

I first blamed cards, but even the good ones get clobbered.

Some additional info:
- As somebody else remarked, some of this appears to depend to some degree on the response time of the card or USB flash stick/adapter. Some cards I have do not work at all, but are fine in cameras an on OS X/WIN32.
- Problem go from just corrupting the boot or super block to a whole range of blocks not being written to flash resulting in an unrecoverable disk. These are then also not recognized by the firmware.
- This appears to be more of an issue with Joyride and update.1 candidate builds than the shipping version (656.)

I seemed to have less trouble, when running from the SD card directly. Booting and running from NAND seemed to create the issue with external cards.

I also noticed that power management did not seem to work/was disabled on 651/656 (this is documented) and when running from the SD card on other builds. It was enabled in a number of experimental builds running from NAND. Could it be the power management is interfering with the SD/USB flash writes?