Sorry it's taken a while to get back to you on this.
The build needs to happen with the correct toolchain to generate a rom that
is similar (or identical) to the original rom that was tested in the board
status. That would be done with with 'make crossgcc'. If I try to build a
rom that was submitted 8 months ago, I'd want to use the toolchain that was
in use 8 months ago, not today's toolchain.
Boards that are in the board status repo:
These are boards that have been tested. These submissions are known to at
least boot (with the configuration that was used to test the rom).
Any valid board:
The source code for these boards is in the codebase, but we have no way of
knowing whether it's currently booting or not until we actually test it.
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
The preference would be to do everything on the server or in the browser
though. We would really prefer not to have any scripts that need to be run
on the user's system.
On Thu, Mar 17, 2016 at 3:35 PM, ron minnich <rminnich(a)gmail.com> wrote:
On Thu, Mar 17, 2016 at 2:33 PM Yurii Shevtsov <ungetch(a)gmail.com> wrote:
I can't see any other way, it's all about running the commands. Browsers
can't do this. Certain actions are still required from user. Some shell
script, which will run commands and then send stdout to the server, can be
the board-status script can send the ref and the configuraiton.
That's not part of rom-o-matic.
Further, tools at coreboot.org
and create the tables whih rom-o-matic
uses to present choices to the user.
That's what I was wondering, anyway.