Microchip KernelCi contributions


Santiago.Esteban@...
 

Dear KernelCi,

I'm Santiago Esteban, SW Engineer at Microchip. I'm  leading the effort
for continuous integration of our Linux developments. We are setting up
the  infrastructure for CI in a  board farm containing several boards.
We would like to contribute to the KernelCI effort with build and test
data. Hopefully, as our knowledge increases we will be able to help  in
some other ways.


How should I prodeed?


Best Regards,

Santiago Esteban


Kevin Hilman
 

Hi Santiago,

<Santiago.Esteban@microchip.com> writes:

I'm Santiago Esteban, SW Engineer at Microchip. I'm  leading the effort
for continuous integration of our Linux developments. We are setting up
the  infrastructure for CI in a  board farm containing several boards.
We would like to contribute to the KernelCI effort with build and test
data. Hopefully, as our knowledge increases we will be able to help  in
some other ways.


How should I prodeed?
How is your lab currently setup? Are you using LAVA? If not, can you
tell us a bit more about how your lab is setup? What kind of hardware
you're testing?

If using LAVA, getting integrated into KernelCI is pretty straight
forward.

Some pre-requisites:

- boards can boot an upstream Linux kernel using an upstream defconfig,
(minimum: boot to a serial-console shell using a ramdisk)
- LAVA device-types for your boards are submitted upstream to the LAVA
project

From there, with a basic LAVA setup/working, we just add your lab to our
list of labs[1] and then add your device-types in your lab to our list
of devices[2].

For kernelci.org to be able to submit jobs to your LAVA lab, you'll need
to create a `kernel-ci` user, setup an auth token and share that token
with us. Any boards that the kernel-ci LAVA user has access to,
kernelci.org will have access to.

Hope that helps get you started,

Kevin

[1] https://github.com/kernelci/kernelci-core/blob/master/lab-configs.yaml
[2] https://github.com/kernelci/kernelci-core/blob/master/test-configs.yaml


Santiago.Esteban via info
 

Hi Kevin,

I'm sorry for my late reply, but was on hollidays...

On 6/7/20 20:20, Kevin Hilman wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

Hi Santiago,

<Santiago.Esteban@microchip.com> writes:

I'm Santiago Esteban, SW Engineer at Microchip. I'm leading the effort
for continuous integration of our Linux developments. We are setting up
the infrastructure for CI in a board farm containing several boards.
We would like to contribute to the KernelCI effort with build and test
data. Hopefully, as our knowledge increases we will be able to help in
some other ways.


How should I prodeed?
How is your lab currently setup? Are you using LAVA? If not, can you
tell us a bit more about how your lab is setup? What kind of hardware
you're testing?
Unfortunately, we are not using LAVA, we are using a corporate Jenkins
server, a local development KernelCI server and Labgrid (from
Pengutronix) for testing the boards on the farm.

Right now, we are testing 3 different ARM Cortex-A5 SOCs (SAMA5D3,
SAMA5D4, SAMA5D2) and ARM9 device (SAM9X60), all SoCs and test boards
are mainlined. We are in the process of mainlining support for 2 new
devices/boards.


If using LAVA, getting integrated into KernelCI is pretty straight
forward.

Some pre-requisites:

- boards can boot an upstream Linux kernel using an upstream defconfig,
(minimum: boot to a serial-console shell using a ramdisk)
- LAVA device-types for your boards are submitted upstream to the LAVA
project

From there, with a basic LAVA setup/working, we just add your lab to our
list of labs[1] and then add your device-types in your lab to our list
of devices[2].

For kernelci.org to be able to submit jobs to your LAVA lab, you'll need
to create a `kernel-ci` user, setup an auth token and share that token
with us. Any boards that the kernel-ci LAVA user has access to,
kernelci.org will have access to.

Hope that helps get you started,

Kevin

[1] https://github.com/kernelci/kernelci-core/blob/master/lab-configs.yaml
[2] https://github.com/kernelci/kernelci-core/blob/master/test-configs.yaml
As we are not using LAVA, we are using a local KCI docker setup. We are
able to perform builds for a selected set of repos/branches (simplified
version of lab-configs.yaml), test the outputs using Labgrid, and
publish the test results in the local KCI application.

Right now it is a simple boot test, but I'm working on a full baseline
test and later, in the future, add more functional tests.

I guess that in this case, I would need from you to create a lab, let's
say  "lab-microchip" and share the token with us (maybe starting with a
staging repository), so I can push our test results.

Best regards,

Santiago Esteban


Guillaume Tucker
 

On 20/07/2020 13:11, santiago.esteban via groups.io wrote:
Hi Kevin,

I'm sorry for my late reply, but was on hollidays...

On 6/7/20 20:20, Kevin Hilman wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

Hi Santiago,

<Santiago.Esteban@microchip.com> writes:

I'm Santiago Esteban, SW Engineer at Microchip. I'm leading the effort
for continuous integration of our Linux developments. We are setting up
the infrastructure for CI in a board farm containing several boards.
We would like to contribute to the KernelCI effort with build and test
data. Hopefully, as our knowledge increases we will be able to help in
some other ways.


How should I prodeed?
How is your lab currently setup? Are you using LAVA? If not, can you
tell us a bit more about how your lab is setup? What kind of hardware
you're testing?
Unfortunately, we are not using LAVA, we are using a corporate Jenkins
server, a local development KernelCI server and Labgrid (from
Pengutronix) for testing the boards on the farm.

Right now, we are testing 3 different ARM Cortex-A5 SOCs (SAMA5D3,
SAMA5D4, SAMA5D2) and ARM9 device (SAM9X60), all SoCs and test boards
are mainlined. We are in the process of mainlining support for 2 new
devices/boards.


If using LAVA, getting integrated into KernelCI is pretty straight
forward.

Some pre-requisites:

- boards can boot an upstream Linux kernel using an upstream defconfig,
(minimum: boot to a serial-console shell using a ramdisk)
- LAVA device-types for your boards are submitted upstream to the LAVA
project

From there, with a basic LAVA setup/working, we just add your lab to our
list of labs[1] and then add your device-types in your lab to our list
of devices[2].

For kernelci.org to be able to submit jobs to your LAVA lab, you'll need
to create a `kernel-ci` user, setup an auth token and share that token
with us. Any boards that the kernel-ci LAVA user has access to,
kernelci.org will have access to.

Hope that helps get you started,

Kevin

[1] https://github.com/kernelci/kernelci-core/blob/master/lab-configs.yaml
[2] https://github.com/kernelci/kernelci-core/blob/master/test-configs.yaml
As we are not using LAVA, we are using a local KCI docker setup. We are
able to perform builds for a selected set of repos/branches (simplified
version of lab-configs.yaml), test the outputs using Labgrid, and
publish the test results in the local KCI application.

Right now it is a simple boot test, but I'm working on a full baseline
test and later, in the future, add more functional tests.

I guess that in this case, I would need from you to create a lab, let's
say  "lab-microchip" and share the token with us (maybe starting with a
staging repository), so I can push our test results.
It seems like you're already automating jobs from Jenkins, so one
option would be to add Labgrid support to let KernelCI do that as
well if you want to test KernelCI builds directly. That should
also help with running bisections. Do you have a public-facing
web API for Labgrid that KernelCI could use to trigger jobs?

Presumably you're already sending test results to your local
kernelci-backend instance. So another option is to keep all that
in place but also submit your results to the production
api.kernelci.org instance (or api.staging.kernelci.org initially
to try things out). The new kci_data tool which is being
developed now should help with that.

Then of course you can also set up a LAVA lab but that would seem
overkill if you already have a working test system, unless you're
planning to stop using Labgrid and migrate to LAVA anyway.

Thanks,
Guillaume