Netgear Orbi Pro support-booting from MMC

For Developers
42

Well I gues that that should be enough.
I hoped that Web UI will also work.

Obviously they are checking something but I cant find out what since it is blobed

43

well, you can run "strings" on the usr/bin/fw-upgrade and see if there's something obvious.
My guess is that Netgear's fw-upgrade tool extracts files from the provided factory image to check them. maybe that's why the stock images have these files in the root:

 firmware_language_version
 firmware_region
 firmware_version
 ... (there are more)

maybe you can "cheese it" by (temporarily) adding those to files to
target/linux/ipq40xx/base-files/

edit:
At least this would be easy to test.

44

I already ran strings on the binary,there is way too much stuff.
They are adding a lot of stuff to the image.

I think that it is searching for firmware_language_version
As region is empty

45

Ahh,damn I had the wrong model I put RSR60 instead of SRS60.
Now its accepted by web ui,but that wont work after flashing.
TFTP also does not work.
MMC gets read and dts is show and then it read the MMC again until it boots the backup firmware.

Error is
Unknown image format!
rootfs checksum error

46

the netgear firmware "wraps" a uimage/u-boot header around the squashfs rootimage.

47

Hm,shouldnt DniImage do that too?

48

technically not. But it does: append-uImage-fakehdr filesystem.

I wonder if this is caused by the padding.
pad-offset 64k 64

At least I remember dealing with the padding on the WNDR4700 factory.img too.
And there I did : pad-offset $$(BLOCKSIZE) 64 with a blocksize of 128 . Do you know the blocksize of the emmc?

49

It has to be padding.
BLOCKSIZE := 4k
PAGESIZE := 256

Those are the values for Orbi, I added recipes to use those values for DniImage but the same errors are still present

50

Hm, there's conflicting information in

for ubinize it uses 128K

 UBIFS_OPTS = -m 2048 -e 124KiB -c 4096 -U -F
 UBI_OPTS = -m 2048 -p 128KiB

But is ubi even used?

It doesn't look like there's any special padding added in Image/Build/Orbi . But the build code also uses an external program, so no idea what it does.

well, you could try adding this and see what happens:

  IMAGE/factory.img := append-kernel | pad-offset $$$$(BLOCKSIZE) 64 | append-uImage-fakehdr filesystem | pad-to $$$$(KERNEL_SIZE) | append-rootfs | pad-rootfs | netgear-dni

(Looks like john killed his old ipq4019 tree. So no idea what he had)

51

I dont think that ubi is used.
Most likely they just reused that.
I will try your line,I pretty much used the same line but changed both blocksize and pagesize.
Even Netgear is using the netgear-dni written by Gabor Juhos a long time ago to generate the header.

John uses the same values as I did,his tree was up today.

I checked using binwalk and Netgear images only have squashfs.

128k block size got it detected and kernel gets extracted.
But there is an issue with mounting the partition.

52

@chunkeey I am out of ideas why is the kernel unable to mount rootfs.
I even gave it roowait argument and it clearly finds the mmblock0p14 partition and then spits out unable to mount error like in previous bootlog.

And then kernel crashes

53

well, let's look into the mmcblk0p14 partition then. Can you please boot the orbi via initramfs (on the broken install) and do:

# hexdump -C /dev/mmcblk0p14 | head -n 20

The first bytes should be the "hsqs" squashfs magic. If it's the u-boot header "27 05 19 56" magic then the rootfs isn't aligned. If it is some random garbage then it would
be very helpful to have the factory.img you tried to install (so the thing can be matched against something).

54

Ok,here it is:

And here are the images used,as well as factory.img
https://drive.google.com/drive/folders/1FsTOtCI04ME9cqZtWYpSjFS5PWsLZBev?usp=sharing

In factory.img I can find the hsqs but its like it does not get flashed correctly

55

This is really interesting. I didn't find any of that "38 38 e8 19 77 8f..." in the openwrt-ipq40xx-netgear_orbipro-squashfs-factory.img ... However, I did find the same exact values in Netgear's vendor firmware SRS60-V2.1.3.2.img at 0xc80080.

Do you know if Netgear implemented a backup/fallback kernel+rootfs strategy with the Orbi? What do the other partitions look like? Maybe the rootfs gets flashed to a different partition (and the u-boot is in charge of switching the rootfs?). You'll probably need to look in the u-boot source for clues.

56

Yes,they have dual kernel and rootfs partitions.
12 and 13 are kernel and 14 and 15 are rootfs.
And 16 is rootfs_data with size over 1.5GB.

Here is the partition table as OpenWRT detects it.
https://gist.github.com/robimarko/a81c11aa7f0d126f341e746858adb3ee.

Uboot lists partitions as following:

57

Oh ok, what does

# hexdump -C /dev/mmcblk0p15 | head -n 20

look like?

58

And here are how stock p14 and p15 dumps I made before flashing anything header looks like

59

ok, did you take these snapshots with the stock firmware? Or did you extract them with the help of John's sdhci-msm2 driver with your self-compiled openwrt initramfs?

60

Second option.
But I had reflashed all of the partitions after corrupting the bootconfig partition and stock firmware works without issues.

So I would say that Johns driver works

61

Well, at this point I would need the hardware to tell what's going on. To my eye, It really looks like the logical addressing is shifted/wrong/bad as the data has a bad offset (the data itself however looks to be consistent). That hexdump from mmcblk0p14.img is sort of a giveaway - since unless Netgear has some special sauce, it really should start with "hsqs". I guess I'll pick up a ipq40xx emmc device once they get affordable... unless of course, somebody wants to sent me one :wink: :smile: .

Well, this was fun :smirk:.