On Tue, 10 Jun 2025 at 14:31, Guenter Roeck <li...@roeck-us.net> wrote: > > On 6/10/25 01:42, Peter Maydell wrote: > > 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.
It is the point from my perspective. This board type is supposed to be modelling real hardware, and therefore in determining how it should behave we start by saying "so what does the real hardware do?". Adding extra behaviour that the real hardware does not have is something that has a tendency to lead into unspecified, untested and hard to maintain complexity. > 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. Why this machine type in particular, though? You say in the commit message that aspeed lets you specify the flash type. > 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. That sounds like a bug we should fix. Would one of the Nuvoton maintainers like to take a look? thanks -- PMM
