Hi!
Isn't there at least some kind of "test build" somewhere around?
The content of this topic has been archived between 8 Feb 2018 and 2 May 2018. Unfortunately there are posts – most likely complete pages – missing.
Hi!
Isn't there at least some kind of "test build" somewhere around?
Any news?
Hi, I´ve sucessfully build image with GPL NETGEAR firmware, as a result I have an openwrt sysupgrade firmware , but now I can´t not flash into the device ( WNDR3700v4 ) . I´ve investigated and seems that I need to generate a factory openwrt firmware, but anyone knows how is possible ? I´m reading about openwrt build generator but is not clear for me..
The NETGEAR GPL firmware is easy enough to build and flash to your device. The problem is that it is based on a very old version of openWRT (it's running kernel 2.6.31), and includes some binary kernel modules and packages to make it work (Ethernet driver, WLAN driver, etc). The busybox and kernel packages are also heavily modified to support the Atheros NAND flash, but what modifications were made to actually make that happen remain undocumented at this point.
If you're happy with an older version of openWRT with heavy hacks to the boot process/etc, then the Netgear GPL is workable... but if you want full modern openWRT my understanding is that somebody needs to figure out a driver/support for the NAND flash controller (and probably a few other bits and pieces).
Thanks for the response jolouis. as you mentioned GPL is easy to build , and i´m happy with the old kernel version of WRT. My problem is that I didn´t find a way to flash the image, as a result from building GPL I have a sysupgrade.bin that I was trying to flash using tftp but no success, do you know what other methods can work or as alternate how can I pass my sysupgrade image to a factory image ?
When you build the Netgear GPL image if you have done everything correctly you should see in the bin directory a file called "WNDR3400-V1.0.1.42.img" (might vary slightly depending on what version of the GPL SDK you downloaded). If you don't, re-run your build and double check to make sure things actually succeeded and you have the proper WNDR3400/WNDR4300 target selected. Don't be fooled, none of the other bin or image files in that directory are able to be flashed to the router.
Once you've got the WNDR3400 image file mentioned above, you can upload it to the router by using the bootloader's TFTP recovery. To do this, power on the router while holding the small reset button on the bottom. Keep holding it, and the power led will blink amber, then wait a few seconds, and finally start blinking green. Once it's blinking green, you can TFTP the .img file to 192.168.1.1
It's NAND flash, so the write process is pretty quick compared to other routers (usually < 30 seconds), but what I found is for some bizarre reason the router won't recognize the new firmware (it always gives an Atheros bus error), until you actually power the thing off and back on again. So after your TFTP upload, wait 45-60 seconds to be safe, then power the router off and on again. From that point you should be booting into your build.
One important thing to note here: the Netgear GPL firmware does a pretty nasty job of hijacking and fudging the normal openWRT boot process. The router also doesn't do the normal SquashFS/JFFS2 overlay filesystem that you'd expect: instead you get a readonly squashFS, a writeable JFFS2 on /apps (or something like that), and some proprietary "config" partition that holds all of the Netgear settings. With some work you can get it fairly close to the normal openWRT again, but all the steps to that are far beyond what I'd be able to write up.
(Last edited by jolouis on 4 Jul 2013, 17:09)
I'm currently trying to ubinize the ar71xx target, but I'm afraid I'll wipe the bootloader if I misconfigure UBI, so I'm kind of afraid to flash generated images
The patch (using trunk) is attached for anyone with a serial cable and more experience and confidence to review (please do) and test. I am fairly sure about the UBIFS_OPTS and UBINIZE_OPTS, as a block is 0x20000 (128KiB), and a page is 0x800(2048B), see also the OEM bootlog on the wiki.
diff --git target/linux/ar71xx/Makefile target/linux/ar71xx/Makefile
index f32c6a3..a64d67d 100644
--- target/linux/ar71xx/Makefile
+++ target/linux/ar71xx/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
ARCH:=mips
BOARD:=ar71xx
BOARDNAME:=Atheros AR7xxx/AR9xxx
-FEATURES:=squashfs targz mips16
+FEATURES:=squashfs ubifs targz mips16
CFLAGS:=-Os -pipe -mips32r2 -mtune=34kc -mno-branch-likely
SUBTARGETS:=generic nand
diff --git target/linux/ar71xx/config-3.10 target/linux/ar71xx/config-3.10
index 6c75f14..2556b08 100644
--- target/linux/ar71xx/config-3.10
+++ target/linux/ar71xx/config-3.10
@@ -120,8 +120,11 @@ CONFIG_CPU_R4K_CACHE_TLB=y
CONFIG_CPU_R4K_FPU=y
CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y
CONFIG_CPU_SUPPORTS_HIGHMEM=y
+CONFIG_CRC16=y
+CONFIG_CRYPTO_DEFLATE=y
+CONFIG_CRYPTO_LZO=y
+CONFIG_CRYPTO_XZ=y
CONFIG_CSRC_R4K=y
-CONFIG_DECOMPRESS_LZMA=y
CONFIG_DMA_NONCOHERENT=y
CONFIG_EARLY_PRINTK=y
CONFIG_ETHERNET_PACKET_MANGLE=y
@@ -185,6 +188,8 @@ CONFIG_IRQ_WORK=y
# CONFIG_LEDS_TRIGGER_NETDEV is not set
# CONFIG_LEDS_TRIGGER_TIMER is not set
# CONFIG_LEDS_WNDR3700_USB is not set
+CONFIG_LZO_COMPRESS=y
+CONFIG_LZO_DECOMPRESS=y
# CONFIG_M25PXX_USE_FAST_READ is not set
CONFIG_MARVELL_PHY=y
CONFIG_MDIO_BOARDINFO=y
@@ -204,10 +209,18 @@ CONFIG_MTD_M25P80=y
# CONFIG_MTD_MAP_BANK_WIDTH_1 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_4 is not set
CONFIG_MTD_MYLOADER_PARTS=y
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_ECC=y
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-2
CONFIG_MTD_REDBOOT_PARTS=y
+# CONFIG_MTD_SM_COMMON is not set
CONFIG_MTD_TPLINK_PARTS=y
+CONFIG_MTD_UBI=y
+CONFIG_MTD_UBI_BEB_LIMIT=20
+# CONFIG_MTD_UBI_FASTMAP is not set
+# CONFIG_MTD_UBI_GLUEBI is not set
+CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UIMAGE_SPLIT=y
CONFIG_MTD_WRT160NL_PARTS=y
CONFIG_MYLOADER=y
@@ -260,7 +273,14 @@ CONFIG_SYS_SUPPORTS_32BIT_KERNEL=y
CONFIG_SYS_SUPPORTS_ARBIT_HZ=y
CONFIG_SYS_SUPPORTS_BIG_ENDIAN=y
CONFIG_TICK_CPU_ACCOUNTING=y
+CONFIG_UBIFS_FS=y
+CONFIG_UBIFS_FS_ADVANCED_COMPR=y
+CONFIG_UBIFS_FS_LZO=y
+CONFIG_UBIFS_FS_XZ=y
+CONFIG_UBIFS_FS_ZLIB=y
CONFIG_UIDGID_CONVERTED=y
CONFIG_USB_ARCH_HAS_XHCI=y
CONFIG_USB_SUPPORT=y
+CONFIG_ZLIB_DEFLATE=y
+CONFIG_ZLIB_INFLATE=y
CONFIG_ZONE_DMA_FLAG=0
diff --git target/linux/ar71xx/image/Makefile target/linux/ar71xx/image/Makefile
index b755a9d..02b7146 100644
--- target/linux/ar71xx/image/Makefile
+++ target/linux/ar71xx/image/Makefile
@@ -9,6 +9,9 @@ include $(INCLUDE_DIR)/image.mk
JFFS2_BLOCKSIZE = 64k 128k 256k
+UBIFS_OPTS = -m 2048 -e 126KiB -c 4096
+UBINIZE_OPTS = -m 2048 -p 128KiB
+
define imgname
$(BIN_DIR)/$(IMG_PREFIX)-$(2)-$(patsubst jffs2-%,jffs2,$(patsubst squashfs-%,squashfs,$(1)))
endef
diff --git target/linux/ar71xx/image/ubinize.cfg target/linux/ar71xx/image/ubinize.cfg
new file mode 100644
index 0000000..49d55b9
--- /dev/null
+++ target/linux/ar71xx/image/ubinize.cfg
@@ -0,0 +1,14 @@
+[rootfs]
+# Volume mode (other option is static)
+mode=ubi
+# Source image
+image=root.ubifs
+# Volume ID in UBI image
+vol_id=0
+# Allow for dynamic resize
+vol_type=dynamic
+# Volume name
+vol_name=rootfs
+# Autoresize volume at first mount
+vol_flags=autoresize
+
(Last edited by Zsub on 25 Aug 2013, 16:51)
Any update on this patch??? this router deserves alot more attention it has great capacity and ram plus decent performance im running dd-wrt and am willing to test i just dont like to use linux to compile so if someone wants to compile a image ill gladly test
Nope, apparently there is no one more experienced who also owns this model and has time to comment on it
Although I have identified some possible biiig issues with that patch, mainly that it may break the normal overlay functionality quite horribly, but I'm not sure wether OpenWRT can cope with that.
I am not willing to provide binary builds, as those images may brick the router and I don't even feel comfortable installing them on my own device, because I am not quite sure I'd be able to recover from that brick. So for now pretty much no work is being done. Although I am going to buy a serial cable and fix the board headers so I can easily use it, but as for time, best if you now think: "that's going to be _at least_ another year"
However, anyone you may know who can judge this patch, please do send them here!
(Last edited by Zsub on 5 Sep 2013, 22:35)
Hi,
I'm new to OpenWRT development (not user, I run OpenWRT already for years, but so far I had a supported device :-)). However, I have experience with embedded linux development, including U-boot etc..
@dlang
I tried this too, when loading the initramfs using TFTP recover mode, the console says "File has bad checksum!" I suspect that this recovery mode is not ment to load this initramfs file.
The kernel built with latest git snapshot doesn't support the NAND at all, so you don't see any partition in Linux (/proc/mtd).
(@Zsub)
I then patched my tree with Zsub's patch and built a image. The initramfs still doesn't see the MTD partitions. Dmesg also doesn't show any MTD partition parsing output.
Netgears kernel shows this output:
Atheros on-chip NAND FLash Controller Driver, Version 0.1 (c) 2010 Atheros Communications, Ltd.
Ath Nand ID[878555a0]: 2c:f1:80:95:02
ONFI MICRON MT29F1G08ABADAWP
Micron NAND 128MiB 3,3V 8-bit [128MB]
12 cmdlinepart partitions found on MTD device ath-nand
This output is completly missing so I suspect that the SoC NAND Driver is missing...
Booting the initramfs is relativly easy, however you need to open your device... First build the image and copy it to your TFTP server (running at 192.168.1.2 and serving /srv/tftp/ in my case):
$ #build openwrt as documented
$ cd bin/ar71xx/
$ cp openwrt-ar71xx-generic-wndr4300-initramfs-uImage.bin /srv/tftp/wndr4300.img
Then I hooked up my device to the serial console to gain access to U-Boot. Press space to abort the automatic boot process and type these commands:
ar7240> setenv serverip 192.168.1.2
ar7240> setenv bootfile wndr4300.img
ar7240> tftpboot
....
ar7240> bootm
The kernel then successfully boots and drops me to a root shell.
Ok, needed to add one more kernel driver:
CONFIG_MTD_NAND_AR934X
The partitions are recognized:
[ 2.730000] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xf1 (Micron NAND 128MiB 3,3V 8-bit), 128MiB, page size: 2048, OOB size: 64
[ 2.740000] Scanning device for bad blocks
[ 2.850000] 12 cmdlinepart partitions found on MTD device ar934x-nfc
[ 2.860000] Creating 12 MTD partitions on "ar934x-nfc":
[ 2.860000] 0x000000000000-0x000000040000 : "u-boot"
[ 2.870000] 0x000000040000-0x000000080000 : "u-boot-env"
[ 2.880000] 0x000000080000-0x0000000c0000 : "caldata"
[ 2.880000] 0x0000000c0000-0x000000140000 : "pot"
[ 2.890000] 0x000000140000-0x000000340000 : "language"
[ 2.900000] 0x000000340000-0x0000003c0000 : "config"
[ 2.900000] 0x0000003c0000-0x0000006c0000 : "traffic_meter"
[ 2.910000] 0x0000006c0000-0x0000007e0000 : "kernel"
[ 2.920000] 0x0000007e0000-0x000001fc0000 : "rootfs"
[ 2.920000] mtd: partition "rootfs" set to be root filesystem
[ 2.930000] __nand_correct_data: uncorrectable ECC error
[ 2.930000] split_squashfs: error occured while reading from "ar934x-nfc"
[ 2.940000] 0x0000006c0000-0x000001fc0000 : "firmware"
[ 2.950000] 0x000001fc0000-0x000002000000 : "caldata_backup"
[ 2.950000] 0x000002000000-0x000008000000 : "reserved"
And I get a lot of these errors:
[ 23.420000] __nand_correct_data: uncorrectable ECC error__nand_correct_data: uncorrectable ECC error
I tried to do a read test, on the original firmware I get this output
md5sum /dev/mtdblock7
caaebae0814cee76def07b0d2b4d5a67 /dev/mtdblock7
On the new kernel, I get this:
[ 49.960000] __nand_correct_data: uncorrectable ECC error
[ 49.960000] __nand_correct_data: uncorrectable ECC error[ 49.970000] end_request: I/O error, dev mtdblock7, sector 0
[ 49.970000] Buffer I/O error on device mtdblock7, logical block 0
The driver looks broken (for this device)...
Good news: I think the driver works correctly, but the original driver didn't used the ECC feature.. When I erease a partition and do a md5sum, it works. When I do a md5sum of the same partition in the original firmware, I even get the same md5sum!
Next step is flashing and running the image. But as far as I can tell the on board U-Boot checks some magics on the kernel (0x33373033 same as CONFIG_WNDR3700V3?) as well as on the rootfs. The image header for the rootfs, is just before the actual partition, see here:
011ffc0 3337 3033 a041 3b05 50b3 4ec9 008b 0004
011ffd0 8000 2000 8028 2bc0 b75d 5d85 0505 0203
011ffe0 4d49 5053 204f 7065 6e57 7274 204c 696e
011fff0 7578 2d32 2e36 2e33 3100 0000 0000 0000
0120000
Ugly! The actual check is done by loadn_dniimg/chk_dniimg which seem to be Netgear specific commands.
But one can easily load/run the image without verification:
nand read 0x81000000 0x6c0000 0x120000
bootm
But saving custom environment variables is not possible in given u-boot :-(
Since I'm new to OpenWRT development, anybody knows if OpenWRT does such magic hacks in image generation? If yes, where is this code located? Any idea how to work around this issue?
I think those image headers are in the ar71xx/image/Makefile somewhere. For example, around "define Image/Build/CyberTAN", line 627, this code can be found:
-$(STAGING_DIR_HOST)/bin/addpattern -B $(2) -v v$(4) \
-i $(KDIR)/image.tmp \
-o $(call sysupname,$(1),$(2))
Also, the ubinize.cfg I posted as part of that horrible patch probably will not work when you flash it, as it only contains one partition and no overlay whatsoever. Viewing your MTD layout from the wiki (THANKS!!!) it seems like a good idea to use UBI on mtd8, initially. There are some issues with JFFS2 over UBI, an additional UBI-glue component needs to be installed. However, the image should boot even if no JFFS is present, I'd venture.
But you're the one actually managing to fix the mess I posted, so my hat's off to you
(Last edited by Zsub on 11 Sep 2013, 19:20)
Further to Zsub's comment, if you compare the Netgear GPL sources you'll find in their target they call some specific binary to generate the image, which I would guess adds the headers and funky things needed for the bootloader to accept it.
For the GPL source:
target/linux/wndr4300/image/Makefile:
define Image/Build/WNDR4300
..(does a bunch of stuff here)..
$(STAGING_DIR_HOST)/bin/mkdniimg \
-B $(MODULE_NAME) -v $(FW_VERSION) -r $(FW_REGION) -H $(HW_ID) \
-i $(call imgname,$(1),$(2))-sysupgrade.bin \
-o $(BIN_DIR)/$(MODULE_NAME)-$(FW_VERSION)$(FW_REGION).img
The mkdniimg command is what stands out, as that seems to be some strange binary that Netgear ships with the GPL code which I suspect adds the unusual headers to the image.
Notice that this mkdniimg is already used for other Netgear targets like the original WNDR3700... I suspect if you compare the build process for that specific device to what you're trying to implement you may be able to get things working.
Keep at it, looks like you're getting very close!
Thanks for the answers! I found that this funky header patching is already implemented since the initramfs needs it too. Its basically the same as before, just the numbers are slightly different...
The whole thing grew a bit since my last post. I could manage to flash a UBI/UBIFS root image and boot a kernel. However, still a long way to get a easily flashable image, since I did this manually and had to do several work arounds.
Read the technical detail in my E-Mail to the openwrt-devel mailing list:
https://lists.openwrt.org/pipermail/ope … 21351.html
This is how I did the actual flashing right now:
Patch the Sources with Zsub patch and add the additional kernel configuration CONFIG_MTD_NAND_AR934X
Generate the UBI image with enabled UBI tools (part of busybox)
Generate a Kernel with fixed cmdline (console=ttyS0,115200 board=WNDR4300 ubi.mtd=8 rootdelay=5 root=ubi0:rootfs rootfstype=ubifs mtdparts=...) and patched magic (taken from the intermediate files)
Opened the device, hookup serial console, enter U-Boot
Run the initramfs image (loaded through TFTP)
Erased partition mtd8
Create UBI volume
Flashed the UBIFS root filesystem to mtd8
Enter U-Boot again
Load the kernel over TFTP
Flash the kernel in U-Boot on mtd7
I now can start the kernel and have a running OpenWRT distribution. However, theres no overlay, and the root filesystem is read/writeable.
The default boot instructions check the root partitions CRC. But since I have a writeable filesystem there, this CRC would always change..
Therefor I have to currently manually boot the kernel. I'm not sure if its possible to overwrite the U-Boot environment, at least there are no such commands inside U-Boot.
I need advice from advanced developers how to proceed, since there are many ways to go now and I would prefer the way which will be accepted upstream :-)
One thing which I don't fully understand right now: How/when is the overlay done? Does the kernel boot first with the Rom rootfs and some init scripts does the overlay? Where are the relevant commands?
(Last edited by falstaff on 11 Sep 2013, 22:37)
@Zsub
Regarding MTD layout, you are welcome I really needed such a thing since I was about to mess with the Flash. One wrong number and you are screwed
One thing which I don't fully understand right now: How/when is the overlay done? Does the kernel boot first with the Rom rootfs and some init scripts does the overlay? Where are the relevant commands?
Overlay and rootfs mounting is handled by the preinit scripts located in /lib/preinit on the SquashFS partition usually. Take a look at the wiki entry for details:
http://wiki.openwrt.org/doc/techref/process.boot
I'm not sure of all the details on how that first SquashFS/rom usually gets mounted (I assume the bootloader does this somewhere somehow), but the preinit scripts are responsible for actually setting up the overlay and doing the pivot_root to it before the rest of the normal init continues.
I'm not sure where you're planning to go next, but it might be possible to add the WNDR4300 to the AR71XX makefile as a new machine/subtarget, similar to what exists for the WNDR3700 et al. You can add kernel command lines, MTD configurations,etc all there... It's a bit old now but try taking a look at the patch which added support for the old WNDR3700:
https://dev.openwrt.org/ticket/8727
On an side note, I would just like to ask if anyone can tell me why exactly all this UBI stuff is needed for NAND. My understanding was that the issue with NAND was that SquashFS would fail if the NAND controller reallocated blocks in response to bad ones.... Yet the Netgear GPL firmware still uses the normal SquashFS and JFFS2 (they don't use it an an overlay in the same way, but that's more their configuration choice than anything I believe). So is Netgear shipping a product that could brick the first time a block in NAND goes bad, or ??
Regarding NAND: JFFS2 has NAND support, so this is not the problem. Then, I don't think that the controller by itself does any relocating. As far as I understand, the bootloader does a simplistic approach of bad block handling: If write fails, it just takes the next block. If read fails, it just takes the next block too. Since new bad blocks usually come up upon writing, the bootloader can usually read a Squashfs image without errors. The question is, what happens if a block fails while reading? (according to http://wiki.openwrt.org/doc/techref/flash this can happen...)
The bootloader does a CRC check after loading the rootfs to RAM. So if this happens, this would end up in a CRC error and the router would switch to recovery mode. I guess this happens rare enough that Netgear can live with it.. So currently, to me it looks like Netgear uses this basic bad block handling along with the fact that squashfs is read only...
As I write this, it looks to me that doing exactly the same would the simplest way to bring OpenWRT to this router too. Although I would prefer a UBI solution. but since its quite hard to bring UBI on the router, it might be a start for now...
The UBI/UBIFS only solution (with a rw part overlaying a ro part, but both on the same UBI volume) would better in terms of bad block handling (it handles bad blocks even on read, it would relocate that block somewhere else). But UBIFS would need boot process changes (no CRC check on rootfs), either by replacing U-Boot with an altered one or writing a non standard environment.
For me it looks like there are two ways to go:
Stay close on Netgear's implementation and use squashfs/jffs2.
Go the idealistic way and use UBI/UBIFS. Since this would need a lot of changes anyway, we could even alter the MTD partition table, e.g. using the whole NAND (which would give as incredible amount of flash!!)
I just saw a post to the devel-list in which someone identifies a preferred way forward and explains some things quite nicely.
I even managed to reply
I also updated the wiki-page with some photos.
Maybe we should have a nice place where we can post the output from git-diff or somesuch, so we can always have the latest version of a patch without having to keep posting them here. Maybe a github gist?
I tried to buy stuff to attach a serial cable to my router, but the electronics shop that I previously held in high regard have slightly disappointed me. So you guys'll have to wait until tuesday before I can really contribute
(Last edited by Zsub on 15 Sep 2013, 08:47)
I have forked the OpenWrt trunk repo on Github, available read-only here: https://github.com/Zsub/openwrt
Ok, now I think I bricked my device... At least the device doesn't make it to the U-Boot prompt anymore:
WASP BootROM Ver. 1.1
Nand Flash init
ONFI: Control setting = 0xb44
hdr: [0xffffffff : 0xffffffff : 0xffffffff : 0xffffffff]
nand_load_fw: read 2097151 pages
ExcCode 03 -> TLB(store)
EPC bfc01328, BadVAddr ffffffff, Cause 0000000c, Status 10400006
R0 (r0) = 00000000 R8 (t0) = ffffffff R16(s0) = 00000023 R24(t8) = 2e070009
R1 (at) = 00000001 R9 (t1) = 000000c0 R17(s1) = 00000800 R25(t9) = bfc010f4
R2 (v0) = 000000ff R10(t2) = 000000ff R18(s2) = 00030000 R26(k0) = ffffffff
R3 (v1) = 00000001 R11(t3) = 000f1b40 R19(s3) = 00010000 R27(k1) = bd007bf0
R4 (a0) = ffffffff R12(t4) = 000003e6 R20(s4) = 00000800 R28(gp) = 2e670009
R5 (a1) = bd004010 R13(t5) = 00000500 R21(s5) = ffffffff R29(sp) = bd007f60
R6 (a2) = 000007ef R14(t6) = 26470009 R22(s6) = ffffffff R30(fp) = 00000000
R7 (a3) = ffffffff R15(t7) = 266b0009 R23(s7) = bd000000 R31(ra) = bfc055f0
[bd007f60] 0000002c bfc099c0 001fffff bfc09bb4
[bd007f70] ffffffff 02000040 ffffffff ffffffff
[bd007f80] 000007f0 14012201 00000023 bd000000
[bd007f90] 00030000 b8060004 bd000000 00000184
[bd007fa0] ffffffff bd000000 00000000 bfc00fd0
[bd007fb0] 28564c02 452a7b95 b7e00442 ce8a4326
[bd007fc0] e0ee1555 a0f23a6d a53ea1f4 7a70858a
[bd007fd0] e8d1318b efe91a8a bd007ff0 00000024
[bd007fe0] bd000000 bd007ff0 b8060004 bfc004fc
What happend? Well, after I turned on the ath79_nfc_set_swap_dma(true); option, I flashed my device using Linux. Things worked, that way. But I had still the issue, if I use U-Boot, I could not boot the system...
So I switched back to a Kernel without this option, and ended up in 179 bad blocks in the rootfs. Obviously, those were not really bad, but OOB data were corrupted while using the DMA swapped kernel... I could tell that those blocks showed data in the OOB area, while must good once showed just ff:
ar7240> nand dump.oob 0x0000009e0000
Page 009e0000 dump:
OOB:
85 19 ff ff 00 00 03 20
ff ff 08 00 ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
So I cleaned them using U-Boot nand erase clean (which clears the OOB data)
ar7240> nand erase clean 0x7e0000 0x17e0000
NAND erase: device 0 offset 0xc, size 0x7e0000 ath_nand_erase: 0xc 63 62Skipped 0 bad blocks
OK
*ouch!* I should have stopped at that very moment, since as you can see, U-boot parsed this command wrong, offset 0xc is not what I typed!!
However, I started OpenWRT Linux once again using the Initramfs image. I still got those Bad Blocks! I think linux maintains its own table (called BBT, see http://www.linux-mtd.infradead.org/tech … /x144.html). I issued "mtd erase rootfs", but didn't help since Linux don't erase bad blocks... I then rebooted and get the output above...
Btw, as Zsub suggested on the mailing list, I compared the drivers a bit:
The current trunk has software ecc turned on (see target/linux/ar71xx/files/drivers/mtd/nand/ar934x_nfc.c, NAND_ECC_SOFT)
The GPL Linux Kernel has hardware ecc on, (ATH_NF_HW_ECC, see git_home/linux-2.6.git/drivers/mtd/nand/ath_nand.c)
The GPL U-Boot looks quite the same, hw ecc on (ATH_NF_HW_ECC, see git_home/u-boot.git/board/ar7240/common/ath_nand.c)
I think this difference prevents the kernel from using a U-Boot flashed rootfs. If we don't wan't to replace U-Boot on this device (which would be risky anyway) we need to alter our Linux Kernel NAND driver or use Linux (initramfs) to flash the rootfs.
I will try to recover from the whole situation using a JTAG programmer. Don't know if I can manage that, and if I'm patient enough doing it... The positive side: If I succeed, I don't have to fear another brick
DD-WRT has WNDR3700v4 support, which is essentially the same as the WNDR4300 but only 2T2R on 5GHz. If you want to sift through their code, there might be something to guide you. That said, I couldn't even find you a decent starting point since they are so disorganized.
*edit* there's a WNDR4300 build of DD-WRT too.
(Last edited by drawz on 17 Sep 2013, 04:24)
Ok, now I think I bricked my device...
[...]
I will try to recover from the whole situation using a JTAG programmer. Don't know if I can manage that, and if I'm patient enough doing it... The positive side: If I succeed, I don't have to fear another brick
Aww darn, that sucks! I'm keeping my fingers crossed for you.
I'm going to look and see if I can get hardware ECC enabled in OpenWrt, I'll push to the github repo I posted earlier.
That said, I couldn't even find you a decent starting point since they are so disorganized.
*edit* there's a WNDR4300 build of DD-WRT too.
Starting from their support of WNDR3700v4:
http://svn.dd-wrt.com/changeset/20751
http://svn.dd-wrt.com/changeset/20752
(WNDR3700v4 uses ROUTER_BOARD_WHRHPGN - see utils.c )
then NAND flash fixups: http://svn.dd-wrt.com/changeset/20753
https://dev.openwrt.org/changeset/38071
ar71xx: wndr4300: enable HW ECC mode for the NAND controller
While waiting for my parts to arrive so I can *finally* see the serial console, I'm trying some different combo's of ECC/not and see if perchance U-Boot will eat them via tftp. No luck yet