Spectrum SAX1V1K is an interesting device. It’s a rebranded (and redressed, meaning, put in a different case) Askey RT5010W (based mainly on Qualcomm componentry). The form factor is tower. There’s decent processing capacity (quad-core ARM Cortex-A53 processor running at 2.2 GHz), ample memory (2 GB), and good networking (2.5-gig WAN port, three Gigabit LAN ports, dual-band wireless with 4x4 AX working in each band). To make all this work in a tower form factor, the device has a fan (which, truth be told, is off most of the time); the intake openings are on the bottom of the device, the grill on the top is the exhaust.
In its stock form, the device runs proprietary Spectrum firmware (Spectrum is an ISP, so they put out firmware that ties the device both to their service and to their mobile app). Long story short, if there ever was a device that could benefit from OpenWrt conversion (good hardware + restrictive stock firmware), this one is it.
The conversion procedure is described in detail on the device page; briefly, it works like this:
- You disassemble the device and connect a UART console cable to openings in the system board using breadboard wires
- You make a console connection to the device at 115200 bps
- You turn the device on and let it boot all the way
- Once the boot sequence is complete, you log in as
rootusing the device’s serial number as password (note that at this stage, the device is functional and can access the Internet if connected) - After logging in, you run a U-Boot configuration script by Lanchon (this is the stage to which the hack I am about to describe pertains)
- After the script is finished, you reboot the device, interrupt the boot, and load OpenWrt kernel via TFTP
- Once the device is running OpenWrt kernel, you execute a sysupgrade, which installs the complete firmware
Problems sometimes arise when you run the U-boot configuration script. The script requires that two partitions on the device’s eMMC module, /dev/mmcblk0p15 and /dev/mmcblk0p16, be identical. If they are not, you can copy one over the other, thus fixing the problem. Then, the script does slightly different things depending on the version of the stock firmware, determined based on the checksum of those partitions.
So far so good, but occasionally, the script encounters a version of stock firmware it cannot recognize, so it can’t proceed with re-configuration. The advice the script gives you is, make a dump of one of those partitions, post it on the support forum, and let those in the know help you. Yesterday, this happened to me. This was my fourth SAX1V1K device; first three were converted with zero issues. So here’s what I did rather than bother those in the know.
One. I made a dump of one of those partitions on another SAX1V1K:
dd if=/dev/mmcblk0p15 of=/tmp/15.img
It’s a single file about 2 MB in size (I called it 15.img). Note that I did it on a device that already ran OpenWrt; the two partitions in question appear to hold copies of U-boot and are not overwritten by OpenWrt (OpenWrt appears to use other partitions).
Two. I put that file on an HTTPS-accessible machine (for illustration purposes, let’s say the file ended up accessible as https://example.com/randomFiles/15.img).
Three. After logging in as root, but before running U-Boot setup, I did:
cd /tmp
wget https://example.com/randomFiles/15.img
dd if=15.img of=/dev/mmcblk0p15
dd if=15.img of=/dev/mmcblk0p16
I can’t remember if I had to reboot at this point (I may have rebooted reflexively even if I didn’t have to). One way or another, at that point, I had U-boot partitions that looked familiar to the re-configuration script, so it was able to run and do its work.
If you get stuck in this situation and don’t have a second device to fall back on, shoot me a private message; I’ll be happy to share my 15.img with you. Also, if there’s anywhere public I can put this file without it expiring, let me know, I’ll do that.