OpenWrt Forum Archive

Topic: Netgear R6300 supported? (and if not, how can I help?)

The content of this topic has been archived between 17 Oct 2017 and 20 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

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.

Zajec wrote:

In next few days there will be experimental firmware for R6300 V2 (the BCM4708 ARM version, not the BCM4706 MIPS) under following URL:
http://downloads.openwrt.org/snapshots/trunk/bcm53xx/

If someone wants to help, make sure you have serial console, connect it and then install firmware from the above URL. Please provide the booting log.
If the OpenWrt boots correctly, you can help and find out GPIOs responsible for all LEDs and buttons, see: http://wiki.openwrt.org/doc/devel/add.new.device#gpios

ecore wrote:

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

Zajec wrote:
ecore wrote:

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)

nobk wrote:

If squashfs on NAND still unstable, why don't using squashfs on RAMDisk? I think R6300v2 have enough RAM to hold whole root filesytem.

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.

Zajec wrote:
nobk wrote:

If squashfs on NAND still unstable, why don't using squashfs on RAMDisk? I think R6300v2 have enough RAM to hold whole root filesytem.

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 nobk on 18 Oct 2014, 11:26)

nobk wrote:

R6300V2 have enough memory to be wasted,  I still have  197912 free but total is 255392.

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.

Zajec wrote:

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

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

@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.

nroberto13 wrote:

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

nroberto13 wrote:

i guess one solution is to do the flashing at UBI level instead of mtd level as it's done currently

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

nroberto13 wrote:

I guess we flash only kernel and rootfs partitions, and don't touch the bootloader.

Correct.

nroberto13 wrote:

how can we pass options to the kernel? on X86 systems this is done through the bootloader.

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.

Zajec wrote:

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

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

Zajec wrote:
nroberto13 wrote:

I guess we flash only kernel and rootfs partitions, and don't touch the bootloader.

Correct.

is there a way to flash new bootloader?

Zajec wrote:
nroberto13 wrote:

how can we pass options to the kernel? on X86 systems this is done through the bootloader.

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.

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

nroberto13 wrote:

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

Define "kinds" of bootloaders.

nroberto13 wrote:

is there a way to flash new bootloader?

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.

nroberto13 wrote:

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? ;(

IngoPan wrote:

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

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

nroberto13 wrote:

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.