Hi Cedric,
On [2022 Oct 10] Mon 11:58:40, Michael Walle wrote:
> Am 2022-10-10 08:23, schrieb Cédric Le Goater:
> > On 10/7/22 16:44, Francisco Iglesias wrote:
>
> > > > --- a/hw/block/m25p80.c
> > > > +++ b/hw/block/m25p80.c
> > > > @@ -234,6 +234,8 @@ static const FlashPartInfo known_devices[] = {
> > > > { INFO("mx25l12855e", 0xc22618, 0, 64 << 10, 256, 0) },
> > > > { INFO6("mx25l25635e", 0xc22019, 0xc22019, 64 << 10,
> > > > 512, 0),
> > > > .sfdp_read = m25p80_sfdp_mx25l25635e },
> > > > + { INFO6("mx25l25635f", 0xc22019, 0xc22019, 64 << 10,
> > > > 512, 0),
I think I missed the (ER_4K | ER_32K) flags above (in case we go for a v4 we
can add it in).
> > >
> > > I think I'm not seeing the extended id part in the datasheet I've
> > > found so
> > > might be that you can switch to just INFO and _ext_id 0 above
> >
> > This was added by commit 6bbe036f32dc ("m25p80: Return the JEDEC ID
> > twice for
> > mx25l25635e") to fix a real breakage on HW.
>
> From my experience, the ID has a particular length, at least three bytes
> and if you read past that length for some (all?) devices the id bytes just
> get repeated. I.e. the counter in the device will just wrap to offset 0
> again. If you want to emulate the hardware correctly, you would have to
> take that into consideration.
If we decide to go with Michael's proposal above you can use '0' on the
'extended_id' and enable 's->data_read_loop = true' when reading the ID.
Best regards,
Francisco
> But I don't think it's worth it, OTOH there seems to be some broken
> software which rely on that (undefined?) behavior.
>
> -michael
