Re: [PATCH v2 0/2] mtd: devices: Qualcomm SCM storage support

[Val Packett]

On 2/3/26 11:20 AM, Miquel Raynal wrote:

> > > > For something like the "DPP" partition, I think it's better to access it
> > > > from userspace than from kernel.
> > > If it's a MAC address that you are accessing, direct userspace does not
> > > sound like a good fit. If I may, NVMEM cells are there exactly for this
> > > purpose: identifying the content of a subpart of a storage device in a
> > > storage agnostic way. The NVMEM cells are made available to in-kernel
> > > drivers (ie. network devices have all the infrastructure to get the MAC
> > > address from there) and their content is also exposed to userspace
> > > through sysfs now.
> > Qualcomm's SPI-NOR boot firmware uses a GPT partition table. The "DPP"
> > partition contains a FAT file system, and the MAC address is stored in
> > one of these files.
> >
> > Because the data is stored inside a filesystem rather than at a fixed
> > offset, it does not fit well with the NVMEM model, which assumes simple
> > offset-based access.
> Not anymore, there are nvmem layouts now that are much more
> flexible, so if a network driver shall get this MAC address, it is still
> doable.
>
> Otherwise there is no such need, and in the case of a file in a FAT
> filesystem, I guess it is preferable to use mtdblock/ubiblock in order
> to expose a block device and mount it from userspace.
>
> Please note that exposing a FAT filesystem on top of a SPI NOR is very
> inappropriate. FAT is a block filesystem, not aware of all the MTD
> specificities (like bad blocks).

FWIW there is an existing widely used solution (workaround?) for the MAC 
address: dtbloader reads the DPP partition in UEFI and applies the MAC 
address as a DT fixup.

https://github.com/TravMurav/dtbloader/blob/493e7e82025edddab29fe99c2b6ec566f6e01ac1/src/qcom.c#L260

(But this means that any dtbloader alternative such as the systemd UKI 
stub must also implement the same thing, which is not great.)

Reading that code, it does not seem to be a FAT filesystem exactly? It's 
something called "RWFS" where files have 49-char long names and a 
49-char "vendor" string field that's either "QCOM" or "OEM".


Also on the rare older devices that have SNOC WiFi/modem but NVMe 
storage —basically the Surface Pro X— the modem partitions need to be 
accessed from userspace (rmtfs) and they're stored on the NOR flash. 
Well, at least in the WiFi-only case even blank files are enough to 
replace them :) but for cellular I think the IMEI and stuff is there..


So this all sounds supremely annoying, we have a GPT partitioned flash 
where some specific partitions should be given to the WiFi&BT drivers 
(as nvmem cells?) but others should be accessible as mtdblock devices in 
userspace >_<


~val