Restore MTD backup via serial

Hi all, I originally posted this in the uboot section, but after thinking about it, i'll likely get a better response here as it's not a uboot problem.

I use my goflex net with the standard pogo os, although something cocked up on it last week and it's fairly fluffed up. I took backups of my mtdblocks using nanddump as soon as I received it. I no longer have SSH access to my GFN (part of the problem I'm having), but I have serial access.

How do I go about restoring my mtd blocks over a serial cable? I'm guessing if I boot into pogo OS and do it from there, I'm asking for trouble as I'm effectively erasing my current boot device, so would I have to do it through the uboot prompt?

I've currently reloaded a very early pogoplug image on the GFN via tftp, mainly for shits and giggles. It actually boots up into pogo OS, but I want to restore my own MTD backups now. If I know how to restore them, and I find out that the process works properly, I'll likely be whacking debian on it in the next month or so to play around with, knowing its reversible.

My guess is that you should be able to tftpload them, and then flash it into NAND. It should be pretty much the same as a NAND restore.

You'd of course want to be careful w/ the offsets (locations) and lengths & such. Are you restoring _all_ of your NAND? Or just the Pogo OS? Or just U-Boot?

=====================================================

• davy's Github Repo's rescue-dg

ahh... well, maybe here: http://archlinuxarm.org/forum/viewtopic.php?f=18&t=789

These should give you the gist of things... I'd start by thinking about something like this...but do some reading & research - ie. check them for sanity... I've flash uboot and images to NAND many times, but never did a restore, AFAICR.

tftp <RAM location> filename
nand erase <begin> <end>
nand write.e <RAM location> <begin> <end>


The _last_ thing you should do is to flash back to the original U-Boot. (that is personal preference on my part - I prefer the newer uboot- I guess I"m more familiar w/ it).

BTW, if something happens that it goes wrong, the GFN's are very difficult to brick. You can recover from a bad U-Boot flash using UART-booting and a UART-uboot.kwb file.

=====================================================

• davy's Github Repo's rescue-dg

It's always been running the stock uboot, so that's not a problem. I managed to get the flash restored from within Pogo OS (not sure if that was a wise move but hey, can't hurt it too much!), and it partially works.

I still can't enable SSH from my.pogoplug (although SSH is now enabled as it was in the backups), and whether the drives show up in my.pogoplug is seemingly hit and miss. At least I've got a good reason to delve into debian now!

Will have a play with reflashing in uboot before I do that though. Nice to know it's fairly rugged should things go wrong, and I'm still new to embedded devices - so lots of learning to be had in the process.

Managed to wipe out uboot from the flash by accident, so going to need to start looking into the UART booting.

Take a look at Neutron Scott's modified picocom that is ideal for this purpose. He explains briefly how to run it here: http://wiki.scottn.us/goflex:start#serial_recovery
and he also has a precompiled binary for it... and yes, even a UART.kwb for it as well. Timing is a tricky thing on them... you have to get it just right. When I started out, I initially got it to UART-boot only 1/4 or 1/3 of the time. Now it is more like 3/4 or more.

Good luck with reanimating your GoFlex ... it is pretty hard to brick them, unless you mess up U-Boot AND fry the (hardware) serial port.

=====================================================

• davy's Github Repo's rescue-dg

Once I get UART working, I have a completely unused (as in sealed box still) 2nd GFN. Do you know of a way where this flash could be dumped at the uboot prompt, then flashed to the kaput'd GFN? I suppose once the MAC address, and Pogo ID etc are all changed (if required), it would be just like a new GFN out the box - could possibly upload these dumps should other people need them in future.

Although first things first is to get UART sorted, which is taking a back seat while real life gets in the way for a month.

Do I need to get a full install of Linux setup,, or will my OS X install suffice?



Edited 1 time(s). Last edit at 05/02/2012 11:20AM by Biohead.

There is a nanddump (IIRC) binary somewhere in Jeff's downloads... dunno exactly where... but I'm pretty sure it is here somewhere (semi-quasi-documented)...

Sounds like great idea to me. I know that some router forums keep commonly used (or lost!) NAND dumps here and there for recovery purposes...

=====================================================

• davy's Github Repo's rescue-dg

I have original mtd partitions dumps for GoFlex Home and Pogoplug V4. In case somebody needs them.

If someone tells me how to backup the entire flash through the uboot prompt I'll gladly open the box.

I figure it would have to be done through uboot so that the flash remains completely fresh (I think it does a few changes on first boot).


Anyway, as for fixing my dead one, I got a quick uart boot running - but either it could not find or not initialise the flash - too many bad blocks or along those lines. It was a really quick attempt though and I've seen the bad block error mentioned on here before.

Had another quick try tonight, and got the same error with the flash - it's as though it's not seeing it at all.
Is this because the uboot.uart won't function on the GFN? Or am I not uploading something else before hand?

This bit isn't in the log I've provided: When I try to upload my mtd0 backup (which is 1024kb in size, not 512kb like the uboot.uart) via picocom, it just sits at 0k/0k and same for the uboot.orig file I found, so I used the provided uboot.uart.


Also after that, I copied over my mtd0 through uboot and tried to boot from that in memory (I guess much like a chainload, which failed - bad magic number?).

Then I uploaded a pogo provided restore image which ran as far as shown. Gathering that stopped at that point due to no OS found in flash.

Once again, I'm still very much new to embedded stuff, particularly going at this low a level, so there's likely some obvious errors I'm blissfully unaware of.

Here's my full process, from opening picocom to when the pogo img stopped loading:

root@bt:~/picocom-debug# ./picocom -b 115200 /dev/ttyUSB0
picocom v1.6

port is        : /dev/ttyUSB0
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv
imap is        : 
omap is        : 
emap is        : crcrlf,delbs,

Terminal ready

*** file to upload: '/root/picocom-debug/uboot.uart' 
Sending DEBUG for about 5 seconds. Power on device NOW!
Waiting NAK... Press 'x' to escape.
sx -vv -b '/root/picocom-debug/uboot.uart'  
Sending /root/picocom-debug/uboot.uart, 4096 blocks: Give your local XMODEM receive command now.
Bytes Sent: 524416   BPS:6346                            

Transfer complete

*** exit status: 0
done.


U-Boot 1.1.4  Cloud Engines 1.1.2 (3.4.22) SATA PHYADDR=0

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 00691750

Soc: 88F6281 A1 (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 256MB 
DRAM CS[1] base 0x10000000   size 256MB 
DRAM Total size 512MB  16bit width
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
NAND:Bad block table not found for chip 0
Bad block table not found for chip 0
No space left to write bad block table
128 MB
*** Warning - bad CRC or NAND, using default environment

Flash:  0 kB

CPU : Marvell Feroceon (Rev 1)
CLOUD ENGINES BOARD (GUESSED): DISCOVERY:0.1

Streaming disabled 
Write allocate disabled


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

no devices available
## Booting image at 00800000 ...
Bad Magic Number
CE>> setenv ipaddr 192.168.1.104
CE>> setenv serverip 192.168.1.100
CE>> tftp 0x800000 mtd0
Using egiga0 device
TFTP from server 192.168.1.100; our IP address is 192.168.1.104
Filename 'mtd0'.
Load address: 0x800000
Loading: #################################################################
	 #################################################################
	 #################################################################
	 #################
done
Bytes transferred = 1081344 (108000 hex)
CE>> bootm 0x800000
## Booting image at 00800000 ...
Bad Magic Number
CE>> bootm 0x108000
## Booting image at 00108000 ...
Bad Magic Number
CE>> tftp 0x800000 ce_kernel_redstone_v63.img
Using egiga0 device
TFTP from server 192.168.1.100; our IP address is 192.168.1.104
Filename 'ce_kernel_redstone_v63.img'.
Load address: 0x800000
Loading: #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 ##############################################################
done
Bytes transferred = 1978608 (1e30f0 hex)
CE>> bootm 0x800000
## Booting image at 00800000 ...
   Image Name:   Linux-2.6.22.18
   Created:      2009-10-14  20:23:19 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1978544 Bytes =  1.9 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux............................................................................................................................ done, booting the kernel.

Edited 3 time(s). Last edit at 05/03/2012 04:32PM by Biohead.

Biohead Wrote:
-------------------------------------------------------
> Had another quick try tonight, and got the same
> error with the flash - it's as though it's not
> seeing it at all.
> Is this because the uboot.uart won't function on
> the GFN? Or am I not uploading something else
> before hand?

It is booting the uart.kwb just fine... the uart.kwb has the same functionality as the nand.kwb (a normal uboot for flash), except that it can be booted via uart.

> This bit isn't in the log I've provided:
> When I try to upload my mtd0 backup (which is
> 1024kb in size, not 512kb like the uboot.uart) via
> picocom, it just sits at 0k/0k and same for the
> uboot.orig file I found, so I used the provided
> uboot.uart.
>
>
> Also after that, I copied over my mtd0 through
> uboot and tried to boot from that in memory (I
> guess much like a chainload, which failed - bad
> magic number?).

???? Questions below...


> Then I uploaded a pogo provided restore image
> which ran as far as shown. Gathering that stopped
> at that point due to no OS found in flash.
>
> Once again, I'm still very much new to embedded
> stuff, particularly going at this low a level, so
> there's likely some obvious errors I'm blissfully
> unaware of.
>
> Here's my full process, from opening picocom to
> when the pogo img stopped loading:
>

> root@bt:~/picocom-debug# ./picocom -b 115200
> /dev/ttyUSB0
> picocom v1.6
> 
> port is        : /dev/ttyUSB0
> flowcontrol    : none
> baudrate is    : 115200
> parity is      : none
> databits are   : 8
> escape is      : C-a
> local echo is  : no
> noinit is      : no
> noreset is     : no
> nolock is      : no
> send_cmd is    : sz -vv
> receive_cmd is : rz -vv
> imap is        : 
> omap is        : 
> emap is        : crcrlf,delbs,
> 
> Terminal ready
> 
> *** file to upload:
> '/root/picocom-debug/uboot.uart' 
> Sending DEBUG for about 5 seconds. Power on device
> NOW!
> Waiting NAK... Press 'x' to escape.
> sx -vv -b '/root/picocom-debug/uboot.uart'  
> Sending /root/picocom-debug/uboot.uart, 4096
> blocks: Give your local XMODEM receive command
> now.
> Bytes Sent: 524416   BPS:6346                     
>       
> 
> Transfer complete
> 
> *** exit status: 0
> done.
> 
> 
> U-Boot 1.1.4  Cloud Engines 1.1.2 (3.4.22) SATA
> PHYADDR=0
> 
> U-Boot code: 00600000 -> 0067FFF0  BSS: ->
> 00691750
> 
> Soc: 88F6281 A1 (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 256MB 
> DRAM CS[1] base 0x10000000   size 256MB 
> DRAM Total size 512MB  16bit width
> Addresses 8M - 0M are saved for the U-Boot usage.
> Mem malloc Initialization (8M - 7M): Done
> NAND:Bad block table not found for chip 0
> Bad block table not found for chip 0
> No space left to write bad block table
> 128 MB
> *** Warning - bad CRC or NAND, using default
> environment
> 
> Flash:  0 kB
> 
> CPU : Marvell Feroceon (Rev 1)
> CLOUD ENGINES BOARD (GUESSED): DISCOVERY:0.1
> 
> Streaming disabled 
> Write allocate disabled
> 
> 
> USB 0: host mode
> PEX 0: interface detected no Link.
> Net:   egiga0 [PRIME]
> Hit any key to stop autoboot:  0 
> 
> no devices available
> ## Booting image at 00800000 ...
> Bad Magic Number
> CE>> setenv ipaddr 192.168.1.104
> CE>> setenv serverip 192.168.1.100
> CE>> tftp 0x800000 mtd0
> Using egiga0 device
> TFTP from server 192.168.1.100; our IP address is
> 192.168.1.104
> Filename 'mtd0'.
> Load address: 0x800000
> Loading:

To me, mtd0 looks like it is an apt name for uboot partition contents.  Is that what mtd0 actually is in your case?



> ##################################################
> ###############
> 	
> ##################################################
> ###############
> 	
> ##################################################
> ###############
> 	 #################
> done
> Bytes transferred = 1081344 (108000 hex)
> CE>> bootm 0x800000
> ## Booting image at 00800000 ...
> Bad Magic Number
> CE>> bootm 0x108000
> ## Booting image at 00108000 ...
> Bad Magic Number

Not sure I understand here: you are tftploading mtd0 to offset x800000, but then you try to bootm w/ the contents at  00108000... 

don't you mean 
bootm  00800100  
??

Also, are you trying to boot a kernel & initrd?  


> CE>> tftp 0x800000 ce_kernel_redstone_v63.img
> Using egiga0 device
> TFTP from server 192.168.1.100; our IP address is
> 192.168.1.104
> Filename 'ce_kernel_redstone_v63.img'.
> Load address: 0x800000
> Loading:
> ##################################################
> ###############
> 	
> ##################################################
> ###############
> 	
> ##################################################
> ###############
> 	
> ##################################################
> ###############
> 	
> ##################################################
> ###############
> 	
> ##################################################
> ############
> done
> Bytes transferred = 1978608 (1e30f0 hex)
> CE>> bootm 0x800000
> ## Booting image at 00800000 ...
>    Image Name:   Linux-2.6.22.18
>    Created:      2009-10-14  20:23:19 UTC
>    Image Type:   ARM Linux Kernel Image
> (uncompressed)
>    Data Size:    1978544 Bytes =  1.9 MB
>    Load Address: 00008000
>    Entry Point:  00008000
>    Verifying Checksum ... OK
> OK
> 
> Starting kernel ...
> 
> Uncompressing
> Linux.............................................
> ..................................................
> ............................. done, booting the
> kernel.
> 
> 
>

This part here ^^^ looks like it may be been successful, but I can't tell what's going on after that.

=====================================================

• davy's Github Repo's rescue-dg

mtd0 is the contents of uboot partition, correct. I was just trying to get it to load from memory when doing the booth commands, although it didn't do any of them.

When trying to load the ce_kernel, it was purely a kernel, no initrd - just to see if it would at least start the booting process, which it did.

Am I right in thinking that the problem lies with this uboot not detecting the flash chip?

> U-Boot 1.1.4  Cloud Engines 1.1.2 (3.4.22) SATA
> PHYADDR=0
> 
> U-Boot code: 00600000 -> 0067FFF0  BSS: ->
> 00691750
> 
> Soc: 88F6281 A1 (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 256MB 
> DRAM CS[1] base 0x10000000   size 256MB 
> DRAM Total size 512MB  16bit width
> Addresses 8M - 0M are saved for the U-Boot usage.
> Mem malloc Initialization (8M - 7M): Done
> NAND:Bad block table not found for chip 0
> Bad block table not found for chip 0
> No space left to write bad block table
> 128 MB
> *** Warning - bad CRC or NAND, using default
> environment
> 
> Flash:  0 kB
> 
> CPU : Marvell Feroceon (Rev 1)
> CLOUD ENGINES BOARD (GUESSED): DISCOVERY:0.1

Yes, that does look like a flag (definitely!), but I'm not sure it is an "obituary" for the NAND. It is possible that if you get it booted into something, you may be able to flash (using nandwrite) from Linux. It's just a thought.

Which UART.kwb is this? Is it Neutron Scott's? I've never tried it (I made my own UART.kwb, from the newer U-Boot that I rolled for GNF), so I don't know that it properly recognizes the NAND chip. It could be that the NAND chip in that GFN of yours, is simply different (like CloudEngines changed between Toshiba and Hynix for NAND chips), and for some unknown reason doesn't properly detect it.

Would you be interested in a different (and tested) UART.gfn.kwb? (it only takes 60 seconds to roll it - another few minutes to test it).

Also, I've got a universal image that will boot on any supported mainline kirkwood device + GoFlex Net/Home + ZyXEL NSA320... You could always try to boot it - the kernel inside contains the correct settings for (known) NAND chips on the GFN (though it is always possible that there are some 'unknown' chip types floating around out there - this was the case for some of the Buffalo LinkStations out there 5 or 6 years ago...). That image is in this thread: http://forum.doozan.com/read.php?2,7806 You'd want to prepare the image on a USB drive and try to boot that. [you wouldn't want to use the uboot from the NSA320 package - it is _too_ different].

I'll work on making a uart.gfn.kwb and testing it to make sure that I _know_ that it sees the flash on my GFN correctly. (one less unknown for you would be good).

==============================================
part 2

Maybe this will help you out, at least to help determine the nature/severity of the problem... If not, perhaps someone else w/ your same difficult may be able to benefit from it.

Here is a u-boot.UART.gfn.kwb "rescue u-boot" file that I built and tested on my GFN. It boots over UART, just like Neutron Scotts, but it is based on the newer source, and thus supports booting from USB, or SATA (either slot). Only catch is that it is just for UART-boot rescue - like when NAND seems corrupt or has a bad image in it. It should automatically enable netconsole and use serverip 192.168.11.149, ipaddr 192.168.11.150, and it has a predefined (dummy but functional) ethaddr. If an ethernet cable isn't attached then it should just fail ping and fall back to serial.

As you can see, it will boot a USB image.

Here is the proof/trial output (with some of the lines omitted for brevity/sanity - some of the lines that I left in the output are there to validate it, others for hints/ideas for which commands in uboot might be useful):

davygravy@bitbaker64:~/Desktop/picocom-debug$ ./picocom -b 115200 /dev/ttyUSB0
picocom v1.6

port is        : /dev/ttyUSB0
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv
imap is        : 
omap is        : 
emap is        : crcrlf,delbs,

Removing stale lock: /var/lock/LCK..ttyUSB0
Terminal ready



U-Boot 2011.12 (Apr 18 2012 - 23:08:20)
Seagate GoFlexNet

SoC:   Kirkwood 88F6281_A1
DRAM:  128 MiB
WARNING: Caches not enabled
NAND:  256 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0
88E1116 Initialized on egiga0
Using egiga0 device
ping failed; host 192.168.11.149 is not alive
Hit any key to stop autoboot:  0 
GoFlexNet> 
GoFlexNet> 
*** file to upload: uboot.UARTgoflexnet-IDEpatched-netconsoleON.kwb
Sending DEBUG for about 5 seconds. Power on device NOW!
Waiting NAK... Press 'x' to escape.
sx -vv -b uboot.UARTgoflexnet-IDEpatched-netconsoleON.kwb 
Sending uboot.UARTgoflexnet-IDEpatched-netconsoleON.kwb, 4096 blocks: Give your local XMODEM receive command now.
Bytes Sent: 524288   BPS:6341                            

Transfer complete

*** exit status: 0
done.

WARNING: Caches not enabled
NAND:  256 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0
88E1116 Initialized on egiga0
Using egiga0 device
ping failed; host 192.168.11.149 is not alive
Hit any key to stop autoboot:  0 
GoFlexNet> 
GoFlexNet> help
?       - alias for 'help'

bdinfo  - print Board Info structure

mtdparts- define flash/nand partitions

nand    - NAND sub-system

usb     - USB sub-system

version - print monitor, compiler and linker version
GoFlexNet> version

U-Boot 2011.12 (May 03 2012 - 20:14:15)
Seagate GoFlexNet
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2009q3-67) 4.4.1
GNU ld (Sourcery G++ Lite 2009q3-67) 2.19.51.20090709
GoFlexNet> 
arcNumber=3089
baudrate=115200
...
usb_boot=mw 0x800000 0 1; ext2load usb $usb_device 0x800000 /boot/uImage; if ext2load usb $usb_device 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi
usb_bootcmd=run usb_init; run usb_set_bootargs; run usb_boot
usb_device=0:1
usb_init=run usb_scan; setenv usb_root LABEL=rootfs
usb_root=/dev/sda1
usb_rootdelay=10


Environment size: 3789/131068 bytes
GoFlexNet> usb start
(Re)start USB...
USB:   Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 2 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found
GoFlexNet> run usb_bootcmd
Loading file "/boot/uImage" from usb device 0:1 (usbda1)
1 bytes read
Found bootable drive on usb 0:1
Loading file "/boot/uImage" from usb device 0:1 (usbda1)
2279256 bytes read
Loading file "/boot/uInitrd" from usb device 0:1 (usbda1)
7575688 bytes read
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-3.3.2
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2279192 Bytes = 2.2 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 01100000 ...
   Image Name:   initramfs-3.3.2-kirkwood-dg
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    7575624 Bytes = 7.2 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.3.2-kirkwood-dg (davygravy@bitbaker64) (gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-70) ) #1 Mon Apr 23 17:09:27 CDT 2012
[    0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
[    0.000000] CPU: VIVT data cache, VIVT instruction cache
[    0.000000] Machine: Seagate GoFlex Net
[    0.000000] Memory policy: ECC disabled, Data cache writeback

[   10.265811] serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
[   10.730416] console [ttyS0] enabled
[   10.734875] NAND device: Manufacturer ID: 0x98, Chip ID: 0xda (Toshiba NAND 256MiB 3,3V 8-bit)
[   10.743549] Scanning device for bad blocks
[   10.961563] 4 cmdlinepart partitions found on MTD device orion_nand
[   10.967874] Creating 4 MTD partitions on "orion_nand":
[   10.973038] 0x000000000000-0x000000100000 : "u-boot"
[   10.978836] 0x000000100000-0x000000500000 : "uImage"
[   10.984592] 0x000000500000-0x000002500000 : "rootfs"
[   10.990397] 0x000002500000-0x000010000000 : "data"
[   10.996843] mousedev: PS/2 mouse device common for all mice
[   12.004997] rtc-mv rtc-mv: internal RTC not ticking
[   12.009977] i2c /dev entries driver
[   12.013600] cpuidle: using governor ladder


Debian GNU/Linux 6.0 nsa320-usb ttyS0

nsa320-usb login:

=====================================================

• davy's Github Repo's rescue-dg

Edited 3 time(s). Last edit at 05/03/2012 08:53PM by davygravy.

Hey Biohead, somethings weird there. To me it looks like the output suggests that your GFN has 512MB dram. Precisely, 2 banks of 256MB. That doesn't look right. Any chance your UART uboot is from the wrong machine ?

=====================================================

• davy's Github Repo's rescue-dg

Yes I used the uart uboot from Scott's site as I've even looked at compiling uboot yet. Thank you for providing one - it detects my NAND fine and also my RAM.

What I have tried doing now is erase each mtd block in the nand, so I know i'm on a clean slate.
Then I've copied my mtd0 backup into ram at address 0x800000, and written it into mtd0 using

nand write.e 0x800000 0x0 0x100000

I've then done the same for mtd1 and mtd2.

When I reset or reboot the GFN, it goes back to nothingness and requires the uart boot once more. I thought that restoring the complete backup of mtd0 into the mtd0 address space would get my uboot back - or am I mistaken?

Just currently downloading the working image and will test that out as my next step.

I'm not sure but it sounds like your mtd0 backup could be faulty.

As a test you could just install the Newer U-Boot that is posted for the GFN in the thread named Newer U-Boot....
Make
Sure you use the exact commands shown. Good luck.

=====================================================

• davy's Github Repo's rescue-dg

There's something not quite right with my mtd backups, heres the output from my attempt at restoring mtd1, but they all have the same error:

root@debian-kirkwood-wide:~# ./flash_erase /dev/mtd1 0 4
Erase Total 4 Units
Performing Flash Erase of length 131072 at offset 0x60000 done
root@debian-kirkwood-wide:~# ./nandwrite /dev/mtd1 mtd1
Image 4325376 bytes, NAND page 2048 bytes, OOB area 2048 bytes, device size 4194304 bytes
Input file does not fit into device: Success
Data was only partially written due to error
: Success
root@debian-kirkwood-wide:~#

But I have successfully written a new uBoot, and I'm now able to boot without the need of uart - so it makes things a little easier for me.

Wondering if it's some form of error correction which has been added to the files, hence it being slightly too large. Either way, happy it's now booting on it's own.



Edited 1 time(s). Last edit at 05/04/2012 03:39PM by Biohead.

Well, at least you know your box is (seemingly) not compromised/semi-broken.

Yes, it is possible that the NAND-dump process needed some sort of ECC consideration...

Do you have the output of the commands when you dumped the mtdN's? (I sometimes keep output of crucial steps as reference for further comparison...)

=====================================================

• davy's Github Repo's rescue-dg

I don't have any output saved, but I can't remember any errors being shown when I did it.

I believe the command I used was:

nanddump -nf mtd0 /dev/mtd0

Looking at the idea of creating backups from the unused gfn, but I'm unsure how I'd get the files off there without booting it past uboot? Can you also send through tftp?

I'm pretty sure Jeffs script would have the correct commands. (I don't always use it - prolly why I didnt consider this before. )

=====================================================

• davy's Github Repo's rescue-dg

Right I'm pretty resigned to the fact that the backups are duds. I didn't use Jeff's script to backup, but just issued commands manually. It seems that you have to specify an option specifically or you will get problems relating to error correction and what not which means they backups aren't really usable.

So I'm looking at trying to make a new set of backups from my unused device (which I'll gladly mirror for people). My only problem is I don't know how to extract the image file I create when at the uboot prompt. I don't want to load the OS, as on the pogoplug the first boot makes quite a few changes, and so won't be an untouched dump after that.

As a thought, would I be able to interrupt uboot, download Jeffs uboot into memory, and launch that uboot from memory? I could then boot from USB, make the backups and the flash chips remain untouched?



Edited 1 time(s). Last edit at 05/06/2012 01:24PM by Biohead.

I'm pretty sure that Jeff's (and Shyd's) scripts dump and to /tmp ...

Let me take a look. ... OK, you can do this from inside Linux on the unmodded GFN...

The stuff you need to look at/think about...
http://projects.doozan.com/uboot/install_uboot_mtd0.sh
its in here ^^^^

# dump the first 512k of mtd0 to /tmp
$NANDDUMP -no -l 0x80000 -f /tmp/uboot-mtd0-dump /dev/mtd0

You'll have to download nanddump from http://jeff.doozan.com/debian/uboot/nanddump

cd /tmp
wget http://jeff.doozan.com/debian/uboot/nanddump

If your fs is read-only, then you'd have to find a way around that...

make sure it is executable

chmod +x nanddump

so something like:

./nanddump -no -l 0x80000 -f /tmp/uboot-mtd0-dump /dev/mtd0

would dump the 512k of u-boot image

I'd look at the rest of the script and see what it says in terms of offsets and how many chunks you need to dump. Certainly the kernel, rootfs, and uboot.env would be good to dump, but I'd be hesitant about posting the env w/ your actual MAC(hardware etheraddr) for everyone to see. Maybe that chunk (and the CEID) could be obfuscated/randomized or something such.

=====================================================

• davy's Github Repo's rescue-dg

Edited 3 time(s). Last edit at 05/06/2012 01:58PM by davygravy.

The restore files provided for V2 pogo plugs (nothing is available for GFN) are in the form of a ramdisk image. Upon first boot, the ramdisk is opened, and then it starts writing to flash what is needed, you can't actually get into the OS until this has run, and been replaced with the OS. Assuming it's a similar setup on the unused GFN, I want to try and preserve this bit so the installation is carried out on the device itself. That's a big assumption though.

Which is why I'm trying to avoid booting the GFN fully until I have either captured that image, or confirmed that there isn't one. If I can get Jeffs modified uboot to boot from memory, I could load up that universal image you provided and dump the flash through that.

...Now just to find out where I actually put this spare one!

From what I can see it isn't clear to me how to do this from within U-Boot. FWIW, there is an OpenWRT howto here: http://wiki.openwrt.org/toh/seagate/dockstar#backup which matches pretty closely w/ what I was thinking in terms of doing it from w/i Linux. But be advised : that is a DockStar, which is similar to a GFN in some respects... maybe different in some crucial way.

Also, just so you know, you can activate and then _deactivate_ your pogoplug device - if you are registering it so you can boot into it and go in via ssh, remember you can go back via Pogoplug (either a webpage or via Support) and de-register it (handy if you are selling it later). IIRC, the GFN is a pogo device, right? (or is it via Seagate only?).

=====================================================

• davy's Github Repo's rescue-dg

Bio: I don't know why I didn't think of this before: Try downloading this: see if it works for you: (EDIT: TESTED and WORKS)

http://ppl.ug/uwKjFfOXzk8/

I don't have the original GFN uboot, but I found one at NeutronScott's... I've tested it and it worked... I was able to restore the original U-Boot to my GFN.

I took mtd1 (kernel uImage) & mtd2 (rootfs) from my GFN:

root@GoFlexHome:/# ./nanddump -no -l 0x400000 -f uImage-mtd1-dump /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00400000...
root@GoFlexHome:/# ./nanddump -no -l 0x2000000 -f rootfs-mtd2-dump /dev/mtd2
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x02000000...

Out of curiosity, I may try to restore mine to factory just for GrinsNGiggles.


I have env stuff for you too - it is possible that it is still in tact on your machine...
though you'd need the CE id and the MAC specific to your box. I'm pretty sure that you don't need it... toward the end I'll tell and show you why.

===============================

Result of restoring U-Boot: (note that the env was still intact, so I didn't have to restore that... just the U-Boot : Also note that I had to set ipaddr and serverip to my local values for it to work. ethaddr is required as well, but since it was still defined in env, I didn't have to restore it):

davygravy@bitbaker64:~/Desktop$ ./kwboot -t -B 115200 /dev/ttyUSB0 -p -b mtddumps-goflexnet/uboot-mtd0-orig-goflexhome.kwb 
Sending boot message. Please reboot the target...\
Sending boot image...
  0 % [......................................................................]
  1 % [......................................................................]
  3 % [......................................................................]
...
 97 % [......................................................................]
 99 % [....................................]
[Type Ctrl-\ + c to quit]


	 -- NAS EXPLORER --
 _   _     ____              _
| | | |   | __ )  ___   ___ | |_ 
| | | |___|  _ \ / _ \ / _ \| __| 
| |_| |___| |_) | (_) | (_) | |_ 
 \___/    |____/ \___/ \___/ \__| 
 ** QSI BOARD: NAS-PLUG LE 

U-Boot 1.1.4 (Jun 10 2010 - 08:28:13) Marvell version: 3.4.27
QSI NAS version: 1.0.4

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CFB00

Soc: 88F6281 A1 (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
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
NAND:256 MB
Flash:  0 kB

CPU : Marvell Feroceon (Rev 1)

Streaming disabled 
Write allocate disabled


USB 0: host mode
PEX 0: interface detected no Link.
Net:   egiga0 [PRIME]
Hit any key to stop autoboot:  0 
NAS>> 
NAS>> print
baudrate=115200
loads_echo=0
ipaddr=169.254.254.253
serverip=169.254.254.254
rootpath=/mnt/ARM_FS/
netmask=255.255.0.0
run_diag=yes
console=console=ttyS0,115200
CASset=min
MALLOC_len=1
ethprime=egiga0
bootargs_root=root=/dev/mtdblock2 ro
ethmtu=1500
usb0Mode=host
nandEcc=1bit
ethact=egiga0
ethaddr=00:10:75:xx:xx:xx
cesvcid=xxxxxxxxxxxxxxxxxxxxxxxxxxx
ceserialno=xxxxxxxxxx
ceboardver=DISCOVERY:0.1
bootcmd=nand read.e 0x800000 0x100000 0x300000; setenv bootargs $(console) $(bootargs_root); bootm 0x800000
stdin=serial
stdout=serial
stderr=serial
nandEnvBase=x=no
mainlineLinux=no
enaMonExt=no
enaCpuStream=no
enaWrAllo=no
pexMode=RC
disL2Cache=no
setL2CacheWT=yes
disL2Prefetch=yes
enaICPref=yes
enaDCPref=yes
sata_dma_mode=yes
netbsd_en=no
vxworks_en=no
bootargs_end=:::DB88FXX81:eth0:none
image_name=uImage
standalone=fsload 0x2000000 $(image_name);setenv bootargs $(console) root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvPhoneConfig); bootm 0x2000000;
bootdelay=3
disaMvPnp=no
netretry=no
rcvrip=169.254.100.100
loadaddr=0x02000000
autoload=no
enaAutoRecovery=yes
pcieTune=no



NAS>> set ipaddr 192.168.11.150
NAS>> set serverip 192.168.11.149
NAS>>  tftpboot 0x800000 uboot-mtd0-orig-goflexhome.kwb
Using egiga0 device
TFTP from server 192.168.11.149; our IP address is 192.168.11.150
Filename 'uboot-mtd0-orig-goflexhome.kwb'.
Load address: 0x800000
Loading: #################################################################
	 ######################################
done
Bytes transferred = 524288 (80000 hex)
NAS>> nand erase 0x0 0x80000

NAND erase: device 0 offset 0x0, size 0x80000
Erasing at 0x60000 -- 100% complete.
OK
NAS>> nand write.e 0x800000 0x0 0x80000

NAND write: device 0 offset 0x0, size 0x80000

Writing data at 0x7f800 -- 100% complete.
 524288 bytes written: OK
NAS>> reset


	 -- NAS EXPLORER --
 _   _     ____              _
| | | |   | __ )  ___   ___ | |_ 
| | | |___|  _ \ / _ \ / _ \| __| 
| |_| |___| |_) | (_) | (_) | |_ 
 \___/    |____/ \___/ \___/ \__| 
 ** QSI BOARD: NAS-PLUG LE 

U-Boot 1.1.4 (Jun 10 2010 - 08:28:13) Marvell version: 3.4.27
QSI NAS version: 1.0.4

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CFB00

Soc: 88F6281 A1 (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
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
NAND:256 MB
Flash:  0 kB

CPU : Marvell Feroceon (Rev 1)

Streaming disabled 
Write allocate disabled


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

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

Reading data from 0x3ff800 -- 100% complete.
 3145728 bytes read: OK
## Booting image at 00800000 ...
   Image Name:   Linux-2.6.22.18
   Created:      2010-10-19  23:05:02 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1979140 Bytes =  1.9 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux............................................................................................................................ done, booting the kernel.
[    0.000000] Linux version 2.6.22.18 (bdietrich@buildman) (gcc version 4.2.1) #81 Tue Oct 19 16:05:00 PDT 2010
[    0.000000] CPU: ARM926EJ-S [56251311] revision 1 (ARMv5TE), cr=00053977
[    0.000000] Machine: Feroceon-KW
[    0.000000] Using UBoot passing parameters structure
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] CPU0: D VIVT write-back cache
...
Loading xce.ko:              [   17.110000] Cloud Engines XCE Init [Version: 2.0.5.10]
[   17.120000] XCE: CPU MEMORY MAP:
[   17.120000] XCE:   -- 0x00001000 - 0xbeffffff (3055 MB)  User Space Mappings
[   17.130000] XCE:   -- 0xbf000000 - 0xbfffffff (  16 MB)  Kernel module space
...
[   17.280000] XCE:  GPIO H POL:    0x00000000
[   17.280000] XCE:  GPIO H IN:     0x0000c00d
[   17.290000] XCE: Kernel thread starting PID: 400
Success
Starting hbplug:             Success
starting pid 402, tty '': '/bin/sh'
-sh-3.2# [   18.390000] XCE: BLPARAMS: reading 2048 bytes @ a0000
[   18.390000] XCE: BLPARAMS: reading 2048 bytes @ a0800
[   18.400000] XCE: BLPARAMS: reading 2048 bytes @ a1000
[   18.410000] XCE: BLPARAMS: reading 2048 bytes @ a1800
[   23.860000] XCE: XCE: LED -> CONNECTED

-sh-3.2#

======================================
Flashing in uImage and rootfs from backups:

NAS>> set serverip 192.168.11.149
NAS>> set ipaddr 192.168.11.150
NAS>> tftpboot 0x800000 uImage-mtd1-dump
Unknown command 'tftpboot' - try 'help'
NAS>> tftpboot 0x800000 uImage-mtd1-dump
Using egiga0 device
TFTP from server 192.168.11.149; our IP address is 192.168.11.150
Filename 'uImage-mtd1-dump'.
Load address: 0x800000
Loading: #################################################################
	 #################################################################
	 #################################################################
...
	 #################################################################
	 ########################################
done
Bytes transferred = 4194304 (400000 hex)
NAS>> nand erase 0x100000 0x400000

NAND erase: device 0 offset 0x100000, size 0x400000
Erasing at 0x4e0000 -- 100% complete.
OK
NAS>> nand write.e 0x800000 0x100000 0x400000

NAND write: device 0 offset 0x100000, size 0x400000

Writing data at 0x4ff800 -- 100% complete.
 4194304 bytes written: OK
NAS>> NAS>>  tftpboot 0x800000 rootfs-mtd2-dump
Unknown command 'NAS>>' - try 'help'
NAS>>  tftpboot 0x800000 rootfs-mtd2-dump
Using egiga0 device
TFTP from server 192.168.11.149; our IP address is 192.168.11.150
Filename 'rootfs-mtd2-dump'.
Load address: 0x800000
Loading: #################################################################
	 #################################################################
	 #################################################################
...
	 #################################################################
	 ######################################################
	 32 MB reveived
	 #
done
Bytes transferred = 33554432 (2000000 hex)
NAS>> nand erase 0x500000 0x02000000

NAND erase: device 0 offset 0x500000, size 0x2000000
Erasing at 0x24e0000 -- 100% complete.
OK
NAS>> nand write.e 0x800000 0x500000 0x02000000

NAND write: device 0 offset 0x500000, size 0x2000000

Writing data at 0x24ff800 -- 100% complete.
 33554432 bytes written: OK
NAS>> reset


	 -- NAS EXPLORER --
 _   _     ____              _
| | | |   | __ )  ___   ___ | |_ 
| | | |___|  _ \ / _ \ / _ \| __| 
| |_| |___| |_) | (_) | (_) | |_ 
 \___/    |____/ \___/ \___/ \__| 
 ** QSI BOARD: NAS-PLUG LE 

U-Boot 1.1.4 (Jun 10 2010 - 08:28:13) Marvell version: 3.4.27
QSI NAS version: 1.0.4

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CFB00

Soc: 88F6281 A1 (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
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
NAND:256 MB
Flash:  0 kB

CPU : Marvell Feroceon (Rev 1)

Streaming disabled 
Write allocate disabled


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

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

Reading data from 0x3ff800 -- 100% complete.
 3145728 bytes read: OK
## Booting image at 00800000 ...
   Image Name:   Linux-2.6.22.18
   Created:      2010-10-19  23:05:02 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1979140 Bytes =  1.9 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux............................................................................................................................ done, booting the kernel.
[    0.000000] Linux version 2.6.22.18 (bdietrich@buildman) (gcc version 4.2.1) #81 Tue Oct 19 16:05:00 PDT 2010
[    0.000000] CPU: ARM926EJ-S [56251311] revision 1 (ARMv5TE), cr=00053977
[    0.000000] Machine: Feroceon-KW
[    0.000000] Using UBoot passing parameters structure
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] CPU0: D VIVT write-back cache
[    0.000000] CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
[    0.000000] CPU0: D cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets

It actually worked!

Working on how to restore the env values. And I see now that it is stored at another offset (_not_ c0000 in mtd0, but at a0000, same size...) so hopefully ...

nanddump -nof uboot.environment-for-pogoplugOS -s 0xa0000 -l 0x20000 /dev/mtd0

will get that for us... trying it now...

OK, that also worked... now to see if it can be flashed in... using something like this:
[[b]UNNECESSARY[/b]]

NAS>> set ipaddr 192.168.11.150
NAS>> set serverip 192.168.11.149
NAS>> tftpboot 0x800000 uboot.environment-for-pogoplugOS
Using egiga0 device
TFTP from server 192.168.11.149; our IP address is 192.168.11.150
Filename 'uboot.environment-for-pogoplugOS'.
Load address: 0x800000
Loading: ##########################
done
Bytes transferred = 131072 (20000 hex)
NAS>> nand erase 0xa0000 0x20000

NAND erase: device 0 offset 0xa0000, size 0x20000
Erasing at 0xa0000 -- 100% complete.
OK
NAS>> nand write.e 0x800000 0xa0000 0x20000

NAND write: device 0 offset 0xa0000, size 0x20000

Writing data at 0xbf800 -- 100% complete.
 131072 bytes written: OK

(Afterthought & Discovery... I suspect that the CE U-Boot does not allow restoration of values this way. It seems like it may have actually just reset them when I overwrote them with nandwrite.e ... or it may have just reset a few "proprietary" items like the CE-specific stuff. You can __just__ restore the values below without doing the nandwrite.e of uboot.env . I've checked it and the values below are all it needs... some bootcmd and args, and some CloudEngine proprietary ID stuff...)

Restore these machine particular values [ the last few digits of each are hidden since these are particular to my machine - use your values stated on the bottom stamp of your device]:

set bootargs_root 'root=/dev/mtdblock2 ro'
set ethaddr '00:10:75:xx:xx:xx'
set cesvcid XATV5KXME93F7TKTWN95xxxxxx
set ceserialno NA1Yxxxx
set ceboardver 'DISCOVERY:0.1'
set bootcmd 'nand read.e 0x800000 0x100000 0x300000; setenv bootargs $(console) $(bootargs_root); bootm 0x800000'
saveenv

Huzzah!! it works... just tested it again...

I'm laughing a bit now as I'd read a few times that this wasn't possible...


======================================
Another idea from ArchLinuxArm forums: via Seagate Tech Support : http://archlinuxarm.org/forum/viewtopic.php?f=18&t=1580#p8798 (only works if you have the factory U-Boot installed, apparently)

=====================================================

• davy's Github Repo's rescue-dg

Edited 8 time(s). Last edit at 05/06/2012 10:56PM by davygravy.

Nice to know it should work at least Davy. I did briefly try it last night (it's the only place I can get an hour or so free) and it didn't go quite so well. I'm working from memory now, but I'll post in more detail later.

I'd restored each bit of the NAND and then let it reboot. Flashed the uboot one from 0x0, size 0x80000.

Watched it as it booted through serial and I was getting a Bad CRC error just after displaying the NAND size (wondered if it was to do with the bad block table being destroyed?). Looked at the uboot environment settings: the MAC address was not that of my GFN, and there was no sign of a CEID or CE serial number. I know the CEID is on the base if the unit, but not sure about the serial number?

Anyway, after changing the mac to what it should be, the CRC error went away, but it continually tries to boot from tftp. There was a lot of variables shown in printenv, more so than I believe is required. Hopefully tonight I'll wipe out the uboot environment and just put in the ones you said are required.

Everything you saw sounds familiar. BTW, you shouldn't wipe any variables, rather just add or change the ones I showed.

They will allow it to boot and to communicate w the Pogoplug main server.

Good luck

=====================================================

• davy's Github Repo's rescue-dg

Many many many thanks for your help Davy. I have got it running, and could access it through my.pogo. I guess this is also useful for anyone who has completely hosed their GFN like I did ;)

What I also noticed was in your MTD2 dump, is the original uboot that was backed up when you ran Jeff's script (Don't worry, it doesn't have any of your env stuff in it - i've checked). The one on Scott's site is for a goflex home (I presume this is the reason why one of the disk indicator LEDs randomly lights up during booting) - notice how the UBoot logo is on the Goflex Home uboot but not the GFN, and the prompt is CE rather than NAS.

I've tried flashing that back into mtd0, reconfigured my env with the appropriate CE info and tried to let it boot. I decided to completely erase my variables as I had a huge number there - compared to yours I had about 3 times worth. Just ran "nand erase 0xa0000 0x20000" then let it boot up which created a fresh env which matched yours aside from unit specific stuff. This is what happens when I use your uboot.kwb from the filesystem:

CE>> reset


U-Boot 1.1.4  Cloud Engines 1.1.2 (3.4.22) SATA PHYADDR=0

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 00691750

Soc: 88F6281 A1 (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
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
NAND:256 MB
Flash:  0 kB

CPU : Marvell Feroceon (Rev 1)
CLOUD ENGINES BOARD: DISCOVERY:0.1

Streaming disabled
Write allocate disabled


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

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

Reading data from 0x3ff800 -- 100% complete.
 3145728 bytes read: OK
## Booting image at 00800000 ...
Bad Magic Number
CE>>

No longer the case:---> I now get that error no matter what uboot I use. So I've either killed the NAND or I touched something I shouldn't have! Still playing about with it though. <---
No matter what I did I would always get the bad magic number error above. I reflashed Jeff's uBoot, copied the generic linux install to USB, along with the MTD dumps and completely wiped the nand again using "flash_eraseall" utility in linux, rather than uboot. Then it's just a case of reflashing back each mtd section. I advise MTD0 to be done as soon as it's wiped to avoid need UART booting. Then shutdown linux/reboot the GFN, interrupt the first boot and add the CE variables then reboot again.

Shows up again on my.pogo. If you remove then re-add the device, it will then update the pogo software from 3.2.5 (to 3.2.6 which is the latest I'm guessing). Funnily enough, I cannot enable SSH access on the my.pogo website (one of the reasons I attempted to restore my GFN) - is this the same for anyone else? I currently can get the to the SSH login, but I don't know the password for the prompt - did you have one set Davy? I guess there's a way to change it via serial connection?

It's certainly been quite an experience... but I'm always in favour of learning by doing!

I will definitely attempt to dump the flash from the unused unit though when I do open it, as it may be like the pogoplug where a ramdisk image boots.



Edited 4 time(s). Last edit at 05/07/2012 02:13PM by Biohead.

1. If you need to change your password, make the filesystem rw, and then execute the passwd command - you should be able to do this from serial connection, IIRC.


2. Check to see if dropbear is actually running. Also, somewhere in /etc/init.d/ , IIRC, there is a script...
maybe it is /etc/init.d/db that has to be referenced/run to start dropbear (ssh server) automatically at boot...

Anyway, in my GFN, /etc/init.d/db and /etc/init.d/rcS have the following contents it it seems to start dropbear up each time.

-sh-3.2# cat rcS 
#! /bin/sh

mount -t proc none /proc
mount -t sysfs none /sys
mount -t devpts none /dev/pts
mount -t tmpfs none /tmp
mount -t usbfs none /proc/bus/usb
mkdir /tmp/var

echo "/tmp/core_%e_%t" > /proc/sys/kernel/core_pattern

hostname Pogoplug

ifconfig lo 127.0.0.1
ifconfig eth0 169.254.37.133
udhcpc -b -H `hostname`

#telnetd
/etc/init.d/db
#ntpd -g

/etc/init.d/hbmgr.sh start

#/bin/mount -a

-sh-3.2# cat db          
#!/bin/sh

if [ ! -e /etc/dropbear/dropbear_rsa_host_key ]; then
    cat /proc/mounts | grep ' / ' | grep ro > /dev/null
    isro=$?
    if [ $isro == 0 ]; then 
        mount / -o remount,rw,noatime
    fi
    mkdir -p /etc/dropbear
    /usr/bin/dropbearkey -t rsa -f /etc/dropbear/dropbear_rsa_host_key
    /usr/bin/dropbearkey -t dss -f /etc/dropbear/dropbear_dss_host_key
    if [ $isro == 0 ]; then 
        mount / -o remount,ro
    fi
fi

#/usr/sbin/dropbear

3. Double check your MACaddress/ethaddr & CE variables in U-Boot env. If one of them is off even a character, it will not initiate services correctly (though it may work partially)... More than once I've had to double check these and nudge something just a bit to get it just right.




4. As for the

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

Reading data from 0x3ff800 -- 100% complete.
 3145728 bytes read: OK
## Booting image at 00800000 ...
Bad Magic Number

It does sound like the uImage was clobbered. Yes, try reflashing just that section, uImage, which is mtd1, IIRC.

=====================================================

• davy's Github Repo's rescue-dg