• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: [1]
1  Linux Stuff / Kernel / Re: sheevaplug USB mount fails periodically (debian) on: June 26, 2011, 03:28:20 AM
Are your USB drives powered externally or by sheevaplugs power supply? I had the same issue when I changed my external powered 3.5" usb hdd to a 2.5" hdd (WD with reduced spinup power) which is powered by the sheevaplug only (so no extra power supply). I wanted to change to 2.5" to reduce my power costs but got an unstable system.

My workaround was to use a Y-cable for a second usb power source and conneted the second cable end to one of the free usb ports on my OpenRD client. No problems afterwards. My conclusion is that Sheevaplugs internal power supply isn't able to power the plug AND an external hdd even if it has reduced power consumption. Maybe a SSD drive would be ok.
2  General Category / General Discussion / Re: External Drive Spin Down? on: February 28, 2010, 02:50:54 PM
I use hd-idle and an external usb hdd TrekStor (with WD AV 500GB).
http://hd-idle.sourceforge.net/

You have to compile the source code yourself. This could easily be done on the sheevaplug once you installed the build-essentials. First test should be:
hd-idle -t sda
This should spin down the disk (usually you'll hear that).

Unfortunately the disk normally spins up again after a short period of time. Therefore you'll have to minimize all read/write attempts to the disk. Here you'll find some hints:
http://www.peter-woods.co.uk/slug/#s8
http://old.nabble.com/Spinning-down-disks-when-using-Samba-td15855345.html

If your disk spins up too fast resp. too often after you applied the above hints then you can check what's going on with:
find / -xdev -mmin -60

In my case I had a file wins.dat written by Samba. This could be stopped after setting "local master = no" in smb.conf.
After installation of lighttpd I had two files /etc/cron.d/php5 and /etc/cron.d/php4 which purged every 30minutes session files and therefore spun up the disk. You could set the time from every 30minutes to every 24h.

With hd-idle my disk spins down after 10 minutes of inactivity and will remain silent most of the time.
3  Hardware and U-Boot firmware / U-Boot stuff / Re: Problem with Booting the kenel from a spinning USB disk on: January 21, 2010, 01:25:34 PM
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.
4  Hardware and U-Boot firmware / U-Boot stuff / Re: U-Boot can't read USB HDD partition table on: January 05, 2010, 10:44:10 AM
That's a usual behavior for the current u-boot versions. You should first power on the usb hdd, so that the disk is spinning (you'll hear that). Afterwards you should power on the sheevaplug.

When the boot fails then do the following: At first poweroff/poweron the disk, 5sec later type reset at the Marvell prompt. Then the disk will remain spinning while u-boot searches for the disk.

If you compare the output you'll notice that there is an additional single T every time before scanning the drive in the case the boot fails. This additional single T will not appear if the boot succeed.

Be aware that this u-boot failure will also disable the possibility to do a shutdown -r now without manual assistance. This is also a reason why the serial console is always in use at my plug.

Yes, it's annoying. Globalscale should know it since months but wasn't able to fix it yet. On the other side u-boot is not their software, as far as I understood they have only adapted u-boot for the plug.

5  Hardware and U-Boot firmware / U-Boot stuff / Re: What about Open U-Boot for SheevaPlug ? on: November 19, 2009, 12:03:14 PM
hammerinhank,

which Open u-boot versions have you tested? Did you use an usb stick or an usb hdd? If hdd, what model?
6  Hardware and U-Boot firmware / U-Boot stuff / Re: What about Open U-Boot for SheevaPlug ? on: November 18, 2009, 11:59:15 AM
I tried Open U-Boot 2009.08-00285-ge1c35ea (Oct 21 2009 - 16:20:03) a few weeks ago. It was an already compiled version given by a forum member. This u-boot was only 170kB and did only support fatload, no ext2load. Because I boot from an external usb hdd I had to resize my partitions to build an additional FAT32 partition to hold the kernel files. I could fatload the uInitrd but the uImage run into a "Unable to handle kernel paging request at virtual address e1a06003" when starting the file alteration monitor (FAM).

I also recognized that the open u-boot does the same spin down at reset as the former Marvell u-boot. After that the disk does not spin up until usb start (exactly when "scanning bus for storage devices..." is executed). After a while the message "Device NOT ready" with the following rows occured:
Request Sense returned 00 00 00
1 Storage Device(s) found

So for me the same usb problem in open u-boot and Marvell u-boot. To boot properly I must power on the plug and my external usb hdd at the same time. A reset from u-boot prompt or from Debian results in a not recognized storage device.

Afterwards I switched back to Marvell u-boot 3.4.19 and the kernel boots without any problem (if plug and hdd are powered on at the same time) regardless whether I fatloaded the kernel from the FAT32 partition or ext2loaded the kernel from the ext3 rootfs partition.

From my experience I could not really recommend to switch to open u-boot. Though maybe things have changed meanwhile.
7  Hardware and U-Boot firmware / U-Boot stuff / Re: new uboot version 3.4.23 on: November 13, 2009, 01:10:52 PM
I haven't tried yet u-boot 3.4.24 but I tried 3.4.23. It seems that a waiting time was build in to give usb hdds a little bit more time to settle before scanning. Here a part of my log:

(Re)start USB...
USB:   scanning bus for devices... 2 USB Device(s) found
Waiting for storage device(s) to settle before scanning...
T 1 Storage Device(s) found
** Bad partition 2 **
** Bad partition 2 **
## Booting image at 00400000 ...
Bad Magic Number

When I perform a reset from the u-boot prompt, my usb hdd spins down. It doesn't spin up when "(Re)start USB..." is displayed. It spins up as soon as the single "T" is displayed. But the usb hdd is now found, it wasn't found in the previous u-boot versions.

So there should be an additional spin up command just before the waiting time, exactly the same command which is given at the single "T".

I already took a look into the source but this is far behind my programming skills. It would be great if someone who understand the sources could check what should be added to spin up the usb hdd early enough.

As with the previous u-boot versions the usb hdd boot without problem when powered on with the plug at the same time. Then the usb hdd spins up directly and spins all the time, no "T" is displayed, booting without any problem.
8  General Category / General Discussion / Re: Commercial software for sheeva plug on: November 08, 2009, 07:03:49 AM
Sounds interesting but does the Tonido Sheevaplug version only run with the preinstalled Ubuntu in the NAND? I am running Debian Lenny installed from Martin Milchmayr's tar ball on an usb hdd. Would Tonido also run from usb hdd? Any side effects with other software which is already installed? Any chance to test Tonido on the Sheevaplug before purchasing a license?
9  General Category / General Discussion / Re: Sheevaplug installer - version 1.0 on: September 11, 2009, 04:26:30 AM
Rabeeh,

what are the changes within u-boot ? I don't find details about the u-boot update in the wiki.

The reason I ask is that I have exactly the same difficulties with usb hdd which tnagai reported here:
http://plugcomputer.org/plugforum/index.php?topic=131.0

We already have two delays which we can use within u-boot:
bootdelay = time before automatic boot starts
rootdelay = time between bus scan for devices and loading the kernel

I think we also need a delay within the bus scan for devices (call it "scandelay") because our usb hdds do not start to spin up until "usb start" is executed "scanning bus for devices". Unfortunately the following "scanning bus for storage devices" is executed immediatly before the usb hdd had finished the spin up. bootdelay and rootdelay will not influence this behaviour because they are used before respective after the bus scan.

I also can only boot from usb hdd when I manually power on the usb hdd just before booting the SheevaPlug, keeping the drive awake until "scanning bus for storage devices". On reboot the usb hdd spins down, therefore every reboot fails.

I assume that such a scandelay would fix a whole bunch of problems with usb devices.

Please let us know whether the u-boot update from version 3.4.16 to 3.4.19 bring us any progress with the bus scan problem for usb devices. Or are there any plans to work on this in a future u-boot update ? I am really waiting for a full working usb hdd support because that is the only reason why the SheevaPlug haven't yet replaced my NSLU2.

10  Hardware and U-Boot firmware / Hardware / Re: Can't boot from large usb harddrive on: August 27, 2009, 01:37:12 PM
I use a 500GB USB HDD and had similar messages until I formatted the rootfs with 128bit Inodes (I use ext3 but I assume ext2 will also work).
11  Hardware and U-Boot firmware / U-Boot stuff / Re: Problem with Booting the kenel from a spinning USB disk on: August 19, 2009, 01:13:21 PM
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  Smiley ). 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 ?
Pages: [1]