On Thu, 17 Mar 2016 15:56:13 -0600
Martin Roth <gaumless(a)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.
- It would also warn the user when additional binaries have to be
added to cbfs. 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
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
- A big warning if some are lacking in cbfs.
- If the files matches, but the hash differ from the one in
board-status, 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
- 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
Part the necessary binaries can be deduced from coreboot's .config.
That can be deduced from board-status: it has the list of CBFS files.
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.
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