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.

@Zsub, hm ,never tried that, but I guess it will do the same as the normal boot: Check the root filesystems CRC. This CRC checksum is currently not implemented in the OpenWRT toolchain. So we would need to add this header first to get it flashed...

But once you have it flashed, you will meet this other problem: Our kernel can't read the image which was flashed by U-Boot (and when you use TFTP, you actually flash the Firmware using U-Boot).

I don't think I will be able to unbrick my device... Maybe I will do the fastest unbrick method: Buy a new one hmm

But then, I'm not very attracted to do NAND driver hacks. This would need a reliable NAND clean command. This command  screwed my (first) router sad

@zloop, oh yes, this change looks promising.

(Last edited by falstaff on 22 Sep 2013, 21:41)

@Zsub, I created a own repository on my Github account, see https://github.com/falstaff84/openwrt/tree/wndr4300-ubi. In this branch I changed the Subtarget "nand" to generate UBI/UBIFS image including proper NAND support (including the new HW NAND support) for WNDR4300. I tested the initramfs, I still have some errors with the NAND driver, I wrote also on the mailing list about this...

(Last edited by falstaff on 23 Sep 2013, 21:38)

falstaff wrote:

@Zsub, I created a own repository on my Github account, see https://github.com/falstaff84/openwrt/tree/wndr4300-ubi. In this branch I changed the Subtarget "nand" to generate UBI/UBIFS image including proper NAND support (including the new HW NAND support) for WNDR4300. I tested the initramfs, I still have some errors with the NAND driver, I wrote also on the mailing list about this...

OK cool, I'll have a look at your repo. You obviously are slightly more experienced than I am tongue

Edit: hurr durr. This is not going to work if it is not possible to dd to the flash properly, of course.
I think it is a good idea to try Gabor's test from 17-09-2013, at 08:18. As soon as I get my USB->3.3v serial I'll try and do that, I got an email saying they packaged everything, no tracking code yet.

Gabor wrote:

I guess that it would be easy to figure out if the bootloader uses a different
OOB layout or not.

1. Flash an image from U-Boot.
2. Boot an initramfs based image, and read the image back via the 'nanddump'
utility including the OOB data.
3. Write the same image to the same partition from the initramfs based kernel.
4. Dump it again and check what is the difference in the OOB data between the two.

Second edit: I made two small pull requests at your repo.

(Last edited by Zsub on 24 Sep 2013, 15:39)

Hi all,

Thinks looking good right now. I could flash an image using stock U-Boot (factory reset/upgrade using TFTP). The root filesystem is UBIFS on UBI. Theres no overlay right now, so the rootfs is mounted read/write.

Check this out:
https://github.com/falstaff84/openwrt/tree/wndr4300-ubi

@Zsub, I tried to use the suggested (and I was also sure it was right) logical erase block size (LEB) of 126Kib. But when I tried to flash UBIFS on a in-kernel generated UBI volume, it did not work:

[ 1437.250000] UBIFS error (pid 1170): validate_sb: LEB size mismatch: 129024 in superblock, 126976 real

Therefor I use 124KiB now. However, 126KiB might work when we use ubinize/U-Boot to flash the image, however, I did not tried that.

Also note that I had to clean the rootfs partition first manually because UBI needs a clean partition!

nand erase 0x7e0000 0x17e0000
falstaff wrote:

@Zsub, I tried to use the suggested (and I was also sure it was right) logical erase block size (LEB) of 126Kib. But when I tried to flash UBIFS on a in-kernel generated UBI volume, it did not work:

[ 1437.250000] UBIFS error (pid 1170): validate_sb: LEB size mismatch: 129024 in superblock, 126976 real

Therefor I use 124KiB now. However, 126KiB might work when we use ubinize/U-Boot to flash the image, however, I did not tried that.

I suddenly realize that the LEB must be smaller than the Physical Erase Block because of course UBI uses a little space for the erase counter.

Not sure if it's relevant/helpful as I'm not an UBI person at all... but straight from the UBI FAQ:
http://www.linux-mtd.infradead.org/faq/ … z_mismatch

The error message means that LEB size information which is stored in the UBIFS superblock does not match the real LEB size, which UBIFS takes from UBI. The superblock was created by the mkfs.ubifs utility, therefore you failed to pass the correct LEB size to the utility. Fix this by passing correct LEB size via the -e option.

Maybe just a value missing in the UBIFS generation code? There's also a good section on how to use mtdinfo to validate all of the actual settings needed:
http://www.linux-mtd.infradead.org/faq/ … L_mkfubifs

Again you guys have probably done all of that and are well aware of it, but just wanted to link it in to be safe ;o)

jolouis wrote:

Not sure if it's relevant/helpful as I'm not an UBI person at all... but straight from the UBI FAQ:
http://www.linux-mtd.infradead.org/faq/ … z_mismatch

The error message means that LEB size information which is stored in the UBIFS superblock does not match the real LEB size, which UBIFS takes from UBI. The superblock was created by the mkfs.ubifs utility, therefore you failed to pass the correct LEB size to the utility. Fix this by passing correct LEB size via the -e option.

Maybe just a value missing in the UBIFS generation code? There's also a good section on how to use mtdinfo to validate all of the actual settings needed:
http://www.linux-mtd.infradead.org/faq/ … L_mkfubifs

Again you guys have probably done all of that and are well aware of it, but just wanted to link it in to be safe ;o)

Just to be sure I checked it (Falstaff's image did work though) and here is the output:

root@OpenWrt:/# mtdinfo -u /dev/mtd8
mtd8
Name:                           rootfs
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          191 (25034752 bytes, 23.9 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  2048 bytes
OOB size:                       64 bytes
Character device major/minor:   90:16
Bad blocks are allowed:         true
Device is writable:             true
Default UBI VID header offset:  2048
Default UBI data offset:        4096
Default UBI LEB size:           126976 bytes, 124.0 KiB
Maximum UBI volumes count:      128

@jolouis, yes I've seen that.. Its just that the default values when using UBI tools is 124KiB LEB size, and the initial patch of Zsub suggested 126KiB. I altered ubinize.cfg to use 124KiB, then the image can be used even when using the UBI tools to write the image to the NAND...

@Zsub, I just pushed another commit which should fix the build issue. The problem was that the squashfs image target was called before the UBIFS image was created by image.mk. Since I already had those UBIFS image already on my disk, I didn't realized that this was a problem. Now the image is generated in the UBI(FS) target. Did the WAN interface works on your router? I noticed once that I don't have a WAN interface around :-)


The whole ROM/overlayfs doesn't work with UBIFS right now since the userspace tools don't support it.

I also tried squashfs and jffs2 on UBI, both worked fine. I consider to look into that rather than fix the whole userspace, I think it would be the easier solution for now... The question is, in which target should generate such an image, since its a mix of all of it :-)

falstaff wrote:

@Zsub, I just pushed another commit which should fix the build issue. The problem was that the squashfs image target was called before the UBIFS image was created by image.mk. Since I already had those UBIFS image already on my disk, I didn't realized that this was a problem. Now the image is generated in the UBI(FS) target.

Yeah, I figured that was it, also commented via GitHub smile

falstaff wrote:

Did the WAN interface works on your router? I noticed once that I don't have a WAN interface around :-)

I haven't tested yet, I did notice the WAN led is always on, so I was suspicious. By the way, I have to reboot the device once after flashing it to make sure that the switch comes up properly, if I don't it doesn't accept any traffic via ethernet, but wifi works.

falstaff wrote:

The whole ROM/overlayfs doesn't work with UBIFS right now since the userspace tools don't support it.

I also tried squashfs and jffs2 on UBI, both worked fine. I consider to look into that rather than fix the whole userspace, I think it would be the easier solution for now... The question is, in which target should generate such an image, since its a mix of all of it :-)

A relatively simple way to have both ubi and ROM/overlay could be to pivot_root (http://wiki.openwrt.org/doc/howto/extro … cate.data2) onto a R/W partition we create in the reserved space (mtd12) and have rootfs read-only.

I have just bougt a WNDR3700v4, and want to run OpenWRT on it too.

If there is anything i can do, i would like to help in developing the firmware.
Ex. if you want to test the builds or similiar assistance.

(Last edited by neophyte on 17 Oct 2013, 14:51)

Hi,

Started to work again on this. I essentially manually rebased the changes on trunk. My old commits moved the nand subtarget first, but since the subtarget nand is nowadays called mikrotik, this is not necessary anymore. But this doesn't allowed a straight forward rebasing..

@Zsub, I saw all your changes but when I was at the point looking at them (and pulling them) I already rebased or developed in another direction. But your work and findings are definitely helpful!

A relatively simple way to have both ubi and ROM/overlay could be to pivot_root (http://wiki.openwrt.org/doc/howto/extro … cate.data2) onto a R/W partition we create in the reserved space (mtd12) and have rootfs read-only.

pivot_root is used by OpenWRT by default. But currently, ubox (the utility which does the magic) and some scripts are coded to create a JFFS2 partition on the device with the name rootfs_data, and uses that as overlay on the ROM (the device which is mounted initially, usually rootfs).


Things are working again on trunk, and I make use of the profile specific UBI settings introduced by Luka.

In my new branch called "wndr4300-nand-squashfs" the root MTD partition is now called ubiroot in order to solve autodetection issues (the kernel tried to split the MTD partition called rootfs). The UBI image consists now of two UBI volumes, the first wih a squashfs on it (called rootfs, which can be mounted using GLUEBI, it ends up as /dev/mtdblock12) and the data volume (rootfs_data, UBI, which ends up as /dev/mtdblock13). The layout looks like this now:

dev:    size   erasesize  name
mtd0: 00040000 00020000 "u-boot"
mtd1: 00040000 00020000 "u-boot-env"
mtd2: 00040000 00020000 "caldata"
mtd3: 00080000 00020000 "pot"
mtd4: 00200000 00020000 "language"
mtd5: 00080000 00020000 "config"
mtd6: 00300000 00020000 "traffic_meter"
mtd7: 00120000 00020000 "kernel"
mtd8: 017e0000 00020000 "ubiroot"
mtd9: 01900000 00020000 "firmware"
mtd10: 00040000 00020000 "caldata_backup"
mtd11: 06000000 00020000 "reserved"
mtd12: 0024d000 0001f000 "rootfs"
mtd13: 011ec000 0001f000 "rootfs_data"

The kernel should mount the MTD called rootfs directly, but this doesn't work, so I pass root=/dev/mtdblock12 to the kernel.

When starting this image, userspace tools try to format the rootfs_data using jffs2.

At first, I haven't compiled this filesystem, so this didn't succeed:

Thu Jan  1 00:00:18 1970 user.err syslog: No jffs2 marker was found
Thu Jan  1 00:00:18 1970 kern.emerg switch2jffs: No jffs2 marker was found
Thu Jan  1 00:00:18 1970 user.err syslog: no jffs2 marker found
Thu Jan  1 00:00:18 1970 kern.emerg switch2jffs: no jffs2 marker found
Thu Jan  1 00:00:18 1970 user.err syslog: failed - mount -t jffs2 /dev/mtdblock13 /rom/overlay: No such device
Thu Jan  1 00:00:18 1970 kern.emerg switch2jffs: failed - mount -t jffs2 /dev/mtdblock13 /rom/overlay: No such device
Thu Jan  1 00:00:18 1970 kern.emerg setting up led WAN (green)
Thu Jan  1 00:00:18 1970 kern.emerg setting up led USB
Thu Jan  1 00:00:18 1970 kern.emerg - init complete -

The code then falls back to a RAM based rootfs_data, which gets mounted and overlayed. So overlaying works.

When adding JFFS2 to the kernel configuration, everything works fine, the partition gets formatted and I have persistent storage!

Well, this should enable all our wishes feature wise, but technically its not a clean solution since we run JFFS2 on UBI, and using the GLUEBI layer which makes the whole a bit unclean.

Also from the image generation standpoint things are still dirty: Its now required to enable Squashfs and UBIFS as root filesytem since the UBI target is only called when UBIFS is enabled... This certainly needs cleanup.

In order to have UBIFS as rootfs_data, we would need to extend the ubox utilites (which provide switch2jffs) and some scripts and bring them to format the partition using UBIFS.

Code: https://github.com/falstaff84/openwrt/t … d-squashfs

@neophyte: I can send you an image if you're ready to take the risk. Flashing only works using factory reset (at least, I tried only that way so far). This worked already several times on my device, but I can not guarantee for anything... (in other words, it might break your device!)

I looked over your code, looks pretty ok. I'd suggest to clean up the steps for image generation and separate them further.

Also, have you seen the kernel size increase? Kufat on IRC noticed that the kernel lmza size was much bigger, especially ubifs takes 138 or something KB in the kernel, and at some point it will not fit in the kernel partition anymore. We can save a lot of space by choosing a single filesystem, I'd guess. Also, for the subtarget we can disable the automatic splitting of rootfs in squashfs and rootfs_data via make kernel_menuconfig.

Another consideration is that when flashing ubi/ubifs volumes it is preferable to save erase counters. We should use ubiformat or something like that for flashing to preserve them. It would probably be a good idea to get sysupgrade to support that way smile

As an aside, I'm currently sortakinda merging your (falstaff's) changes into my fork, but I'm going the UBI(FS) way all the way, disabling other filesystems and splitting of the rootfs and other such stuff and my router currently boots like lightning! It feels like tens of seconds faster during boot, although I'll have to verify that at some point smile

Awesome work @Zsub and @falstaff. Is there any update on the progress? I've been looking at the git pages. I'd like to try it.

Hi danielg,

Yes, most work is already upstream. Currently a factory image can be built which you can flash using the webinterface of the stock firmware  or the TFTP method.

The relevant commits were:

The board is supported in the NAND subtarget of the ar71xx target. You need to manually enable the subtarget since its still marked as broken. You can do this by editing the file target/linux/ar71xx/nand/target.mk and remove "broken" from FEATURES. You get the file "openwrt-ar71xx-nand-wndr4300-ubi-factory.img" in your output folder.

sysupgrade still doesn't work. Once you flashed the OpenWRT firmware, you need to use the TFTP Server method. See also the WNDR3700 installation description and the generic TFTP installation description.

--
Stefan

Cool! I may be blind, but I tried to svn the bleeding-edge and fetch the git repo of @Zsub, but I cannot seem to find the WNDR4300 profile in menuconfig.

Edit: Nevermind, found it.

(Last edited by danielg on 22 Nov 2013, 01:49)

@falstaff
I build a firmware from openwrt svn with default options, but WNDR3700 V4 says the firmware is not a valid firmware.
Did I need to modify any thing?

PS: I'm not a developer, just a user.


falstaff wrote:

Hi danielg,

Yes, most work is already upstream. Currently a factory image can be built which you can flash using the webinterface of the stock firmware  or the TFTP method.

The relevant commits were:

The board is supported in the NAND subtarget of the ar71xx target. You need to manually enable the subtarget since its still marked as broken. You can do this by editing the file target/linux/ar71xx/nand/target.mk and remove "broken" from FEATURES. You get the file "openwrt-ar71xx-nand-wndr4300-ubi-factory.img" in your output folder.

sysupgrade still doesn't work. Once you flashed the OpenWRT firmware, you need to use the TFTP Server method. See also the WNDR3700 installation description and the generic TFTP installation description.

--
Stefan

(Last edited by checksum on 24 Nov 2013, 11:27)

@falstaff

I want to try out this but before I take the plunge I wanted to confirm that will I be able to revert to Netgear stock from openwrt? I understand that this can only be done from the u-boot TFTP interface.

Thanks for your wonderful work.

Hi everyone.

I have checkout @falstaff 's repo: https://github.com/falstaff84/openwrt
When I build it with:

$ make menuconfig
  Target: Atheros AR7xxx/AR9xxx
  Subtarget: Ar71xx/AR913x based devices with NAND flash
  Target Profile: NETGEAR WNDR4300
$ make V=s

I got following error:

dd: opening '/home/jcz/tmp/openwrt/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/linux-ar71xx_nand/root.ubi': No such file or directory

Any ideas?

thks.

nijhawank wrote:

@falstaff

I want to try out this but before I take the plunge I wanted to confirm that will I be able to revert to Netgear stock from openwrt? I understand that this can only be done from the u-boot TFTP interface.

Thanks for your wonderful work.

This procedure worked for me when returning to stock (WNDR4300) from some other *wrt firmware. You may want to test the procedure to give yourself some experience prior to switching (ie: follow the procedure and flash from stock Netgear to stock Netgear as a test of the process).

  1. Manually set your PC's ip address to 192.168.1.x -- Not 1.

  2. Download the current Netgear firmware for the router.

  3. Download the TFTP2.exe utility and run.

  4. Disconnect all network cables except your PC from the router.

  5. In the TFTP utility:

    1. Set the SERVER field to: 192.168.1.1

    2. Set the PASSWORD field to: password

    3. Set the FILE field to: the current Netgear stock firmware file you downloaded earlier

  6. Press and hold the RESET button for 45 seconds, the green will light start blinking

  7. Click the UPLOAD button.

  8. After the firmware upload completes it will start the reboot cycle, wait at least 15 minutes.

  9. Unplug the power cable and wait 1 minute.

  10. Plug in the power cable.

This is essentially Netgear's process except that the reset and boot process are different with this model.

(Last edited by spencer on 4 Dec 2013, 22:19)

Hello,

first thanks for your work to support this device.

Can someone please give a copy of the .config file for the wndr 4300 v4, or are there any compiled images already out there?
I'm not sure for the correct compile options for the wndr 4300 v4...

thanks in advance!

I would also appreciate any download links for a pre-built image for this device! Thanks

Don't want to seem impatient but atm I have a v2 and a v4 and I'll be giving one away soon. Which one I'm getting rid of depends on on if openwrt will be coming to the v4. As far as I can tell from  this topic you guys do actually have a version of openwrt (not the netgear one) up and running and are mainly changing things so they work in the proper (non-hacky) way before the changes are made upstream? If so I'll keep the v4 because of the more powerful hardware.

I am really looking forward to a fully "working" support. Where is the current build located? is port-based vlan supported?

I was able to build and upload it to my WNDR4300.  The OS loaded and ran perfectly.

I am having a problem I had on dd-wrt on this router (also on a 3700v4) where I have massive amounts of packet loss over the switch, including the WAN.  The stock firmware does not have this problem.  I read something in the past that may indicate that the huge netmask my ISP uses (/22) could be the cause.  I'd be interested to hear if I am alone with this problem, but this is probably outside the scope of this thread however.

Update:
It looks like the port is going up/down with traffic:
root@router:/proc# swconfig dev switch0 port 5 get link
port:5 link:up speed:1000baseT full-duplex auto
root@router:/proc# swconfig dev switch0 port 5 get link
port:5 link:down
root@router:/proc# swconfig dev switch0 port 5 get link
port:5 link:down
root@router:/proc# swconfig dev switch0 port 5 get link
port:5 link:up speed:1000baseT full-duplex auto

(Last edited by TheAsp on 29 Dec 2013, 18:42)