On Mon, Jan 02, 2023 at 04:43:49PM +0100, Michael Walle wrote: > Am 2023-01-02 14:53, schrieb Cédric Le Goater: > > On 12/27/22 07:31, Tudor Ambarus wrote: > > > > > > > > > On 25.12.2022 14:18, Ben Dooks wrote: > > > > On Wed, Dec 21, 2022 at 06:36:02PM +0100, Cédric Le Goater wrote: > > > > > On 12/21/22 13:22, Guenter Roeck wrote: > > > > > > Generated from hardware using the following command and > > > > > > then padding > > > > > > with 0xff to fill out a power-of-2: > > > > > > xxd -p /sys/bus/spi/devices/spi0.0/spi-nor/sfdp > > > > > > > > > > > > Cc: Michael Walle <[email protected]> > > > > > > Cc: Tudor Ambarus <[email protected]> > > > > > > Signed-off-by: Guenter Roeck <[email protected]> > > > > > > > > > > Reviewed-by: Cédric Le Goater <[email protected]> > > > > > > > > If SFDP is a standard, couldn't we have an function to generate > > > > it from > > > > the flash parameters? > > > > > > > > > > No, it's not practical as you have to specify all the flash parameters > > > at flash declaration. > > > > Indeed and the definition of flash models in QEMU is far to cover all > > the SFDP > > features. The known_devices array of m25p80 would be huge ! However, we > > could > > generate some of the SFDP tables if no raw data is provided. It could be > > useful > > for testing drivers. > > I don't think adding (incomplete) SFDP tables makes sense for any real > devices. E.g. sometimes our linux driver will look at specific bits in > SFDP to figure out what particular flash device is attached. For example > when there are different flashes with the same jedec id. > > But since the last released kernel, we support a generic SFDP driver, which > is used when there is no matching driver for the flash's jedec id. > Theoretically, you can build your own flash device (with a unique id) and > generate the sfdp tables for that one. > How about older kernels versions ? Would those still support such (virtual ?) flash devices ?
Thanks, Guenter
