Thanks. I have been waiting for these for over a year...

I currently have WZR-1750DHP and R6300v2, and I can help test these models if it is helpful. Also I have a WZR-600DHP2 which uses a BCM4707 (arm), if there's any support plan on this model, I'd also like to help test it.

It's BCM47081A0, not BCM4707 like DD-WRT wiki says.

I've just added initial support for this device (https://dev.openwrt.org/changeset/42925/). It's actually the easiest Broadcom ARM device to support, as it uses 802.11n WiFi cards only.

Unfortunately, we sill miss a nice NAND support, it's on my list...

If squashfs on NAND still unstable, why don't using squashfs on RAMDisk? I think R6300v2 have enough RAM to hold whole root filesystem. Keep NAND partitions only for jffs2 mount on /jffs or /opt.

So i take a look into my R6300v2 dd-wrt box:

root@R6300v2:~# free
             total         used         free       shared      buffers
Mem:        255392        57480       197912            0         7740
-/+ buffers:              49740       205652
Swap:       251964            0       251964
root@R6300v2:~# mount
rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro,relatime)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
ramfs on /tmp type ramfs (rw,relatime)
none on /dev type tmpfs (rw,relatime,size=512K)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
devpts on /proc/bus/usb type usbfs (rw,relatime)
/dev/mtdblock/5 on /jffs type jffs2 (rw,relatime)
/dev/sda1 on /opt type ext4 (rw,relatime,data=ordered)
root@R6300v2:~# df -m
Filesystem           1M-blocks      Used Available Use% Mounted on
rootfs                      19        19         0 100% /
/dev/root                   19        19         0 100% /
/dev/mtdblock/5             96         3        93   3% /jffs
/dev/sda1                  709         4       653   1% /opt
root@R6300v2:~#

/dev/root and rootfs just the same size, but diffrent file system squashfs and rootfs
it just like
mount -t squashfs /rootimg.squashfs /

(Last edited by nobk on 18 Oct 2014, 11:19)

Because it's not clean solution in general. We prefer to avoid wasting RAM.

Anyway, it doesn't matter anymore. I've added UBI support few days ago to the bcm53xx:
https://dev.openwrt.org/changeset/42937/
https://dev.openwrt.org/changeset/42938/
https://dev.openwrt.org/changeset/42939/
https://dev.openwrt.org/changeset/42940/
https://dev.openwrt.org/changeset/42941/

If you install snapshot firmware from https://downloads.openwrt.org/snapshots/trunk/bcm53xx/ , it'll use UBI with rootfs (SquashFS) and rootfs_data (UBIFS).

One important thing left to do is sysupgrade. We should think about a way do upgrade firmware without loosing UBI wearing level.

(Last edited by Zajec on 18 Oct 2014, 11:06)

R6300V2 have enough memory to be wasted,  I still have  197912 free but total is 255392.
And RAMDISK rootfs will running much faster than in NAND.

(Last edited by nobk on 18 Oct 2014, 11:26)

It's open source, you're free to drop UBI, UBIFS, use initramfs, compile it on your own, do whatever you want.

UBIFS is cool

Zajec,

any idea what's going on with 2.4 radio with the latest build? I tried r43006 and I still cannot get wifi to start on my r6300v2:

root@OpenWrt:/etc/config# logread -f
Tue Oct 21 02:52:05 2014 daemon.notice netifd: radio0 (1145): Configuration file: /var/run/hostapd-phy0.conf
Tue Oct 21 02:52:05 2014 daemon.notice netifd: radio0 (1145): Could not set interface wlan0 flags (UP): Cannot assign requested address
Tue Oct 21 02:52:05 2014 daemon.notice netifd: radio0 (1145): nl80211: Could not set interface 'wlan0' UP
Tue Oct 21 02:52:05 2014 daemon.notice netifd: radio0 (1145): nl80211 driver initialization failed.
Tue Oct 21 02:52:05 2014 daemon.notice netifd: radio0 (1145): hostapd_free_hapd_data: Interface wlan0 wasn't started
Tue Oct 21 02:52:05 2014 daemon.notice netifd: radio0 (1145): cat: can't open '/var/run/wifi-phy0.pid': No such file or directory
Tue Oct 21 02:52:05 2014 daemon.notice netifd: radio0 (1145): Command failed: Invalid argument
Tue Oct 21 02:52:05 2014 daemon.notice netifd: radio0 (1145): Device setup failed: HOSTAPD_START_FAILED

Our driver that reads & parses NVRAM still doesn't support wireless entires on ARM machines. You may try to assign manual MAC as a quick workaround.

ifconfig wlan0 hw ether AA:BB:CC:DD:EE:FF

I plan to work on this, but my last SPROM/NVRAM changes were missed for the 3.18-rc1 release which doesn't simplify things.

Hmmm..

It doesn't seem to find wlan0

root@OpenWrt:~# ifconfig wlan0
ifconfig: wlan0: error fetching interface information: Device not found
root@OpenWrt:~# iwinfo wlan0 info
No such wireless device: wlan0
root@OpenWrt:~# iwinfo radio0 info
radio0    ESSID: unknown
          Access Point: 00:00:00:00:00:00
          Mode: Unknown  Channel: unknown (unknown)
          Tx-Power: unknown  Link Quality: unknown/70
          Signal: unknown  Noise: unknown
          Bit Rate: unknown
          Encryption: unknown
          Type: nl80211  HW Mode(s): 802.11bg
          Hardware: unknown [Generic MAC80211]
          TX power offset: unknown
          Frequency offset: unknown
          Supports VAPs: no  PHY name: phy0
root@OpenWrt:~# lspci -nn -k
0000:00:00.0 PCI bridge [0604]: Broadcom Corporation Device [14e4:8011] (rev 01)
0000:01:00.0 Network controller [0280]: Broadcom Corporation BCM4331 802.11a/b/g/n [14e4:4331] (rev 02)
        Subsystem: Broadcom Corporation BCM4331 802.11a/b/g/n [14e4:4331]
        Kernel driver in use: bcma-pci-bridge
0001:00:00.0 PCI bridge [0604]: Broadcom Corporation Device [14e4:8011] (rev 01)
0001:01:00.0 Network controller [0280]: Broadcom Corporation Device [14e4:4360] (rev 03)
        Subsystem: Broadcom Corporation Device [14e4:4360]

I just received a R6300v2.

@tusc, thanks for the explanation. have you had any luck with the data persistence with the UBI images?

@zajec, just read a bit up on UBI, if I understand well it works in the following way:

raw flash -> MTD -> UBI -> UBIFS

UBI layer does wear-leveling and bad-block management. If i understand well, wear-leveling means that it keeps all the erase blocks at the same erase level via the Erase Counter ( EC ) in the UBI header. If the wear level is aprox. the same for all erase blocks not sure why we need to keep it over the upgrades. I assume the flashing happens at the mtd level, so the UBI headers are getting overwritten and all will start from 0, which is good because we are again at an average level with all blocks, but we lost the old level. Do we really need that level? or we just want all the blocks to be at the same level.
I've got another question in my mind, regarding bad-blocks. if the bad-blocks are know at UBI level, and flashing happens at MTD level, how will the flashing avoid the bad-blocks?

the UBI doc says ( http://www.linux-mtd.infradead.org/doc/ … bi_headers ) :
UBI stores 2 small 64-byte headers at the beginning of each non-bad physical eraseblock:

    erase counter header (or EC header) which contains the erase counter of the physical eraseblock (PEB) plus some other not so important information;
    volume identifier header (or VID header) which stores volume ID and logical eraseblock (LEB) number this PEB belongs to (plus some other not so important information).

maybe the fact that an UBI header is missing helps us identifying the bad-blocks.

I guess it's more complicated. Go, ask UBI developers.

I dug a bit deeper. i guess one solution is to do the flashing at UBI level instead of mtd level as it's done currently, this way all the ubi data will be preserved. I understood ubi comes with a tool ubiupdatevol which flashes and image to an ubi volume :

ubiupdatevol -t /dev/ubi0_0  - wipes a volume
ubiupdatevol /dev/ubi0_0 /path/to/ubifs.img - flashes ubifs.img to /dev/ubi0_0 ( which needs to be empty ).

some rework is required on the sysupgrade script.

got a question in mind about the kernel options.
I guess we flash only kernel and rootfs partitions, and don't touch the bootloader.
if I understood it well, the bootloader loads the kernel from a hardcoded address, but if we don't touch the bootloader, how can we pass options to the kernel? on X86 systems this is done through the bootloader.

This part is trivial. Unfortunately kernel partition is separated from UBI and this is the hard part.

Correct.

What options do you want to pass? Kernel can be compiled with default options, see

grep -H CMDLINE target/linux/brcm47xx/config-*

CFE doesn't pass any options itself.

bootloader doesn't support  UBI volumes? what kind of bootloader is the CFE?

is there a way to flash new bootloader?

thanks. I was just wondering how are the options passed to kernel.

Define "kinds" of bootloaders.

Yes, you can write to any part of the flash.

I meant it's a u-boot or something else?
this is all related to the first question, if the boot loader supports ubi volumes.
if it doesn't I guess the only way is to rewrite the bootloader with one which knows UBI volumes , and then we can flash the kernel partition as well on ubi volume. Am I getting this correct?

I understood u-boot knows ubi volumes.

No, it's CFE. CFE doesn't support UBI / UBI volumes.
It would be nice to have U-Boot supporting Broadcom boards, but this will require a lot of work.
I don't know how well U-Boot supports UBI.

Hi Guys,

I've just flashed the CC-RC3 on a R6300v2, and for some reason, on 2.4Ghz the range is like 2m, on channles 1-11. on channels 12-13 it works as it should, but unfortunately, not all the devices see the channels above 11.
What could I do to have channles 1-11 working properly? with the original fw, it was working properly.

I compile openwrt for NETGEAR 6300 on ubuntu but when I make menuconfig there is no NETGEAR 6300 in Target Profile.why and how can I solve it? I see in the link "https://downloads.openwrt.org/latest/bc … uashfs.chk" there has supplied the fireware,Does it support OpenFlow?If it dose,which version it supports ?

Any news regarding the r6300v2 support ? Is WLAN now working or just wired ? Thanks for update!

No one? ;(

I don't know if this is up to date, but there is a status page
https://wiki.openwrt.org/toh/netgear/netgear_r6300_v2

Looking back on this thread, it seems the fact that the router uses NAND flash was a problem.  I would have hoped that this was fixed by now because it is a problem that would affect many routers.

(I have one of these, running Netgear's firmware.  I'm lazy, but I would switch to OpenWRT if it were known to work well.)

It didn't work for me, I tried CC, it doesn't see 5GHz radio at all, and 2.4GHz range after 1 cold reboot is like 2m. so useless if you need wifi. I tried Kong's dd-wrt and both radios work very well with his drivers. I'd like to build an image with the wl drivers taken from the dd-wrt sources, but not sure how to do it. If someone could give some directions, would be highly appreciated, so we could benefit of the great hardware inside this router and great fw ( openwrt ).

Ask & get GPL wl.ko sources.