As mentioned above the partition table on the device doesn't reflect the actual partitioning, so you need to hardcode it which doesn't work as the kernel is built for the entire cpu family at once.
I'd love to test an updated version though to see if that is better.
so theres no way to bring it into openwrt?
If you figure out a way to get around this there might be a way to get it merged.
In this case, is it possible to rewrite the partition table on EMMC with the correct one before flashing openwrt firmware to circumvent this issue? A backup is necessary to revert to factory then, or maybe factory firmware doesn't care about this at all.
That is an excellent question and was one of my first thoughts aswell when I read about that issue: Why not just fix the partition table. The only way is probably to try it and see what happens. Either the bootloader freaks out or it just works.
Hi, I checked both devices and only changing the ID will not work. Memory wise both are different and mtd partitions are different too. So it must be tweaked, I reckon.
OK so the blkdevparts cmdline works as a solution to the faulty partition table issue. Here's what I did based on Flole's tree; tested on my RBR50 and it boots well. No more ghost partitions when I plug in USB hard drives.
Delete the efi patch: target/linux/ipq40xx/patches-4.19/870-Netgear-Orbi-Use-netgear-EFI-hack.patch.
Make sure the following setting is enabled in target/linux/ipq40xx/config-4.19:
CONFIG_CMDLINE_PARTITION=y
blkdevparts=mmcblk0:512K@17K(0:SBL1),512K(0:BOOTCONFIG),512K(0:QSEE),512K(0:QSEE_ALT),256K(0:CDT),256K(0:CDT_ALT),256K(0:DDRPARAMS),256K(0:APPSBLENV),1M(0:APPSBL),1M(0:APPSBL_ALT),256K(0:ART),256K(ARTMTD),2M(language),256K(config),256K(pot),256K(traffic_meter),256K(pot_bak),256K(traffic_meter.bak),3840K(kernel),47360K(rootfs),50M@8977K(firmware),256K(mtdoops),3840K(kernel-2),47360K(rootfs-2),50M@60433K(firmware-2),256K(cert),5M(device_table),48M(circle),50M(streamboost),30M(forceshield),5M(arlo),2M(rae),1239023104(reserved),-(unallocated)
With this, can someone help to bring orbi routers to openwrt?
Well you're super close to doing it yourself: You have my work minus a hacky workaround that wouldn't get merged so you can try to submit a PR and see what happens.
I'd love to do it myself, however I'm not an developer, just an amateur - no experience editing github, patches, or various kernel drivers. So many thanks to anyone who work out the PR for our devices!
And as a new forum user I can only post in this topic 24h after I delete my previous post 
Hello everyone,
I got a Netgear SRS60 so I started working on it few weeks ago (to be honest most of the work was already done by @robimarko and @chunkeey) and now I think that we are very close to a proper upstream support thanks to the latest addition of @zhoushiyi213 . So I just did some minor fixes, cleaned up the repository and spitted in 3 different commits.
This is my repository: https://github.com/DavideFioravanti/openwrt/tree/netgear_srs60. Any test is apreciated!
Currently it should also support the SRR60 and RBR50, but I don't have these devices so I can't test these images. Because of this, please try the initramfs image before flashing and please post in this thread the results. 
Finally, I was thinking to add @robimarko @chunkeey and @zhoushiyi213 as co-author of these patches. My primary goal is to support these routers and give credit to everyone involved If I am forgetting someone or someone is not agree with this, let me know.
In this post I'll add some notes to the commits included in the repository I posted earlier
base-files: add minimal mmc support
I decided to create the file package/base-files/files/lib/upgrade/mmc.sh so we will be able to create a standard procedure for mmc devices (e.g. nbg6817)
For what concerns the "find_mmc_part" function I think the we should be able to merge into the "find_mtd_part" function. However I don't know if messing with block devices and mmc could create problems, so I decided to leave them separate
ipq40xx: add support for Netgear SRK60/SRS60 and RBR50
I will complete the commit message in the next few hours or days
I calculated the partitions sizes starting from the efi.c file of the first GPL source available on the netgear website for every device.
RBR50 / RBS50 / RBK53 (Orbi) Version 1.1.0.16
{"ARTMTD", 0x2A22, 0x200},
{"language",0x2C22, 0x1000},
{"config", 0x3C22, 0x200},
{"pot", 0x3E22, 0x200},
{"traffic_meter", 0x4022, 0x200},
{"pot_bak", 0x4222, 0x200},
{"traffic_meter.bak", 0x4422, 0x200},
{"kernel", 0x4622, 0x1E00},
{"rootfs", 0x6422, 0xF600},
{"firmware",0x4622, 0x11400},
{"mtdoops", 0x15A22, 0x200},
{"reserved",0x15C22, 0x2B70FF},
SRK60(SRS60 & SRR60) Version 1.12.1.28
{"ARTMTD", 0x2C22, 0x200},
{"language",0x2E22, 0x1000},
{"config", 0x3E22, 0x200},
{"pot", 0x4022, 0x200},
{"traffic_meter", 0x4222, 0x200},
{"pot_bak", 0x4422, 0x200},
{"traffic_meter.bak", 0x4622, 0x200},
{"kernel", 0x4822, 0x1E00},
{"rootfs", 0x6622, 0xF600},
{"firmware",0x4822, 0x11400},
{"mtdoops", 0x15C22, 0x200},
{"cert", 0x15E22, 0x080},
{"kernel-2", 0x15EA2, 0x1E00},
{"rootfs-2", 0x17CA2, 0xF600},
{"firmware-2",0x15EA2, 0x11400},
{"device_table", 0x272A2, 0x2800},
{"cp_file", 0x29AA2, 0x8800},
{"reserved",0x322A2, 0x29AAFF},
@robimarko and @Flole my ROOTFS_SIZE seems different from yours. Could you please check my values?
0xF6000 * 0x200 = 0x1EC0000 -> 32243712 bytes while you wrote 27787264. Who is right?
The file target/linux/ipq40xx/base-files/lib/preinit/08_check_boot_partition.sh checks if you are booting from the first partition or not. Ideally we should mount the first or the second pair of partitions based on the 297th byte of the /dev/mmcblk0p12 partition. But I am not aware of any way of doing this. If we won't find anything i will drop this file and we will stick to the first pair of partitions
@robimarko I didn't understand why you set the drive-strength = <16>; to pins = "gpio58", "gpio59"; (the i2c). I disabled these lines and the led driver is still working.
I simplified the image creation process in the Makefile. I tested many times on my router and should work. Please report any problem about this
Thank you for work! I will build and test on my RBR50 (the only orbi I have) sometime this or next week.
As some point of Netgear's firmware release, they changed the partitation table, so it's single rootfs as the initial release you used and at some point become the following one, also double rootfs layout (as of 2.0.0.72):
{"ARTMTD", 0x2A22, 0x200},
{"language",0x2C22, 0x1000},
{"config", 0x3C22, 0x200},
{"pot", 0x3E22, 0x200},
{"traffic_meter", 0x4022, 0x200},
{"pot_bak", 0x4222, 0x200},
{"traffic_meter.bak", 0x4422, 0x200},
{"kernel", 0x4622, 0x1E00},
{"rootfs", 0x6422, 0x17200},
{"firmware",0x4622, 0x19000},
{"mtdoops", 0x1D622, 0x200},
{"kernel_bak", 0x1D822, 0x1E00},
{"rootfs_bak", 0x1F622, 0x17200},
{"firmware_bak",0x1D822, 0x19000},
{"cert", 0x36822, 0x200},
{"device_table", 0x36A22, 0x2800},
{"circle", 0x39222, 0x18000},
{"streamboost", 0x51222, 0x19000},
{"forceshield", 0x6A222, 0xA000},
{"arlo", 0x74222, 0x8000},
{"reserved",0x7C222, 0x250AFF}
They also add/modify partitions at the end, but (I hope) the firmware and firmware-2 partitions have the same location and size. The following is extracted from 2.3.0.32:
{"ARTMTD", 0x2A22, 0x200},
{"language",0x2C22, 0x1000},
{"config", 0x3C22, 0x200},
{"pot", 0x3E22, 0x200},
{"traffic_meter", 0x4022, 0x200},
{"pot_bak", 0x4222, 0x200},
{"traffic_meter.bak", 0x4422, 0x200},
{"kernel", 0x4622, 0x1E00},
{"rootfs", 0x6422, 0x17200},
{"firmware",0x4622, 0x19000},
{"mtdoops", 0x1D622, 0x200},
{"kernel-2", 0x1D822, 0x1E00},
{"rootfs-2", 0x1F622, 0x17200},
{"firmware-2",0x1D822, 0x19000},
{"cert", 0x36822, 0x200},
{"device_table", 0x36A22, 0x2800},
{"circle", 0x39222, 0x18000},
{"streamboost", 0x51222, 0x19000},
{"forceshield", 0x6A222, 0xF000},
{"arlo", 0x79222, 0x2800},
{"rae", 0x7BA22, 0x1000},
{"armor", 0x7CA22, 0x19000},
{"reserved",0x95A22, 0x23FCFF}
So what's the best way to address the discontinuity? Maybe it's also the case for RBK60... Probably remind users to create a dump before installing openwrt, or the official firmware can re-create them anyway? I don't remember the firmware version of my RBR50 before flashing openwrt, but it's a dual firmware partition layout already...
Never mind. It seems the offset & size of the first kernel is the same, and the offset for rootfs is also the same for the layouts I looked at - I guess those are the numbers that matter. There must be a way official firmware builds up the partitions. Personally I'll run extroot on reserved and unallocated space LOL.
Edit: maybe we can be more audacious and set all the space following rootfs for use in rootfs? I know for Netgear WNDR4500v3/4300v2 all nonsense partitions are combined to rootfs. I'll test that on my rbr50.
I was running RBR50 firmware 2.3.0.32 before flashing. The blkdevparts is set as follows to use all space following kernel (3.3 G:-). (As a side note, when I put all OEM partitions into the blkdevparts, dmesg reported error size in partition cmdline and loaded GPT table with no mmcblk0p20; not sure why...)
blkdevparts=mmcblk0:512K@17K(0:SBL1),512K(0:BOOTCONFIG),512K(0:QSEE),512K(0:QSEE_ALT),256K(0:CDT),256K(0:CDT_ALT),256K(0:DDRPARAMS),256K(0:APPSBLENV),1M(0:APPSBL),1M(0:APPSBL_ALT),256K(0:ART),256K(ARTMTD),2M(language),256K(config),256K(pot),256K(traffic_meter),256K(pot_bak),256K(traffic_meter.bak),3840K(kernel),-(rootfs)
For Makefile, according to efi.c from firmware 2.3.0.32 I changed to these numbers: ROOTFS_SIZE := 48496640, IMAGE_SIZE := 52428800
And the generated images work well:
Flashing from router web interface works. Overlayfs is in /tmp/root after flashing; requires a subsequent sysupgrade to initialize the filesystem with 3.3G size. Even if I erase the previous kernel-2 partition the router still boots well.
Reverting to OEM firmware (2.3.0.32) works fine using nmrpflash. 2nd firmware is missing so it requires updating again with OEM firmware to populate 2nd firmware partitions (for subsequent webpage flashing to openwrt).
Failsafe, ethernet, three Wifis, USB, LEDs, reset button and WPS button all work. The CSR8811 bluetooth and its ttyQHS0 are not there, same case with Linksys EA8300. Anyway it's really awesome!
Hi @zhoushiyi213, thank you very much for your tests 
Probably the safest way is to use the smallest rootfs partition. The main advantage is that other partitions wont be messed up (allowing the user to boot the other partition without re-flashing [1])
While the main disadvantage is that the user will have less free space ~31 Megabyte vs ~47 Megabyte. (However I think that even 31 Megabyte is more than enough space for the average user)
I am almost sure that this is feasible but, as I said before, in my opinion it's not worth the risk messing with partitions considering the 31 Megabyte of free space (even if the risk is very very small).
Obviously this is just my opinion... We should ask the reviewers what they think about it for a definitive answer
However I have a bigger problem now to solve: the wan port.
Is the wan port working for you? I wasn't able to get it working. The SRS60 doesn't have the WAN port in the OEM fw, so I didn't add it in the openwrt, but your RBR50 (and SRR60) has one and should be the port 1 of the switch.
Using this patch should be enough, but on my router only the RX counter of the WAN port works, while TX counter is always 0.
If you still have the OEM fw on the router, could you please boot it and show me te output of these commands?
hexdump /proc/device-tree/soc/ess-switch@c000000/switch_lan_bmp
hexdump /proc/device-tree/soc/ess-switch@c000000/switch_wan_bmp
hexdump /proc/device-tree/soc/edma@c080000/gmac0/vlan_tag
hexdump /proc/device-tree/soc/edma@c080000/gmac1/vlan_tag
[1] Currently is possible to read the current boot partition reading the 297th byte of /dev/mmcblk0p12 using this line (at least on SRS60/SRR60):
hexdump -v -s 297 -n 1 -e '1 "%_p"' /dev/mmcblk0p12
Changing that byte to 1 or 2, is possible to boot the other partition set
Unfortunately I don't know how emmc works so I don't know if is possible to edit a single byte on the storage or we must dump it, edit and then write back. If you know wich is the safer method, we can create a simple script to allow the user to reboot on the OEM partition 
Thanks for the feedback! No I didn't test the wan port; I am using a wierd internet setup at home and I don't know much about vlan stuff so I neglected it. I test the wan port tomorrow or over the weekend.
I agree with your compatibility point. But, for the partition layout, is it possible to create two profiles? Or I guess I'll figure out a way to edit the device tree before flashing when it comes to mainline (clearly uboot checks the checksum so direct binary editing doesn't work 
).
As for the emmc, based on my experience with smartphones and this router it is safe to treat it as block devices. There is already a flash transition layer in between. I've been using dd and cat for a quite while on mmcblk0 of many of my phones for flashing purposes and it works fine.
Here's the output. I'll follow up with the openwrt wan tests later.
root@RBR50:/# hexdump /proc/device-tree/soc/ess-switch@c000000/switch_lan_bmp
0000000 0000 1e00
0000004
root@RBR50:/# hexdump /proc/device-tree/soc/ess-switch@c000000/switch_wan_bmp
0000000 0000 2000
0000004
root@RBR50:/# hexdump /proc/device-tree/soc/edma@c080000/gmac0/vlan_tag
0000000 0000 0200 0000 0200
0000008
root@RBR50:/# hexdump /proc/device-tree/soc/edma@c080000/gmac1/vlan_tag
0000000 0000 0100 0000 3c00
0000008
Thank you!
Those values were very similar to mine, but the missing piece was:
qcom,phy_mdio_addr = <4>; and qcom,phy_mdio_addr = <3>; in the gmac0 and gmac1 section.
I bet that if you type these two lines in the OEM fw
hexdump /proc/device-tree/soc/edma@c080000/gmac1/qcom,phy_mdio_addr
hexdump /proc/device-tree/soc/edma@c080000/gmac0/qcom,phy_mdio_addr
you will get something like
0000000 0000 0300 and 0000000 0000 0400
However the wan port should be working now
I also fixed the led brightness (actually some of the 8 leds were off)
Here you can find my latest commit rebased on the lastest master:
When we will find someone with an SRR60 and an RBS50 we could create the pull request
Unfortunately the wan port is still not working correctly. 
It works only if I connect my pc to the 4th port.... it's a very strange behaviour.
Probably I have to test some more qcom,phy_mdio_addr combination in the next few days...
a good way to bisec this is to check how the bootloader init the port