OpenWrt Forum Archive

Topic: Semi-support for Netgear R6220

The content of this topic has been archived on 24 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi there, I just got a new Netgear R6220 and has been trying to port OpenWrt 15.05(-rc3 then) to the device. I'm new to porting OpenWrt and this is the first device I've tried porting to.

This router has an MT7621S, single core running on 880MHz. And it has 128MB RAM / 128MB NAND Flash, 4x1Gbps LAN, 1x1Gbps WAN, 1xUSB 2.0, 2x2 for both 2.4G and 5G (300M+867M). That should be a good spec.

Here is the my modifications, now rebased onto 15.05 stable: https://github.com/updateing/openwrt-r6220 (r6220 branch)
Some patches required to get mtk_nand.c compile in kernel 3.18: http://www.hastebin.com/epagulozuj.coffee

The ecc wrapper is to force reading via mtk_nand_read_page. Similar hack is adopted in Netgear's kernel source and MTK OpenWrt SDK (nand_base.c)

You will need TTL to write the sysupgrade.bin into flash:

TTL is J4 on the top side of the board, RX NC TX GND from left to right when LEDs are facing towards yourself.

1. Attach a pull-down resistor between RXD and GND on the TTL-USB converter.
2. Set 57600, 8-N-1
3. Press Ctrl-C when prompted
4. Set computer's IP address to 192.168.1.123
---Type into serial console ---

tftpboot 0x85000000 sysupgrade.bin
nand erase 0x200000 0x2000000
nand write 0x200000 0x85000000 <HEX_LENGTH_OF_BIN_FILE>
reset

------
0x200000 is where Kernel partition starts. 0x2000000 is Kernel+Rootfs. See the partition table below.
It works, but there is one question: Is 0x85000000 a proper address to store the firmware in memory? Will it overwrite something UBOOT requires?

From my tests, these things are working:

booting into system
LAN/WAN correct partitioning
LuCI
5G WiFi with pretty good signal strength (at least much better than MTK OpenWrt SDK)

These are not working:

2.4G WiFi (probably no driver)
after rebooting, rootfs refuses to mount (squashfs: unable to read id index table)
^^^^^ This may be due to faulty flash chip and/or NAND driver, see below.

However, my router has some bad blocks in most used area of NAND flash, and the MTK NAND driver and/or my changes are(may be) faulty as well. These add up together to get the router bricked. There is no TTL output. Connected LAN ports have its LED on and blinking. WPS LED gives out weak light. No other LED is on. That's all I can find.

I will describe what happened on my router:

Let's be clear about what's on the chip:
Partition table in Netgear firmware:

dev:    size   erasesize  name
mtd0: 00100000 00020000 "Bootloader"
mtd1: 00100000 00020000 "SC PID"
mtd2: 00400000 00020000 "Kernel"
mtd3: 01c00000 00020000 "Rootfs"
mtd4: 00200000 00020000 "English UI"
mtd5: 00200000 00020000 "ML1"
mtd6: 00200000 00020000 "ML2"
mtd7: 00200000 00020000 "ML3"
mtd8: 00200000 00020000 "ML4"
mtd9: 00200000 00020000 "ML5"
mtd10: 00100000 00020000 "Factory"
mtd11: 00100000 00020000 "SC Private Data"
mtd12: 00200000 00020000 "POT"
mtd13: 00200000 00020000 "Traffic Meter"
mtd14: 00200000 00020000 "DPF"
mtd15: 00200000 00020000 "SC Nvram"
mtd16: 00200000 00020000 "Ralink Nvram"
mtd17: 00200000 00020000 "Ralink Reserved"
mtd18: 00200000 00020000 "ML6"
mtd19: 00200000 00020000 "Upgrade Flag"
mtd20: 00200000 00020000 "Reserved Block3"
mtd21: 03c00000 00020000 "Reserved Block4"

Partition table in my OpenWrt port:

[    2.810000] Creating 3 MTD partitions on "MT7621-NAND":
[    2.820000] 0x000000000000-0x000000100000 : "uboot"
[    2.830000] 0x000000200000-0x000002200000 : "firmware"
<!-- I added some log here so it takes 13sec -->
[   15.700000] 2 uimage-fw partitions found on MTD device firmware
[   15.710000] 0x000000200000-0x000000340000 : "kernel"
[   15.730000] 0x000000340000-0x000002200000 : "rootfs"
[   15.740000] mtd: device 3 (rootfs) set to be root filesystem
[   15.750000] 1 squashfs-split partitions found on MTD device rootfs
[   15.760000] 0x000001460000-0x000002200000 : "rootfs_data"
[   15.770000] 0x000002d00000-0x000002e00000 : "factory"
[   15.780000] [mtk_nand] probe successfully!

Actually, I have
0x000000000000-0x000000100000 : "uboot" (= Bootloader in stock firmware)
0x000000200000-0x000002200000 : "firmware" (= Kernel + Rootfs)
0x000002d00000-0x000002e00000 : "factory" (= Factory)

Bad block is listed as:

[    2.490000] Scanning device for bad blocks
[    2.520000] Bad eraseblock 110 at 0x000000dc0000
[    2.730000] Bad eraseblock 843 at 0x000006960000

After the system was up, I could use serial console and telnet/SSH freely without any problem. But LuCI was not responding. I could only see a black page with white "LuCI - Lua Configuration Interface" and stick on "Waiting for 192.168.1.1". The CPU load went high simultaneously with nearly 90% IO occupation. No LuCI process was eating CPU. Some logs about jffs2 creating filesystem and found bad blocks showed up in dmesg. After some time LuCI started working.
After a reboot, rootfs refused to mount with "squashfs: unable to read id index table".
I found that index table was in the last block of rootfs partition. So I rebooted again into UBOOT and executed the following commands:

# Behavior with bad blocks is inconsistent between UBOOT and Linux kernel. I was trying to figure that out.
nand read 0xdc0000 4
nand read 0xdbfffe 4
nand read 0xde0000 4
nm.l 0x84000000
# write 0x00000000 to 0x84000000
nand write 0xdc0000 0x84000000 4
nand read 0xdc0000 4
nand read 0xde0000 4
# same result for last two commands:
# UBOOT will NOT shift read requests for blocks after a bad block, though it will write data to next good block
nand write 0xdbfffe 0x840000000 4
nand read 0xde0000 4
# 0xde0000 has 3 zero bytes at its beginning, comfirms the conclusion above
# the modified Linux driver will shift the requests automatically to create a continuous address space
nand read 0x1460577 8
# appears 0x1440577 under Linux due to shifting after bad block. This is where squashfs' id table lays
# returns FF FF FF... incorrectly erased?
nand read 0x1480000 8
# this is 0x1460000 under Linux, where rootfs_data/jffs2 starts
# returns:
# Skip bad block for read: 0xa4
# Skip bad block for read: 0xa5
# ...
# Skip bad block for read: 0x110
# some FF FF FF...
# there weren't so many blocks before. That thrilled me.
nand write 0x200000 0x85000000 <HEX_LENGTH_OF_BIN_FILE>
# returns a pile of bad blocks. Only 0xdc0000 before.
nand init
# some errors about data buffer not aligned, but probe succeeded at last
reset
# no more characters appearing on screen

Now I could not find out what bricked my router. The bad blocks went out of nowhere. And there was not a single message about block 0 being bad, but UBOOT just refuses to start. Or did I write something bad into memory (0x84000000 and 0x85000000) and UBOOT/NAND operations got corrupted?

I will try to fix the flash in a few days and see how the UBOOT corrupted the flash. Maybe that would help fix the NAND driver.

If anyone would like to help continue developing this port, that would be nice. Thanks in advance.

The patch of mtk_nand.c seems incomplete and it's likely that the corrupted flash is related to the patch. Please focus on the patch before you flash the firmware to your device.
nand_base.c in MTK SDK has a lof ot #if defined(CONFIG_MTD_MTK_NAND) but I didn't port them all. Just wrote a ecc wrapper now.

Something interesting in MTK's mtk_nand.c:

(mtk_nand_probe)
#ifndef NAND_JFFS2_WORKAROUND
    nand_chip->ecc.write_oob = mtk_nand_write_oob;
#else
    nand_chip->ecc.write_oob = NULL;
#endif

I didn't port this. What is this workaround for? I know JFFS2 read/writes OOB though...

Hi updateing,

I have this router now. I am trying to bring up openwrt on it. Can you please tell me what is the status of your development. Are you able to bring up 5GHz completely? I want to help you bring this up and test it.

rangarajub wrote:

Hi updateing,

I have this router now. I am trying to bring up openwrt on it. Can you please tell me what is the status of your development. Are you able to bring up 5GHz completely? I want to help you bring this up and test it.

The router was bricked due to some hardware issue (TTL reported that NAND chip was malfunctioning when I was loading image from network, and there was no TTL output after reboot), so I gave up porting.

Hi Updateing,

I am sorry to hear that. If you still have that piece with you, can you please send me a picture of the TTL serial cable modifications you made on the board. Also can you please send me the make of TTL-USB serial cable you ordered for this board.

(Last edited by rangarajub on 4 Jul 2016, 11:39)

Hi,

I'm wondering if there is anyone still interested in this device... I have some good news though.

I tried to fix my router by using an SPI flash, and successfully ported LEDE to it. 2.4G and 5G both works, MAC addresses are correct, and LEDs all work as expected. Sources are at ht-tps://github.com/updateing/lede-r6220-spi/tree/r6220-spi . I don't know it there is any stability issue, so use it with caution...

Hope this helps other people who is trying...

The discussion might have continued from here.