On 6/10/25 01:42, Peter Maydell wrote:
On Tue, 10 Jun 2025 at 02:28, Guenter Roeck <li...@roeck-us.net> wrote:In some situations it is desirable to be able to specify the flash type connected to a board. For example, the target operating system may not support the default flash type, its support may be broken, or the qemu emulation is insufficient and the default flash is not detected. On top of that, the ability to test various flash types improves testability since a single emulated board can be used to test a variety of flash chips with the controller supported by that board. The aspeed emulation supports an option to specify the flash type. Use the same mechanism to configure the flash type for Nuvoton 7xx boards. Signed-off-by: Guenter Roeck <li...@roeck-us.net> --- I don't know if there is interest in this, but I figured I should at least submit it. Background is that Macronix flash support is broken when running upstream Linux v6.16-rc1, thanks to upstream Linux commit 947c86e481a027e ("mtd: spi-nor: macronix: Drop the redundant flash info fields"). I needed a workaround, and using a different flash model was the easiest solution.I think the question I would have here is "is this the flash device the hardware actually has?". If QEMU's using the wrong flash type, we should fix that. If QEMU's modelling the right flash type and the kernel doesn't implement it, then that's a kernel bug and the right fix is to get the kernel to handle that flash type.
That isn't the point. Yes, one is that qemu's emulation is broken, the other is that I wanted to be able to test with other flash types anyway. I understand that this 'violates' the idea of exactly emulating some hardware, but I want to be able to use qemu beyond that. Either case, I did some debugging: For flashes with sfdp data (mx25l25635e), qemu returns bad sfdp data (at least with quanta-gsj), causing the kernel (as of v6.16-rc1) to bail out. For other flashes (mx66u51235f) it returns no sfdp data, but the upstream kernel now depends on it. NP, I'll just carry the patch locally in my tree. As mentioned above, I wasn't sure if there is interest in this patch, but I wanted to at least publish it. Thanks, Guenter
