On Thu, 17 Mar 2016 15:56:13 -0600 Martin Roth email@example.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 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. - 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 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: ----------- 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 feedback.