Nice, I've quickly applied this patch, it indeed fixed a bunch of missing
things, however, something about the partitioning is still missing.
I have a SPI NOR device, which has two partitions, one for the bootloader and
one for the rootfs. The rootfs is populated with a squashfs that u-boot can
also read (works with MMC).
The MTD block device now registers, but the partitioning isn't hooked up
properly yet. The MTD partitions don't appear until I run the "mtd list"
command. And attempting to access the partitions also doesn't work.
Example serial session:
ZynqMP> part list mtd 0
Partition Map for mtd device 0 -- Partition Type: MTD
ZynqMP> mtd list
List of MTD devices:
* nor0
- device: flash@0
- parent: spi@ff0f0000
- driver: jedec_spi_nor
- path: /axi/spi@ff0f0000/flash@0
- type: NOR flash
- block size: 0x20000 bytes
- min I/O: 0x1 bytes
- 0x000000000000-0x000010000000 : "nor0"
- 0x000000000000-0x000000180000 : "qspi-boot-bin"
- 0x000000180000-0x000010000000 : "qspi-rootfs"
ZynqMP> part list mtd 0
Partition Map for mtd device 0 -- Partition Type: MTD
- 0x000000000000-0x000000180000 : "qspi-boot-bin"
- 0x000000180000-0x000010000000 : "qspi-rootfs"
ZynqMP> ls mtd 0:2
** Invalid partition 2 **
Couldn't find partition mtd 0:2
ZynqMP> ls mtd 0:1
** Invalid partition type "" (expect "U-Boot")
Couldn't find partition mtd 0:1
On 9/17/26 08:59, Vandhiadevan Karunamoorthy wrote:
This series lets SPI-NOR flash be exposed through the existing MTD
block (UCLASS_MTD) device, so it can be partitioned with a standard
GPT/MBR table and addressed like any other block device (e.g. by
fastboot, "part", or "gpt" commands), instead of requiring the
mtdparts= command-line partitioning scheme.
Patch 1 is a standalone bugfix: mtd_blk_probe() never set
bdesc->lba, so any MTD-backed block device reported zero blocks and
could not be scanned for a partition table. This affects all MTD
block devices, not just SPI-NOR.
Patch 2 wires sf_probe.c to bind the SPI-NOR device into the MTD
block subsystem via the existing mtd_bind() (no signature change),
using a fixed 4 KB logical block size (new CONFIG_MTD_BLOCK_SIZE
Kconfig value) instead of mtd_bind()'s 512-byte default, matching the
sector size GPT images are generated with.
Patch 3 fixes blk_get_devnum_by_uclass_idname() so a block device
whose declared uclass_id (UCLASS_MTD, set by mtd_bind()) differs
from its parent's uclass (UCLASS_SPI_FLASH) can still be looked up by
interface name -- required for the "mtd" interface to work at all
via the generic block lookup helpers.
Patch 4 is a standalone bugfix found while validating this series:
part_init() takes a fast path when a block device's part_type is
already cached (e.g. PART_TYPE_MTD from a prior probe), so a GPT
written via fastboot to a previously-probed SPI-NOR block device
kept reporting the stale MTD type instead of switching to EFI. Force
re-detection after writing a new GPT so the device is recognized
correctly on the next partition lookup.
No existing API signatures are changed and no new Kconfig-gated
behavior is introduced for devices that don't opt in.
---
To: [email protected]
To: Takahiro Kuwano <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Vignesh R <[email protected]>
Cc: Javier Martinez Canillas <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Anurag Dutta <[email protected]>
Cc: Michael Trimarchi <[email protected]>
Cc: Udit Kumar <[email protected]>
Signed-off-by: Vandhiadevan Karunamoorthy
<[email protected]>
---
Vandhiadevan Karunamoorthy (4):
mtd: mtdblock: fix lba not being set on MTD block devices
mtd: spi: sf_probe: bind SPI-NOR into MTD block subsystem
blk: uclass: dispatch UCLASS_MTD lookups by block descriptor
disk: part_efi: force partition re-detection after GPT write
disk/part_efi.c | 2 ++
drivers/block/blk-uclass.c | 3 +++
drivers/mtd/Kconfig | 9 +++++++++
drivers/mtd/mtdblock.c | 2 ++
drivers/mtd/spi/sf_probe.c | 35 +++++++++++++++++++++++++++++++++++
5 files changed, 51 insertions(+)
---
base-commit: a57e30ef46731309e7120d2900d294ac934f7609
change-id: 20260824-series1-spinor-mtd-gpt-c3694cb91fa7
Best regards,
--
Vandhiadevan Karunamoorthy <[email protected]>
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: [email protected]
W: www.topic.nl
Please consider the environment before printing this e-mail
