RN2120v2 bricked

Hello Everyone,
i hope someone can help me..
I was playing (yes.. my bad) with my RN2120v2 u_boot and kernel image to see if i could update debian to a more recent version, the ultimate goal was to install Nextcloud on this hardware, and somehow i bricked everything.
It all happened when trying to erase the mtd partitions i typed .chip instead of the one for the partition. (it was late night..)
All i get from serial when i press the power button now is :

BootROM 1.20
Booting from NAND flash
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00010000
BootROM: Bad header at offset 00020000
BootROM: Bad header at offset 00030000
BootROM: Bad header at offset 00040000
BootROM: Bad header at offset 00050000
....
BootROM: Bad header at offset 012A0000
BootROM: Bad header at offset 012B0000
BootROM: Bad header at offset 012C0000
BootROM: Bad header at offset 012D0000

But my problem is not this. I read other topics and found out it is possible to get u_boot transferred over serial and from there i can restore the mtd content (which i don't have..),
so i tried to use kwboot with different images (RN104), which i suspect don't work because targeting a different cpu
I then tried to download from NetGear the source code from:
ReadyNAS OS 6 (RN102/RN104/2120) thinking i can get u_boot from there and recompile it (i did this before for other boards).

But i couldn't find any u_boot in that package! It seems the package only provide sources for the kernel and OS.
Am i missing something here? I also searched for this version over the net and it seems very hard to find.
The u_boot version is this: (from a serial dump before the mess)

BootROM 1.20
Booting from NAND flash

General initialization - Version: 1.0.0
High speed PHY - Version: 2.1.8  (COM-PHY-V22)
Update Device ID PEX0782311AB
Update Device ID PEX1782311AB
Update Device ID PEX2782311AB
Update Device ID PEX3782311AB
Update Device ID PEX4782311AB
Update Device ID PEX5782311AB
Update Device ID PEX6782311AB
Update PEX Device ID 0x78230
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver 5.7.1
DDR3 Training Sequence - Run with PBS.
DDR3 Training Sequence - Ended Successfully 
BootROM: Image checksum verification PASSED

 __   __                      _ _
|  \/  | __ _ _ ____   _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| |  | | (_| | |   \ V /  __/ | |
|_|  |_|\__,_|_|    \_/ \___|_|_|
         _   _     ____              _
        | | | |   | __ )  ___   ___ | |_ 
        | | | |___|  _ \ / _ \ / _ \| __| 
        | |_| |___| |_) | (_) | (_) | |_ 
         \___/    |____/ \___/ \___/ \__| 
 ** LOADER **


U-Boot 2011.12-gd923454 (Sep 08 2015 - 18:59:32) Marvell version: v2011.12 2014_T2.0p1
Netgear version: 09/08/2015 ReadyNAS-2120 v2.0

Board: DB-78460-BP rev 2.0
SoC:   MV78230 B0
       running 2 CPUs
       Custom configuration
CPU:   Marvell PJ4B (584) v7 (Rev 2) LE
       CPU 0
       CPU    @ 1600 [MHz]
       L2     @ 800 [MHz]
       TClock @ 250 [MHz]
       DDR    @ 800 [MHz]
       DDR 32Bit Width, FastPath Memory Access
       DDR ECC Disabled
DRAM:  2 GiB

Map:   Code:		0x7fedf000:0x7ff9f204
       BSS:		0x7ffefc20
       Stack:		0x7f9deef8
       Heap:		0x7f9df000:0x7fedf000

NAND:  128 MiB
MMC:   MRVL_MMC: 0
Bad block table found at page 65472, version 0x01
Bad block table found at page 65408, version 0x01

Initialize and scan all PCI interfaces
PEX unit.port(active IF[-first bus]):
------------------------------------------
PEX 0.0(0-0): Root Complex Interface, Detected Link X1, GEN 2.0
PEX 0.1(1-1): Root Complex Interface, Detected Link X1, GEN 2.0
PEX 1.0(2-2): Root Complex Interface, Detected Link X1, GEN 2.0
FPU initialized to Run Fast Mode.
USB 0: Host Mode
USB 1: Host Mode
USB 2: Host Mode
Modules Detected:
Net:   egiga0, egiga1 [PRIME]
Power On!

Another problem i have when i try to send u_boot.bin over the serial is that on this machine i have to keep pressing the power button for the entire time (1+ hours..) until the image is downloaded, otherwise the power button lights up the power on led for only 2 seconds. Is this common on other models?

So at the end my question is: is there anybody so kind to point me to where the u_boot for this particular board could be? Or if anybody owns a 2120 would be so kind to dump the mtd partition for u_boot and post it here?

Thanks a lot!
Sandro

Sandro,

U-Boot 2011.12-gd923454 (Sep 08 2015 - 18:59:32) Marvell version: v2011.12 2014_T2.0p1
Netgear version: 09/08/2015 ReadyNAS-2120 v2.0

Board: DB-78460-BP rev 2.0
SoC:   MV78230 B0
       running 2 CPUs
       Custom configuration

You can try to unbrick it while waiting for somebody to upload mtd0. Build mainline u-boot for this board, and run kwboot with it to see if you can get to the u-boot prompt.

Your is an Armada XP SoC with 2 cores.

My source tree shows:

./u-boot-2019.10/board/Marvell/db-mv784mp-gp

If you need help building or running it, let me know.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Bodhi, thanks a lot for helping.

I am recompiling u-boot mainline right now using db-mv784mp-gp_defconfig.

Should i set the boot method to UART in menuconfig? standard is SPI NOR flash

Sandro

Sandro,

> Should i set the boot method to UART in
> menuconfig? standard is SPI NOR flash

Yes. It should be set

CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y

And then build u-boot-spl.kwb image to run kwboot with.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Bodhi,
i did that but the result is strange (to me at least).

alxvt@XPS15-9530:~/u-boot-v2019.10$ ./tools/kwboot -t /dev/ttyUSB0 -b u-boot-spl.kwb 
Sending boot message. Please reboot the target...\
Sending boot image...
  0 % [......................................................................]
  1 % [......................................................................]
  2 % [......................................................................]
  4 % [......................................................................]
  5 % [......................................................................]
  6 % [......................................................................]
  8 % [......................................................................]
  9 % [......................................................................]
 10 % [......................................................................]
 12 % [......................................................................]
 13 % [......................................................................]
 15 % [......................................................................]
 16 % [......................................................................]
 17 % [......................................................................]
 19 % [....................................................+xmodem: Protocol error

The send image progress goes fast until 19%, then it slows down to one dot every 2 seconds.
This with the power button pressed.
If i release the power button i get that Protocol error.

If i wait for the progress counter to get to 100% ( 1:20min ! ) i get nothing back from uart, like it does not boot at all.

It just does not make sense..

|=====|
| AlxVt |
|=====|

alxvt,

> The send image progress goes fast until 19%, then
> it slows down to one dot every 2 seconds.
> This with the power button pressed.
> If i release the power button i get that Protocol
> error.

That's a peculiar behavior seems to be with this box only.

>
> If i wait for the progress counter to get to 100%
> ( 1:20min ! ) i get nothing back from uart, like
> it does not boot at all.
>
> It just does not make sense..

Sorry, it does not make sense to me, too! I've not come across this Power button behavior before with any other Marvell Armada or Kirkwood boxes.

I think the best approach at this point is to find the mtd0 backup from somebody and try kwboot with it.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Quick update:
I am still investigating on this and found this from Barebox.org
which talks about the uart booting of this board:

Quote

The mvebu SoCs support booting from UART. For this there is a tool available in barebox called kwboot. Quite some mvebu boards are reset once more when they already started to read the first block of the image to boot which obviously results in a failure to boot this image. If you want to boot such a board, use the parameter -n 15 for kwboot to delay uploading the image and try to hit the right (i.e. second) window harder. (The number might have to be adapted per board. The semantic is that the magic string is sent until the 15th NAK is seen and only then the image is sent.)

This is interesting, however i am recompiling for the RN2120 and it complains about the missing “binary.0” which happens to be the ram initialization code to be extracted from the vendor uboot..
a neverending loop..

but i don’t give up..
i will try the uboot version of kwboot to see if it support the -n option..

alxvt Wrote:
-------------------------------------------------------
> Quick update:
> I am still investigating on this and found this
> from
> Barebox.org
> which talks about the uart booting of this board:
>

Quote

> The mvebu SoCs support booting from UART. For this
> there is a tool available in barebox called
> kwboot. Quite some mvebu boards are reset once
> more when they already started to read the first
> block of the image to boot which obviously results
> in a failure to boot this image. If you want to
> boot such a board, use the parameter -n 15 for
> kwboot to delay uploading the image and try to hit
> the right (i.e. second) window harder. (The number
> might have to be adapted per board. The semantic
> is that the magic string is sent until the 15th
> NAK is seen and only then the image is sent.)
>

>
> This is interesting, however i am recompiling for
> the RN2120 and it complains about the missing
> “binary.0” which happens to be the ram
> initialization code to be extracted from the
> vendor uboot..
> a neverending loop..
>
> but i don’t give up..
> i will try the uboot version of kwboot to see if
> it support the -n option..

UART booting is the similar for uboot and barebox. Both use kwhoot. The delay option is different in uboot. Also, there is a specific option for your box (Armada XP).

Run kwboot without any parameter to see the usage help.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

i made progress..
I found that the RTC chip IRQ2 line was triggering the power off after few seconds, interrupting my kwboot transfer.
When i manually tied this line to GND i was able to complete the transfer and boot u_boot.

I then copied and wrote into mtd0 the original uboot from netgear.
I am currently able to boot from nand every time i power on but then the other mtd parts are still missing.

BootROM 1.20
Booting from NAND flash

General initialization - Version: 1.0.0
High speed PHY - Version: 2.1.8  (COM-PHY-V22)
Update Device ID PEX0782311AB
Update Device ID PEX1782311AB
Update Device ID PEX2782311AB
Update Device ID PEX3782311AB
Update Device ID PEX4782311AB
Update Device ID PEX5782311AB
Update Device ID PEX6782311AB
Update PEX Device ID 0x78230
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver 5.7.1
DDR3 Training Sequence - Run with PBS.
DDR3 Training Sequence - Ended Successfully 
BootROM: Image checksum verification PASSED

 __   __                      _ _
|  \/  | __ _ _ ____   _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| |  | | (_| | |   \ V /  __/ | |
|_|  |_|\__,_|_|    \_/ \___|_|_|
         _   _     ____              _
        | | | |   | __ )  ___   ___ | |_ 
        | | | |___|  _ \ / _ \ / _ \| __| 
        | |_| |___| |_) | (_) | (_) | |_ 
         \___/    |____/ \___/ \___/ \__| 
 ** LOADER **


U-Boot 2011.12-gd923454 (Sep 08 2015 - 18:59:32) Marvell version: v2011.12 2014_T2.0p1
Netgear version: 09/08/2015 ReadyNAS-2120 v2.0

Board: DB-78460-BP rev 2.0
SoC:   MV78230 B0
       running 2 CPUs
       Custom configuration
CPU:   Marvell PJ4B (584) v7 (Rev 2) LE
       CPU 0
       CPU    @ 1600 [MHz]
       L2     @ 800 [MHz]
       TClock @ 250 [MHz]
       DDR    @ 800 [MHz]
       DDR 32Bit Width, FastPath Memory Access
       DDR ECC Disabled
DRAM:  2 GiB

Map:   Code:		0x7fedf000:0x7ff9f204
       BSS:		0x7ffefc20
       Stack:		0x7f9deef8
       Heap:		0x7f9df000:0x7fedf000

NAND:  128 MiB
MMC:   MRVL_MMC: 0
Bad block table found at page 65472, version 0x01
Bad block table found at page 65408, version 0x01

Initialize and scan all PCI interfaces
PEX unit.port(active IF[-first bus]):
------------------------------------------
PEX 0.0(0-0): Root Complex Interface, Detected Link X1, GEN 2.0
PEX 0.1(1-1): Root Complex Interface, Detected Link X1, GEN 2.0
PEX 1.0(2-2): Root Complex Interface, Detected Link X1, GEN 2.0
FPU initialized to Run Fast Mode.
USB 0: Host Mode
USB 1: Host Mode
USB 2: Host Mode
Modules Detected:
Net:   egiga0, egiga1 [PRIME]
Power On!

FDT loaded successfully
Found 4 disks present
Delay 7s then power on another group of HDDs 1 
Hit any key to stop autoboot:  0 

NAND read: device 0 offset 0x200000, size 0x400000
 4194304 bytes read: OK

NAND read: device 0 offset 0x800000, size 0x400000
 4194304 bytes read: OK
## Booting kernel from Legacy Image at 02000000 ...
Bad Header Checksum
ERROR: can't get kernel image!
Marvell>>

Not sure what to do from here, but i feel i am very close...
Any suggestion?

alxvt,

> i made progress..
> I found that the RTC chip IRQ2 line was triggering
> the power off after few seconds, interrupting my
> kwboot transfer.
> When i manually tied this line to GND i was able
> to complete the transfer and boot u_boot.

Great progress! sounds almost like the watchdog setup that went bad.


> I then copied and wrote into mtd0 the original
> uboot from netgear.
> I am currently able to boot from nand every time i
> power on but then the other mtd parts are still
> missing.

> Hit any key to stop autoboot: 0

Interrupt u-boot at this countdown and

printenv
mtdparts

Depending which u-boot image you have flashed, the envs must be defined correctly to see the mtd parts. That will enable you to boot either with NAND or external disk drives. So at this point, I would find the stock envs definition from somewhere, and compare the current envs with those.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Marvell>> mtdparts
device nand0 <armada-nand>, # parts = 5
 #: name		size		offset		mask_flags
 0: u-boot              0x000000180000		0x000000000000		0
 1: u-boot-env          0x000000020000		0x000000180000		0
 2: uImage              0x000000600000		0x000000200000		0
 3: minirootfs          0x000000400000		0x000000800000		0
 4: ubifs               0x000007400000		0x000000c00000		0

active partition: nand0,0 - (u-boot) 0x000000180000 @ 0x000000000000

defaults:
mtdids  : none
mtdparts: none

Marvell>> printenv
CASset=min
HW_version=MVT
MALLOC_len=5
MPmode=smp
Startup=Normal
amp_enable=no
autoload=no
baudrate=115200
boot_order=hd_scr usb_scr mmc_scr hd_img usb_img mmc_img pxe net_img net_scr
bootargs=console=ttyS0,115200 pm_disable=yes mv_cpu_count=2
bootargs_dflt=$console $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel
bootargs_end=:10.4.50.254:255.255.255.0:DSMP:eth0:none
bootargs_root=root=/dev/nfs rw
bootcmd=nand read 0x2000000 0x200000 0x400000; nand read 0x3000000 0x800000 0x400000; bootm 0x2000000 0x3000000 0x1000000
bootcmd_auto=stage_boot $boot_order
bootcmd_fdt=tftpboot 0x2000000 $image_name;tftpboot $fdtaddr $fdtfile;setenv bootargs $console $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_lgcy=tftpboot 0x2000000 $image_name; setenv bootargs $bootargs_dflt; bootm 0x2000000; 
bootcmd_ubi=ubi part ubifs; ubifsmount rootfs; ubifsload 0x2000000 kernel; ubifsload 0x3000000 initrd.gz; bootm 0x2000000 0x3000000 0x1000000
bootdelay=0
cacheShare=no
console=console=ttyS0,115200
device_partition=0:1
disL2Cache=yes
disL2Prefetch=yes
disaMvPnp=no
eeeEnable=no
enaAutoRecovery=yes
enaClockGating=no
enaCpuStream=no
enaDCPref=yes
enaFPU=yes
enaICPref=yes
enaLPAE=no
enaWrAllo=no
envver=3
eth1addr=00:50:43:02:00:00
eth1mtu=1500
ethact=egiga1
ethaddr=00:50:43:02:02:00
ethmtu=1500
ethprime=egiga1
fdt_skip_update=no
fdtaddr=0x1000000
fdtfile=armada-xp-db.dtb
ide_path=/
image_name=uImage
initrd_name=uInitrd
ipaddr=192.168.58.233
kernel_addr_r=2080000
lcd0_enable=0
lcd0_params=640x480-16@60
lcd_panel=0
loadaddr=0x02000000
loads_echo=0
mtddevname=u-boot
mtddevnum=0
mtdids=nand0=armada-nand
mtdparts=mtdparts=armada-nand:0x180000@0(u-boot),0x20000@0x180000(u-boot-env),0x600000@0x200000(uImage),0x400000@0x800000(minirootfs),-(ubifs)
mvNetConfig=mv_net_config=4,(00:50:43:11:11:11,0:1:2:3),mtu=1500
mv_pon_addr=00:50:43:00:00:02
nandEcc=1bit
netbsd_en=no
netmask=255.255.255.0
netretry=no
partition=nand0,0
pcieTune=no
pexMode=rc
pxe_files_load=:default.arm-armadaxp-db:default.arm-armadaxp:default.arm
pxefile_addr_r=3100000
ramdisk_addr_r=2880000
rcvrip=169.254.100.100
rootpath=/srv/nfs/
sata_delay_reset=0
sata_dma_mode=yes
script_addr_r=3000000
script_name=boot.scr
serverip=192.168.58.189
standalone=fsload 0x2000000 $image_name;setenv bootargs $console $mtdparts root=/dev/mtdblock0 rw ip=$ipaddr:$serverip$bootargs_end; bootm 0x2000000;
stderr=serial
stdin=serial
stdout=serial
usb0Mode=host
usb1Mode=host
usb2Mode=host
usbActive=0
vxworks_en=no
yuk_ethaddr=00:00:00:EE:51:81

Environment size: 2978/131068 bytes

I used the original uboot extracted from the ReadyNASOSxxx.img so i would guess the mtd parts should be correct.

I also noticed the environment vars were saved in mtd1 at the first boot (i didn't write anything in that location), and i think are default vars since the MACs don't match with my machine..

alxvt,


Everything looks great.

So I think the kernel files in NAND were corrupted:

Quote

bootcmd=nand read 0x2000000 0x200000 0x400000; nand read 0x3000000 0x800000 0x400000; bootm 0x2000000 0x3000000 0x1000000

NAND read: device 0 offset 0x200000, size 0x400000
 4194304 bytes read: OK

NAND read: device 0 offset 0x800000, size 0x400000
 4194304 bytes read: OK
## Booting kernel from Legacy Image at 02000000 ...
Bad Header Checksum
ERROR: can't get kernel image!

Those 2 locations store stock kernel uImage and uInitrd for this box. Reflash those 2 files (perhaps Netgear download have them).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

YES YES YES!!!
It worked, i am now into ReadyNas OS again..

Well, this was a hell of a learning curve i guess..

Bodhi,
thank you so much for your assistance!

alxvt Wrote:
-------------------------------------------------------
> YES YES YES!!!
> It worked, i am now into ReadyNas OS again..
>
> Well, this was a hell of a learning curve i
> guess..
>
> Bodhi,
> thank you so much for your assistance!

Cool!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I spoke too early..

NAND read: device 0 offset 0x800000, size 0x400000
 4194304 bytes read: OK
## Booting kernel from Legacy Image at 02000000 ...
   Image Name:   Linux-4.4.184.armada.1
   Created:      2019-09-05   2:39:22 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3469696 Bytes = 3.3 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 03000000 ...
   Image Name:   initramfs
   Created:      2019-09-18   3:20:11 UTC
   Image Type:   ARM Linux RAMDisk Image (lzma compressed)
   Data Size:    3423536 Bytes = 3.3 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 01000000
   Booting using the fdt blob at 0x01000000
   Loading Kernel Image ... OK
   Using Ramdisk in place at 03000040, end 03343d70
   Using Device Tree in place at 01000000, end 01007542
Updating device tree successful

Starting kernel ...


Starting the boot process...
Detected system type: RN2120
Loading kernel modules...done
Boot mode: Normal
UBI device number 0, total 920 LEBs (116817920 bytes, 111.4 MiB), available 9 LEBs (1142784 bytes, 1.1 MiB), LEB size 126976 bytes (124.0 KiB)
Bringing up network...done
Bringing up RAID arrays...done
e2fsck 1.42.13 (17-May-2015)
43020200_root: recovering journal
43020200_root: clean, 11/1048576 files, 86094/1047552 blocks
*** Need to update root image! ***
Extracting root image...ERROR: Could not mount boot flash [/dev/ubi0_0] (Invalid argument)

Welcome to ReadyNASOS
nas-02-02-00 login: command failed: mdev -s
command failed: /usr/sbin/telnetd

I am now having errors loading the rootfs from ubifs (mtd4)
I know i should write root.tlz into mtd4 but doing that doesn't solve.

Note that linux not being able to mount rootfs does not let me login, so i cannot use any bash scripting..

what now?

alxvt,

Quote

mtdparts=mtdparts=armada-nand:0x180000@0(u-boot),0x20000@0x180000(u-boot-env),0x600000@0x200000(uImage),0x400000@0x800000(minirootfs),-(ubifs)

Quote

UBI device number 0, total 920 LEBs (116817920 bytes, 111.4 MiB), available 9 LEBs (1142784 bytes, 1.1 MiB), LEB size 126976 bytes (124.0 KiB)
Bringing up network...done
Bringing up RAID arrays...done
e2fsck 1.42.13 (17-May-2015)
43020200_root: recovering journal
43020200_root: clean, 11/1048576 files, 86094/1047552 blocks
*** Need to update root image! ***
Extracting root image...ERROR: Could not mount boot flash [/dev/ubi0_0] (Invalid argument)

Quote

I am now having errors loading the rootfs from ubifs (mtd4)
I know i should write root.tlz into mtd4 but doing that doesn't solve.

Did you try reflashing stock mtd3 and mtd4? and how did you do that? i.e. usually ubifs need to be flashed with different command, not nand write.

If root.tlz is an mtd4 nanddump, then flash with nand write. But if it is a rootfs backup, you would need to create UBIFS volume, write it ,.... in UBIFS way (look at documentation how Netgear flash this).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

yep,
i did it with nand write but it is a rootfs backup
from what i understand (tarred with lzma),
so i am going to try recreating the UBIFS

Quote
i am going to try recreating the UBIFS

Hi alxvt,

Did you manage to create UBIFS?

Thanks

Bro can yo pls make dd copy of nand and send it to shtirlicz2003@mail.ru

bodhi! can ypu pls help me to build uboot for uart for 2120 /email shtirlicz2003@mail.ru

shtirlicz,

> bodhi! can ypu pls help me to build uboot for uart
> for 2120 /email shtirlicz2003@mail.ru

There is no need to build new u-boot. What you need is the mtd0 dump for this box.

Basically, this is the u-boot on mtd0. Use it to kwboot the box to rescue it.

U-Boot 2011.12-gd923454 (Sep 08 2015 - 18:59:32) Marvell version: v2011.12 2014_T2.0p1
Netgear version: 09/08/2015 ReadyNAS-2120 v2.0

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> shtirlicz,
>
> > bodhi! can ypu pls help me to build uboot for
> uart
> > for 2120 /email shtirlicz2003@mail.ru
>
> There is no need to build new u-boot. What you
> need is the mtd0 dump for this box.
>
> Basically, this is the u-boot on mtd0. Use it to
> kwboot the box to rescue it.
>

> U-Boot 2011.12-gd923454 (Sep 08 2015 - 18:59:32)
> Marvell version: v2011.12 2014_T2.0p1
> Netgear version: 09/08/2015 ReadyNAS-2120 v2.0
>

thnx/ used kwboot with -p key
nand was formated by admin
i restored this rn2120 thank to this topic