[PATCH v6 01/11] mtd: core: always create master device
Miquel Raynal
miquel.raynal at bootlin.com
Mon Jun 9 09:43:19 UTC 2025
>>>> 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
More information about the Intel-gfx
mailing list