Askey RAC2V1K / RT4230W REV6 Support

You'll need to crack it open, connect a USB to serial adapter and just follow the instructions for the SAC model. You should be up and running in no time after that

1 Like

Thanks @lmore377! Was hoping I could avoid the UART route. At least the pin header is already there!

Hi all.. :grinning:
Just to let you know...there is a revision of RAC2V1K with 256 NAND
I received my device today, the lower code is RAC2V1K and no qr code on top part with wifi passwords and an ip adress for the local web interface

I tried lmore377 1st method and got error related to NAND size then soldered a usb serial adapter and used the 2nd method for the SAC2V1K and everything went smoothly

Thank you all for your wonderful support and contribution to OpenWrt community
Regards

hi,

has anybody tried the RAC2V1A? i bought a new RAC2V1K (no QR) and was sent an A instead. obviously this would need serial to root (if it works). but i don't want to open since i'll try to return it. has anybody tried initramfs? what about flashing? thanks!

re RAC2V1A:

i found this commit:

it says:

This commit add support for Arris RAC2V1A (aka TR4400-AC).

Hardware specs:
SoC: Qualcomm IPQ8065
RAM: 256 MB DDR3
Flash: 512 MB NAND
WiFi1: Qualcomm QCA9983 2.4 GHz
WiFi2: Qualcomm QCA9984 5 GHz
Ethernet1: AR8033 PHY -> Wan
Ethernet2: QCA8337 Switch -> Lan 1~4
LED: Status (red / blue)
USB: 1x USB 3.0 Type-A
Button: Reset, WPS
Power: DC 12V,2.5A

Installation:
Interrupt U-Boot, tftpboot initramfs image,
than sysupgrade to openwrt.

Very thanks for asushugo's help.

EDIT

it seems to require a taylored arris-rac2v1a build, doesn't it?

I would return it to the seller for a full refund if you are able to do so. Even if the seller advertised "no returns accepted," ebay will accept returns if an item is not described correctly. In most cases, I doubt this is just an innocent seller mistake.

As an example with another device, I have noticed many Linksys EA6350 for sale on ebay labeled "V3", which is supported by OpenWrt, but if I ask the Seller for a photo of the bottom of the device first (and sometimes when the photo of the bottom is already on ebay), it is obviously a V1 or V2 that is not supported by OpenWrt. Of course the V3 sell for more money, so the seller thinks...why not lie in the ebay description? I was fooled one time and sent it back - ever since, no proof of version, no sale.

I would return it to the seller

thanks. the problem is two fold: 1) i'm in Argentina, and somebody had to hand carry that heavy router to me from the US. i'd need to find and bother another friend who'd go to the US and carry it and post it. 2) it's already past the return date, cause it took a while for the router to reach me here. i don't think that 2 is too much of a problem given the item not as described thing, but i still need to get it back into the US to return it. i'd rather the seller and me split it and refund half, and maybe i can sell it here then.

Curiosity got the better of me and I picked one of these up to flash. RAC2V1K, Factor ID 3, no QR code, 1.1.31 OEM firmware version. Method 1 worked great to a point - I uploaded the 1.1.28 config, got ssh access, served up initamfs.bin with a tftp server and had OpenWrt installed in memory. Nice slow blue light on the unit.

I'm wondering if I botched it when I did the sysupgrade (with the OpenWrt sysupgrade image next) without "-n" to not keep settings. I've got a fast blue light now, no access to the device, reset button doesn't do anything, power off/on doesn't do anything.

Can anyone comment on whether it was keeping settings on the sysupgrade that did this, or is this more likely a sign that I have a unit with only 256 MB of flash, and I need to use the SAC2V1K method 2?

@ashr When you ran into your issue above, did you get a fast blue light?

Use method 2 and you will be OK

from: https://openwrt.org/inbox/toh/askey/rt4230w_rev6

I tried backing up/restoring the original parts but it caused the ubi partition for overlay to become corrupted so settings would be cleared after a reboot. If you come up with a solution to safely backup and restore the router, please post it [here]

here is how you backup an ubi mtd partition:

  1. find out which ubi device is attached to the mtd partition:
dmesg | grep mtdXX
  1. if the partition is not attached, you must attach it:
ubiattach /dev/mtdXX
  1. you have to backup the contained volumes, not the ubi partition itself. attaching an ubi partition creates devices for its volumes. gather info about the partition volumes and save it with the backups:
ubinfo /dev/ubiYY -a
  1. use dd to backup the contents of each volume /dev/ubiYY_*. (as with all volumes, ubi volumes should be unmounted or snapshoted before backing up in order to guarantee consistency.)

  2. when restoring the backup, you will need to recreate the ubi partition and all volumes, and restore the contents of each volume. the ubi volumes must not be mounted:

ubiupdatevol /dev/ubiYY_N dd-image.bin

alternative

there is a way to restore a full ubi partition in one go with:

ubiformat /dev/mtdXX -f image.bin

but i'm not sure that dd would create a valid image for that. i have not tested or read about it, but it makes sense due to the way ubiformat works.

note: in all cases, when creating dd images you may need to skip over read errors.

I'm wondering if I botched it when I did the sysupgrade without "-n"

no. the ubi partition size is completely different between the routers. and unfortunately the partition is described within the image instead of being passed by the bootloader in the kernel command line (which would allow the same image to be shared).

i dont think the current image will work. i think you bricked by following the posted instructions. i think the only way to restore (since you didn't backup ubi i assume) is to wait for an image specifically made for your router revision and install it via bootloader. in the meantime, you are out of luck.

I forgot exactly where I mentioned it (might be the device page) but on the routers with a smaller flash the linux kernel automatically detects that it's smaller during boot and shrinks the size of the last partition down to make it fit properly. He probably just used the wrong bootcmd and all he needs to do is hook up to the serial console and he should be able to recover it

Thank you - that will be what I try next: "method 2" from the serial console, and instead use the smaller flash bootcmd. It will be a week before I have time to try, but I will report back success/fail.

I went into this viewing it as a 50/50 proposition - not too worried about the $25 I have in this unit. It's not like it could get any worse, so time to crack open the case and break out the USB to serial dongle :wink:

EDIT: IMPORTANT: THIS POST IS WRONG!
i was mistaken about the format of U-Boot's mtdparts. i thought it was address-then-length, but it is actually length-then-address, as explained by @lmore377 . this made me think that U-Boot's configuration was incorrect and that it might sometimes not find all the blocks of the kernel and fail to boot. i was wrong, so disregard this post.


on the routers with a smaller flash the linux kernel automatically detects that it's smaller during boot and shrinks the size of the last partition down to make it fit properly

if anyone has pointers for that info, please post.

He probably just used the wrong bootcmd and all he needs to do is hook up to the serial console and he should be able to recover it

assuming that openwrt really does shrink the last partition as used by the kernel if necessary: rereading @eginnc 's post, he clearly stated he used method 1. method 1 after ram boot says:

fw_setenv bootcmd "setenv mtdids nand0=nand0 && set mtdparts mtdparts=nand0:0x1A000000@0x2400000(firmware) && ubi part firmware && ubi read 0x44000000 kernel 0x6e0000 && bootm"

clearly this is what bricked the router. it should be a different command for smaller flash. the router could maybe be recovered just by setting the correct variable in the bootloader ( setenv bootcmd ...) without flashing anything if the start addrress of the ubi partition in that's roter stock fw is the same as the 512 MiB one.

this is an error in the instructions now. both method 1 and 2 need to be updated with the proper data for the 256 MB version of RAC2V1K. we need a stock bootlog (dmesg is ok) of one of those units for that. in the meantime, both methods should state that if the flash is not 512 MB, users should not flash anything.

also, since in SAC2V1K the ubi partition has a different start address, no amount of partition shrinking on boot would work, so instructions should say don't flash!

it is unfortunate that the image is built ignoring the kernel command line and with a rigid predefined partition layout, when the kernel command line could easily be used to define the one single partition that linux needs. and nothing is gained since uboot needs to know about this partition, so now it has to be configured in 2 places instead of one, and requires building separate images for different partitions layouts. maybe this can be changed. hard-set partitions were used before ubi, but now they don't make much sense.

but besides all that, there is something else really weird here...

both method 1 and 2 use this definition for the ubi partition in U-Boot:

mtdparts=nand0:0x1A000000@0x2400000(firmware)

however the openwrt bootlog posted on this device's wiki shows that the device maintainer merged the 3 last mtd partitions into a giant one:

[    1.172730] 21 fixed-partitions partitions found on MTD device qcom_nand.0
[    1.180069] Creating 21 MTD partitions on "qcom_nand.0":
[...]
[    1.302174] 0x000002400000-0x00001c400000 : "ubi"

which does not match U-Boot at all.

it contains 3 volumes: kernel, rootfs, and rootfs_data (the overlay)...

[    3.205908] UBI: auto-attach mtd20
[    3.205928] ubi0: attaching mtd20
[    6.205951] ubi0: scanning is finished
[    6.217200] ubi0: attached mtd20 (name "ubi", size 416 MiB)
[    6.217222] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[    6.221641] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[    6.228567] ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
[    6.235370] ubi0: good PEBs: 3328, bad PEBs: 0, corrupted PEBs: 0
[    6.242217] ubi0: user volume: 3, internal volumes: 1, max. volumes count: 128
[    6.248471] ubi0: max/mean erase counter: 3/1, WL threshold: 4096, image sequence number: 4294007684
[    6.255513] ubi0: available PEBs: 0, total reserved PEBs: 3328, PEBs reserved for bad PEB handling: 80
[    6.264972] ubi0: background thread "ubi_bgt0d" started, PID 92
[    6.265600] block ubiblock0_1: created from ubi0:1(rootfs)

[    6.279798] ubiblock: device ubiblock0_1 (rootfs) set to be root files�[    6.296749] VFS: Mounted root (squashfs filesystem) readonly on device 254:0.

[   14.064216] UBIFS (ubi0:2): UBIFS: mounted UBI device 0, volume 2, name "rootfs_data"
[   14.067505] UBIFS (ubi0:2): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[   14.075436] UBIFS (ubi0:2): FS size: 401371136 bytes (382 MiB, 3161 LEBs), journal size 20062208 bytes (19 MiB, 158 LEBs)
[   14.085359] UBIFS (ubi0:2): reserved for root: 4952683 bytes (4836 KiB)
[   14.096256] UBIFS (ubi0:2): media format: w4/r0 (latest is w5/r0), UUID 826F022A-2D23-492F-ABAA-A6C5A84D1222, small LPT model
[   14.107838] mount_root: switching to ubifs overlay

note that real ubi is 416 MiB, but ubi as seen from the bootloader is the last 36 MiB of those. if the kernel is not there, the router bricks! even if written there, ubi will move it around for wear leveling. and if upgrading, it will write it anywhere else in ubi.

so i think all these devices will brick soon if not fixed. (unbricking would require serial to change uboot environment)

even the published bootlog says the maintainer unit's U-Boot does indeed know about the full ubi:

Creating 1 MTD partitions on "nand0":
0x000002400000-0x00001c400000 : "mtd=0"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    126976 bytes
UBI: smallest flash I/O unit:    2048
UBI: VID header offset:          2048 (aligned 2048)
UBI: data offset:                4096
UBI: attached mtd1 to ubi0
UBI: MTD device name:            "mtd=0"
UBI: MTD device size:            416 MiB

so it seems the bootloader environment should be changed:

from this: mtdparts=nand0:0x1A000000@0x2400000(firmware)
to this:   mtdparts=nand0:0x2400000@0x1A000000(firmware)

i think people should run this command via SSH in their routers ASAP before they brick and require serial access:

fw_setenv bootcmd "setenv mtdids nand0=nand0 && set mtdparts mtdparts=nand0:0x2400000@0x1A000000(firmware) && ubi part firmware && ubi read 0x44000000 kernel 0x6e0000 && bootm"

but i don't have any of these devices and i don't have experience in these matters either, just started looking into router booting yesterday, so wait for the maintainer's word.

If the flash size can be identified by opening the device first, a quick temporary band-aid might be a large bold warning at the top of the flash instructions to do so - open the case and determine the flash size from the chips on the board - and do not proceed or proceed differently if 256 MB. I'll take a look at the chips and see if I can determine if this is possible when I open it up.

FWIW, I picked up two of these used from different sellers, and Method 1 worked fine on the first, which had OEM firmware 1.1.16 installed on it. The second one, as is already noted, is bricked and awaiting me trying to get serial access to try Method 2 with the 256 MB flash bootcmd failing any better next option.

It's the same start address on both variants

This is how the stock firmware and the device I referenced during development (r7800) does it.

Edit: I was somewhat wrong about the stock fw. In the space where I put openwrt, the stock firmware has 2 copies of itself for redundancy then the ubi partition for storing user data. When booting up the proper way with bootipq, u-boot does some signature verification and makes sure that the images are signed by askey. I couldn't figure out how they sign their images so I decided to just wipe all 3 partitions and go with one big one that openwrt sits in which allows for a much easier boot/update process and gives an extra ~135MB of free space to the user for packages or other stuff.

The bootloader is in APPSBL which is near the beginning of flash and wayyyyyyy before anywhere close to the ubi partition. The "firmware" partition is openwrt itself (I'd recommend looking at this page).

Edit: u-boot is actually in APPSBL_1. It doesn't really matter that much since it's still outside of the ubi partition and locked from writing by default but I thought I'd correct myself.

I've been running one of these routers as my daily driver with this firmware since it got accepted into the snapshot builds 9 months ago with biweekly firmware upgrades. No brick so far.

I don't think you understand how the mtdparts variable works. 0x1A000000 is the size of the partition (for 256mb routers it's 0xDC00000) and 0x2400000 is the start of it. If you change this then routers will ACTUALLY soft brick and require serial access.

Then don't spread false info until you have hardware in hand to test with. If you actually scroll back a bit in this post there's a couple mentions of openwrt running perfectly fine on router's with smaller flash

I will admit that I personally haven't ran one of the small flash routers for a long time at all but as mentioned before other people have reported success with it.

One more point, everything in the flash before 0x2400000 is pretty much all the bootloader related which I absolutely do not want to mess with whatsoever out of fear of causing routers to actually hard brick themselves so I set that all to read only in the device tree. I had actually considered not including those partitions at all but decided it'd be best to include them to give users freedom to do what they want with it (they can be unlocked with mtd unlock)

1 Like

I have a few of these devices. they are the workhorses of my homenetwork in various configurations of router and AP, and at least one has he smaller RAM size. i've sysupgraded 20+ times on each of these after following instructions from @lmore more than a year ago.
maybe i've been lucky -? - but these things have been rock-stable.
to avoid bricking smaller devices, wouldn't it just be safer to assume the device has a smaller RAM footprint to start? maybe the default u-boot command should have that. i had expedimented with a 'smart' u-boot command a while ago but now i can't find it.
i'm not a whiz at u-boot but can manage to set those commands. UBI is almost completely incomprehensible to me. these caveats, i'd be happy to try a few things. i'm out of town for a few days so i can try things and report back once this discussion settles out.
thanks!

A bootlog from the 512mb variant is available on the device page and I might have one from a 256mb variant but I need to look around for it

If the flash size can be identified by opening the device first

the flash size is known. the bootloader outputs as soon as it wakes up:

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 0x177d as machine type from smem
NAND:  SF: Unsupported manufacturer 00
ipq_spi: SPI Flash not found (bus/cs/speed/mode) = (0/0/48000000/0)
512 MiB

or if you have access to the running kernel, then dmesg has this:

[    1.749411] Found a supported NAND device
[    1.753280] NAND Controller ID : 0x4030
[    1.757003] NAND Device ID  : 0x1590ac01
[    1.760911] Buswidth : 8 Bits
[    1.763932] Density  : 512 MByte

The second one, as is already noted, is bricked and awaiting me trying to get serial access to try Method 2 with the 256 MB flash bootcmd

possibly you just have to set the right BL variable value. no need for cumbersome tftp. at least try it first. but you need serial to debrick if you can't reach a kernel.

gotcha, thanks!! ok i thought it was address then size as everywhere else, that explains everything. yes, this is my very first contact with u-boot.

i assumed that from misreading your mtdparts variables. (i've never seen a boot log of the SAC2V1K.)

as per your posted stock bootlog:

[    1.981909] 0x000002400000-0x00000a400000 : "rootfs_1"
[    2.231398] 0x00000a400000-0x000012400000 : "rootfs"
[    2.536315] mtd: device 21 (rootfs) set to be root filesystem
[    2.541506] mtdsplit: no squashfs found in "rootfs"
[    2.546437] mtdsplit: no squashfs found in "1ac00000.nand"
[    2.551363] 0x000012400000-0x00001c400000 : "ubifs"

in stock there are 2 rootfs of 128 MiB each, plus an ubifs of 160 MiB. you replaced those 3 with a single 416 MiB ubi. this means that the A/B dual system for recovery is lost. but at least you still have dual bootloaders. if one should fail you can still recover via serial.

I couldn't figure out how they sign their images

in stock those 3 partitions are ubi. the rootfs each have kernel, rootfs, and rootfs_data volumes inside. (the ubifs has a "log" volume.) i supposed you noticed this? if you just laid a regular kernel+initram in there it would have failed to boot.

so I decided to just wipe all 3 partitions

or dual boot could have been implemented. two var save the commands to boot each system and the boot command is simply a run var command. but who wants that... :slight_smile:

sorry, i meant the kernel. (the BL is in ROM in the CPU plus in partitions SBL1, SBL2, SBL3, and APPSBL plus some extra data parts, not counting the TrustZone parts which might be required for booting, plus copies of all these partitions due to the A/B system (except SBL1)).

but again this comment stemmed from my lack of understanding of the format of the mtdparts variable.

i wrote sort of a gparted for android that can safely resize and move partitions around without loosing their data that was ported to a lot of devices. at one point in time, qualcomm started signing and enforcing even the partition table contents, even for bootloader unlocked devices (because the unlock flag is saved in a partition so they don't know if it's unlocked when reading the GPT, and they wanted to reduce attack surface while booting so no processing the GPT unless it is known and thus not evil). that was the end for that tool. so yeah, i know how picky these things can be about their chain of trust stuff.

i know, that is how i was looking into all this. (i don't have any of these devices. i have an Arris RAC2V1A, totally different beast. an ebay seller sent this crap instead of the promised RAC2V1K.) i though the partitions of the RAC2V1S were substantially different (again, my misundertanding of mtdparts). i imagine only difference is that rootfs ubis are 64 MiB each instead of 128 and that's it. no need for a bootlog.