2015-06-11 10:25 GMT+02:00 Holger Levsen <hol...@layer-acht.org>:
> I'm now wondering how to proceed further. I *believe* another set of tests,
> this time with payloads, would be useful, if only to prove that the
> combination "reproducible coreboot" plus "reproducible payload" also is
> reproducible.
> Things is, _AIUI_, there is no common payload which can be enabled for all
> boards. Is that correct?
The one that should run everywhere is Google's depthcharge, and that
isn't hooked up to the build system like SeaBIOS is (and even
depthcharge isn't available for emulation/qemu-riscv). So you're
correct, there is no single payload for every board.

> If it is, is there another way to sensible group targets by payloads or detect
> sensible ones? Currently I'm building all targets in one pass using abuild,
> but I could also loop through each target and build it individually, as long
> as I dont have to configure 247 different configurations... (rather easy would
> be, all i386 targets use seabios, all mips target $that_one and all arm
> targets $another_one...
Since we select default payloads in our Kconfig rules (seabios for
x86), I guess we should start doing the same for other architectures.
I don't think that belongs in your test script - things might change
in the future, and that shouldn't require additional effort on your

We'll work on that, and will tell you once there's a plan and/or implementation.

> And then I'm wondering, "what next"? AIUI you don't ever offer images for
> download and instead expect users to build coreboot themselves. So the whole
> topic of verifying and reproducing the vendors (=your!) binaries is a bit mood
> here, at least atm. Any comments on that?
There are distributions, sort of.
Google ships coreboot as part of Chrome OS (which requires a huge
build system even to build just coreboot).
Then there's libreboot (www.libreboot.org), which ships their
coreboot-variant (without blobs and with as few patches against
coreboot as possible) with GRUB2 as payload for a small selection of
boards that they can support.
There are also some other vendors, but they're less visible.

If you want to support coreboot distributions (that ship binaries),
libreboot is currently your best bet.

> Last, and probably least: currently the headline of the page says "fast,
> flexible and reproducible Open Source firmware_?_" which I felt was
> appropriate when only a few images with payload were reproducible.
Oh, I loved it, still do! At some point we should replace the question
mark with an exclamation mark, though :-)

> Oh, and as the page says, it's currently only updated once a month and on
> demand, so please do ping me if you merged some reproducible changes into
> master!
Thanks, will do. Let's start immediately :-)
Since you mentioned 'once we reach 100% (without payloads)' earlier:
the issue of the remaining 7 non-reproducible board should be fixed
since today, in response to your report. I'd appreciate if you could
do another run to verify this.


Reproducible-builds mailing list

Reply via email to