[SOLVED] Reflash PogoPlug to NAND via serial connection?

[BillyBoy]

My good old DockStar - currently applied with Jeff's uBoot and running an older Plug Box installation from USB stick - seems to have a big problem. After a regular pacman update some time ago I noticed that my configuration had become very unstable, often resulting in a system crash. At one point I had to figure out that my applications stopped working at all, I even couldn't connect to the box anymore via SSH, even though the LED still turned from flashing green into solid green after booting up, indicating that the DockStar has correctly entered the kernel. The box even got its IP address, but anyway, the system wasn't accessable anymore and its installation turned out to be totally screwed up.

In order to re-install a fresh ArchLinux system to my USB stick I tried to boot into the original PogoPlug firmware. But to my surprise I couldn't gain any access to the system, too. Almost the same here: No SSH working, just the presence of a fixed IP address parameter set from several previous netcat tests. So I was able to connect to the DockStar from my WinXP PC using a netcat instance and I could watch the boot process. But so far I couldn't detect any problem with Jeff's bootloader. However, as netcat can only trace the process until the kernel starts, I coudn't find out what really happened to my device configuration.

Last weekend I finally decided to open my DockStar chassis and I attached a CA-42 serial cable. Finally, while watching the PuTTY log during a PogoPlug boot on my PC, I discovered a bad data checksum, preventing the system from starting up correctly. As the bootloader was working every time, I guess MTD 0 is still fine, but that might not apply to MTD 1 and/or MTD 2 partitions on my DockStar's NAND. That could already be a very bad sign, but still I hope the device can be recovered. Here are the PuTTY logs (Host IP address changed) for the two scenarios:

Plug Box (USB stick with damaged Linux installation plugged):
$this->bbcode_second_pass_code('', 'U-Boot 2010.09 (Oct 23 2010 - 11:49:22)
Marvell-Dockstar/Pogoplug by Jeff Doozan

SoC: Kirkwood 88F6281_A0
DRAM: 128 MiB
NAND: 256 MiB
In: serial
Out: serial
Err: serial
Net: egiga0
88E1116 Initialized on egiga0
Using egiga0 device
host 192.168.0.0 is alive
Uncompressing Linux... done, booting the kernel.
[ 12.957785] rtc-mv rtc-mv: internal RTC not ticking
[ 12.967642] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[ 13.811924] sd 0:0:0:0: [sda] Asking for cache data failed
[ 13.817436] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 13.826791] sd 0:0:0:0: [sda] Asking for cache data failed
[ 13.832374] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 13.948667] sd 0:0:0:0: [sda] Asking for cache data failed
[ 13.954183] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 23.344695] EXT2-fs (sda1): error: ext2_check_page: bad entry in directory #62977: : unaligned directory entry - offset=0, inode=1869641829, rec_len=29810, name_len=32

INIT: version 2.88 booting
INIT: No inittab file found
Enter runlevel: ')

PogoPlug (no device plugged):
$this->bbcode_second_pass_code('', 'U-Boot 2010.09 (Oct 23 2010 - 11:49:22)
Marvell-Dockstar/Pogoplug by Jeff Doozan

SoC: Kirkwood 88F6281_A0
DRAM: 128 MiB
NAND: 256 MiB
In: serial
Out: serial
Err: serial
Net: egiga0
88E1116 Initialized on egiga0
Using egiga0 device
host 192.168.0.0 is alive


U-Boot 1.1.4 (Jul 16 2009 - 21:02:16) Cloud Engines (3.4.16)

U-Boot code: 00600000 -> 0067FFF0 BSS: -> 00690D60

Soc: 88F6281 A0 (DDR2)
CPU running @ 1200Mhz L2 running @ 400Mhz
SysClock = 400Mhz , TClock = 200Mhz

DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
DRAM CS[0] base 0x00000000 size 128MB
DRAM Total size 128MB 16bit width
Flash: 0 kB
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
NAND:256 MB

CPU : Marvell Feroceon (Rev 1)
CLOUD ENGINES BOARD: REDSTONE:1.0

Streaming disabled
Write allocate disabled


USB 0: host mode
PEX 0: interface detected no Link.
Net: egiga0 [PRIME], egiga1
Hit any key to stop autoboot: 3 2 1 0

NAND read: device 0 offset 0x100000, size 0x300000


Reading data from 0x100000 -- 0% complete.
Reading data from 0x107800 -- 1% complete.
Reading data from 0x10f000 -- 2% complete.
Reading data from 0x117000 -- 3% complete.
Reading data from 0x11e800 -- 4% complete.
Reading data from 0x126000 -- 5% complete.
Reading data from 0x12e000 -- 6% complete.
Reading data from 0x135800 -- 7% complete.
Reading data from 0x13d000 -- 8% complete.
Reading data from 0x145000 -- 9% complete.
Reading data from 0x14c800 -- 10% complete.
Reading data from 0x154000 -- 11% complete.
Reading data from 0x15c000 -- 12% complete.
Reading data from 0x163800 -- 13% complete.
Reading data from 0x16b800 -- 14% complete.
Reading data from 0x173000 -- 15% complete.
Reading data from 0x17a800 -- 16% complete.
Reading data from 0x182800 -- 17% complete.
Reading data from 0x18a000 -- 18% complete.
Reading data from 0x191800 -- 19% complete.
Reading data from 0x199800 -- 20% complete.
Reading data from 0x1a1000 -- 21% complete.
Reading data from 0x1a8800 -- 22% complete.
Reading data from 0x1b0800 -- 23% complete.
Reading data from 0x1b8000 -- 24% complete.
Reading data from 0x1bf800 -- 25% complete.
Reading data from 0x1c7800 -- 26% complete.
Reading data from 0x1cf000 -- 27% complete.
Reading data from 0x1d7000 -- 28% complete.
Reading data from 0x1de800 -- 29% complete.
Reading data from 0x1e6000 -- 30% complete.
Reading data from 0x1ee000 -- 31% complete.
Reading data from 0x1f5800 -- 32% complete.
Reading data from 0x1fd000 -- 33% complete.
Reading data from 0x205000 -- 34% complete.
Reading data from 0x20c800 -- 35% complete.
Reading data from 0x214000 -- 36% complete.
Reading data from 0x21c000 -- 37% complete.
Reading data from 0x223800 -- 38% complete.
Reading data from 0x22b800 -- 39% complete.
Reading data from 0x233000 -- 40% complete.
Reading data from 0x23a800 -- 41% complete.
Reading data from 0x242800 -- 42% complete.
Reading data from 0x24a000 -- 43% complete.
Reading data from 0x251800 -- 44% complete.
Reading data from 0x259800 -- 45% complete.
Reading data from 0x261000 -- 46% complete.
Reading data from 0x268800 -- 47% complete.
Reading data from 0x270800 -- 48% complete.
Reading data from 0x278000 -- 49% complete.
Reading data from 0x27f800 -- 50% complete.
Reading data from 0x287800 -- 51% complete.
Reading data from 0x28f000 -- 52% complete.
Reading data from 0x297000 -- 53% complete.
Reading data from 0x29e800 -- 54% complete.
Reading data from 0x2a6000 -- 55% complete.
Reading data from 0x2ae000 -- 56% complete.
Reading data from 0x2b5800 -- 57% complete.
Reading data from 0x2bd000 -- 58% complete.
Reading data from 0x2c5000 -- 59% complete.
Reading data from 0x2cc800 -- 60% complete.
Reading data from 0x2d4000 -- 61% complete.
Reading data from 0x2dc000 -- 62% complete.
Reading data from 0x2e3800 -- 63% complete.
Reading data from 0x2eb800 -- 64% complete.
Reading data from 0x2f3000 -- 65% complete.
Reading data from 0x2fa800 -- 66% complete.
Reading data from 0x302800 -- 67% complete.
Reading data from 0x30a000 -- 68% complete.
Reading data from 0x311800 -- 69% complete.
Reading data from 0x319800 -- 70% complete.
Reading data from 0x321000 -- 71% complete.
Reading data from 0x328800 -- 72% complete.
Reading data from 0x330800 -- 73% complete.
Reading data from 0x338000 -- 74% complete.
Reading data from 0x33f800 -- 75% complete.
Reading data from 0x347800 -- 76% complete.
Reading data from 0x34f000 -- 77% complete.
Reading data from 0x357000 -- 78% complete.
Reading data from 0x35e800 -- 79% complete.
Reading data from 0x366000 -- 80% complete.
Reading data from 0x36e000 -- 81% complete.
Reading data from 0x375800 -- 82% complete.
Reading data from 0x37d000 -- 83% complete.
Reading data from 0x385000 -- 84% complete.
Reading data from 0x38c800 -- 85% complete.
Reading data from 0x394000 -- 86% complete.
Reading data from 0x39c000 -- 87% complete.
Reading data from 0x3a3800 -- 88% complete.
Reading data from 0x3ab800 -- 89% complete.
Reading data from 0x3b3000 -- 90% complete.
Reading data from 0x3ba800 -- 91% complete.
Reading data from 0x3c2800 -- 92% complete.
Reading data from 0x3ca000 -- 93% complete.
Reading data from 0x3d1800 -- 94% complete.
Reading data from 0x3d9800 -- 95% complete.
Reading data from 0x3e1000 -- 96% complete.
Reading data from 0x3e8800 -- 97% complete.
Reading data from 0x3f0800 -- 98% complete.
Reading data from 0x3f8000 -- 99% complete.
Reading data from 0x3ff800 -- 100% complete.
3145728 bytes read: OK
F## Booting image at 00800000 ...
Image Name: Linux-2.6.22.18
Created: 2009-08-31 23:31:05 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1976384 Bytes = 1.9 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... Bad Data CRC
CE>> ')

And here I am now posting and asking the community for help. Of course I searched the forum for the best method to recover the DockStar using previously saved backup files as highly recommended in the old Plug Apps forum. But as it seems, some of those really helpful threads/instructions didn't make it to the new ArchLinux forum/homepage. I'm not sure if my old MTD backup files are of any use in that particular case without knowing if they have been created "the good way" and how to restore them correctly. I've also thought about reflashing the original redstone kernel, using a (T)FTP server in my home network, but it would be better to know first what's the best approach to safely erase and re-write Dockstar's NAND partitions MTD 1 / MTD 2, one after another, especially the correct method and procedure which can be triggered from a Windows PC.

There have also been some users complaining that a complete PogoPlug re-flash cannot be done anymore after applying Jeff's uBoot, only after the original bootloader has been restored to MTD 0. After all I'm a little bit confused what's best to do first. However, I don't wanna make any mistakes ending up with an unusable DockStar device. As long as the bootloadser still works and the NAND storage hasn't been physically destroyed, there should still be a chance to recover the device, at least I hope so!

As I'm no real Linux expert (as mentioned I'm more used to Windows enviroments and tools), could anybody please provide me some step by step instructions on how to recover/restore from image or backup files to the proper NAND memory addresses, at least some ideas what to try first/next/last? My target is to re-install the Original PogoPlug firmware from scratch, installing and reconfiguring the final setup from there. Rescue systems running from NAND without the need of USB stick installations are a littly bit too risky for me, so I'd prefer to revert back to the initial PogoPlug state of my DockStar. Anybody who can help me in order to achieve that goal? Would appreciate it!

Thanks a lot in advance!

Regards,
BillyBoy

[sambul13]

What a story... You may want to read this thread.

[BillyBoy]

Thanks sambul13 for the link. I already found this thread before, but there seem to be some inconsistencies, at least some missing steps that make me feel a little bit insecure, that's why I'm better asking twice:

1) The linked thread doesn't explain if the boot process has to be interrupted manually (e.g. by repeatedly pressing the Enter key) to get to the Marvell>> prompt. In my case, if no action is taken while booting up, I'm getting a CE>> prompt (also see my PogoPlug log) which I don't think it's the same environment as for the Marvell>> prompt, right? Which prompt is best to start the recovery from?

2) Of course the description was primarily made for Linux PC users. When copying the redstone kernel and the ramdisk files to a TFTP directory located on a windows server from where PuTTY is also running, do steps like "be sure to chmod 777" have any similar counterpart out of a Windows environment? If yes, what has to be done by Windows users e.g. when running SolarWinds TFTP server?

3) I'm currently using Jeff's uBoot. Pheenix (Sebastian) and some other guys already confirmed that it might be necessary to boot from the original uBoot via RAM first and then to install it permanently to MTD 0 before any PogoPlug recovery procedure. If yes, what are the steps in order to safely achieve this?

4) Still I don't know what the initial MTD 0/1/2 backups (recommendation from the old Plug Apps forum) were good for and what's/when's the right approach/time to write them back to NAND. However, if I'm re-flashing the redstone image instead as recommended here, does this replace the method using any MTD backup files? If yes, which partitions will be involved when flashing the redstone image: only MTD 1, MTD 1 & 2, or all partitions including the original bootloader on MTD 0?

Sorry for bothering, but I just want to get sure I'm not bricking my device. Just in case.

Thx,
BillyBoy

[sambul13]

And it continues...

1. You'll get Marvell prompt after your Uboot says "Hit any key to stop autoboot: 3 2 1 0". But Uboot may remain responsive to your commands at CE prompt. Basically, it just says "bad image in NAND".
2. cmod777 gives write permissions to everyone. Try doing the same in Win Explorer - File Properties, or start a Linux VM in Windows (from PartedMagic ISO) and connect to the DockStar.
3. Not sure what he means under "normal Uboot". If its "original Pogo Uboot", you might need JTAG and Serial cables to reflash Uboot without booting to Linux. Try to follow the above Reflashing thread and see what happens. See also DockStar JTAG.
4. Your DockStar is already bricked. And you ask questions without linking the source... The Reflashing thread answers your "blocks" question.

[WarheadsSE]

There is somewhere, I am not sure where, a kernel & initrd that is loadable via tftp that will load, connect, download, and re-flash the stock. They, 'CE', use it for installation

The dockstar might be a slightly different case however.

[sambul13]

Here's what I got awhile ago from Pogo Support, talking of Pogo V2 but probably valid for DockStar:

"If you can still SSH into your Pogoplug (OS), enter this text: "/usr/local/cloudengines/bin/./blparam 'bootcmd=run bootcmd_original" to restore the original boot loader.

Otherwise, you can build a serial cable and overwrite the firmware and kernel. Links to the most current production images are hosted here: http://download.pogoplug.com/opensource/".

[WarheadsSE]

There are no images there, only sources.

[sambul13]

BillyBoy

Grub DockStar's original Uboot and bzboi's Uboot reflash instructions from here. Then follow the above Reflashing Guide.

It would be nice to restore access to bzboi's Guides in his signature.

[WarheadsSE]

That wiki is dead, and will remain so sambul13.

[BillyBoy]

Thanks a lot guys for your useful inputs. Forthcoming weekend I will try my best to get it working again.