Askey RAC2V1K / RT4230W REV6 Support

i replied above but our sequences got messed up!

Thanks. Just to complete the picture, could you also add the revision (i am guessing 6 or 10) to that table?

@lmore377 - please take a look at the fw_printenv from one of my devices (256md flash, machine id 177e). i think there is an error between the bootcmd and the way the mtdparts was actually set:

root@hoffmanap30:~# fw_printenv
baudrate=115200
bootcmd=setenv mtdids nand0=nand0 && set mtdparts mtdparts=nand0:0xDC00000@0x2400000(firmware) && ubi part firmware && ubi read 0x44000000 kernel 0x6e0000 && bootm
bootdelay=2
eth1addr=7c:db:98:e3:4:64
ethact=eth0
ethaddr=7c:db:98:e3:4:63
fdt_high=48000000
fsbootargs=ubi.mtd=rootfs root=mtd:ubi_rootfs rootfstype=squashfs
ipaddr=192.168.1.1
machid=177e
mtdids=nand0=nand0
mtdparts=mtdparts=nand0:0x1A000000@0x2400000(firmware)
reboot-reason=rea=ffffffff
reboot-time=time=ffffffff
serverip=192.168.1.9
stderr=serial
stdin=serial
stdout=serial
uboot-version=uboot-version="1.0.6

this device gives an error on bootlog:
...
mtd: partition "ubi" extends beyond the end of device "qcom_nand.0" -- size truncated to 0xdc00000
...
it seems that the environment mtdparts setting is not what the bootcmd said it should be.
also - should the boot command be " if bootipq; then echo a; else setenv mtids ......

your latest instructions did not have the if bootipq header, but your older instructions did. it doesnt seem to make a difference now.

thanks!!

Actually with my build the mtdparts command doesn't really have any effect on openwrt at all since I define the partition layout in the device tree (it's effectively only used to tell uboot where the kernel is) What seems to be happening is that openwrt sees that the flash is physically smaller than what I put in the device tree so it just adapts by defining the ubi partition to where it fits in the flash (that "ubi extends beyond..." error). Also I originally had bootipq there because openwrt had a bug where it wouldn't initialize the Wi-Fi cards properly unless it was ran but that was recently fixed so the command isn't needed anymore.

You are right. Sorry for the confusion!

This is a very good format for capturing details of the rac/sac that they have.

Can others on this forum who own these or similar devices, also post information of their devices in the above format, so that it is of collective use for everybody? Thanks.

@hoangdinh86 I just had my wifi cards "die" after I accidentaly dropped the router but all I had to do is unscrew the card and reseat it. I guess it wiggled out just enough to not make a full connection. If you still have the router you should try that.

I don't think there's any correlation between the factory ID and the revision. My router has a factory ID of 2 but the machine ID built into the firmware is 177d (rev 6)

Edit: I reached my 3 consecutive replies limit.
Alright I added a table to show differences between revisions. https://openwrt.org/inbox/toh/askey/askey_rt4230w_rev6#different_revisions

Sample post, to get you out of the cage of 3 consecutive replies limit :slight_smile:

@lmore377 -
great toh page. thank you

So it turns out I accidentally had the wan and lan mac addresses swapped this entire time. I'll build a new image in a bit but the packages will take ~12 hours to finish building so I'll upload it then.
Edit: I also made a few minor changes (made the mtd names match the original ones and set the ethernet mac address in 02_network instead of the device tree)

@lmore377 this is exciting. and I'm now able to build so hopefully i can be more helpful.
best season's wishes to all the community

Alright the new build is up. You can get it from here or here. You'll need to update if you want to keep using the opkg repo (I realized that I should have kept the old one up for a while after I had already deleted it.)

So uh I accidentaly broke sysupgrade (forgot to update a file when a new device was added.) Don't use this image.

@lmore377-
tempting fate, I sysupgraded your r15338 over previous r15177, specifically not saving config over sysupgrade, and it seemed to work.

Alright everything's up. @ghoffman replace /lib/upgrade/platform.sh with this one to fix sysupgrade then upgrade to the new image.

@lmore377- thank you - all synced up and sysupgrade from your recent build does work.

i got a 5th device to play with - a SAC2V1K, also 256mb flash, machid 177e.
i think it's pretty consistent that 177d has 512mb (rev6) and 177e has 256mb (rev10)
these machid values are set in uboot environment at factory config.
i'm wondering if your modified bootcmd could check for the machid and issue the correct command based on the returned value?
thanks again!

I have a RAC2V1K REV 1 on firmware 1.1.32.
I used your 1.1.28 config file to get root, but am hesitant to continue. Do you think your build on github will work on my model? I won't be too disappointed if I brick it; I don't use it for anything important.

The revision on the web interface isn't accurate. Do fw_printenv to get the machine ID and reference the table here to see the actual revision. If it's 6 or 10 there's a pretty much 100% chance it work fine.

1 Like

I couldn't figure out how to get fw_printenv to say anything about the machine ID, but I found that mine is a REV 6 by looking at /proc/device-tree/model.
Thanks!

When you run fw_printenv one of the variables should me machid and it should be set to 177x where x is A thru E