Device only with eMMC [loading ART]

I'm porting a linksys device that only has eMMC available and I'm stuck finding a proper way to expose the partitions to OpenWRT.
Main reason is to be able to load CAL data from ART -- and make it transparent with other MTD dependent tools such as mtd resetbc or the sysupgrade process.

Trying to leverage block2mtd built-in at the kernel level and pass block2mtd and mtdparts does not seem to work -- variables are do passed but the kernel does not contain block2mtd.

Next option was to add it to DEVICE_PACKAGES and thus make it available as a module, but the block2mtd package does not use AUTOLOAD, and changing it will not be device-dependent and potentially break other systems.

Last option that I'm trying is to use the preinit phase, since ATH10k will need CAL data to properly init a wireless driver.
But it does not matter to which step in the preinit process I try to add a hook it is either not invoked or complains about "/dev/mmcblk0" not existing -- maybe /dev is still not populated.

Any idea on how to leverage eMMC only or make it compatible with MTD?


1 Like

Please confirm it's actually built-in properly.

Also see the relevant functions in ... Convention would indicate just loading from eMMC direct would be the logical way to go. ( Thus likely need a new equivalent function here + also in for getmac ).

In other words... emulating mtd is a non-efficient workaround for known/adequate feature-sets.

I might have missed something, but the only option for this target system that contains block2mtd is under kernel modules, which I assume will not be built-in directly into the kernel -- and I did try to select it as built-in but /sys/module/block2mtd does not get populated.

This is how I am actually doing it, using the caldata_from_file instead of caldata_extract and it does work -- with hardcoded block paths.

However I presume it will break other functionality, like proper installation -- being eMMC with GPT means for this device that there are ext4 partitions for the main and alternate FIT, as well as for sysdiag and syscfg.

My assumption is that if it is not emulated, most of the current scripts will need to be adapted to work -- MTD resetbc, access to u_env or s_env, sysupgrade procedures, or even installation.

Is that assumption correct?

1 Like

I'd love to help more... but i'm not a developer.

If you don't get enough input here ask on the mailing list. You might get a response.

As a workaround... you want that built-in... which is typically done with kernel_menuconfig... ( or by hacking target/linux/NAME/config-VERSION )

Hoping you'll get some more help here on the proper way to proceed. Worst case scenario... you have to wait until the developers implement those functions or a similar device gets committed so you have a reference to go by.

1 Like

You need something like I used for Orbi.

And then you plug it into generic function.


This was exactly what I needed.

Unfortunately, while working with mapping u_env partition I've overwritten some bytes in APPSBL and the device won't boot now.
Unless there is a method to restore a backup to APPSBL, I cannot work on it anymore.

Thats why you should always make a full dump before hacking around.

I do have a full dump of the eMMC, but unless there is a way to restore it thru UART, I haven't found a way to interrupt the loader process -- PBL and SBL are not corrupted.

I have not found a JTAG pinout on the board, nor I have found a way to enter EDL -- there are some suggestions to bridge CLK and GND on the eMMC but I should have to trace the pinouts on the PCB as they are not directly exposed.

1 Like

You cant interrupt PBL or SBL and they dont have any rescue utils.
Which Qualcomm SoC is this?

Unless device also has a SPI-NOR you will have a tought time recovering.

It's a IPQ4019 with eMMC -- no NOR or NAND built-in.

Have another device to test with, but I will need to tear this one apart in order to find the right way to recover it.

Is there any way to identify PCB pins to short and force a recovery mode?
What will happen if the PBL cannot find the primary storage device to load SBL?

Again, there is no recovery mode.
Only recovery option from software is U-boot, and if you messed that then you are out of luck.

If PBL cannot find SBL nothing will happen, there will be no output on UART and no booting.
This is a big issue with EMMC only devices as you cant simply reflash them like NOR ones.

I've got a RBR40 (IPQ4019) here with messed up emmc.
It DOES output on UART:

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2020.10.10 12:37:13 =~=~=~=~=~=~=~=~=~=~=~=

Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset),  D - Delta,  S - Statistic
S - Boot Config, 0x00000023
S - Reset status Config, 0x00000000
S - Core 0 Frequency, 0 MHz
B -       261 - PBL, Start
B -      1339 - bootable_media_detect_entry, Start
B -     46422 - bootable_media_detect_success, Start
B -     46436 - elf_loader_entry, Start
B -     49831 - auth_hash_seg_entry, Start
B -     51973 - auth_hash_seg_exit, Start
B -     89854 - elf_segs_hash_verify_entry, Start
B -    203495 - PBL, End
B -    203519 - SBL1, Start
B -    295555 - pm_device_init, Start
D -         9 - pm_device_init, Delta
B -    297062 - boot_flash_init, Start
D -     43273 - boot_flash_init, Delta
B -    344678 - boot_config_data_table_init, Start
D -      4754 - boot_config_data_table_init, Delta - (419 Bytes)
B -    352039 - clock_init, Start
D -      7516 - clock_init, Delta
B -    363746 - CDT version:2,Platform ID:8,Major ID:1,Minor ID:0,Subtype:1
B -    367152 - sbl1_ddr_set_params, Start
B -    372244 - cpr_init, Start
D -         2 - cpr_init, Delta
B -    376627 - Pre_DDR_clock_init, Start
D -         4 - Pre_DDR_clock_init, Delta
D -     13171 - sbl1_ddr_set_params, Delta
B -    389923 - pm_driver_init, Start
D -         2 - pm_driver_init, Delta
B -    461150 - sbl1_wait_for_ddr_training, Start
D -        27 - sbl1_wait_for_ddr_training, Delta
B -    477326 - Image Load, Start
D -     39229 - QSEE Image Loaded, Delta - (262104 Bytes)
B -    516983 - Image Load, Start
D -       899 - SEC Image Loaded, Delta - (0 Bytes)
B -    526828 - Image Load, Start
B -    535390 - Boot error ocuured!. Error code: 3039

In the last line, you see the (not so famous) typo: occurred......
I'm looking to ways to solve this too. As far as I understand now, the PBL is responsible for this output, then SBL1 is found to be corrupted, so boot-process can't continue.

I somehow need to get into EDL now.... Looking for a "howto"

You have a device with a corrupted U-boot, your PBL and SBL are fine.
SBL1 is the one printing this, 3039 means corrupted U-boot.

Well, only DK04 boards have a recovery mechanism in SBL, others don't and you have to reflash the bootloader directly onto the flash storage via external programmers.

If the board is DK04 reference based then USB boot can be forced via bootstrap and then QCA tools that are not public can be used to reflash everything.

Okay, thanks for clarifying this.
It's an EMMC, shouldn't be too difficult to figure out the traces going to it.

What would be the best approach to actually flash the U-Boot partition?
Just pick an Orbi-firmware and find the right partition?
I'm quite a novice on the EMMC-part, but know my way in the hardware-part (I guess).

You can build the U-boot from Netgear GPL from source.
Best would be to dump the whole EMMC and then only reflash the APPSBL partition with the freshly built U-boot

Okay, then I'll have to dive into the building (Openwrt-) process.
Thanks again. Will let you know any progress.

You need to build U-boot from the GPL sources that Netgear releases for each model, not OpenWrt

I'm sorry, was under the impression that parts of the GPL-code from Netgear was incorporated into the Openwrt-Build. As the Openwrt-process is documented, I tended to leaning on them.

As said, I'm a novice finding it's way, but e-learning by every step......

No, you can get it from here:

Great, once more: thanks!

I've also got other RBR40's and an RBR50 that do not give any response on the UART once activated.
Checked all voltages and oscillator already, all are fine.
Apart from hardware-error (damaged CPU or bad soldering joints under it), that might also point to corrupted EMMC, f.e. the PBL and SBL1, right?