• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: [1] 2 3 ... 19
1  Hardware and U-Boot firmware / U-Boot stuff / Re: plug does not boot when unattended, boot fine w/ console on: August 22, 2011, 06:22:42 PM
If it were me, I'd first install the most recent DENIC uBoot, or at least the uBoot that comes with the SheevaPlug installer.

If that doesn't work, I'd look at the SD-card.  Perhaps it is not compatible with the SheevaPlug.  Try another brand.  Or, perhaps it could be made to work reliably with a bit of tweaking, say, by coding two mmcinits before trying to ext2load the uImage.

Good luck with it.
2  Hardware and U-Boot firmware / Hardware / Re: New plug - D2 on: May 25, 2011, 11:07:40 AM
Ubuntu has build-in support for ARMv7. Debian is currently stuck with ARMv5 with the stable release.
"Stuck" may be a loaded word here:  Many of us are (happily) "stuck" with our SheevaPlugs, GuruPlugs, Dockstars, etc., and appreciate Debian for "sticking" with us.
3  Hardware and U-Boot firmware / Hardware / Re: Flashing LEDs meaning? on: April 06, 2011, 01:34:12 PM
Good heavens, don't pay $25 for one of these external supplies.  They can be had for around $6 from eBay:

http://shop.ebay.com/?_from=R40&_trksid=m570&_nkw=5V+3A+power+supply

(BTW, given these supplies are becoming so popular, it's probably not a bad idea to have a spare one on the shelf just in case.)
4  Hardware and U-Boot firmware / Hardware / Re: What's your SheevaPlug's lifetime? on: March 03, 2011, 01:29:11 AM
I've had a SheevaPlug in continuous operation since May, 2009, thus far without failure.  Root partition is on a MicroCenter generic SDcard, still on the original card which is running fine.  Several USB components are hung off of a powered hub.  I keep waiting for something to fail, and I'm sure it eventually will.  Sometimes I wonder if I should open it up and replace the PS caps on general prinicple, but so far I have not done so.
Yep.  Shouldn't have crowed.  I came home tonight to discover my main desktop PC wouldn't boot.  Just hung in the BIOS "initializing USB".  After some experimentation, I found that the underlying culprit was the USB connection to my SheevaPlug's Console/JTAG.
But, the Sheeva was running fine.

I pulled the USB connection to the Sheeva, booted the PC, did some work, and then turned my attention to the SheevaPlug.  Hoping it was a glitch, I reset it.  It came back up fine, but its USB was continuing to drive my PC fits.  Here is a sample of what was spewing in the /var/log/kern.log on the PC over and over:
Code:
Mar  2 22:26:35 pandora kernel: [   10.571285] usb 7-1: new full speed USB device using uhci_hcd and address 17
Mar  2 22:26:35 pandora kernel: [   10.738333] usb 7-1: unable to read config index 0 descriptor/start: -71
Mar  2 22:26:35 pandora kernel: [   10.738506] usb 7-1: chopping to 0 config(s)
Mar  2 22:26:35 pandora kernel: [   10.746332] usb 7-1: string descriptor 0 read error: -71
Mar  2 22:26:35 pandora kernel: [   10.746573] usb 7-1: no configuration chosen from 0 choices
Mar  2 22:26:35 pandora kernel: [   11.021342] usb 7-1: USB disconnect, address 17
Mar  2 22:26:35 pandora kernel: [   11.361308] usb 7-1: new full speed USB device using uhci_hcd and address 18
Mar  2 22:26:35 pandora kernel: [   11.514281] usb 7-1: device descriptor read/all, error -71
Mar  2 22:26:35 pandora kernel: [   11.570095] hub 7-0:1.0: unable to enumerate USB device on port 1
Mar  2 22:26:35 pandora kernel: [   12.131316] usb 7-1: new full speed USB device using uhci_hcd and address 20
Mar  2 22:26:35 pandora kernel: [   12.282226] usb 7-1: device descriptor read/all, error -71
Mar  2 22:26:35 pandora kernel: [   12.340067] hub 7-0:1.0: unable to enumerate USB device on port 1
From the logs, I saw that the PC was having trouble with this USB device since yesterday, although it must have been sane enough then not to interfere with the boot sequence.

Next, I power cycled the Sheeva.  This time, ssh and nfs did not come up, although the device was pingable.  Since I had no console to see what was going on, I took the SDcard over to the PC to fsck, backing it up in the process.  This took some time.  Then, I reinstalled it and powered up the Sheeva.  This time, no-go.  The Sheeva just sat there blinking at me in a manner I've grown accustomed to seeing when a switching PS isn't quite able to jump-start itself.

Examination of the PS revealed no obvious failures.  One cap is bulged, but indeed, mine looked pretty good compared to the pics others have posted here.

Bottom line, I spent the past hour soldering together a wiring harness to power the Plug via an external wall-wart.  Luckily, I had several 5V 2+A wall-warts lying around  This one was a retread from my HDHomeRun box, which I repaired after it failed last summer.  The Sheeva seems happy, and frankly is running a *lot* cooler now.  Was hoping to get two years out of its PS, but 22 months is not bad from what I've seen here.

Oh, BTW, was curious if my Dlink USB hub would back-feed power to the Plug, as some have indicated some powered hubs will do.  (I was also half wondering if perhaps back-fed power might account for my Plug's PS's longevity.  But, alas, the Plug died as soon as I unplugged it from the power strip, even still connected to the powered hub.

Chalk up another one.
5  Hardware and U-Boot firmware / Hardware / Re: What's your SheevaPlug's lifetime? on: February 14, 2011, 04:51:36 PM
I've had a SheevaPlug in continuous operation since May, 2009, thus far without failure.  Root partition is on a MicroCenter generic SDcard, still on the original card which is running fine.  Several USB components are hung off of a powered hub.  I keep waiting for something to fail, and I'm sure it eventually will.  Sometimes I wonder if I should open it up and replace the PS caps on general prinicple, but so far I have not done so.

YMMV.
6  Hardware and U-Boot firmware / Hardware / Re: Sheevaplug powers off on its own on: January 18, 2011, 12:29:33 PM
downtime, your choices are

1. Fix your PS.  This usually involves replacing 1-3 bad capacitors.  See: http://plugcomputer.org/plugforum/index.php?topic=2320.msg16325#msg16325

2. Order a new "improved" PS from your provider and install that.  See: http://plugcomputer.org/plugforum/index.php?topic=2100.msg15399#msg15399

3. Purchase an external wallwart/power brick that is capable of providing at least 2A @ 5V DC, and use it instead of the built-in PS to power your Plug.

Good luck.
7  Linux Stuff / Kernel / Re: Root File System Data Corruption on: January 18, 2011, 12:32:08 AM
Thanks cbxbiker61.  That seems to have resolved at least half the problem.  You were quite correct.  I had (leftover from day 1)
Code:
rootfs / rootfs rw,relatime,errors=remount-ro 0 1
in /etc/fstab.  I changed it to
Code:
/dev/mmcblk0p1 / ext2 rw,relatime,errors=remount-ro 0 1
and rebooted after 37 days of up-time.  The system rebooted cleanly which it almost assuredly would not have done prior to this change.

I'm still seeing the 'not clean' indicator from tune2fs, though, so I'm left wondering how it will respond to a power fail restart.  I'll have to give that a try at a later date.  Perhaps the 'clean' vs. 'not clean' is a side effect of ext2 vs. ext3, as all my other root file systems are ext3.

In any event, on the basis of one test, at least clean reboots appear to work now, and that's a major hurdle.  Thanks again!
8  Linux Stuff / Kernel / Root File System Data Corruption on: January 17, 2011, 11:05:05 PM
I'm not sure if this is a software/kernel issue, a hardware issue, or even a peripheral device issue, but I've noticed that on my SheevaPlug, after running a while (many days), Unix will not boot cleanly.  Instead, I get dumped into single user mode and am forced to fsck the file system manually, and there is often significant corruption found.  I'm running an old Ubuntu 9.04 load on an SDcard with an ext2 file system and cbxbiker61's kernels (several of them, it doesn't seem to matter which one).  While running, the system is very stable, but when I boot -- regardless of whether it is a controlled 'shutdown -r now' boot or a power fail restart -- it rarely comes up cleanly the first time.  I don't think this is a one-of-a-kind problem, because I have also noticed some corruption, albeit less severe, on my Dockstar system running Debian Squeeze (root fs there is ext3 on a HD).

Here's an oddity I have observed on the SheevaPlug:  If I run
Code:
# sync; tune2fs -l /dev/mmcblk0p1 | grep state
I always see a 'not clean' state, whereas if I run this on my Ubuntu desktop's root fs, it always shows 'clean'.

Anyone else seeing a problem with file system corruption?  Any ideas?
9  Linux Stuff / General Linux questions / Re: How to clone a SheevaPlug? on: January 08, 2011, 05:14:22 PM
I don't claim to have any special knowledge of the MTD subsystem, but I wonder if part of the problem with successfully writing the NAND memory involves choosing the proper block size for the device.  Here is what I get if I "cat /proc/mtd":
Quote
$ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00400000 00020000 "uImage"
mtd2: 02000000 00020000 "rootfs"
mtd3: 0db00000 00020000 "data"
$
As you can see, the erase size (block size) of the NAND is rather large -- 0x20000 or 131072 bytes, or 256 512-byte blocks.  'dd' defaults to a 512-byte block.

I don't particularly want to mess with my NAND, but those of you who are might try using "dd bs=128K ...".  If anyone does this, I'd be interested in hearing if it work, or changes things.

The other inherent problem with 'dd' is that its behavior upon encountering an error does not work well with NAND.  My understanding is that NAND errors are to be expected, and when they are encountered, that block is skipped and the contents written to the next good block.  But, 'dd' doesn't do this, and as far as I know, it has no way to deal with NAND write errors appropriately.  Thus, it is a poor tool for this task.

Again, I have no special knowledge of how the MTD subsystem is implemented in practice, so this may not be the problem at all.  Perhaps the subsystem handles 512-byte writes.  Perhaps it silently handles NAND block errors.  It would be nice is someone who knew would answer us here.  This is where I'd start looking, though, if I were trying to investigate this problem.


10  Hardware and U-Boot firmware / Hardware / Re: Poll: What is the status of your SheevaPlug's Power Supply? on: January 01, 2011, 09:09:23 AM
Oh, that's painful to watch. I've observed this same phenomenon with other switching supplies.  Every time the Plug LEDs flash it's a power pulse being supplied to the processor board, but the PS is not able to sustain itself.  It's like a florescent lamp with a bad ballast.  This pulsating power can't be good for the electronics on either the PS or the main boards.  Please fix it before it either corrupts something else!
11  Hardware and U-Boot firmware / Hardware / Re: Guruplug-- Was it a mistake, should I return it? on: December 30, 2010, 09:25:31 AM
My advice: Aside from avoiding connecting it to a 1 GB ethernet, which is where I believe most of the heat issues reside, plug it in and enjoy it.  The GuruPlug is not a finished product.  Rather, it's a device for hacking and/or development.  So, if it breaks, fix it!

(What were you planning to do with your GuruPlug anyway, marse5368?)
12  Hardware and U-Boot firmware / Hardware / Re: Poll: Sheeva Plug Power Supply failures - does the mains voltage matter? on: December 25, 2010, 12:14:35 PM
Thanks, dattaway!  One more question:  I have a blown PS that a friend gave me that has some of the capacitors removed.  What is the value of the small electrolytic that is just to the right of the marking "400V 22uF" in your picture?  It's between the 2nd and 3rd one that you suggest replacing.  That one was removed and lost and I'd like to see if I can resurrect this PS.
13  Hardware and U-Boot firmware / Hardware / Re: Poll: Sheeva Plug Power Supply failures - does the mains voltage matter? on: December 22, 2010, 02:05:38 PM
I believe you are essentially correct, Norbert.  I think 5V/2A is all that is theoretically needed, but 3A would give you a bit more of a safety margin, and is what I would prefer.  Just remember:  Red is +, Black is -.

With all the SheevaPlug power supplies that have failed, has anyone cataloged the components (capacitors) that tend to go bad?  My Sheeva is still running on its original PS, and as a preventative measure, I would not mind preemptively replacing the two or three caps that are prone to fail.  Anyone care to make a list?
14  General Category / Application ideas and development Q/A / Re: Plugcomputer to store and watch movies? on: December 15, 2010, 12:37:57 PM
I use my SheevaPlug, in conjunction with an HDHomeRun tuner box, as a recorder for digital OTA television.  It is perfectly capable of recording two shows while I stream a third (or stream one of the ones actively being recorded -- great for skipping the commercials), so I think it would work fine in this capacity for streaming movies.  I have never tried to convert it to a MythTV back-end, but others have, I think, with success.  Of course, a front-end machine requires a whole lot more horse-power, and I doubt if the Marvel CPU would be up to that task.
15  Hardware and U-Boot firmware / U-Boot stuff / Re: Problem with Booting the kenel from a spinning USB disk on: December 11, 2010, 06:39:20 AM
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.
Pages: [1] 2 3 ... 19