From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Using kernelCI infrastructure for firmware testing
Date: Fri, 8 Nov 2019 16:59:44 -0500 [thread overview]
Message-ID: <20191108215944.GS19317@bill-the-cat> (raw)
In-Reply-To: <CALNFmy3BTuLSdGdYjeGCBGQxzJdRr9=_kBxng9_Hp8WbY2FnWw@mail.gmail.com>
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>
next prev parent reply other threads:[~2019-11-08 21:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-08 9:35 [U-Boot] Using kernelCI infrastructure for firmware testing Patrick Rudolph
2019-11-08 21:59 ` Tom Rini [this message]
2019-11-22 21:37 ` Kevin Hilman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191108215944.GS19317@bill-the-cat \
--to=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox