[U-Boot] Using kernelCI infrastructure for firmware testing

[Tom Rini]

On Fri, Nov 08, 2019 at 10:35:10AM +0100, Patrick Rudolph wrote:

> Hi folks,
> this is an attempt to improve firmware testing by using the
> infrastructure and knowledge of the kernelci community. If you think
> this is not the right place, please point me in the right direction.
> 
> I'm a coreboot[1] developer trying to make sure that the master
> branch[2] doesn't regress. Currently there's no public firmware
> testing, only internal validation suites used by some companies that
> lack direct and automated feedback before a commit is actually merged.
> As this isn't a coreboot only topic, but applies to all open source
> "bios vendors", I added the u-boot project in CC as well.
> 
> For me firmware testing looks pretty similar to kernel testing:
> * flash firmware to test
> * boot a known good linux kernel
> * run tests in userspace and verify hardware/software works as expected
> 
> On the hardware side we have boards in our lab that allow remote power
> cycling and firmware flashing. It is attached to self hosted stock
> LAVA2018. But as we are firmware engineers, we don't want to deal with
> the administration of servers.
> 
> Here are a few questions for you:
> * Would it make sense to also cover open source firmware tests on kernelci?
> * Do you build the linux images yourself?
> * Would you accept firmware images generated by a third party?
> * Can anybody get an account for the LAVA server to run firmware test?
> * What communication channels do you recommend?
> * Will there be meetings or conferences to get in contact with the
> community to talk about this?
> 
> [1]: https://coreboot.org/
> [2]: https://review.coreboot.org/

Over in U-Boot, yes, we have some test suites that we run on real HW as
well as QEMU-based hardware.  And historically I've talked with Kevin
once or twice about testing a current U-Boot on various easy-to-recover
boards rather than just what it shipped with, but things never moved
past the talking about it stage.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191108/ed8898c9/attachment.sig>