OpenWrt Forum Archive

Topic: WNDRv4 fit for openwrt - english

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 tongue

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 smile

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" wink

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 wink

(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:

  1. Patch the Sources with Zsub patch and add the additional kernel configuration CONFIG_MTD_NAND_AR934X

  2. Generate the UBI image with enabled UBI tools (part of busybox)

  3. 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)

  4. Opened the device, hookup serial console, enter U-Boot

  5. Run the initramfs image (loaded through TFTP)

  6. Erased partition mtd8

  7. Create UBI volume

  8. Flashed the UBIFS root filesystem to mtd8

  9. Enter U-Boot again

  10. Load the kernel over TFTP

  11. 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 smile I really needed such a thing since I was about to mess with the Flash. One wrong number and you are screwed yikes

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:

  1. Stay close on Netgear's implementation and use squashfs/jffs2.

  2. 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 big_smile

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 tongue

(Last edited by Zsub on 15 Sep 2013, 08:47)

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 smile

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)

falstaff wrote:

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 smile

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.

drawz wrote:

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 smile