I want to report my recent experience with the new build (r15177) from lmore377:
the good:
i upgraded 2 rac2v1k routers that had the old build (r13577 ?). they were working well, but were limited because opkg sources were unavailable. i performed sysupgrade from the gui, preserving settings. and could log right into the luci gui immediately. for reasons i cannot explain, 1 device needed wireless reset for optimal perfomance, but the other needed no settings updates. i changed the opkg update sources from the gui and could add packages. i got the devices to serve usb-attached printers by adding luci-app-p910nd and usbutils form the hosted sources
fantastic!!!! thank you so much.
potentially a problem, and i need to spend some time this weekend investigating:
i also have a 3rd device (stock 1.1.16) and enabled ssh access by the config-restore method (no serial) to start the conversion process.
i was able to ssh into the device. following the method 1 steps
(at https://github.com/lmore377/openwrt-rt4230w )
i was able to set up to tftp-boot from a local server. i fw_printenv so see the changed ip /serverip settings prior to issuing the tftpboot command, which proceeded to load the new intitramfs image v15177. after the new image loaded, i then changed the fw_setenv boot settings again as directed, and
performed a sysupgrade from the gui. upon reboot, the device has hung with a solid red light, and does not respond to pings.
i think i got the identical 'default environment' message and should have noticed.
i am concerned that the new intramfs image is somehow not working correctly - maybe not setting the fw_env.config file? -; this process worked on the old image, from which i could perform these steps.
of course, i might have made a mistake. if anyone can confirm that the new r15177 initramfs image works from stock as directed, then please let me - and everyone else - know.
this is NOT criticism of anyone's work and I am continually amazed by the genrosity in this community.
thank you - lmore, spurious, eganov, efsg, spacepope, and all
A solid red light means that it ran bootipq on startup so the fw_setenv command somehow failed to set bootcmd. Can you connect to a serial cable and do printenv in uboot and send the output?
@lmore377 -absolutely. ill have time to take apart and get serial access this weekend.
edit:
it appears my device is a weird one with less ram but still a v1.0.16 - a hbrid sac2v1/rac2v1?
the bootlog shows a mtd size error. see log below.
after changing the bootcmd to the sac2v1k command, the deivce boots fine!
U-Boot 1.0.6 [spf.5.0.2_csu1.1] (Nov 15 2018 - 03:26:55)
smem ram ptable found: ver: 0 len: 5
DRAM: 1003 MiB
setting 0x177e as machine type from smem
NAND: SF: Unsupported manufacturer 00
ipq_spi: SPI Flash not found (bus/cs/speed/mode) = (0/0/48000000/0)
256 MiB
MMC:
PCI0 Link Intialized
PCI1 Link Intialized
In: serial
Out: serial
Err: serial
MMC Device 0 not found
cdp: get part failed for 0:HLOS
Net: MAC0 addr:7c:db:98:e3:4:63
athrs17_reg_init: complete
athrs17_vlan_config ...done
S17c init done
MAC1 addr:7c:db:98:e3:4:64
eth0, eth1
Hit space key to stop autoboot: 0
nand0: partitioning exceeds flash size
Error initializing mtdparts!
(IPQ) #
(IPQ) # printenv
baudrate=115200
bootcmd=setenv mtdids nand0=nand0 && set mtdparts mtdparts=nand0:0x1A000000@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
Environment size: 634/262140 bytes
(IPQ) #
Well that's just weird. Give me a few minutes to check something. Also can you just revert to the rac command and try to let it boot real quick? The red light shouldn't light up because bootipq is never run yet in this case it looks like it did for whatever reason.
Edit: So I got some info on other revisions recently (there's 5) and it looks like the router you got there is REV 10. I should probably look into the differences between revisions.
I think I knew about different versions a while ago. since the rev6 config upload worked, i didnt look any further. i should have investigated more when i got the bad crc/feault environment error initially?
i appreciate your work on this project - let me know how else i might help. it looks like i have a rac2v1k rev6, a rev10, and a sac2v1k to work with.
From the posts above, it seems the sac can be identified externally by the QR code at the back. Do you have any idea on how to identify externally between the 256M and the 512M version of the rac? Thanks!
Only difference I saw was smaller nand but I only had it for about a week or 2 before returning it to spectrum (none of my smart home devices could connect because both wifi channels had the same name) and I was still focusing on getting everything ported so there might be more stuff I don't know about
The most notable difference is that the one with a qr code on the back is almost guaranteed to be rev 10 but apparently it can be 50/50 if there's no qr code
Thanks for the clarifications above. Would the following summary be reasonably accurate, based on my understanding the posts above?
The rav Rev 6 has larger NAND of 512M, does not have to be opened up for reflashing to OpenWRT and has no QR code.
The rav Rev 10 has a smaller NAND of 256M, does not have to be opened up for reflashing to OpenWRT, and has no QR code.
The rav with additional sac2v1k nomenclature on the back of the router, has a smaller NAND of 256M, has to be opened up for reflashing to OpenWRT (since it has a different firmware than #2 above), and has QR code.
Any other revisions that I am missing, in the above framework?
Yeah that all sounds about right. There's also a REV 1,3, and 5 but I personally haven't seen those at all anywhere and the only reason I know they exist is because the stock firmware has the device tree files for all of the revisions. I need to go look at the files again but at least one of them seems to be a lot different than the others if I remember correctly. If you want to have a look at the device tree files I have them on my GitHub.
Thank you so much for all your work and leadership in bringing it to this stage! Very nicely done. How is the PR3115 submission coming along?
From the posts above, it seems you have had the 256M version of the rav2v1k and the sac2v1k. Have you also had the 512M version? I am not seeing too many posts on that version, even though the OpenWRT TOH device entry for this router only seems to mention this version. Do you know who created that device page (https://openwrt.org/inbox/toh/askey/askey_rt4230w_rev6)?
I created the page actually. I've been using the 512mb rac version. The first and only 256mb version I've used was being rented from spectrum and it was a SAC router. The only time I've ever seen a RAC router with only 256mb is just a day ago when @ghoffman told me about his. The PR hasn't really progressed anywhere and I haven't really gotten an update about whether it can be merged or not in a while.
Thanks. From the pictures you posted, it seems that the board has 2 mPCIe slots for the two WiFi cards. I am guessing the 2 WiFi cards are connected to the CPU over the PCIe bus. However, the mPCIe slot typically makes two buses available to a daughter card - the PCIe bus and a USB bus. I wanted to figure out if any or both of the mPCIe slots have the USB bus lines made available to the daughter card. Based on your work so far, do you have any idea if the USB bus lines are made available in either or both of the mPCIe slots? If not, any ideas on how to find that out?
I honestly have no idea. I know you can stick other mPCIe devices in there and it'll work but don't have any idea about usb. If you can get a Wi-Fi card that also has Bluetooth built in you can probably test using that since the Bluetooth part usually just uses USB.
Do not expect 100% standards compliant mini-PCIe busses in consumer routers, they're not meant to be user-serviceable (USB- or PCIe lanes might be missing, the cards might be oversized, have beyond-standard power-draws/ heat dissipation or repurpose reserved pins; all of the above happens regularly).
@nolseek: as stated by lmore377 - the outside looks the same to me. the router has only 256mb ram. i had to use the sac2v1k boot command to get it to boot correctly.
these are my 3 different RAC2v1k device types from kernel logs, and external markings:::
macronix nand, 512mb: china, factory id 2
macronix nand, 256mb: taiwan, factory id 3
spansion nand, 512mb: taiwan, factory id 3
and my SAC2V1K: Winbond 256mb, taiwan, factory id 3
Agreed. Hence, I was curious on what the state of this router was. Is there any way to determine from kernel logs/information on whether the USB lane is available for either slot?
Thanks for sharing your information! There was a hypothesis floated in one of the posts earlier that the factory id value (printed near the USB slot) varies by memory. Since you have these 3 rac devices, would you mind sharing the factory id values for each of these three? Also, what was the factory firmware version that each of these routers came with?
No, the existence of USB ports in the logs not brought out to external ports does not imply where those are routed to, if at all. Other than carefully using a scope and/ or logic analyzer on the pins (and measuring voltages), as well as trying to follow the traces on the PCB and matching them up with the SOC data sheets, you can only try it (in the full awareness that router and/ or mini-PCIe card might go up in flames in the process).