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.

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.