On 6/9/25 08:16, Usyskin, Alexander wrote:
Subject: Re: [PATCH v6 01/11] mtd: core: always create master device

On 6/9/25 05:23, Usyskin, Alexander wrote:
Subject: Re: [PATCH v6 01/11] mtd: core: always create master device


Several of my qemu boot tests fail to boot from mtd devices with this
patch
in the mainline kernel. Reverting it fixes the problem. As far as I can
see this affects configurations with
CONFIG_MTD_PARTITIONED_MASTER=y
when
trying to boot from an mtd partition other than mtdblock0, with the
mtd partition data in devicetree (.../aspeed/openbmc-flash-
layout.dtsi).
Is there a guidance describing the changed behavior, by any chance,
and how the boot command line now needs to look like when using
one
of
the flash partitions as root file system ?

Thanks,
Guenter

I've tried to make is as transparent as possible for the existing users.
Only change is that now every partition has master that is not
partitioned.
Is the CONFIG_MTD_PARTITIONED_MASTER=n fixed the problem for
you?
No change is expected, can you please describe the devices that you
observe with and without the patch? Maybe there is something wrong in
the core logic.


I am trying to boot supermicro-x11spi-bmc in qemu from flash partition 6.
The qemu command line is something like

      qemu-system-arm -M supermicro-x11spi-bmc,fmc-
model=n25q256a13,spi-model=n25q256a13 \
        -kernel arch/arm/boot/zImage -no-reboot -snapshot \
        -audio none \
        -drive file=/tmp/flash,format=raw,if=mtd,index=1 \
        -nic user \
        --append "root=/dev/mtdblock6 rootwait console=ttyS4,115200
earlycon=uart8250,mmio32,0x1e784000,115200n8" \
        -dtb arch/arm/boot/dts/aspeed/aspeed-bmc-supermicro-x11spi.dtb
\
        -nographic -monitor null -serial stdio

This is with aspeed_g5_defconfig. Note that the flash models need to be
specified.
The default flashes are no longer recognized when booting from qemu
since
commit
947c86e481a0 ("mtd: spi-nor: macronix: Drop the redundant flash info
fields").

The above only works with this patch reverted (or with v6.15 and older, of
course).

Guenter

Alexander, can you please investigate? We need a fix because Guenter
might not be the only affecter user. Otherwise this patch can't stand,
unfortunately.

Thanks,
Miquèl

Maybe something is moved, and it is not /dev/mtdblock6 now.


With this patch:

# ls -l /dev/*mtd*
crw-------    1 root     root       90,   0 Jan  1 00:00 /dev/mtd0
crw-------    1 root     root       90,   1 Jan  1 00:00 /dev/mtd0ro
crw-------    1 root     root       90,   2 Jan  1 00:00 /dev/mtd1
crw-------    1 root     root       90,   3 Jan  1 00:00 /dev/mtd1ro
crw-------    1 root     root      244,   0 Jan  1 00:00 /dev/mtd_master0
crw-------    1 root     root      244,   1 Jan  1 00:00 /dev/mtd_master1
brw-------    1 root     root       31,   0 Jan  1 00:00 /dev/mtdblock0
brw-------    1 root     root       31,   1 Jan  1 00:00 /dev/mtdblock1
~ # ls /proc/mtd
/proc/mtd
~ # cat /proc/mtd
dev:    size   erasesize  name
mtd0: 02000000 00010000 "bmc"
mtd1: 02000000 00010000 "pnor"

After reverting it:

# ls -l /dev/mtd*
crw-------    1 root     root       90,   0 Jan  1 00:00 /dev/mtd0
crw-------    1 root     root       90,   1 Jan  1 00:00 /dev/mtd0ro
crw-------    1 root     root       90,   2 Jan  1 00:00 /dev/mtd1
crw-------    1 root     root       90,   3 Jan  1 00:00 /dev/mtd1ro
crw-------    1 root     root       90,   4 Jan  1 00:00 /dev/mtd2
crw-------    1 root     root       90,   5 Jan  1 00:00 /dev/mtd2ro
crw-------    1 root     root       90,   6 Jan  1 00:00 /dev/mtd3
crw-------    1 root     root       90,   7 Jan  1 00:00 /dev/mtd3ro
crw-------    1 root     root       90,   8 Jan  1 00:00 /dev/mtd4
crw-------    1 root     root       90,   9 Jan  1 00:00 /dev/mtd4ro
crw-------    1 root     root       90,  10 Jan  1 00:00 /dev/mtd5
crw-------    1 root     root       90,  11 Jan  1 00:00 /dev/mtd5ro
crw-------    1 root     root       90,  12 Jan  1 00:00 /dev/mtd6
crw-------    1 root     root       90,  13 Jan  1 00:00 /dev/mtd6ro
brw-------    1 root     root       31,   0 Jan  1 00:00 /dev/mtdblock0
brw-------    1 root     root       31,   1 Jan  1 00:00 /dev/mtdblock1
brw-------    1 root     root       31,   2 Jan  1 00:00 /dev/mtdblock2
brw-------    1 root     root       31,   3 Jan  1 00:00 /dev/mtdblock3
brw-------    1 root     root       31,   4 Jan  1 00:00 /dev/mtdblock4
brw-------    1 root     root       31,   5 Jan  1 00:00 /dev/mtdblock5
brw-------    1 root     root       31,   6 Jan  1 00:00 /dev/mtdblock6
~ # cat /proc/mtd
dev:    size   erasesize  name
mtd0: 02000000 00010000 "bmc"
mtd1: 00060000 00010000 "u-boot"
mtd2: 00020000 00010000 "u-boot-env"
mtd3: 00440000 00010000 "kernel"
mtd4: 01740000 00010000 "rofs"
mtd5: 00400000 00010000 "rwfs"
mtd6: 02000000 00010000 "pnor"

I am trying to boot from "pnor". It looks like the partition data (from
devicetree)
is now ignored. mtdblock6 used to be the second flash.

Guenter

Is this with CONFIG_MTD_PARTITIONED_MASTER?


Yes

I think that mtd_is_partition is ambiguous now.
We always have master partition when CONFIG_MTD_PARTITIONED_MASTER
is enabled and parent check is useless.
We must check grandparent in this case.
Miquel, am I right?

We can return to older patch version that have created partition
instead of the master device.
Or try to fix mtd_is_partition, like below.
Guenter, is below patch helps?

No, it does not make a difference. Partitions are still not created.

Guenter

Reply via email to