On 7/1/21 3:10 PM, Michael Walle wrote:
Hi Guenter,
Am 2021-07-01 23:34, schrieb Guenter Roeck:
Hi,
On Sat, Apr 24, 2021 at 01:06:08PM +0200, Michael Walle wrote:
Flash OTP regions can already be read via user space. Some boards have
their serial number or MAC addresses stored in the OTP regions. Add
support for them being a (read-only) nvmem provider.
The API to read the OTP data is already in place. It distinguishes
between factory and user OTP, thus there are up to two different
providers.
Signed-off-by: Michael Walle <michael@xxxxxxxx>
This patch causes a boot failure with one of my qemu tests.
With the patch in place, the flash fails to instantiate.
[ 1.156578] Creating 3 MTD partitions on "physmap-flash":
[ 1.157192] 0x000000000000-0x000000040000 : "U-Boot Bootloader"
[ 1.184632] 0x000000040000-0x000000060000 : "U-Boot Environment"
[ 1.201767] 0x000000060000-0x000000800000 : "Flash"
[ 1.222320] Deleting MTD partitions on "physmap-flash":
[ 1.222744] Deleting U-Boot Bootloader MTD partition
[ 1.303597] Deleting U-Boot Environment MTD partition
[ 1.368751] Deleting Flash MTD partition
[ 1.430619] physmap-flash: probe of physmap-flash failed with error -61
-61 is -ENODATA.
Other boot tests with different flash chips can still boot.
Reverting this patch (as well as the follow-up patches) fixes
the problem.
I do not know if this is a problem with qemu or a problem with the
patch, but, as I mentioned, other flash chips do still instantiate.
Do you have an idea what to look for when I try to track down the problem ?
I'd start by looking at the return code of mtd_otp_size() because that
should be the only function which communicates with the flash at probe
time.
Can you share how to reproduce that problem? Like the qemu commandline
and involved images?
qemu-system-arm -M z2 -kernel arch/arm/boot/zImage -no-reboot \
-snapshot -drive file=/tmp/flash,format=raw,if=pflash \
--append "root=/dev/mtdblock2 console=ttyS0" \
-nographic -monitor null -serial stdio
This is with qemu v6.0 and pxa_defconfig. The actual flash image doesn't
really matter (an empty file with a size of 1024*1024*8 bytes is sufficient).
Debugging shows that -ENODATA is reported by cfi_intelext_otp_walk(),
thanks to:
[ 0.737244] #### FeatureSupport: 0x0 NumProtectionFields: 1
which seems to suggest that there are indeed flash chips which don't support
OTP data. With this in mind, is it indeed appropriate to disable support for
all flash chips which don't support OTP data ?
Thanks,
Guenter
