Netgear Orbi Pro support-booting from MMC

Yeah, that's what I was referring too.
Hopefully it wont take too long for v5.4 support

well..... 5.4 is going lts in like 1-2 month... we already are at rc
problem is that openwrt will switch to it very late

We still have some trouble port everything to 4.19

Usually OpenWrt starts with generic kernel support at rc3-4 and we get everything tested right on final release time.
IPQ40xx target wont be hard as to get working as we can drop even more upstream patches.
Targets that struggle with 4.19 wont be impacted in any way.

Just a little update: I switched now to a USB Ethernet NIC and since then it's working absolutely great.

@robimarko Have you had a chance to look at my changes and somehow integrate them in your repo aswell?

Sorry, but I dont have access to Orbi I had o prior so i really cant help in this matter anymore.

I am trying to port another device which is somehow similar to the Netgear Orbi Pro, the Linksys Velop WHW03.
Both are based on IPQ4019 and they use eMMC for flash.
They differ in the Wl2 chip ( Qualcomm Atheros QCA9884 vs QCA9886) and switch chip ( Qualcomm Atheros QCA8075 vs QCA8072).

I'm just learning OpenWRT and managed to get a serial connection to the device, extracted FTD and partition table -- different from Orbi's Pro.

Is it feasible to try use @robimarko tree to flash it, omitting the EFI changes made?
Or will the current kernel 4.19 or 5.4 detect the eMMC?

Do not do that.
A new tree needs to be made.
Unlike before there is full support for EMMC on IPQ4019 in OpenWrt.
Take a look on Habanero DTS for how to configure the SD/MMC and LDO nodes as well as pinctrl

1 Like

Perhaps we can pump this to kernel 5.4 with better nic support?
I have rbr50 and rbs50 (i think i just have to change the hwid) and also would help to bring it into a merge request.

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.

@Moefreak

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.

  1. Delete the efi patch: target/linux/ipq40xx/patches-4.19/870-Netgear-Orbi-Use-netgear-EFI-hack.patch.

  2. Make sure the following setting is enabled in target/linux/ipq40xx/config-4.19:

CONFIG_CMDLINE_PARTITION=y

  1. Figure out the actual partition table from /sys/block/mmcblk0 for the blkdevparts kernel cmdline. The following is the partition table for RBR50 to be appended to the cmdline in /target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-orbi-pro.dtsi. This increases the cmdline length to 617, luckily smaller than the 1024 limit as defined in asm/setup.h. Note that there is a previously unallocated ~2GB space; can it be used for overlay instead?

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)

  1. Build and do sysupgrade. That's it!

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

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 :slight_smile:. 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. :wink:

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 :slight_smile: If I am forgetting someone or someone is not agree with this, let me know. :slight_smile:

2 Likes

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