On 3/22/24 11:02, Daniel Golle wrote:
On Fri, Mar 22, 2024 at 10:52:17AM -0700, Bart Van Assche wrote:
On 3/21/24 12:31, Daniel Golle wrote:
On embedded devices using an eMMC it is common that one or more (hw/sw)
partitions on the eMMC are used to store MAC addresses and Wi-Fi
calibration EEPROM data.
Implement an NVMEM provider backed by a block device as typically the
NVMEM framework is used to have kernel drivers read and use binary data
from EEPROMs, efuses, flash memory (MTD), ...
In order to be able to reference hardware partitions on an eMMC, add code
to bind each hardware partition to a specific firmware subnode.
Overall, this enables uniform handling across practially all flash
storage types used for this purpose (MTD, UBI, and now also MMC).
As part of this series it was necessary to define a device tree schema
for block devices and partitions on them, which (similar to how it now
works also for UBI volumes) can be matched by one or more properties.
Since this patch series adds code that opens partitions and reads
from partitions, can that part of the functionality be implemented in
user space? There is already a mechanism for notifying user space about
block device changes, namely udev.
No. Because it has to happen (e.g. for nfsroot to work) before
userland gets initiated: Without Ethernet MAC address (which if often
stored at some raw offset on a partition or hw-partition of an eMMC),
we don't have a way to use nfsroot (because that requires functional
Ethernet), hence userland won't come up. It's a circular dependency
problem which can only be addressed by making sure that everything
needed for Ethernet to come up is provided by the kernel **before**
rootfs (which can be nfsroot) is mounted.
How about the initial RAM disk? I think that's where code should occur
that reads calibration data from local storage.
Thanks,
Bart.
