Hi Anastasia and other flashrom folks,

we had some brainstorming today about GSoC project ideas.

I can't access my Google account right now, so failed to edit the
original doc[1]. Maybe somebody can copy the following ideas there,
or we just put the document on Gerrit (doesn't have to be submitted)
for the moment?

It's a first revision, written in a hurry, so feel free to fix/
adapt anything ;) Also, some of the smaller topics seem too
short/boring. Maybe we could combine some into a refactoring project?

Nico


Optimize Erase-Function Selection
=================================

To change any 0 to a 1 in the contents of a NOR-flash chip, a full
block of data needs to be erased. So to change a single byte, it is
sometimes required to erase a whole block, which we'll call erase
overhead. Most flash chips support multiple erase-block sizes.
Flashrom keeps a list of these sizes and ranges for each supported
flash chip and maps them to internal erase functions. Usually these
lists are sorted by ascending size.

Traditionally, Flashrom tries all available erase functions for a flash
chip during writes. Usually only the first function is used, but if
anything goes wrong on the wire, or the programmer rejects a function,
it falls back to the next. As the functions are sorted by size, this
results in a minimum erase overhead.

However, if big portions of the flash contents are re-written, using
the smallest erase-block size results in transaction overhead, and also
erasing bigger blocks at once often results in shorter erase times
inside the flash chip.

So there is a tradeoff between picking smaller and larger blocks
which heavily depends on the amount of data that is changed. With
some preparation and a re-write of the loop over the erase-functions,
it seems possible to optimize for both cases, the few, scattered
changes and long, continuous changes:

* Adapt the programmer API so we can check in advance if
  a programmer supports an erase-function.
* Ensure the erase-function list is sorted, filter it using
  the new API, and then for each change hunk, pick the function
  with the smallest erase overhead (favoring functions for
  bigger blocks if the overhead is equal).

Duration: medium

Requires a skilled C programmer.


Fix Endianness Issues
=====================

Over the years, flashrom picked up support for some in-flash
partitioning formats (e.g. Intel Flash Descriptor, coreboot's
FMAP). These have a (hopefully) defined endianness. But it may
differ from the device that runs flashrom.

* Add a unified API to read data endian-safe (a draft
  exists on Gerrit).
* Port the existing code in Flashrom to use this API.
* Integrate IFWI (another format by Intel) using the
  new API (patches exist, but likely need to be updated).

Duration: low/medium


Integration work for CI Containers
==================================

Flashrom supports a massive amount of platforms, both hardware and
OS wise. For some time now, we try to get more test-coverage for
non-Linux, non-x86 platforms (at least for building Flashrom!). One
approach is manibuilder (found under util/manibuilder/ in the source
tree): It tries to integrate many Docker containers, and works so
far to build-test commits on Gerrit.

However, many things are lacking. For instance,

* Source-code pull only works over IP and is currently hard-coded to
  `review.coreboot.org`. To test local changes, two ideas exists to
  get them into the containers:
  1. Set up another container with access to the local files that
     runs an HTTP/Git server.
  2. Give every container access to the local files. This could barely
     be called work for a Linux container, however if we run another
     OS in QEMU, for instance, file access becomes a lot harder
     (possible solution: 9pfs).

* To test non-Linux OS's, we currently run QEMU inside the container.
  This could be integrated much better, for instance the container could
  be built such that it contains the bare files of the target OS (i.e.
  not just a disk image with another file system in it). QEMU could
  then be run transparently so that one can issue normal Docker commands
  like `run` that automatically target the emulated OS.

* Some popular OS's are currently untested and containers for them
  would be very welcome, e.g. FreeBSD, OpenBSD, Mac (if that's possible
  license-wise, might need to be run on Mac hardware).

Duration: open-ended?


Update Meson Integration
========================

We have a `meson.build` but it looks like it only targets Linux on x86.
Would be nice to get it fully functional, including cross-compilation.

Duration: ?


Restructure Shutdown Functions
==============================

Flashrom code has an API to register arbitrary functions to be run when
flashrom exits. This has led to a rather unstructured code flow that is
hard to keep track of. While the API is generally useful, its usage
should be restricted. This is something that will likely need further
discussion with the whole community. Some things that seem desirable:

* Have a defined shutdown function in the programmer API. Instead
  of registering a function to be called later, we would call it
  directly when we are done with a programmer.
* There are several wrapper functions to alter hardware state that
  automatically register a shutdown function to undo what they did
  (cf. rmmio/rpci/rphysmap/rget_io_perms). They currently rely on
  global state and as they are not used very often, it might be
  easier to drop them.

Duration: medium/long


Revise serial/serprog Code
==========================

The serprog code and generally the serial-terminal support code needs
an update and testing on non-Linux/non-Windows platforms. For further
maintenance it's desirable to extract the per-platform code into
separate files. Platforms that don't work currently should be fixed.

Duration: short/medium


Add Mac M1 support
==================

Building flashrom for MacOS is already possible, however the combination
of MacOS and ARM is untested. There are generally three classes of
programmers to support:

* External programmers connected via serial or USB. (might work OOB)
* Internal PCI-based programmers, e.g. targeting the OptionROM of a
  NIC/graphics card.
* The `internal` programmer, targeting flash ROMs on the mainboard.

At least the latter most likely requires a driver, like the unmaintained
DirectHW[1] and also specific support for the M1 SoCs.

Duration: flexible, depending on the programmer classes

Requires access to M1 Mac hardware. Potentially experience in low-level
programming.

[1] https://review.coreboot.org/plugins/gitiles/directhw/+/refs/heads/master