It is still in the GitHub pull requests (https://github.com/openwrt/openwrt/pull/3371) with status:
At least 2 approving reviews are required by reviewers with write access.
Merging is blocked
Merging can be performed automatically with 2 approving reviews.
So you'll need to get 2 reviewers with write access to approve. I've done what I can by adding my Tested By.
I bring back device to me. I plan to push it forward.
Where can I find the exact steps taken to load this on the device? I don't know how to stop booting in uboot or connect to the console. I haven't done any ARM-based Linux stuff and this box is old, but needs new life.
To stop booting please press any key when u-boot ask for it.
Installation by USB + serial:
usb resetfatload usb 0:1 0x1200000 openwrt-kirkwood-netgear_readynas-duo-v2-initramfs-uImagesetenv bootargs 'console=ttyS0,115200n8 earlyprintk'bootm 0x1200000
Installation by TFTP + serial:
setenv serverip 192.168.1.1setenv ipaddr 192.168.1.2setenv bootargs 'console=ttyS0,115200n8 earlyprintk'tftpboot 0x1200000 openwrt-kirkwood-netgear_readynas-duo-v2-initramfs-uImagebootm 0x1200000
Many thanks - that was easy. The instructions I was looking at seemingly omitted the J5 connector. Is that image you've linked above the latest version?
I recommend to use latest snapshot:
Hi,
thanks for the great work. OpenWrt instead of electronic scrap!
I followed your instructions and installed the latest snapshot.
After sysupgrade the device rebootet as expected.
download sysupgrade.bin to /tmp
sysupgrade -v
Unfortunately an error occurs after reboot: "Bad Magic Number".
__ __ _ _
| \/ | __ _ _ ____ _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| | | | (_| | | \ V / __/ | |
|_| |_|\__,_|_| \_/ \___|_|_|
_ _ ____ _
| | | | | __ ) ___ ___ | |_
| | | |___| _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
\___/ |____/ \___/ \___/ \__|
** MARVELL BOARD: DB-88F6282A-BP LE
U-Boot 1.1.4 (Jun 29 2012 - 16:06:40) Marvell version: 3.4.27
Netgear version: Uboot-1_1_4-NetgearDUOV3-V1009
U-Boot code: 00600000 -> 0067FFF0 BSS: -> 006D0120
Soc: MV88F1155 Rev 1 (DDR3)
CPU running @ 1600Mhz L2 running @ 533Mhz
SysClock = 533Mhz , TClock = 200Mhz
DRAM unknown CAL tRP = 8 tRAS = 20 tRCD=8
DRAM CS[0] base 0x00000000 size 256MB
DRAM Total size 256MB 16bit width
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
NAND:128 MB
Flash: 0 kB
CPU : Marvell Feroceon (Rev 1)
Streaming disabled
Write allocate disabled
USB 0: host mode
PEX 0: PCI Express Root Complex Interface
PEX interface detected Link X1
Switch On !
Net: egiga0 [PRIME]
Hit any key to stop autoboot: 0
NAND read: device 0 offset 0x200000, size 0x600000
Reading data from 0x7ff800 -- 100% complete.
6291456 bytes read: OK
NAND read: device 0 offset 0x800000, size 0x1000000
Reading data from 0x17ff800 -- 100% complete.
16777216 bytes read: OK
## Booting image at 01200000 ...
Image Name: ARM OpenWrt Linux-5.10.92
Created: 2022-01-19 8:44:26 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2813934 Bytes = 2.7 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
OK
## Loading Ramdisk Image at 02000000 ...
Bad Magic Number▒
Some changes was done before merge. Please follow steps from commit message:
thanks a lot!
I am a complete newbie.
setenv bootcmd ... and saveenv makes sense.
See, this is the kind of thing I'm talking about when I say I hate all things Linux. I was having the same issue, going in circles and not getting anywhere. I'm glad someone cleared that detail up - too late for me though I've already soft bricked it operating off the old instructions and thinking it must've been a nand issue. I'm throwing the box away at this point. I realize the effort that went into this addition, and that it's free - so don't think I'm entitled when I say this. But if we're going to do this, let's put out complete and correct instructions. It'll save hours of frustration and wasted equipment.
Most ARM Kirkwood devices can't actually be bricked. Your recovery process is kwboot. See https://forum.doozan.com/read.php?3,51739,51919#msg-51919 for instruction on how to use kwboot.
Thanks for that - I just realized I was a little vague on the actual issue. I was careful to use the term soft-brick because I knew the bootloader could be reinstalled easily. The last straw was having that happen during an already long struggle with a "bad magic number" error. The good news is that after a good night's sleep I pulled it out of the trash, reinstalled U-boot, and tried the updated instructions.
They worked perfectly and this unit narrowly escaped the hammer I had positioned nearby in case it failed. I'm kidding there was no hammer. I hear you about the lack of contributions and I agree. I think that's partly why I had such a hard time. Although there is a wiki and the instructions have been updated, I think perhaps there's still room to improve clarity for new users. I'd be happy to contribute either way.
@CHKDSK88 I've been testing alot with your OpenWRT port to the Netgear ReadyNAS V2.
I've been testing OpenWRT v22 and v23 on the ReadyNAS and it seems to work quite well.
As I was eager to get a bit better performance (OpenWRT lacks a bit in raw NET->HDD throughput) I was test several kernel configurations to see where it would bring me.
I was able to get rsync over gigabit LAN upto 28MB/s to the HDD sustained throughput. Original OpenWRT did about 23MB/s in my setup. With the original firmware it liked to do about 35MB/s sustained.
Performance didn't improve on raid0 setup. A single HDD or SSD was just as fast in my case.
Upto today. The fun seems over when I did another sysupgrade -v and was greeted on the serial console by a CRC error on loading the kernel ...
It seemed to me the NAND flash was going demented. I figured, why not start all over and did a 'nand erase' on the u-boot console.
That didn't seem clever. The device doesn't auto boot since then.
I am able to boot the device into u-boot again with kwboot and the u-boot.bin from Netgear. Even starting OpenWRT over TFTPBOOT is working fine.
Do you have an explanation available on how to recover the Netgear Readynas from zero (blank NAND) ?
When I boot with kwboot using Netgear's u-boot.bin I do see 4 MTD partitions (which seems odd to me - I figured it to be blank) and start your OpenWRT uImage over TFTPBOOT.
I tried reading the u-boot.bin over TFTPBoot into memory address 0x1200000 and doing a nand erase 0x00 0x80000 followed by a nand write 0x1200000 0x00 0x80000 in the hope to get the u-boot back on track. To no avail. Console stays as blank at power on as it can be.
I see many links on how to recover using kwboot for other Kirkwood devices, but none specific for the ReadyNAS V2.
I have no clue any more. Maybe someone can make an 128MB backup of his flash and I can do a restore from it. I should have done that in the first place I guess 
PS when trying to overwrite the u-boot (mtd0) partition from inside OpenWRT using:
root@OpenWrt:/# cat /etc/fw_env.config
/dev/mtd1 0x0 0x20000 0x20000
root@OpenWrt:/# cat /proc/mtd
dev: size erasesize name
mtd0: 00180000 00020000 "u-boot"
mtd1: 00020000 00020000 "u-boot-env"
mtd2: 00600000 00020000 "kernel"
mtd3: 07800000 00020000 "ubi"
root@OpenWrt:/# flash_erase /dev/mtd0 0 4
flash_erase: error!: /dev/mtd0
error 13 (Permission denied)
All I get is: permission denied.
I did set:
setenv mtdparts mtdparts=orion_nand:2M(u-boot),3M(uImage),3M(uImage2),8M(failsafe),112M(root)
Can I overwrite mtd0 from inside u-boot doing a 'nand write' at nand address 0x20000 ?
The default settings in OpenWrt are such that the uboot region is read only to avoid problems with people accidentally bricking their devices.
To write to the uboot region you first need to load kernel module 'kmod-mtd-rw'
Or another option is to remove the 'read only' flag in the dts file and compile your own custom firmware.
Ah I didn't see anything mentioned about loading the kernel module 'kmon-mtd-rw' in any recovery publication.
I will give a 'modprobe mtd-rw' a go !
I am able to load Netgear's recovery Linux (uImage-recovery - downloaded from Netgear's website) uImage from USB and can write to the mtd from there.
When I boot Netgear's recovery I do see a 'plausible' fw_printenv output. I will try to overwrite the u-boot region with the original Netgear u-boot today. See where it gets me.
I guess I must make a dump of the 0x20000 region to backup the environment vars first, then overwrite u-boot and later restore the 0x20000 region ?
I have a unit with the vendor firmware on it. If needed I’m willing to share a backup. If you still need it, just let me know.
I think I managed to at least get back into the basic u-boot today:
I followed these steps:
Made a USB recovery stick with these files:
initrd-recovery.gz (Netgear)
tools (OpenWrt - tar zxf linux-tools-installation-bodhi.tar.gz)
u-boot.bin (Netgear)
uImage-recovery (Netgear)
uboot.bin (Netgear)
Boot the ReadyNAS V2 using kwboot using Netgear's u-boot.bin over serial:
./kwboot -t -B 115200 /dev/ttyUSB0 -b netgear/u-boot.bin -p
Press both the Power and Backup buttons around the 95% mark, keep pressing.
Wait till the serial output of the u-boot starts appearing. Let go of the buttons.
Recovery image is loaded in memory and tries to recover.
It drops into root shell quite soon, but at least it has the /dev/mtd* partitions available in read/write mode. Plus it seems to have the environment vars restored in flash. Good deal.
From inside the recovery image I did (ref: https://forum.doozan.com/read.php?3,74954):
The devil seemed to be in the details here: I needed the -n option for no-ecc and -p option for padding.
I was finally able to write /dev/mtd0
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
Sounds promissing.
Requesting system reboot
Restarting system.
�
__ __ _ _
| / | __ _ _ ____ _| | |
| |/| |/ _` | '\ \ / / _ \ | |
| | | | (| | | \ V / __/ | |
|| ||_,|| _/ _|||
| | | | | __ ) ___ ___ | |_
| | | || _ \ / _ \ / _ | __|
| || || |) | () | () | |_
_/ |____/ _/ ___/ __|
** MARVELL BOARD: DB-88F6282A-BP LE
U-Boot 1.1.4 (Mar 30 2011 - 17:54:31) Marvell version: 3.4.27
USISH-SMB Ver: topkick1281p2-001-007-20101210
U-Boot code: 00600000 -> 0067FFF0 BSS: -> 006CFD40
Soc: MV88F1155 Rev 1 (DDR3)
CPU running @ 1600Mhz L2 running @ 533Mhz
SysClock = 533Mhz , TClock = 200Mhz
DRAM unknown CAL tRP = 8 tRAS = 20 tRCD=8
DRAM CS[0] base 0x00000000 size 256MB
DRAM Total size 256MB 16bit width
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
NAND:128 MB
Plug On and Power down, Please Switch On !
U-Boot is back.
After booting from TFTP again and doing a 'sysupgrade -v' the system automatically tries to boot the new kernel again at power on.
Only to find out the kernel CRC (NAND dementia or kernel obesity ?) error at boot was back:
Reading data from 0x7ff800 -- 100% complete.
6291456 bytes read: OK
Image Name: ARM OpenWrt Linux-5.15.127
Created: 2023-08-19 14:01:06 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 6550902 Bytes = 6.2 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... Bad Data CRC
Saving Environment to NAND...
Erasing Nand...Writing to Nand... done
sysupgrade-netgear_readynas-duo-v2# l
total 70156
drwxr-xr-x 2 root root 4096 Aug 19 15:01 .
drwxr-xr-x 3 root root 4096 Aug 30 12:57 ..
-rw-r--r-- 1 root root 30 Aug 19 15:01 CONTROL
-rw-r--r-- 1 root root 6550966 Aug 19 15:01 kernel
-rw-r--r-- 1 root root 65270784 Aug 19 15:01 root
I figure the root cause of my CRC error at boot is the kernel size and not the NAND flash.
I do have quite some filesystems NFS, EXFAT, NTFS, etc, etc, linked in hard.
Problem solved.
Another question:
Which modern u-boot file can I use for this Netgear ? I would love to get rid of the 'Please switch on' and have the system auto boot on power on.