The reason others haven't responded is that we haven't really tried a restoral ourselves, so we cannot speak with authority. I would, however, try naugtur's method above if I needed to restore my NAND. Another possibility, using the uboot as the restoral vehicle, is outlined here: http://plugcomputer.org/plugforum/index.php?topic=878.msg16414#msg16414 Of course, you'dby restamp - Debian
Here's what I do: Quote# cd / && find . dev -mount | cpio -oc | gzip >/sheeva/res/root-`date +%F`.cgz where, obviously, the /sheeva directory is mounted (not part of the root file system). This should produce a backup that provides everything you need should you need to restore your root file system, but it populates /dev with more devices than is actually needed, a minor buby restamp - Debian
For us uninitiated folks, how does one tell whether the Marvel chip's hardware encryption engine is being used? Was it built into the kernel after some point? Does it require a special dm_crypt?by restamp - Debian
Brandon, I don't think it is the Dockstar hardware that's the bottleneck, at least if all you are trying to do is stream programming without conversion. Outwardly, my setup is quite different from yours, but I am doing something similar. I don't have a Bluetooth player, PS3, nor mediatomb, and my WiFi router is located several switches away from the Dockstar. However, I'veby restamp - Debian
If mtd0 points to the part of the NAND containing the uBoot -- i.e, the first 1Mb or so of NAND -- which it does on Jeff's device mapping for the Dockstar (but does not, for instance, on my SheevaPlug), then no, I don't think the CA-42 cable could be used by itself to restore a Dockstar device after mtd0 has been erased. Think of the uBoot as analogous to a PC's BIOS. By defaulby restamp - uBoot
And, with luck, you'll never need it. In our environment, the JTAG is really only useful in two specific situations: 1. When something has so thoroughly bricked the device that even the uBoot will not run. 2. When you want to easily get your device back to a known state. If you have a bootable and sane uBoot on the device, especially one capable of booting from external media, you caby restamp - uBoot
The following post was shamelessly lifted from the busybox mailing list. Rob is well known in the embedded community, and this (including the two cited URLs) is probably worth the read for most folks here: QuoteSubject: Re: flashcp Date: Thu, 6 Jan 2011 03:59:39 -0600 From: Rob Landley Organization: Boundaries Unlimited To: busybox@busybox.net References: <AANLkTikTLAbTo5aAs7=5TqHsewOby restamp - Debian
Well, I've never attached a JTAG to a Dockstar, so I cannot speak definitively, but I have used the JTAG on a SheevaPlug to reload it. The JTAG interface is a completely different interface from the serial console. There is a command language interface to the JTAG to do things like reflashing the NAND memory or stepping through the processor, but it is fairly low level. Typically, the JTAby restamp - uBoot
Just curious: Are you saying that running Jeff's uBoot script, install_uboot_mtd0.sh, from an active booted Linux,won't work unless the original uBoot is first reinstalled? If so, how does it fail? I'm wondering if the problem you experienced wasn't a uBoot problem per se, but rather a problem with an altered uBoot environment. Jeff's uBoot script, I believe, doesnby restamp - uBoot
Jeff's install script checks the existing uBoot to see if it is indeed the latest version. If it is, the script will not reinstall it, but should leave it alone.by restamp - Debian
The only thing I can suggest is that perhaps you inadvertently coded a non-hexadecimal character in one of the MAC hextets, or perhaps typed a semi-colon instead of a colon, or put in a space -- something like that. That's why altering the uboot (or even its parameters) is potentially dangerous. I'm not sure whether you'd even be able to use the netconsole, if you have configurby restamp - Debian
The modules are normally located in /lib/modules under the directory associated with the running kernel ("uname -r"). In a word, I don't know where you'd get them if they are not provided. I think the options of what gets built with the kernel (and either included in it directly, or made available via modprobe) are specified in a configuration file which is populated prior tby restamp - Debian
QuoteStill wonder why the upgraded kernel's dmesg doesn't see my printer and lsmod only lists 4 modules??? I suspect this because the Debian default kernel comes with a lot of modules compiled in, whereas the new kernel does not. In other words, you are expected to modprobe what you need. Adding modules after the fact allows for a lot of flexibility, but some modules need to be built-by restamp - Debian
I did a some additional checking, and here's something potentially interesting: If you "od -Ax uboot.mtd0.kwb | tail", you get:Quotep0 od -A x uboot.mtd0.kwb | tail 053010 130326 000144 130353 000144 000000 000000 142414 000144 053020 000001 000000 000001 000000 041020 000141 130402 000144 053030 073352 000144 000000 000000 131030 000144 000004 000000 053040 000001 000000 04by restamp - uBoot
I'm not an expert on this, but it seems to me that you have the dreaded "bad blocks on mtd0" condition. Jeff says don't try to install his uBoot if you have this, but of course, at this point, you have already done so, so you need to figure out how to continue before you turn off the power and brick your PogoPlug. It seems the 4th block of NAND in your device -- the one frby restamp - uBoot
R-One, see http://forum.doozan.com/read.php?2,2962,2964#msg-2964 for how to replicate your root partition onto a bigger drive. The details should be the same regardless of whether you are moving to a HD or a different thumb drive. Good luck!by restamp - Debian
I note that Jeff's uBoot environment explicitly sets the root filesystem file type to ext2. This is probably not a bad choice when the file system is on a thumb drive -- ext3 file systems generally require more disk writes than ext2 ones. However, now that I'm booting from an HD, I find it desirable to convert to ext3. ext3 file systems are in general more robust in the face of powerby restamp - Debian
Phreon, I agree: Once I determined that Jeff's uBoot would handle a HD on the Dockstar, I copied everything over to the HD and unplugged the thumb drive. A couple comments: I come from a SheevaPlug background, and there people had all sorts of trouble getting a HD to reliably boot. I think it has something to do with the fact that the SheevaPlug only has one USB port, and thus requires aby restamp - Debian
Thanks, ecc, I think that will work for me!by restamp - Debian
The same CA-42 cable, sold for a different model Nokia phone, is a couple bucks cheaper here, and from the same vendor. (Go figure!) Can anyone tell me the pinouts on the Nokia end of the cable, so I can tell which wire serves which function without having to resort to opening up the USB end to check?by restamp - Debian
You might try changing your /etc/apt/sources.list to:Quotedeb http://ftp.us.debian.org/debian squeeze mainby restamp - Debian
One problem with your serial console is that your signal levels are incorrect. You need to have a 3V signal at the board interface, whereas the standard RS-232 puts out a much higher signal level. If you tried connecting an RS-232 signal directly to your board, you may have fried something (or maybe not). The easiest way to connect to the serial port is with a CA-42 USB cable. See: http://by restamp - uBoot
I also am running my Dockstar entirely off of a hard drive. This works fine for me on the Dockstar, but I could never quite make it work on the SheevaPlug. I believe the reason for this is that the Sheeva required an external USB hub, unless you intended to only have a HD on it (and even then it was not recommended to draw the drive power from the Sheeva's USB port), and the hub seemed toby restamp - Debian
It shouldn't be a problem that the first partition doesn't start at the beginning of the hard disk. Are you sure that your partition table doesn't have any overlaps? As far as the ext2/ext3 thing, when I went to a hard drive solution, I also created the root partition as ext3. I had avoided doing that on the thumb drive because the ext3 journal can significantly increase the nby restamp - Debian
Well, it looks as if you succeeded in installing the change. It would have been nice if you had done the fw_printenv before you did the fw_setenv, so that you knew what to set mtdparts back to if the change didn't fix things. But I really suspect the new value is the correct one for your Plug. Can you boot to the NAND now? If not, then it must be some other problem.by restamp - Debian
Eww, that fsck doesn't look good. FWIW, my Dockstar boot proceeds very much like yours up to the "Disabled Privacy Extensions", but then continues on with another dozen lines or so from RPC, eth0, etc. Since the fsck has removed some necessary files, you'll have to reload to try it again. Pay close attention to the repopulation of your root partition to see if there areby restamp - Debian
The net console output looks odd to me. It seems like you have a thumb drive attached, but the drive only contains uImage, and not uInitrd. Were you trying to boot to a thumb drive when you captured this output, or were you trying to boot to the NAND here? Were any USB devices plugged in at the time? I've never seen this before. It's difficult to diagnose this remotely. If the nby restamp - Debian
I think it is "flash_erase", followed by "nandwrite". For an example of how this is done, see Jeff's install_uboot_mtd0.sh script. Please understand though, that if you write to the wrong parts of NAND, you can wind up with a bricked device, so make sure you are careful and fully understand what you are doing before playing with these commands.by restamp - Debian
rgtaa, I googled tonidoplug, but didn't find the particulars. If it is truly like a SheevaPlug, it should have a mini-USB connector that you can attach a cable from to your PC and examine the uBoot and console there. If it has that, and an on-board JTAG, you might be able to use the Sheeva Installer to restore your Plug to sanity, but without knowing more about the tonidoplug, I'm onlby restamp - Debian
ayrlander Wrote: > If your LEDs show up under plug:green:health, then > I'm not sure what kernel you're running; it's not > one of the the more recent kirkwood kernels. In > that kernel, they show up as > /sys/class/leds/dockstar:green:health and > /sys/class/leds/dockstar:orange:misc. Hi ayrlander. Thanks for your post above. I was still running the kby restamp - Debian