* [PATCH] m25p80: Add the is25wp256 SFPD table
@ 2022-12-21 12:22 Guenter Roeck
2022-12-21 17:36 ` Cédric Le Goater
0 siblings, 1 reply; 10+ messages in thread
From: Guenter Roeck @ 2022-12-21 12:22 UTC (permalink / raw)
To: Alistair Francis
Cc: Kevin Wolf, Hanna Reitz, qemu-block, qemu-devel, Guenter Roeck,
Michael Walle, Tudor Ambarus
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 <michael@walle.cc>
Cc: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
hw/block/m25p80.c | 3 ++-
hw/block/m25p80_sfdp.c | 40 ++++++++++++++++++++++++++++++++++++++++
hw/block/m25p80_sfdp.h | 2 ++
3 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
index 02adc87527..802d2eb021 100644
--- a/hw/block/m25p80.c
+++ b/hw/block/m25p80.c
@@ -221,7 +221,8 @@ static const FlashPartInfo known_devices[] = {
{ INFO("is25wp032", 0x9d7016, 0, 64 << 10, 64, ER_4K) },
{ INFO("is25wp064", 0x9d7017, 0, 64 << 10, 128, ER_4K) },
{ INFO("is25wp128", 0x9d7018, 0, 64 << 10, 256, ER_4K) },
- { INFO("is25wp256", 0x9d7019, 0, 64 << 10, 512, ER_4K) },
+ { INFO("is25wp256", 0x9d7019, 0, 64 << 10, 512, ER_4K),
+ .sfdp_read = m25p80_sfdp_is25wp256 },
/* Macronix */
{ INFO("mx25l2005a", 0xc22012, 0, 64 << 10, 4, ER_4K) },
diff --git a/hw/block/m25p80_sfdp.c b/hw/block/m25p80_sfdp.c
index 77615fa29e..b33811a4f5 100644
--- a/hw/block/m25p80_sfdp.c
+++ b/hw/block/m25p80_sfdp.c
@@ -330,3 +330,43 @@ static const uint8_t sfdp_w25q01jvq[] = {
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
};
define_sfdp_read(w25q01jvq);
+
+/*
+ * Integrated Silicon Solution (ISSI)
+ */
+
+static const uint8_t sfdp_is25wp256[] = {
+ 0x53, 0x46, 0x44, 0x50, 0x06, 0x01, 0x01, 0xff,
+ 0x00, 0x06, 0x01, 0x10, 0x30, 0x00, 0x00, 0xff,
+ 0x9d, 0x05, 0x01, 0x03, 0x80, 0x00, 0x00, 0x02,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xe5, 0x20, 0xf9, 0xff, 0xff, 0xff, 0xff, 0x0f,
+ 0x44, 0xeb, 0x08, 0x6b, 0x08, 0x3b, 0x80, 0xbb,
+ 0xfe, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0xff,
+ 0xff, 0xff, 0x44, 0xeb, 0x0c, 0x20, 0x0f, 0x52,
+ 0x10, 0xd8, 0x00, 0xff, 0x23, 0x4a, 0xc9, 0x00,
+ 0x82, 0xd8, 0x11, 0xce, 0xcc, 0xcd, 0x68, 0x46,
+ 0x7a, 0x75, 0x7a, 0x75, 0xf7, 0xae, 0xd5, 0x5c,
+ 0x4a, 0x42, 0x2c, 0xff, 0xf0, 0x30, 0xfa, 0xa9,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0x50, 0x19, 0x50, 0x16, 0x9f, 0xf9, 0xc0, 0x64,
+ 0x8f, 0xef, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+};
+define_sfdp_read(is25wp256);
diff --git a/hw/block/m25p80_sfdp.h b/hw/block/m25p80_sfdp.h
index df7adfb5ce..011a880f66 100644
--- a/hw/block/m25p80_sfdp.h
+++ b/hw/block/m25p80_sfdp.h
@@ -26,4 +26,6 @@ uint8_t m25p80_sfdp_w25q512jv(uint32_t addr);
uint8_t m25p80_sfdp_w25q01jvq(uint32_t addr);
+uint8_t m25p80_sfdp_is25wp256(uint32_t addr);
+
#endif
--
2.36.2
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH] m25p80: Add the is25wp256 SFPD table
2022-12-21 12:22 [PATCH] m25p80: Add the is25wp256 SFPD table Guenter Roeck
@ 2022-12-21 17:36 ` Cédric Le Goater
2022-12-25 12:18 ` Ben Dooks
0 siblings, 1 reply; 10+ messages in thread
From: Cédric Le Goater @ 2022-12-21 17:36 UTC (permalink / raw)
To: Guenter Roeck, Alistair Francis
Cc: Kevin Wolf, Hanna Reitz, qemu-block, qemu-devel, Michael Walle,
Tudor Ambarus
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 <michael@walle.cc>
> Cc: Tudor Ambarus <tudor.ambarus@linaro.org>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Thanks,
C.
> ---
> hw/block/m25p80.c | 3 ++-
> hw/block/m25p80_sfdp.c | 40 ++++++++++++++++++++++++++++++++++++++++
> hw/block/m25p80_sfdp.h | 2 ++
> 3 files changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
> index 02adc87527..802d2eb021 100644
> --- a/hw/block/m25p80.c
> +++ b/hw/block/m25p80.c
> @@ -221,7 +221,8 @@ static const FlashPartInfo known_devices[] = {
> { INFO("is25wp032", 0x9d7016, 0, 64 << 10, 64, ER_4K) },
> { INFO("is25wp064", 0x9d7017, 0, 64 << 10, 128, ER_4K) },
> { INFO("is25wp128", 0x9d7018, 0, 64 << 10, 256, ER_4K) },
> - { INFO("is25wp256", 0x9d7019, 0, 64 << 10, 512, ER_4K) },
> + { INFO("is25wp256", 0x9d7019, 0, 64 << 10, 512, ER_4K),
> + .sfdp_read = m25p80_sfdp_is25wp256 },
>
> /* Macronix */
> { INFO("mx25l2005a", 0xc22012, 0, 64 << 10, 4, ER_4K) },
> diff --git a/hw/block/m25p80_sfdp.c b/hw/block/m25p80_sfdp.c
> index 77615fa29e..b33811a4f5 100644
> --- a/hw/block/m25p80_sfdp.c
> +++ b/hw/block/m25p80_sfdp.c
> @@ -330,3 +330,43 @@ static const uint8_t sfdp_w25q01jvq[] = {
> 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> };
> define_sfdp_read(w25q01jvq);
> +
> +/*
> + * Integrated Silicon Solution (ISSI)
> + */
> +
> +static const uint8_t sfdp_is25wp256[] = {
> + 0x53, 0x46, 0x44, 0x50, 0x06, 0x01, 0x01, 0xff,
> + 0x00, 0x06, 0x01, 0x10, 0x30, 0x00, 0x00, 0xff,
> + 0x9d, 0x05, 0x01, 0x03, 0x80, 0x00, 0x00, 0x02,
> + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> + 0xe5, 0x20, 0xf9, 0xff, 0xff, 0xff, 0xff, 0x0f,
> + 0x44, 0xeb, 0x08, 0x6b, 0x08, 0x3b, 0x80, 0xbb,
> + 0xfe, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0xff,
> + 0xff, 0xff, 0x44, 0xeb, 0x0c, 0x20, 0x0f, 0x52,
> + 0x10, 0xd8, 0x00, 0xff, 0x23, 0x4a, 0xc9, 0x00,
> + 0x82, 0xd8, 0x11, 0xce, 0xcc, 0xcd, 0x68, 0x46,
> + 0x7a, 0x75, 0x7a, 0x75, 0xf7, 0xae, 0xd5, 0x5c,
> + 0x4a, 0x42, 0x2c, 0xff, 0xf0, 0x30, 0xfa, 0xa9,
> + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> + 0x50, 0x19, 0x50, 0x16, 0x9f, 0xf9, 0xc0, 0x64,
> + 0x8f, 0xef, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +};
> +define_sfdp_read(is25wp256);
> diff --git a/hw/block/m25p80_sfdp.h b/hw/block/m25p80_sfdp.h
> index df7adfb5ce..011a880f66 100644
> --- a/hw/block/m25p80_sfdp.h
> +++ b/hw/block/m25p80_sfdp.h
> @@ -26,4 +26,6 @@ uint8_t m25p80_sfdp_w25q512jv(uint32_t addr);
>
> uint8_t m25p80_sfdp_w25q01jvq(uint32_t addr);
>
> +uint8_t m25p80_sfdp_is25wp256(uint32_t addr);
> +
> #endif
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH] m25p80: Add the is25wp256 SFPD table
2022-12-21 17:36 ` Cédric Le Goater
@ 2022-12-25 12:18 ` Ben Dooks
2022-12-27 6:31 ` Tudor Ambarus
0 siblings, 1 reply; 10+ messages in thread
From: Ben Dooks @ 2022-12-25 12:18 UTC (permalink / raw)
To: Cédric Le Goater
Cc: Guenter Roeck, Alistair Francis, Kevin Wolf, Hanna Reitz,
qemu-block, qemu-devel, Michael Walle, Tudor Ambarus
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 <michael@walle.cc>
> > Cc: Tudor Ambarus <tudor.ambarus@linaro.org>
> > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>
> Reviewed-by: Cédric Le Goater <clg@kaod.org>
If SFDP is a standard, couldn't we have an function to generate it from
the flash parameters?
--
Ben Dooks, ben@fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] m25p80: Add the is25wp256 SFPD table
2022-12-25 12:18 ` Ben Dooks
@ 2022-12-27 6:31 ` Tudor Ambarus
2023-01-02 13:53 ` Cédric Le Goater
0 siblings, 1 reply; 10+ messages in thread
From: Tudor Ambarus @ 2022-12-27 6:31 UTC (permalink / raw)
To: Ben Dooks, Cédric Le Goater
Cc: Guenter Roeck, Alistair Francis, Kevin Wolf, Hanna Reitz,
qemu-block, qemu-devel, Michael Walle
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 <michael@walle.cc>
>>> Cc: Tudor Ambarus <tudor.ambarus@linaro.org>
>>> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>>
>> Reviewed-by: Cédric Le Goater <clg@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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] m25p80: Add the is25wp256 SFPD table
2022-12-27 6:31 ` Tudor Ambarus
@ 2023-01-02 13:53 ` Cédric Le Goater
2023-01-02 15:43 ` Michael Walle
0 siblings, 1 reply; 10+ messages in thread
From: Cédric Le Goater @ 2023-01-02 13:53 UTC (permalink / raw)
To: Tudor Ambarus, Ben Dooks
Cc: Guenter Roeck, Alistair Francis, Kevin Wolf, Hanna Reitz,
qemu-block, qemu-devel, Michael Walle
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 <michael@walle.cc>
>>>> Cc: Tudor Ambarus <tudor.ambarus@linaro.org>
>>>> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>>>
>>> Reviewed-by: Cédric Le Goater <clg@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.
Thanks,
C.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] m25p80: Add the is25wp256 SFPD table
2023-01-02 13:53 ` Cédric Le Goater
@ 2023-01-02 15:43 ` Michael Walle
2023-01-02 16:23 ` Guenter Roeck
0 siblings, 1 reply; 10+ messages in thread
From: Michael Walle @ 2023-01-02 15:43 UTC (permalink / raw)
To: Cédric Le Goater
Cc: Tudor Ambarus, Ben Dooks, Guenter Roeck, Alistair Francis,
Kevin Wolf, Hanna Reitz, qemu-block, qemu-devel
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 <michael@walle.cc>
>>>>> Cc: Tudor Ambarus <tudor.ambarus@linaro.org>
>>>>> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>>>>
>>>> Reviewed-by: Cédric Le Goater <clg@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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] m25p80: Add the is25wp256 SFPD table
2023-01-02 15:43 ` Michael Walle
@ 2023-01-02 16:23 ` Guenter Roeck
2023-01-02 17:42 ` Michael Walle
0 siblings, 1 reply; 10+ messages in thread
From: Guenter Roeck @ 2023-01-02 16:23 UTC (permalink / raw)
To: Michael Walle
Cc: Cédric Le Goater, Tudor Ambarus, Ben Dooks, Alistair Francis,
Kevin Wolf, Hanna Reitz, qemu-block, qemu-devel
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 <michael@walle.cc>
> > > > > > Cc: Tudor Ambarus <tudor.ambarus@linaro.org>
> > > > > > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> > > > >
> > > > > Reviewed-by: Cédric Le Goater <clg@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.
>
How about older kernels versions ? Would those still support such (virtual ?)
flash devices ?
Thanks,
Guenter
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] m25p80: Add the is25wp256 SFPD table
2023-01-02 16:23 ` Guenter Roeck
@ 2023-01-02 17:42 ` Michael Walle
2023-01-02 18:49 ` Guenter Roeck
0 siblings, 1 reply; 10+ messages in thread
From: Michael Walle @ 2023-01-02 17:42 UTC (permalink / raw)
To: Guenter Roeck
Cc: Cédric Le Goater, Tudor Ambarus, Ben Dooks, Alistair Francis,
Kevin Wolf, Hanna Reitz, qemu-block, qemu-devel
Am 2023-01-02 17:23, schrieb Guenter Roeck:
> 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 <michael@walle.cc>
>> > > > > > Cc: Tudor Ambarus <tudor.ambarus@linaro.org>
>> > > > > > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>> > > > >
>> > > > > Reviewed-by: Cédric Le Goater <clg@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.
>>
> How about older kernels versions ? Would those still support such
> (virtual ?)
> flash devices ?
No with older kernels you'd be out of luck. They will just print
"unknown flash
id" and skip the device.
-michael
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] m25p80: Add the is25wp256 SFPD table
2023-01-02 17:42 ` Michael Walle
@ 2023-01-02 18:49 ` Guenter Roeck
2023-01-02 19:58 ` Michael Walle
0 siblings, 1 reply; 10+ messages in thread
From: Guenter Roeck @ 2023-01-02 18:49 UTC (permalink / raw)
To: Michael Walle
Cc: Cédric Le Goater, Tudor Ambarus, Ben Dooks, Alistair Francis,
Kevin Wolf, Hanna Reitz, qemu-block, qemu-devel
On Mon, Jan 02, 2023 at 06:42:03PM +0100, Michael Walle wrote:
> Am 2023-01-02 17:23, schrieb Guenter Roeck:
> > 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 <michael@walle.cc>
> > > > > > > > Cc: Tudor Ambarus <tudor.ambarus@linaro.org>
> > > > > > > > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> > > > > > >
> > > > > > > Reviewed-by: Cédric Le Goater <clg@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.
> > >
> > How about older kernels versions ? Would those still support such
> > (virtual ?)
> > flash devices ?
>
> No with older kernels you'd be out of luck. They will just print "unknown
> flash
> id" and skip the device.
That would mean that qemu versions including this change could no longer
be used to test flash support on older kernel versions. That would be
extremely undesirable. I'd rather live with the current code and still be
able to test older kernels.
Thanks,
Guenter
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] m25p80: Add the is25wp256 SFPD table
2023-01-02 18:49 ` Guenter Roeck
@ 2023-01-02 19:58 ` Michael Walle
0 siblings, 0 replies; 10+ messages in thread
From: Michael Walle @ 2023-01-02 19:58 UTC (permalink / raw)
To: Guenter Roeck
Cc: Cédric Le Goater, Tudor Ambarus, Ben Dooks, Alistair Francis,
Kevin Wolf, Hanna Reitz, qemu-block, qemu-devel
Am 2023-01-02 19:49, schrieb Guenter Roeck:
> On Mon, Jan 02, 2023 at 06:42:03PM +0100, Michael Walle wrote:
>> Am 2023-01-02 17:23, schrieb Guenter Roeck:
>> > 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 <michael@walle.cc>
>> > > > > > > > Cc: Tudor Ambarus <tudor.ambarus@linaro.org>
>> > > > > > > > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>> > > > > > >
>> > > > > > > Reviewed-by: Cédric Le Goater <clg@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.
>> > >
>> > How about older kernels versions ? Would those still support such
>> > (virtual ?)
>> > flash devices ?
>>
>> No with older kernels you'd be out of luck. They will just print
>> "unknown
>> flash
>> id" and skip the device.
>
> That would mean that qemu versions including this change could no
> longer
> be used to test flash support on older kernel versions. That would be
> extremely undesirable. I'd rather live with the current code and still
> be
> able to test older kernels.
Your board wouldn't need to use it. I don't think that emulating a real
spi flash device would go away. But it might still make sense to have
such a flash device, one example already mentioned is for testing
drivers.
-michael
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2023-01-02 19:58 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-12-21 12:22 [PATCH] m25p80: Add the is25wp256 SFPD table Guenter Roeck
2022-12-21 17:36 ` Cédric Le Goater
2022-12-25 12:18 ` Ben Dooks
2022-12-27 6:31 ` Tudor Ambarus
2023-01-02 13:53 ` Cédric Le Goater
2023-01-02 15:43 ` Michael Walle
2023-01-02 16:23 ` Guenter Roeck
2023-01-02 17:42 ` Michael Walle
2023-01-02 18:49 ` Guenter Roeck
2023-01-02 19:58 ` Michael Walle
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).