Problem with Booting the kenel from a spinning USB disk

[kilowatt]

Uboot has two commands for reading the kernel from the USB interface. I have tried both and they only work sometimes.

bootcmd=usb start; fatload usb 0:1 0x8000000 uImage.sheeva.20090319;bootm 0x8000000

  Attempts to read the kernel from a fat partition (in this case uImage.sheeva.20090319 from the root directory of partition 1 on device 0)

bootcmd=usb start; ext2load usb 0:1 0x800000 /boot/uImage; bootm 0x800000

  Attempts to read the kernel from an ext3 partition on the usb drive (in this case uImage from /boot/ directory of partition 1 on device 0)

Both these methods work if uBoot succeeds in starting the USB subsystem (usb start) and finding the spinning disk as a storage device.  Some of the time this works following a push of the reset button (not always).   I have not seen it work on reboot via shutdown -r now.  Uboot times out while searching for the USB storage device.  Sometimes it boots anyway if the last read kernel image is still in memory at 0x800000.  This gets you running again but if my reason for reboot was to switch kernel images then I'm out of luck.

I did some testing using a USB flash Drive and This method seemed to work more reliably with a flash drive.  I'm not sure if it was 100 percent reliable though since I did not do a lot of testing.

I need to use a spinning drive for my application and would like to get the kernel from there.  This allows me to put the kernel images in /boot/ and use a soft link to select the current kernel without needing to write the kernel to flash or changing the uBoot bootcmds.

root@server:~# ls -l /boot
total 4196
lrwxrwxrwx  1 root   root          33 Apr 19 15:56 uImage -> uImage-2.6.30-rc2-optware-build-4
-rw-r--r--  1 root   root     2079828 Apr 19 14:41 uImage-2.6.30-rc2-optware-build-4
-rw-r--r--  1 root   root     2106760 Mar 19 15:05 uImage.sheeva.20090319

The spinning Drive I'm testing with is a Western Digital Elements 640GB USB 2.0 External Hard Drive.  If you get different results please post your configuration.

Some initial observations were posted under this topic:  http://openplug.org/plugforum/index.php?topic=33.0

[pushbx]

I can confirm this problem as I notice it too on my plug.  It can easily go unnotice because the rebooting the plug from the command line do work but only because the kernel image was still in ram.

I don't know if this is a spin up problem with the hdd.  I did a test where I reboot from Linux and stop the boot process at uboot.  Then I wait a long time before I did "usb start" and "fatload..." and the problem is the same.  Also strangely, I don't see it if I yank the power completely.

[pushbx]

At bit more testing shows the problem to be in U-Boot, and it appears to toggle between working and not working.  I did:

reset from U-boot
stop the boot process
usb start [failed]

reset from U-boot
stop the boot process
usb start [ok]

reset from U-boot
stop the boot process
usb start [failed]

if you keep going, usb start will pass, then fail, then pass.....

So as an ugly, ugly hack.  I did this to my bootcmd

bootcmd=usb start; fatload usb 0:1 0x8000000 uImage; bootm 0x8000000; reset

That way, U-Boot will reboot itself if the usb start failed.  At least with this hack the plug will, eventually, boot itself to prompt.

[tnagai]

I have the same problem in booting from USB hard disk drive.
In my case, the cause of the problem seems to be in the USB device detection phase of uBoot.

When 'usb start' is executed, uBoot begins to find USB devices.
However, the process is too quick for (at least my) USB HDD to wake up.
There should be a few-seconds of wait between 'scanning bus for devices' and 'scanning bus for storage devices'.

The details are as follows.

I'm using BUFFALO HD-HS1.0TSU2 (the internal drive is SAMSUNG HD103UJ), and the drive wakes up
after it receives a USB command from the host or it is re-connected to USB.

A) failure case

   0.The USB drive is connected to the SheevaPlug and is powered on.

   1.The drive becomes sleep because no USB commands are sent from the plug.

   2.Boot the SheevaPlug

   3.The plug begins to scan USB devices, and show the message on the console:

      USB: scanning bus for devices... 2 USB Device(s) found

   4.The drive begins to spin up.

   5.The plug begins to scan USB storage devices, and shows the message on the console:

      scanning bus for storage devices... 0 USB Device(s) found

      # My HDD is still under waking up at this time, and missed by the plug.

   6.The plug fails to boot from USB storage, and show the message on the console:

      ** Bad partition 1 **
      ** Bad partition 1 **
      ## Booting image at 00400000 ...
      Bad Magic Number

   7.The drive falls asleep because the host sends no USB commands anymore.

      Hence, rebooting the plug does not solve the problem in my case.

During the step 3 and 5, the plug should wait for a few seconds.

B) success case

   I could boot from USB HDD by modifying the step 2 as follows:

   2'.  Reconnect (or manually power on) the USB HDD just before booting the SheevaPlug

   This hack keeps the drive awake until the step 5.

[Tom]

I've installed Debian on an USB hdd based on Martin Milchmayr's instructions. rootfs is ext3 (with 128bit Inodes). rootdelay is set to 10. Every time I do a cold boot (power on) the plug boots without any problem. When I shutdown the plug with "shutdown -r now", then the plug restarts, u-boot starts USB, find 2 devices, one storage device. Then it reports:
** Bad partition 1 **
** Bad partition 1 **
## Booting image at 00400000 ...
Bad Magic Number

The USB hdd is plugged directly into the SheevaPlug, no additional devices. Boot arguments exactly the same as in Martin Milchmayr's instructions. U-Boot 1.1.4 (Mar 19 2009 - 16:06:59) Marvell version: 3.4.16.

When I compare the cold boot and reboot log files I observe, that there is a difference in one row:

Cold boot:
scanning bus for storage devices... 1 Storage Device(s) found

Reboot:
scanning bus for storage devices... T 1 Storage Device(s) found

There is an additinal "T" (like trouble, terror  ). What does this indicate ?

Then I also tried the different usb commands in u-boot and found the following differences:

Cold boot:
Marvell>> usb info
1: Hub, USB Revision 2.0
- Marvell EHCI
- Class: Hub
- PacketSize: 64 Configurations: 1
- Vendor: 0x0000 Product 0x0000 Version 1.0
Configuration: 1
- Interfaces: 1 Self Powered 0mA
Interface: 0
- Alternate Settings 0, Endpoints: 1
- Class Hub
- Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

2: Mass Storage, USB Revision 2.0
- Trekstor DataStation maxi g.u 00E14E88
- Class: (from Interface) Mass Storage
- PacketSize: 64 Configurations: 1
- Vendor: 0x0c0b Product 0xb159 Version 1.3
Configuration: 1
- Interfaces: 1 Self Powered 2mA
- String: "Bulk Only Configuration"
Interface: 0
- Alternate Settings 0, Endpoints: 2
- Class Mass Storage, Transp. SCSI, Bulk only
- String: "Bulk Only Interface"
- Endpoint 1 In Bulk MaxPacket 512
- Endpoint 2 Out Bulk MaxPacket 512

Marvell>> usb part
print_part of 0

Partition Map for USB device 0 -- Partition Type: DOS

Partition Start Sector Num Sectors Type
1 63 20482812 83
2 20482875 956285190 5 Extd
5 20482938 2056257 82
6 22539258 954228807 83


Reboot:
Marvell>> usb info
1: Hub, USB Revision 2.0
- Marvell EHCI
- Class: Hub
- PacketSize: 64 Configurations: 1
- Vendor: 0x0000 Product 0x0000 Version 1.0
Configuration: 1
- Interfaces: 1 Self Powered 0mA
Interface: 0
- Alternate Settings 0, Endpoints: 1
- Class Hub
- Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

2: Mass Storage, USB Revision 2.0
- Trekstor DataStation maxi g.u 00E14E88
- Class: (from Interface) Mass Storage
- PacketSize: 64 Configurations: 1
- Vendor: 0x0c0b Product 0xb159 Version 1.3
Configuration: 1
- Interfaces: 1 Self Powered 2mA
- String: ""
Interface: 0
- Alternate Settings 0, Endpoints: 2
- Class Mass Storage, Transp. SCSI, Bulk only
- String: ""
- Endpoint 1 In Bulk MaxPacket 512
- Endpoint 2 Out Bulk MaxPacket 512

Marvell>> usb part
print_part of 0
## Unknown partition table


So "usb info" doesn't find the strings "Bulk Only Configuration", "Bulk Only Interface" after reboot. Also after reboot u-boot doesn't find the partitions anymore! This explains why the reboot fails. Power off the disk and the command reset will reboot without problems again.

I think that the communication between u-boot and the USB hdd fails partially after reboot (all other usb commands give no output differences between cold boot and reboot).

The same USB hdd model reboots without any problem at a NSLU2. If I understood this thread correctly I am not the only one who has this problem. Maybe I'm wrong but I don't think that the USB hdd itself has a problem. Rather u-boot runs different routines for cold boot and reboot, which could be seen on the additional "T" while scanning for storage devices. Or the shutdown of the plug leaves the USB hdd in a state which is incompatible with the plug.

Any idea how this could be fixed or bypassed ?

[trampjuice]

Anyone ever get a workaround for this? appending reset doesnt work for me because it bombs out...

[Tom]

I tried different u-boot versions. All show the same behaviour that my USB hdd stopped spinning at reset and is therefore not found while u-boot scans for bootable devices.

Meanwhile I found a workaround how the SheevaPlug could start every time. I had an old 32MB (not GB!) card out of an old Palm device. The card is FAT formatted. I deleted all files and directories from the card and copied two files to the root directory:
uImage (copied from /boot)
uInitrd (copied from /boot)

Since I had installed Debian after Martin Milchmayrs instructions, I only had to change two variables within u-boot:
bootcmd_mmc=mmcinit; fatload mmc 0 0x0800000 /uInitrd; fatload mmc 0 0x400000 /uImage
bootcmd=setenv bootargs $(bootargs_console) $(bootargs_root); run bootcmd_mmc; bootm 0x400000 0x0800000

This way the kernel and initrd is loaded from the SD card. The kernel loads its own drivers to start (and find) the usb hdd regardless whether the dive is already spinning or not. The whole system is loaded from usb once the kernel is loaded, the SD card isn't used afterwards.

Now I can use ssh, no need for permanent use of the serial console anymore. One big advantage of ssh is that the Midnight Commander could be controlled by mouse within putty (mouse won't work with the serial console).

I see no problem so far. Also kernel updates are very easy this way. Simply copy a new uImage to the SD card (and name it exactly uImage). I only see one disadvantage: with mmcinit the SD card reader started and I assume it will remain running. This will  increase power dissipation a little bit. I don't know how I could power off the sd card within debian.

Now I am relaxed while waiting until u-boot will learn to handle usb hdds correctly.

[hammerinhank]

It doesn't work.  I have tried all of the u-boot's that I can find including the open u-boot and they all predictably fail every other boot.  I just don't have the time to even look into debugging this problem.  I'll keep trying new ones as they come out, but I'll stick to booting the kernel from the flash.  That works every time. 

[Nematocyst]

Meanwhile I found a workaround how the SheevaPlug could start every time. I had an old 32MB (not GB!) card out of an old Palm device. The card is FAT formatted. I deleted all files and directories from the card and copied two files to the root directory:
uImage (copied from /boot)
uInitrd (copied from /boot)

Thanks much for this advice, it worked for me (see below) using uboot version 3.4.19.  My problem was not the drive failing to spin, but that uboot didn't recognize it as a storage device.  I got 'T T T T' and then 0 storage devices found, but of course after booting the default Ubuntu, mounting worked fine.  I used the tarball method from Michlmayr's instructions.  After that failed, I used your hint to get the plug booting properly.  [Followed Michlmayr's instructions completely for USB boot, then applied yours]

The only problem with your instructions was a typo:  I needed 0x0800000 instead of 0x080000 on the bootcmd_mmc variable.  eg.

Code:

setenv bootcmd_mmc 'mmcinit; fatload mmc 0 0x0800000 /uInitrd; fatload mmc 0 0x400000 /uImage'
setenv bootcmd 'setenv bootargs $(bootargs_console) $(bootargs_root); run bootcmd_mmc; bootm 0x400000 0x0800000'
saveenv
boot

Thanks again!

For the record, my drive that required this treatment was a Samsung S2 640GB External Hard Drive HX-MU064DA/G22.

[restamp]

Is anyone successfully booting their SheevaPlug from a HD attached through a powered USB hub?  If so, I'd like to hear about it.  Personally, I've never had any success.

I understand a few folks have succeeded in booting from a HD directly attached to the SheevaPlug, but that precludes attaching any other USB devices to the Plug.

OTOH, I've had good success with booting a Dockstar directly from a HD, which is viable because the Dockstar brings out 4 USB ports.

I suspect the problem is that the uBoot doesn't know how to initialize the HD when it is attached through a remote hub, but that's only a guess.  Thus, most people elect to use an SDcard as their boot device because that method works reliably.

[swaery]

Same issue here! I don’t know why this is the case but the only way of getting it back work is rebooting the plug from command line. There are chances that it could be because of a spin up problem occurring in the Hard Disk Drive but we can’t stop considering other issues as well!

[Zortrium]

The HD spin up issues crop up even when the HD is connected directly, but can be (sort of) worked around -- the USB hub is the issue that, to my knowledge, hasn't been worked around.  I was booting my plug off a USB HD for awhile (both kernel and root partition), and it worked mostly, but occasionally the spin-up issue would cause it to fail at boot and I'd have to use the serial console to kick it back into booting.  I've since switched to an SD card.

[birdman]

Is anyone successfully booting their SheevaPlug from a HD attached through a powered USB hub? 

I have /boot on an SD card, but everything else (/, etc.) is on a HD though a hub.

[susiehaynes]

i also have the same issue here.

please update us if this is fixed already. thanks!