@numero53 I deleted my last post since I was able to bring it back to life with UART so never mind that!
I built openwrt using @numero53 tree with RBS50 as a target.
Now I'm trying to flash my RBS50 (which I think might be v2) using nmrpflash but it keeps waiting for the device to respond and it never does. My next try was to then flash it using tftp which it does successfully but fails on boot with the following errors (read through the serial connection)
Loading DNI firmware for checking...
Loading firmware 1 ...
NAND read: device 0 offset 0x3280000, size 0x20000
131072 bytes read: OK
NAND read: device 0 offset 0x3280000, size 0x2a0000
2752512 bytes read: OK
dniimg_len is 2752512 (aligned to 2752512)
NAND read: device 0 offset 0x3280000, size 0x2a0000
2752512 bytes read: OK
if iminfo 0x84000000; then echo kernel checksum OK !;if iminfo 0x8429FFC0; then echo rootfs checksum OK !;boot_partition_set 1;true;else echo rootfs checksum error !!!;fw_recovery;false;fi;else echo kernel checksum error !!!;fw_recovery;false;fi;
## Checking Image at 84000000 ...
FIT image found
FIT description: ARM OpenWrt FIT (Flattened Image Tree)
Image 0 (kernel@1)
Description: ARM OpenWrt Linux-5.4.86
Type: Kernel Image
Compression: uncompressed
Data Start: 0x840000e4
Data Size: 2702640 Bytes = 2.6 MiB
Architecture: ARM
OS: Linux
Load Address: 0x80208000
Entry Point: 0x80208000
Hash algo: crc32
Hash value: 7d831d33
Hash algo: sha1
Hash value: 3ebef3573af8efd71157277ceebe052796af6393
Image 1 (fdt@1)
Description: ARM OpenWrt netgear_rbs50 device tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x84293f4c
Data Size: 17925 Bytes = 17.5 KiB
Architecture: ARM
Hash algo: crc32
Hash value: de7c73b1
Hash algo: sha1
Hash value: fdd0712c2ba0efa2ef02faa2d841a16611f668bc
Default Configuration: 'config@1'
Configuration 0 (config@1)
Description: OpenWrt
Kernel: kernel@1
FDT: fdt@1
## Checking hash(es) for FIT Image at 84000000 ...
Hash(es) for Image 0 (kernel@1): crc32+ sha1+
Hash(es) for Image 1 (fdt@1): crc32+ sha1+
kernel checksum OK !
## Checking Image at 8429ffc0 ...
Legacy image found
Image Name: OpenWrt fake filesystem
Image Type: ARM Linux Filesystem Image (uncompressed)
Data Size: 0 Bytes = 0 Bytes
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
rootfs checksum OK !
Burn BOOT PARTITION (= 1) into boarddata2 block
131072 bytes read: OK
Erasing: off d80000, size 20000
Erasing at 0xd80000 -- 100% complete. Cleanmarker written at 0xd80000.
OK
Writing: from RAM addr 871cf9c8, to NAND off d80000, size 20000
131072 bytes written: OK
Alive-timer 11
Done.
## Booting kernel from FIT Image at 84000000 ...
ERROR: can't get kernel image!
i flashed @numero53 version (bb2ba07800f2476459aefda090e372332d58ffa8) to my rbs50 over bootloader tftp.
It comes up, running fine so far (i will test it for some days for stability). Performance is amazing, iperf3 running on rbs50 does gigabit! Power consumption is much lower than expected for this big cooling metal beast (4.5w idle with wifi on, 6w on traffic over wifi and 2 gigabit ports used)
Wifi0 (QCA9984) is not coming up, but i think this is not a problem since there's the IPQ4019 5ghz radio working.
The Wan-Port Problem is not solved yet: Lan1-3 working great (also with vlan) but the wan port does not come up right. Kernel detects link but traffic doesn't come thru. I'm using vlan on lan port (eth0) to emulate a wan port (like many other devices), this works.
I'm not a developer, but i can do tests with rbs50 and also EX8000 (same hardware!).
Is vlan reliably working for you, even after some time? I had it working on my build aswell but it stopped working after a few days. I am using a USB-Ethernet-Adapter for now But if I could use the internal LAN Ports that would be even better (for obvious reasons).
Hello,
I have RBK50 and RBK40 (with RBS40V) if needed.
With OpenWRT, is it still possible to link RBR50 and RBS50 with backhaul? or this feature is a Netgear proprietary?
Wanted to chime in with my testing. I have 3 RBS50s (one flashed as an RBR50 with the artmtd command) and have been running them in a batman-adv mesh with several different VLANs for a few days now. I rebased to the latest master before building and it has been working great with several nodes on my network, most of which are IoT devices. I see the PR needs it's conflicts resolved before continuing and am wondering if that's holding it up from merging. I could take care of the conflicts, though I don't think I have permissions to do so. Anyways, loving this patch and so glad to be running VLAN segmented SSIDs on my Orbi system finally.
Basically, all I did was create a build using a Linux VM and loaded the firmware using the Orbi TFTP recovery method. I have a Mac so I used vagrant to setup the build system using this Vagrantfile config. Link for the TFTP method.
I've played around with several different configurations such as ieee80211k/r/v, batman-adv, and some performance improvements so I'm hoping I get some time to post a write-up and/or guide.
I had the same issue and noticed the ksoftirqd/0 was running at 100% most of the time I did speed tests.
If you haven't done so try installing irqbalance and running it with the --oneshot flag. Also you can enable the performance flag on the cpus and tweak some of the scaling behaviors to see if that improves things. The stock Orbi firmware sets the values in the qca-edma and powerctl init scripts.
Here's one of my better runs using iperf3 with 4 parallel streams:
interesting. So, this is due to them being defined in the device-tree bootargs. Here's the
"rbr50" as an example (but all versions use bootargs)
From what I know (don't have any orbis) this is because the partition table in the mmc is unusable. So the "specify partitions via bootargs" is necessary.
As for "overlapping". This is "kernel+rootfs" is "firmware" is quite common to have on flash devices. Usually, if people want to restore back to the original firmware, they would only need to "mtd write" (or "dd" in this case) to this single partition without having to worry about re-partitioning the device.
(As for the orbis and their mmc. I wondered why they sticked to ext4 as the rootfs. From what I know, f2fs is much better for the longevity.)
Judging from OpenWrt on x86_64 hardware, probably because of the huge filesystem overhead incurred by using f2fs.
/dev/loop0 on /overlay type f2fs (rw,lazytime,noatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=reuse,fsync_mode=posix)
β¦
/dev/loop0 902.6M 143.8M 758.7M 16% /overlay
(actual file sizes on the overlay accumulate to just over 1 MB, so ~141 MB wasted for fs overhead only; in this case the underlying block device is a 2.5" spinning HDD).
"Handling filesystem-full conditions in traditional filesystems is relatively easy. If no space is left, you just return an error. With a log-structured filesystem, it isn't that easy. There might be a lot of free space, but it might all be in different sections and so it cannot be used until those sections are "cleaned", with the live data packed more densely into fewer sections. It usually makes sense to over-provision a log-structured filesystem so there are always free sections to copy data to for cleaning. "
this makes it sounds like it does this overhead/over-provisioning for better wear-leveling. So as long as there's space to do that, f2fs will just fill things up to help out the dumb FTL.
Anyone have the orbi RBR50s setup in a mesh? Wanted to know what that speeds you're getting. I did a test between two orbis (RBR50 and RBS5) by connecting a PC to each devices port. I can't get more than 175 Mbits at a distance of 2.5 meters with direct line of sight.
I used the 5ghz (radio0) band on each device using batman-adv.
Hello,
I am currently trying to compile a build for RBK50 but for v2 (without USB port).
Can this be installed on this particular version as well?
Also, I would like to use ext4 version to use complete eMMC storage space so is expanding main partition is possible?