Well, cmdline overide is here:
Currently upgrade script I am using is not changing which firmware to write to as auto-detection does not work properly and it will update the currently used set of kernel/rootfs partitions.
But do note that they are also hardcoded and need to be changed.
So what I have to do is change the partition table in target/linux/ipq40xx/patches-4.19/870-Netgear-Orbi-Use-netgear-EFI-hack.patch, no other changes necessary in that patch.
Change the dts to have the correct rootfs path.
Change the upgrade script to not read out the rootfs as the stock firmwares cmdline doesnt contain it (make it static instead for now), remove the board_name stuff as my device doesnt have that command on stock firmware and change the partition numbers in that aswell.
Then I can compile and get an image which I can upload to through the orbi's webinterface (or should I manually flash it?) or did I miss something?
Yes, change the partition table.
Only thing you need to do in upgrade script is to change partition names to ones matching your device so if you sysupgrade it does not get written to wrong ones.
Do not remove anything as this is OpenWrt only, it does not have anything to do with the stock firmware.
Then if IDs are changed in the: https://github.com/robimarko/openwrt/blob/Orbi-Pro-4.19-rebase/target/linux/ipq40xx/image/Makefile#L321
You should be able to flash through web ui
Isnt that upgrade script being executed by the netgear updater if I flash it? Or how does it know that it should not do the partition switch once its done (cause I'm sure it will if its not running that script)? If its part of netgears update process I need to make sure that I remove everything that will fail on the original firmware (like checking the active rootfs through the cmdline)....
By the way: Stock OS has files hw_id and hardware_version in / which reveal
root@RBR50:/# cat hardware_version
RBR50
root@RBR50:/# cat hw_id
29765352+0+4000+512+2x2+2x2+4x4
Again, it has nothing to with the stock firmware, only OpenWrt uses it.
Netgear only unpacks the tar archive and flashes the kernel and rootfs with mtd to their partitions.
I dont remember whether stock firmware will flash the update to secondary partition, it has been a while since using the stock firmware.
This is why UART is important because you can see if this is the case really simply or simply use TFTP recovery to primary or secondary partition directly.
Ah, so unless I want to use the OpenWRT upgrade mechanism I dont have to worry about the script at all for now. I will just dd the kernel and rootfs manually onto the devices secondary partition and do the bankswitch through the command line afterwards manually so those get used, that should be the safest way for now.
The very similar HW IDs suggest that its indeed the same board (but we'll see very soon).
The boot partition can be identified with "artmtd -r boot_part", mine is currently on 1 which means I am booted from the first set currently (2 would be the second one).
I dont need to do anything else like delete configuration, format overlayfs or something like that, do I?
Do not use DD to write this, its a sure way to your router not booting.
Use web ui or TFTP to flash and then you dont have to do anything manually.
I dont understand what is so hard with editing the partitions in the upgrade script.
Why would dd cause it to not work? That's a perfectly fine way if I seperate kernel and sqfs and they end up on the correct parts.... Anyways, I'll use the webinterface and see what happens with that one, just to not take any risks...
Editing the upgrade script is not necessary at the moment and I am trying to do only the changes absolutely necessary for now to avoid any issues, I will do that later on once the router booted up the first time. The first partitions are already correct, I just need to change the second ones (-1 for those). As this script is part of the upgrade file I can still fix it for the first image that will be flashed using that method, right?
But why would you use DD at all?
If you don't edit the upgrade script now, then you will need to edit it before trying to upgrade using sysupgrade but that has to be done locally on the device.
But since its quite literally matter of changing the partition number why not do it now if you know which partition is which
So I tried to upgrade through the webinterface and it failed. In the upgrade websites javascript I found
//when cfg_allow_upgrade is 0,and version lower than V1.4.0.0,can't allow user upgrade fw. If /tmp/hw_revision = 01(01~FF) and Uploaded FW < 2.1.2.20 then show it as invalid FW. If /tmp/hw_revision =2 and uploaded FW<2.2.2.10 then show it as invalid FW.
So I guess I need to give it an official version number and not VOpenWrt.unknown (I have hw_revision 01 by the way). I have changed the netgear-dni now to statically make it 2.1.2.22 as that should work for rev1 but not for rev2. (Now you know why someone would like to just dd it on there and be done).
I also just changed the upgrade script to the correct part numbers, recompiling now.
Well that version checking is something that SRK60 does not have.
It still can easily be bypassed by using TFTP recovery instead
Or by using dd, turns out /tmp/cfg_allow_upgrade_fw was also set to 0 (so I changed it to 1) and 2.1.2.22 was not high enough so I changed it to 1.2.3.5.31 (currently on 2.3.5.30 and the first part before the dot gets ignored as its always prefixed with a v which should never be there) and now it at least accepted the update. Its rebooting now.
And its not booting up. It flashes white, then its steady green for a second, steady yellow for half a second, then very short red and then it goes off and starts the same procedure again. Now I need to figure out how to open this thing.....
Well, if its like SRK60 then you 2 screws under the sticker with LAN ports and after that one part will slide down.
Then you have 4 more screws on the board itself and then on the other side you have UART header
I wish it was that easy, there is just a hole and apparently the guys who are supposed to open this device have a "key" that they can insert and it will magically open......
Hm, that is weird
Can you take a picture?
I mean you gotta be able to open it
Check out the FCC Pictures, they show that mechanism and I dont understand it (or that is for a Kensington lock).
That is gotta be a Kensington lock, but it still has 2 screws only on the back.
You can even see them in FCC pictures, you also gotta cut the sticker on the bottom in half so you can slide one of the case halfs
There are screws hidden behind the label at the ethernet port.....