[flashrom] Re: Support for sub-1KByte EEPROM-s

[Anastasia Klimchuk]

> Microchip has 128, 192, 256 and 512 byte EEPROMs (below 1024 bytes)

Thanks, that's useful info.

Also I wanted to say, adding a feature flag (or something else) would
be the last step.

The first step would be to try whether the idea works, you can use
command-line options for layout. Which are: options -i or --include
and -l or --layout, read the manpage or here:
https://flashrom.org/classic_cli_manpage.html
You need to put 1 as total_size, and then create a layout with one
region of real size of micro chip, and only operate on that region.

If it works, it unblocks your further work with STLinkV3. If it
doesn't work please tell! :)

On Fri, Aug 16, 2024 at 12:48 AM Miklós Márton
 wrote:
> Hello Anastasia,
>
> Many thanks for your quick reply!
> > This needs to be designed... for example, what are the possible sizes
> > of those smaller EEPROMs? can that be any size, or only a few standard
> > options (like 256 and 512 bytes)?
>
> Microchip has 128, 192, 256 and 512 byte EEPROMs (below 1024 bytes).
> They do offer a DFP (bunch of XML device descriptors) from which the flash descriptors could be generated.
>
> Miklos
>
> Anastasia Klimchuk  ezt írta (időpont: 2024. aug. 15., Cs, 14:50):
> > Hello Miklos,
> >
> > I remember this, I was in a (somewhat) similar situation when I was
> > writing unit tests. The total_size is in kilobytes and so the smallest
> > size would be 1 kilobyte. While I only needed 16 bytes for test
> > scenarios. The workaround for unit tests is to put 1 as total_size,
> > then have 1024 bytes as a "total memory" but only really care about
> > the first 16 bytes.
> >
> > I think you can try something in that direction. Something like, what
> > if you put 1 as total_size (not 0), and then create a layout with one
> > region of 512 bytes (or how much is real-total-size), and only operate
> > on this region.
> > Do you have a work in progress code that you could upload as a WIP
> > patch? It might be easier to talk over the code.
> >
> > Both layout boundaries, and erase block sizes are measured in bytes,
> > so they can be defined in an actual size.
> > > Is supporting smaller EEPROMs considered a feature what could be merged at some point
> >
> > I think yes, why not merge a useful feature. If we figure out the
> > working solution :)
> >
> > This needs to be designed... for example, what are the possible sizes
> > of those smaller EEPROMs? can that be any size, or only a few standard
> > options (like 256 and 512 bytes)?
> >
> > Maybe it can be a feature flag (FEATURE_MICRO256B or something like
> > that), and then with this feature flag layout with 256 bytes region
> > can be silently created.
> >
> > On Thu, Aug 15, 2024 at 12:10 AM Miklós Márton
> >  wrote:
> > > Hello all,
> > >
> > > I tried to add support for some Microchip serial EEPROMs to being able to program them with an STLinkV3. I ran into problems with the smaller EEPROMs for e.g. 25LC040 which is only a 4Kbit device.
> > >
> > > The total_size in the flashchip structure is an unsigned int so I could only enter 0 as total size.
> > >
> > > In this case the flashrom shows the following message to me:
> > > ERROR: Flash chip 25C040 erase function 0 region walking resulted in 0x000200 bytes total, expected 0x000000 bytes. Please report a bug at [e-mail]
> > > ERROR: Flash chip 25C040 erase function 0 is not in order. Please report a bug at [e-mail]
> > >
> > > Is there any recommendations how to overcome on this?
> > > Is supporting smaller EEPROMs considered a feature what could be merged at some point, or the flashrom is going to focus purely on flash memories?