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 <mich...@walle.cc>
Cc: Tudor Ambarus <tudor.amba...@linaro.org>
Signed-off-by: Guenter Roeck <li...@roeck-us.net>
Reviewed-by: Cédric Le Goater <c...@kaod.org>
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.
-michael
