[coreboot] [GSoC 2016] ROM-O-Matic project

[Denis 'GNUtoo' Carikli]

On Thu, 17 Mar 2016 15:56:13 -0600
Martin Roth <gaumless at gmail.com> wrote:

> As the project proposal says, first we want to just build roms that
> are already present in the board status database.  We have a config
> already present for these, so we don't need to ask any configuration
> options at all, just give them a list of boards that they can build a
> rom for.  We also don't need to give users every option available in
> Kconfig.  Maybe we give them an edit window that they can paste a
> config into or edit an existing config.
I would see ROM-O-Matic for coreboot working this way:

The users would have a list of boards, and could then select the given
known-good configuration that they want.

The configuration would list the hardware variations used in the test,
such as RAM, CPU when relevant[3].
- It would also warn the user when additional binaries have to be
  added to cbfs[1]. The user would then need to keep that in mind when
  consulting the installation documentation.
- It would warn against or filter out configurations with unknown
  payloads, or payloads with unknown revisions.
- It would warn against or filter out boards and configurations not in
  board-status.

Then an image would be produced, but also its hash and signature.
The website would also use https (everywhere).

Along with the image (and its hash and signature), some information
would appear:
- A big warning if some are lacking in cbfs[2].
- If the files matches, but the hash differ from the one in
  board-status[4], then a big warning will appear too.
- A link to the relevant documentation explaining how to install/flash
  this image for the given board.

I'm undecided on the idea of permitting users to do dangerous things,
such as editing the configuration, building for master revisions of
payloads, building for untested boards:
- One one hand, it would permit users to test that configuration, and
  then to upload the result on board-status more easily.
- On the other hand, we might rather want the given configuration to be
  uploaded on board-status first. This would be to reduce bricking
  probabilities.
- Another option would be to have both. In that case, we might want to
  very strongly warn the user if they want to have their own
  configuration built.

References:
-----------
[1]Part the necessary binaries can be deduced from coreboot's .config.
[2]That can be deduced from board-status: it has the list of CBFS files.
[3]This would have to be deduced from the logs. It's not trivial, so
   maybe there is some better way. Doing it at board-status log
   submission time is probably a better idea. Its scripts would have to
   be modified for that.
[4]board-status scripts will need to be modified to add such feature.
   Coreboot build scripts will also need to be modified to make sure
   that builds are reproducible. In coreboot,
   util/genbuild_h/genbuild_h.sh still leaks some non-reproducible
   information. Fixing it would also be needed to give users proper
   feedback.

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160319/b5951e4c/attachment.sig>