Curious, is there a reason no PR has been created for this device?
Realtek switch driver needs OEM blob to work; maybe something changed in last 6 months
trying to build a new version and getting this while upgrading
Mon Sep 8 02:31:07 UTC 2025 upgrade: Performing system upgrade...
/lib/upgrade/do_stage2: line 211: mmc_do_upgrade: not found
i checked my upgrade scripts and all seem to be updated to use standard emmc_do_upgrade now
Where does this error coming from? @robimarko ?
Function name is emmc_do_upgrade.
I have tried to read as much of this thread as possible with 1200+ replies, so my apologies if I missed something obvious. I’ve also used the search without success.
I was able to connect an EMMC reader to the traces and dump the flash.
Number Start (sector) End (sector) Size Code Name
1 34 1057 512.0 KiB A012 0:SBL1
2 1058 1569 256.0 KiB FFFF 0:BOOTCONFIG
3 1570 2081 256.0 KiB FFFF 0:BOOTCONFIG1
4 2082 5153 1.5 MiB A016 0:QSEE
5 5154 8225 1.5 MiB FFFF 0:QSEE_1
6 8226 8737 256.0 KiB FFFF 0:DEVCFG
7 8738 9249 256.0 KiB FFFF 0:DEVCFG_1
8 9250 9761 256.0 KiB A022 0:APDP
9 9762 10273 256.0 KiB FFFF 0:APDP_1
10 10274 10785 256.0 KiB A018 0:RPM
11 10786 11297 256.0 KiB FFFF 0:RPM_1
12 11298 11809 256.0 KiB A01B 0:CDT
13 11810 12321 256.0 KiB FFFF 0:CDT_1
14 12322 12833 256.0 KiB FFFF 0:APPSBLENV
15 12834 14369 768.0 KiB A015 0:APPSBL
16 14370 15905 768.0 KiB FFFF 0:APPSBL_1
17 15906 16417 256.0 KiB FFFF 0:ART
18 16418 57377 20.0 MiB FFFF 0:HLOS
19 57378 98337 20.0 MiB FFFF 0:HLOS_1
20 98338 405837 150.1 MiB FFFF rootfs
21 405838 471373 32.0 MiB FFFF 0:WIFIFW
22 471374 778573 150.0 MiB FFFF rootfs_1
23 778574 844109 32.0 MiB FFFF 0:WIFIFW_1
24 844110 1106253 128.0 MiB FFFF rootfs_data
25 1106254 1107277 512.0 KiB FFFF 0:ETHPHYFW
26 1107278 1111373 2.0 MiB FFFF certificate
27 1111374 1115469 2.0 MiB FFFF oops
28 1115470 7552101 3.1 GiB FFFF data
29 7552102 7556197 2.0 MiB FFFF backup_bd
I took the opportunity to rewrite the environment with TestMode=mfg included:
$ mkenvimage -p '\x00' -s 262144 -o cr1000a-mfgenv.bin cr1000a_env.txt
$ dd if=cr1000a-mfgenv.bin of=/dev/sdb14 bs=262144 count=1 # APPSBLENV is U-Boot env
Now, which header is UART? I am assuming it’s the 4 pin J6, since my hardware revision (0.0.C) does not have the unpopulated 6 pin footprint in the lower left. J6 is to the right of the CPU outside the RF shield. I measured 1.7V on pin 3, which I assume is Tx pin (edit: Rx?); 0V on pin 2 (Tx).
However, no one else in the thread ever mentions 1.8V for the UART voltage, as usually it’s 3.3V on embedded devices. Although other IPQ807x devices I’ve looked at have 1.8V IO.
I would appreciate it if someone could reply with:
- UART header
- UART pinout
- UART voltage
Should I be using a 1.8V or 3.3V UART adapter?
Edit: J6 does appear to be UART, Vcc (3.3V), Tx (1.8V), Rx, GND.
My U-Boot (2016.01-v00.06 from Aug 31 2023) doesn’t seem to respect the modified environment I flashed, unless the above mkenvimage command is wrong.
Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic
S - QC_IMAGE_VERSION_STRING=BOOT.BF.3.3.1-00163
S - IMAGE_VARIANT_STRING=HAASANAZA
S - OEM_IMAGE_VERSION_STRING=CRM
S - Boot Config, 0x000002e3
B - 201 - PBL, Start
B - 2736 - bootable_media_detect_entry, Start
B - 24733 - bootable_media_detect_success, Start
B - 24738 - elf_loader_entry, Start
B - 26091 - auth_hash_seg_entry, Start
B - 64161 - auth_hash_seg_exit, Start
B - 78778 - elf_segs_hash_verify_entry, Start
B - 141411 - PBL, End
B - 154909 - SBL1, Start
B - 207644 - GCC [RstStat:0x10, RstDbg:0x600000] WDog Stat : 0x4
B - 214201 - pm_device_init, Start
B - 342118 - PM_SET_VAL:Skip
D - 127429 - pm_device_init, Delta
B - 344558 - pm_driver_init, Start
D - 5215 - pm_driver_init, Delta
B - 350689 - clock_init, Start
D - 2165 - clock_init, Delta
B - 354837 - boot_flash_init, Start
D - 7930 - boot_flash_init, Delta
B - 366549 - boot_config_data_table_init, Start
D - 1037 - boot_config_data_table_init, Delta - (575 Bytes)
B - 374174 - Boot Setting : 0x00000619
B - 378017 - CDT version:2,Platform ID:8,Major ID:1,Minor ID:0,Subtype:14
B - 384940 - sbl1_ddr_set_params, Start
B - 388753 - CPR configuration: 0x30c
B - 392199 - cpr_init, Start
B - 394975 - Rail:0 Mode: 5 Voltage: 784000
B - 400190 - CL CPR settled at 736000mV
B - 402996 - Rail:1 Mode: 5 Voltage: 880000
B - 407175 - Rail:1 Mode: 7 Voltage: 888000
D - 16500 - cpr_init, Delta
B - 414037 - Pre_DDR_clock_init, Start
B - 418063 - Pre_DDR_clock_init, End
B - 421449 - DDR Type : PCDDR4
B - 428494 - do ddr sanity test, Start
D - 1037 - do ddr sanity test, Delta
B - 431910 - DDR: Start of HAL DDR Boot Training
B - 436638 - DDR: End of HAL DDR Boot Training
B - 442341 - DDR: Checksum to be stored on flash is -49502814
B - 452650 - Image Load, Start
D - 348036 - QSEE Image Loaded, Delta - (1384120 Bytes)
B - 800777 - Image Load, Start
D - 366 - SEC Image Loaded, Delta - (0 Bytes)
B - 808311 - Image Load, Start
D - 288743 - DEVCFG Image Loaded, Delta - (32548 Bytes)
B - 1097146 - Image Load, Start
D - 293227 - RPM Image Loaded, Delta - (93060 Bytes)
B - 1390403 - Image Load, Start
D - 311436 - APPSBL Image Loaded, Delta - (557450 Bytes)
B - 1701961 - QSEE Execution, Start
D - 61 - QSEE Execution, Delta
B - 1707756 - USB D+ check, Start
D - 0 - USB D+ check, Delta
B - 1714161 - SBL1, End
D - 1561539 - SBL1, Delta
S - Flash Throughput, 33393 KB/s (2068425 Bytes, 61941 us)
S - DDR Frequency, 600 MHz
S - Core 0 Frequency, 1651 MHz
U-Boot 2016.01-v00.06 (Aug 31 2023 - 08:43:27 +0000)
DRAM: smem ram ptable found: ver: 1 len: 4
2 GiB
NAND: Could not find nand-flash in device tree
SF: Unsupported flash IDs: manuf ff, jedec ffff, ext_jedec ffff
ipq_spi: SPI Flash not found (bus/cs/speed/mode) = (0/0/48000000/0)
0 MiB
MMC: <NULL>: 0 (eMMC)
PCI Link Intialized
In: serial@78B3000
Out: serial@78B3000
Err: serial@78B3000
Console Disable
Here’s the signing cert used for U-Boot:
New Jersey1
Basking Ridge1
Verizon1
Device Technology1402
+CHR2f-A Arcadyan Secure Boot Attestation CA0
240507174351Z
440502174351Z0
US1=0;
4CHR2f-A Arcadyan Secure Boot Attestation Certificate1
Basking Ridge1
Verizon1
New Jersey1"0
01 0000000000000009 SW_ID1"0
02 000DD0E100000000 HW_ID1
04 0000 OEM_ID1
05 000000A8 SW_SIZE1
06 0000 MODEL_ID1
07 0001 SHA2561"0
03 0000000000000000 DEBUG0
New Jersey1
Basking Ridge1
Verizon1
Device Technology1604
-CHR2f-A Arcadyan Secure Boot Root of Trust CA0
201229071241Z
301227071241Z0
New Jersey1
Basking Ridge1
Verizon1
Device Technology1402
+CHR2f-A Arcadyan Secure Boot Attestation CA0
New Jersey1
Basking Ridge1
Verizon1
Device Technology1604
-CHR2f-A Arcadyan Secure Boot Root of Trust CA0
201229071206Z
301227071206Z0
New Jersey1
Basking Ridge1
Verizon1
Device Technology1604
-CHR2f-A Arcadyan Secure Boot Root of Trust CA0
Maybe Verizon removed the ability to enable console through TestMode=mfg? Can someone DM a dump of U-Boot 2016.01-v00.04 (May 06 2022 - 14:40:18 +0800)?
Edit 2: Found the GDrive link and flashed U-Boot 2016.01-v00.04 (May 06 2022 - 14:40:18 +0800). There seems to be no rollback protection. But, it doesn't find MMC:
MMC: sdhci: Node Not found, skipping initialization
MMC Device 0 not found
*** Warning - No MMC card found, using default environment
So it seems 2016.01-v00.04 won't work on hwrev 0.0.C
Can someone run fw_setenv TestMode=mfg and post a dump of their appsblenv please?
use hydra to see if the TestMode options is still there
No idea what hydra is. I dumped appsblenv again and it's been reset to defaults. No TestMode
Ghydra - decompiler. Folks used it here to restore the code. TestMfg was plain text constant. Check respective posts here (search around first mention)
The config partitions gets reset back from backup by OEM kernel if not matches. You can try updating both I guess.
Ah, Ghidra. Yes I am familiar. I threw 2016.01-v00.06 into Ghidra and there were references to TestMode but I didn't feel like cleaning up all the variables to see if there was a comparison to mfg. Since I don't have a console, there is either something wrong with the environment that mkenvimage created (or my usage of the command), or Verizon removed TestMode. Which is why I am asking for an appsblenv dump from someone who has shell access and can set TestMode=mfg because then I can rule out an invalid environment.
The tools needed to access flash on this shouldn't cost more than $25, and you don't need to reball.
Use an Exploiteers Low Voltage EMMC adapter and a Transcend RDF5K reader which can be purchased as new old stock on eBay, make sure the copyright date on the package is ~2016. You want the one that identifies as 8564:4000 (USB vendor:product). Newer models don't support 1-bit MMC mode.
(edit: Hmm, the newer one I have (that doesn’t support 1-bit MMC) uses the same USB vendor/product ID, so better go by the copyright date of the package)
Remove 0 ohm resistor R118 (just above AE text next to the CPU) to disconnect CLK from the CPU to prevent bus conflicts. When you're finished with manipulating EMMC you'll need to put it back (or bridge the pads) to reconnect clock. Beware it's quite tiny.
Power up the router from the AC adapter. Plug in the Transcend USB reader and you should see a USB drive show up. You will need to use dd or similar to write the partitions (appsblenv for U-Boot Environment, appsbl for U-Boot, HLOS for firmware) as they don't have a filesystem on them. gdisk can tell you the partition labels or just refer to my previous post.
Thanks to @hurrian for the U-Boot env dump. Right now, it looks like Verizon updated the devices to defeat the TestMode=mfg bypass previously discovered.
U-Boot 2016.01-v00.06 (Aug 31 2023 - 08:43:27 +0000) contains strings suggesting an additional parameter mt_key is verified, and failing that TestMode is cleared:
Unsupported BOOT flash type
Verifying...
mt_key
pass
fail, clear flag
TestMode
board/qca/arm/common/cmd_bootqca.c
@spol-eff or @meisterlone you previously reverse engineered U-Boot on this device to discover TestMode. I am not that well versed in reversing, if I can provide a dump of U-Boot 2016.01-v00.06 (Aug 31 2023 - 08:43:27 +0000) would you mind having a look at this mt_key verification? From my first look, it seems there are RSA signatures involved and arc_rsa_verify is mentioned:
Unfortunately this seems to be a customization from Verizon/Arcadyan, I looked for other ipq807x u-boot releases on GitHub and cannot find any reference to mt_key or arc_rsa_verify
Since rolling back U-Boot to 2016.01 v00.04 does not work on this hardware, you should refrain from buying hwrev 0.0.C until we know if it can be rooted.
Can you send me the dump? You might be able to patch out that equality check directly in the binary and flash it back.
U-Boot is signed on this platform, no? Patching it would invalidate the signature and I expect it will not boot.
Okay, so we've been stuck on this for some time. Time to PR this device into mainline?
Spent some time refactoring the device support code, currently requesting comments here: link
Sticking points:
- CR1000A BDF pull request is stuck
- Current device package list is kind of crazy, do we need all of this?
ipq-wifi-verizon_cr1000a e2fsprogs kmod-fs-ext4 losetup kmod-ath11k-pci mdio-tools ethtool-full kmod-spi-dev spidev-test kmod-sfp libubox libubus parted f2fs-tools kmod-fs-f2fs lvm2 cryptsetup kmod-dm kmod-dax kmod-leds-fan5646
Note: This still requires you load the OEM RTL9303 switch driver, unless you like having no LAN ports.
I'm all for it
Few more sticking points:
- Moca misses driver (works if you initialize it from in memory one kernel and then soft reboot)
- Aqr 10gb needs firmware loaded via tool too (not sure why it's not loaded from emmc)
- Bdf is old and new one needs some processing via non-public tools
- Initial hardware revisions also had Bluetooth - not supported either.
How do we proceed from here?
I was thinking maybe involving AI to rewrite rtl driver into regmapped version?
-
For the MoCA driver, I don't know why the MxL driver on the latest CR1000A firmware is so big (~2MB?) - afaik, some Asus router just has a small ~600kB kernel driver and the userspace component was semi-open.SEE BELOW -
The eMMC data partition barely contains anything worth keeping (and keeping cryptsetup etc to maintain the OEM keys is a hassle) - thoughts on us just redistributing the
files(RTL SDK driver and AQR fw) folder as a separately-downloadable/flashable image for the eMMC? -
Yep, the whole ath11k situation sucks, we're stuck with a very old BDF. Has anyone dumped the new bdf from the newer firmwares (I think they're on 4.x iirc? The open source dumps don't include it)
-
Anyone have a unit with Bluetooth? I have three of these with different designs (large gray verizon logo, small red verizon logo) but none of them have the Bluetooth section populated.
-
For those with newer units - anyone see EFR32 hardware inside? The newer firmwares (4.x) have EFR32 firmware...
Can anyone on the Verizon network grab a copy of 4.0.22.42?
This is the newest CR1000A firmware with kernel 6.1; it hopefully contains a much newer board.bin.
By the way, for those playing at home - please test my MoCA driver.
- the link is broken - it looks like they started to add some number at the end to prevent guessing?
- will definitely try the MXL driver over weekend! impressive feat!
Just got done testing the preliminary kernel 6.12 build with the mxl driver
Good news:
- It doesn't immediately blow up
Bad news:
- Kernel runs the probe function, but since the "PHY" isn't attached to the real PHY (instead it's attached to the RTL930x switch) it neer calls the config_init function
- WiFi doesn't work, at all. Ath11k firmware issue.