I think you may need to program the flash with raw data.The raw data I mean is with OOB. So the first step is to find the raw data someone dumped. And also please don't program the calibration and board data partitions.
Hi, there was someone on github who wanted to finish Jawwest work with rax120v2. Any news on this last reply was 3 weeks ago?
@Tony.He I got the dumps for the mtd partitions but probably won't be able to reflash the chip, too complicated.
@WiZaR5789 that is me, yes. I wanted to give @jewest some time to react but will prepare a replacement PR soon.
While preparing a replacement PR for the RAX120v2 I rebased @jewest code to latest OpenWrt master.
With no changes to the DTS file the labeling of the ethernet ports is not working anymore. Instead of lan#/wan they are named eth#.
Anyone an idea what could cause this? (Maybe @robimarko)
Can you push it somewhere, also the kernel log would be great
Thank you @robimarko, writing down the question solved it 
... I did think again what I did different.
I did check out your nss_package repo to include aq-fw-download. And this time not as a feed but by git checkout into the `./package/. That didn't work out.
That obviously wont work
I created a new PR for the Netgear RAX120v2. As much I could remember is written down (what is fixed from @jewest PR, or added, or changed).
The git log should help in installing OpenWrt on the RAX120v2, serial console is still needed.
Although it's possible to flash the factory image using nmrpflash one has to change the bootcmd to be able to boot. That could be done in stock firmware and that way serial console access wouldn't be needed; but still telnet would be.
But I'm not sure what the stock/default content is of mtd14/'appsblenv'. For me it was empty at one time and then fw_setenv writes a standard environment which is missing information. u-boot on the other hand writes the correct values to an empty mtd14/'appsblenv'.
So if there's a way to set 'bootcmd' or if booting without changing the 'bootcmd' variable is possible, serial console access won't be needed.
2 Likes
Thanks for your work, hopefully this pull request will push this device into official support. Small suggestion maybe add @robimarko as reviewer in pull request. 
Hey @WiZaR5789, let's see if it makes it into official support. And I don't know how to add a reviewer - now button to add one. I did assume that since it is tagged the right people will find it :).
Il take a look today or tommorow
3 Likes
You can possibly take a look at the script I previously posted. It generates a firmware that is compatible with the offcial bootcmd, and can be flashed by using and only using the router's web UI (or tftp if you like).
It competely avoids changing bootcmd thus safer.
Or after your PR is merge, I will take a look by myself. (might take a while for me to have the free time)
1 Like
Or maybe robimarko can do the same with DNI image recipe?
1 Like
I'll have a look at your script for sure. Would be amazing if that worked. The netgear-din is already in use. Right now it fails when it checks for the rootfs size in uboot.
Will look into it later today or tomorrow.
Thanks for your help!
1 Like
My rax120v2 finally arrived, so if you need any help checking or testing I'm in.
@WiZaR5789 : Good Morning, if you are able to get telnet access (link to the tool earlier in this thread) it would be interesting to see if the '0:APPSBLENV' (/dev/mtd14) is empty or populated. I never check before I fiddled with the device.
The easiest way would be to check with hexdump -Cn 256 /dev/mtd14. That reads the first 256 bytes and if all are ff's the it's empty otherwise you would see u-boot variables.
Or run fw_printenv and if the output mentions 'CRC error' then it would it's empty.
@wangyu: I had a look at your script and I think I understand what it does. Right now I'm not able to replicate it in OpenWrt itself yet, but I'll investigate more later.
If I use your gen.sh script on the PR the resulting final.img does indeed boot with the default bootcmd but there are not network devices. And I don't see any QSKD related log entries. I will have to look into that, too.
that's weird.
I took a fast look of my own script to try to recall something, I saw some constant numbers. Possibly some of them need to be adapted to the new branch? E.g. If I remember correcly the offset of filesystems are hardcoded in the kernel dts, the vaule in the script need to be matched. If some filesystem is not loaded correcly, you are probably in a failsafe mode or ramdisk mode, which doesn't have the drivers.
And by the way when I wrote the script, my stock firmware was 1.2.3.28, not sure if this can make a difference.
UPDATE: also, as you mentioned, the new branch has switched to ubifs now. That might also cause a difference despite of the offset.
Finally after a long battle with enabling telnet I have the results if you need anything else feel free to ask.
Great, good work ... to get telnet access can be pain indeed.
I'd be interested in mtd14 (not mtd1) if possible.
That should be it.
1 Like