Date   

Re: Project-X (minimal root filesystem) for renesas board

Yoshitake Kobayashi
 

On 2017/07/07 17:54, Agustin Benito Bethencourt wrote:
Hi,

On 07/07/17 04:40, Daniel Sangorrin wrote:
Hi Agustin, Chris

-----Original Message-----
From: cip-dev-bounces@... [mailto:cip-dev-bounces@...] On Behalf Of Agustin Benito Bethencourt
Sent: Thursday, June 29, 2017 5:21 PM
To: cip-dev@...
Subject: Re: [cip-dev] Project-X (minimal root filesystem) for renesas board

Hi,

On 29/06/17 02:37, Daniel Sangorrin wrote:
Hi Koguchi-san,

-----Original Message-----
From: 小口琢夫 / KOGUCHI,TAKUO [mailto:takuo.koguchi.sw@...]
Sent: Wednesday, June 28, 2017 6:08 PM
To: 'Daniel Sangorrin'; cip-dev@...
Cc: 'Chris Paterson'
Subject: RE: RE: Project-X (minimal root filesystem) for renesas board

Daniel-san,

I think this is not a good approach. We would need to have a new linux-cip folder for each
release.
Let make it clear. Will you please describe your recommendation?
Yes, please see below.

Patches for the cyclone board should be on its own CIP kernel repository (where you can
merge cip releases and add tags). Then, we can choose which version we want by
specifying the repository and tag/commit_id.
Good point. But CIP kernel repository is curerntly used for release assuming it is tested. And CycloneV is not supported by CIP at
this
moment. So I put the patches in the yocto project way.
I didn't mean to put it on Ben's CIP repository rather on github. This way you can better maintain your "out-of-tree" cyclone V
patches
and merge (do not rebase please) changes from Ben's CIP kernel regularly. In other words, do the same as Renesas is doing at [1].

[1] https://github.com/renesas-rz/renesas-cip
In order to have all the cip related code in one place, it would be
good, if anybody is using github, that at least there is a mirror of
that repo in gitlab. When we start automating builds/test, that would be
helpful.
Agustin: I don't mind, but is this necessary?.
Necessary? not in my opinion. I think that development should take place whenever is best for the developers.

Two considerations:

TSC agreed to use Gitlab for mainly one reason: services built with gitlab can be replicated by Members in-house. That is not the case for GitHub.

Once the code is developed and the developer want to distribute it in the context of the CIP, CIP needs to host the source code and the binaries for compliance reasons. In that case having a mirror in GitLab would be a requirement.
I agree with you. But I have a consideration for current status for renesas-cip repository.
I think the current repository is under development. It looks Renesas's upstreaming effort for CIP. We can refer the repository to test the CIP kernel with Renesas backported patches on Renesas RZ/G as one of CIP reference board.
In this case, the repository can be mirroed Renesas's account or cip-playground on GitLab. But I also think GitHub (or any other place) is still an option for them, if it is under development.
Once the backported patches succesfully merged with linux-cip, we can use linux-cip on GitLab to test the Renesas RZ/G.

Best regards,
Yoshi



Chris: Will you create another repository for u-boot?

Thanks,
Daniel





I don't think it is necessary since the CIP root filesystem only supports a few packages.
Do you mind if I rewrite this and other unnecessary definitions?
I am happy if you go ahead and fix it!
OK, thanks. I will also separate Beaglebone from Cyclone V.

Thanks,
Daniel

Best regards,
Takuo Koguchi



-----Original Message-----
From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: Wednesday, June 28, 2017 5:52 PM
To: 小口琢夫 / KOGUCHI,TAKUO; cip-dev@...
Cc: 'Chris Paterson'
Subject: [!]RE: Project-X (minimal root filesystem) for renesas board

Ho Koguchi-san

-----Original Message-----
From: 小口琢夫 / KOGUCHI,TAKUO [mailto:takuo.koguchi.sw@...]
Sent: Wednesday, June 28, 2017 5:35 PM
To: Daniel Sangorrin; cip-dev@...
Cc: 'Chris Paterson'
Subject: RE: Project-X (minimal root filesystem) for renesas board

Hi Daniel-san,

I have a few questions:
- Why do you have two directories "linux-cip" and "linux-cip2" that are almost
identical?

linux-cip directory is for linux-4.4.55-cip3.
linux-cip2 is for the previous release and it is not necessary if you update linux-cip.
I think this is not a good approach. We would need to have a new linux-cip folder for each
release.

Patches for the cyclone board should be on its own CIP kernel repository (where you can
merge cip releases and add tags). Then, we can choose which version we want by
specifying the repository and tag/commit_id.

- I can see some xserver-related definitions on the board's
configuration file. Are those necessary?
beaglebone.conf is based on poky/meta-yocto-bsp/conf/machine.
xserver-related definition was inculude in the original. I am not sure if it is necessary.
I don't think it is necessary since the CIP root filesystem only supports a few packages.
Do you mind if I rewrite this and other unnecessary definitions?

Thanks,
Daniel



Takuo Koguchi


-----Original Message-----
From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: Wednesday, June 28, 2017 4:05 PM
To: cip-dev@...; 小口琢夫 / KOGUCHI,TAKUO
Cc: 'Chris Paterson'
Subject: [!]Project-X (minimal root filesystem) for renesas board

Hi Koguchi-san,
Cc: Chris, cip-dev

I'm going to add support to project-X for the Renesas iwg20m board
which is equipped with an armv7 chip.
I have noticed that you added support for beaglebone and cyclone on
the deby-armv7 folder [1].

I have a few questions:
- Why do you have two directories "linux-cip" and "linux-cip2" that are almost
identical?
- I can see some xserver-related definitions on the board's
configuration file. Are those necessary?

Thanks,
Daniel

[1]
https://gitlab.com/cip-playground/project-x/tree/master/deby-armv7


_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: Renesas dev CIP repository announcement

Yoshitake Kobayashi
 

Hi Chris and all,

[1] https://github.com/renesas-rz/renesas-cip
I had looked the repository and have a suggestion.
When you backport patches from upstream, could you add the following line in commit message?

(cherry picked from commit UPSTREAM_COMMIT_ID)

I think this approach might be better for the tracablity reason. But this is just a suggestion and I would like to know others opinion.

Best regards,
Yoshi

On 2017/06/20 17:49, Chris Paterson wrote:
Dear CIP friends,



I’d like to announce the availability of a development repo [1] based on the CIP Kernel for the iWave RZ/G1M Qseven Development Platform [2].



The main aim of this repository is to allow CIP users to get up and running with the Renesas CIP reference platform. Please note that this is just an interim step as support for the platform is added upstream/backported to the CIP Kernel.



Currently there are two branches, one based on v4.4.55-cip3, and the other based on v4.4.69-cip4.



Please use the “shmobile_defconfig” configuration when compiling, and use r8a7743-iwg20m.dtb. uImage LOADADDR should be set to "0x40008000". For u-boot environment settings, please see the iWave documentation that should come with the boards.





[1] https://github.com/renesas-rz/renesas-cip

[2] http://www.iwavesystems.com/rz-g1m-qseven-development-kit.html



Kind regards, Chris



_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Kernel maintenance and CIP testing report weeks 25 to 27

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

Kernel maintenance

1. We have a new CIP kernel v4.4.75cip6 As anecdote, the kernel includes two patches that fix two regressions introduced by LTS patches. These fixes will be part of the next LTS version.

2. Ben is focused now on the evaluation of the kernel features. The goal is to send the evaluation by mail and then attend to the CIP TSC bi-weekly call on July 24th to answer questions.

3. Ben keeps reviewing 4.4 LTS patches on ongoing basis.

Testing

1. As informed this week, Robert has been for some weeks now running the health-check on daily basis, building and booting the CIP kernel on the BBB, including the locally built initramfs.

2. Don's last task was to investigate how to configure LAVA API to send mails. Robert will pick up this task in the coming weeks. https://gitlab.com/cip-project/cip-testing/testing/issues/102

3. As reported by Robert, he has been focused in making B@D work on Windows 10, which was a request from Hitachi. There is significant progress in that front. https://gitlab.com/cip-project/cip-testing/testing/issues/106

4. After some discussion within the team, we provided a workaround to overcome the webproxy issue reported by Daniel Sangorrin. We will find out if the workaround is a good one or we need to put more effort on this topic. https://gitlab.com/cip-project/cip-testing/testing/issues/99

5. After going through the TSC request/approval process some new repositories has been created to overcome past issues with B@D and to start working on Action 2. In a couple of cases we have submitted upstream the license file which has been merged right away. https://gitlab.com/cip-project/cip-testing/testing/issues/100

6. Other topics
* Now the creation of initramfs is manual. Robert is working in automating the process https://gitlab.com/cip-project/cip-testing/testing/issues/111
* Addressing a contribution from Daniel Wargner https://gitlab.com/cip-project/cip-testing/testing/issues/107
* The testing team is starting the discussion about how to technically implement the check required to achieve the fully distributed service architecture, specially focusing now in the health-check. An e-mail has been sent about it to the cip-dev mailing list.


Other topics

1. Don is no longer working at Codethink, I would like to take this opportunity to thank him for his effort, commitment and contributions to the project. The engineering team behind CIP testing is now limited to Robert Marshall.

2. Ben H. and myself created an abstract that we have presented for ELCE.

3. CIP is a DebConf sponsor. Plat'Home was last year and Codethink is also sponsoring this edition.

Best Regards
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...


Re: B@D on Windows 10

Robert Marshall <robert.marshall@...>
 

Robert Marshall <robert.marshall@...> writes:

Robert Marshall <robert.marshall@...> writes:

The B@D development team has been investigating if there are any issues
with the use of the B@D VM on Windows. The ticket
https://gitlab.com/cip-project/cip-testing/testing/issues/106
is being used to collect information and workarounds.

Briefly the current issues/state is as follows:

- We are using virtualbox rather than rsync for config.vm.synced_folder
- core.autocrlf=input is needed in the git settings for the scripts to
run under Debian (and an ssh client either via git or another route)
- We need to look at a substitute for ser2net running on the host in
order to open a connection from the VM to the BBB
- The VM installs and both the KernelCI webserver and Lava2 run
- Having built a kernel the build does not appear in the KernelCI web
interface, there's a long delay before it times out
- Health checks can be created but they don't appear to run, the admin
interface knows about the devices but they don't appear in
Scheduler->All Devices

This testing has been carried out directly from the pure Vagrant install
- once this is running the pre-loaded Vagrant box will also be tested.

Further work is continuing to get B@D fully operational on a Windows 10 host.
To report on the progress since Friday:

- KernelCI does not work with Microsoft Edge or Internet Explorer - we
recommend the use of firefox to display kernel build results - where
the KernelCI web interface does work.
- The hostname in the VM is different when run from windows a MR
has been created to deal with both versions of this
- The QEMU health check now runs on the W10 virtual machine
- The BBB health check will run when connecting to a BBB attached to a
debian machine from the Windows VM both with the linaro kernel and a
locally built one
- We are still in progress of creating and testing a local initiramfs
and configuring the FTDI connection correctly
A further update on progress on this issue:

We've configured the Windows 10 virtual machine with ser2net (running
on the vm and enabling usb in the Vagrantfile) and now the beaglebone
black health check runs - and has been used to health check the new
v4.4.75-cip6 (together with a locally built initramfs).

I've exported a box from the W10 VM and successfully reimported it and
run a HC. We're still having problems with boxes exported from Debian
which give an error that port 8888 is in use or it attempts to
re-provision the box.

Robert


Re: Project-X (minimal root filesystem) : rewrite and renesas iwg20m board support

Jan Kiszka
 

On 2017-07-07 10:50, Daniel Sangorrin wrote:
Hi,

I've been working on a minimal root filesystem made with "deby".
The code is here and it includes BSP meta layers for qemux86-64, Beaglebone black,
Renesas iwg20m board and CycloneV.

https://gitlab.com/cip-playground/project-x/tree/master/deby

The meta-cip-common layer is where we put the packages that will be included
for all targets. The BSP meta-layers contain settings related to the architecture of
the processor, and Linux/u-boot configuration.

Currently, I have tested qemux86-64 and Renesas iwg20m. Both of them worked fine
so in the next step I will try to run tests on them using B@D.
# Beaglebone should work fine, but I haven't tested it yet.

For Cyclone V, I need a kernel repository.
Koguchi-san: could you create it on https://gitlab.com/cip-playground/linux-cip-cyclonev

Finally, for U-boot I need repositories to fetch the sources.
Should we have separate repositories for each board? For example:
https://gitlab.com/cip-playground/u-boot-iwg20m
https://gitlab.com/cip-playground/u-boot-cyclonev
Nice work! Maybe I find the time to model a binary Debian variant as
well, using Isar [1] - ideally prior to DebConf.

Btw, instead of having yet another setup.sh, you may want to have a look
at kas [2]. There is no release yet (next week, hopefully), but it is
fairly mature. Moreover, you can build inside Docker, removing most of
the host dependencies. We are using this now with both Yocto and Isar
projects, often in layered ways [3] that enable reuse.

Jan

[1] https://github.com/ilbers/isar
[2] https://github.com/siemens/kas
[3]
https://github.com/siemens/meta-iot2000/commit/eb4c3df4a62d0e5c32c74082e4c5c467627b9a84


Re: Distribution of binaries: support to Renesas board in B@D

Chris Paterson
 

Hello Agustin,

From: cip-dev-bounces@... [mailto:cip-dev-
bounces@...] On Behalf Of Agustin Benito Bethencourt
Sent: 07 July 2017 10:54

Hi Chris,

one of the things we need to figure out is how we will distribute the kernel
including the support for the Renesas board at CIP.

We have three options to provide the kernel with the board support to those
users that download the B@D box from the CIP site, to test the kernel:
1. Include the binary (kernel + board support) in the box itself.
2. Download the binaries from the CIP download page.
3. Download from a third party site.
4. Users have to build the kernel themselves.

Since we have a very limited amount of reference boards and kernels, we
would like to see option one as the default one. Option 2 would also work
fine. The other two are not ideal for the box (might be for deployment
through Vagrant).

What are the restrictions we need to face in order to distribute the Renesas
(source) code and binaries?
Let me check internally as to what we can provide.

Kind regards, Chris


Best Regards
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink agustin.benito@...
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Distribution of binaries: support to Renesas board in B@D

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi Chris,

one of the things we need to figure out is how we will distribute the kernel including the support for the Renesas board at CIP.

We have three options to provide the kernel with the board support to those users that download the B@D box from the CIP site, to test the kernel:
1. Include the binary (kernel + board support) in the box itself.
2. Download the binaries from the CIP download page.
3. Download from a third party site.
4. Users have to build the kernel themselves.

Since we have a very limited amount of reference boards and kernels, we would like to see option one as the default one. Option 2 would also work fine. The other two are not ideal for the box (might be for deployment through Vagrant).

What are the restrictions we need to face in order to distribute the Renesas (source) code and binaries?

Best Regards
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...


Re: CIP testing project: outcome of the OSSJ

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

If Chris, both Daniels or others have something to report about in the
kernel maintenance/testing front related with CIP, maybe you can help
us to deliver the talk.
I'll have a think about what we could add.

Regards, Chris


Sure, I think I will have several things that can be presented during the talk
and a demo.
I'll let you know if the talk is accepted and we will coordinate.

Best Regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...


Re: Project-X (minimal root filesystem) : rewrite and renesas iwg20m board support

Chris Paterson
 

Hello Daniel,

From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: 07 July 2017 09:51

Hi,

I've been working on a minimal root filesystem made with "deby".
The code is here and it includes BSP meta layers for qemux86-64, Beaglebone
black, Renesas iwg20m board and CycloneV.

https://gitlab.com/cip-playground/project-x/tree/master/deby

The meta-cip-common layer is where we put the packages that will be
included for all targets. The BSP meta-layers contain settings related to the
architecture of the processor, and Linux/u-boot configuration.

Currently, I have tested qemux86-64 and Renesas iwg20m. Both of them
worked fine so in the next step I will try to run tests on them using B@D.
# Beaglebone should work fine, but I haven't tested it yet.
Great to see you're making some good progress.


For Cyclone V, I need a kernel repository.
Koguchi-san: could you create it on https://gitlab.com/cip-playground/linux-
cip-cyclonev

Finally, for U-boot I need repositories to fetch the sources.
Should we have separate repositories for each board? For example:
https://gitlab.com/cip-playground/u-boot-iwg20m
https://gitlab.com/cip-playground/u-boot-cyclonev
If the consensus is to use different u-boot versions/repos for each platform, (rather than push vendors to add support upstream), then this approach makes sense.

However, perhaps we should try and use exiting repositories provided by the vendors, rather than CIP create and maintain them. If we start hosting these repositories we will have to continue to maintain them forever.

Of course, the downside of using externally maintained repositories is that support may end at any time. Perhaps bringing this ownership/maintenance into the CIP project is something we want to do/fund.


Kind regards, Chris


Thanks,
Daniel


Re: Project-X (minimal root filesystem) for renesas board

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

On 07/07/17 04:40, Daniel Sangorrin wrote:
Hi Agustin, Chris

-----Original Message-----
From: cip-dev-bounces@... [mailto:cip-dev-bounces@...] On Behalf Of Agustin Benito Bethencourt
Sent: Thursday, June 29, 2017 5:21 PM
To: cip-dev@...
Subject: Re: [cip-dev] Project-X (minimal root filesystem) for renesas board

Hi,

On 29/06/17 02:37, Daniel Sangorrin wrote:
Hi Koguchi-san,

-----Original Message-----
From: 小口琢夫 / KOGUCHI,TAKUO [mailto:takuo.koguchi.sw@...]
Sent: Wednesday, June 28, 2017 6:08 PM
To: 'Daniel Sangorrin'; cip-dev@...
Cc: 'Chris Paterson'
Subject: RE: RE: Project-X (minimal root filesystem) for renesas board

Daniel-san,

I think this is not a good approach. We would need to have a new linux-cip folder for each
release.
Let make it clear. Will you please describe your recommendation?
Yes, please see below.

Patches for the cyclone board should be on its own CIP kernel repository (where you can
merge cip releases and add tags). Then, we can choose which version we want by
specifying the repository and tag/commit_id.
Good point. But CIP kernel repository is curerntly used for release assuming it is tested. And CycloneV is not supported by CIP at
this
moment. So I put the patches in the yocto project way.
I didn't mean to put it on Ben's CIP repository rather on github. This way you can better maintain your "out-of-tree" cyclone V
patches
and merge (do not rebase please) changes from Ben's CIP kernel regularly. In other words, do the same as Renesas is doing at [1].

[1] https://github.com/renesas-rz/renesas-cip
In order to have all the cip related code in one place, it would be
good, if anybody is using github, that at least there is a mirror of
that repo in gitlab. When we start automating builds/test, that would be
helpful.
Agustin: I don't mind, but is this necessary?.
Necessary? not in my opinion. I think that development should take place whenever is best for the developers.

Two considerations:

TSC agreed to use Gitlab for mainly one reason: services built with gitlab can be replicated by Members in-house. That is not the case for GitHub.

Once the code is developed and the developer want to distribute it in the context of the CIP, CIP needs to host the source code and the binaries for compliance reasons. In that case having a mirror in GitLab would be a requirement.

Chris: Will you create another repository for u-boot?

Thanks,
Daniel





I don't think it is necessary since the CIP root filesystem only supports a few packages.
Do you mind if I rewrite this and other unnecessary definitions?
I am happy if you go ahead and fix it!
OK, thanks. I will also separate Beaglebone from Cyclone V.

Thanks,
Daniel

Best regards,
Takuo Koguchi



-----Original Message-----
From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: Wednesday, June 28, 2017 5:52 PM
To: 小口琢夫 / KOGUCHI,TAKUO; cip-dev@...
Cc: 'Chris Paterson'
Subject: [!]RE: Project-X (minimal root filesystem) for renesas board

Ho Koguchi-san

-----Original Message-----
From: 小口琢夫 / KOGUCHI,TAKUO [mailto:takuo.koguchi.sw@...]
Sent: Wednesday, June 28, 2017 5:35 PM
To: Daniel Sangorrin; cip-dev@...
Cc: 'Chris Paterson'
Subject: RE: Project-X (minimal root filesystem) for renesas board

Hi Daniel-san,

I have a few questions:
- Why do you have two directories "linux-cip" and "linux-cip2" that are almost
identical?

linux-cip directory is for linux-4.4.55-cip3.
linux-cip2 is for the previous release and it is not necessary if you update linux-cip.
I think this is not a good approach. We would need to have a new linux-cip folder for each
release.

Patches for the cyclone board should be on its own CIP kernel repository (where you can
merge cip releases and add tags). Then, we can choose which version we want by
specifying the repository and tag/commit_id.

- I can see some xserver-related definitions on the board's
configuration file. Are those necessary?
beaglebone.conf is based on poky/meta-yocto-bsp/conf/machine.
xserver-related definition was inculude in the original. I am not sure if it is necessary.
I don't think it is necessary since the CIP root filesystem only supports a few packages.
Do you mind if I rewrite this and other unnecessary definitions?

Thanks,
Daniel



Takuo Koguchi


-----Original Message-----
From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: Wednesday, June 28, 2017 4:05 PM
To: cip-dev@...; 小口琢夫 / KOGUCHI,TAKUO
Cc: 'Chris Paterson'
Subject: [!]Project-X (minimal root filesystem) for renesas board

Hi Koguchi-san,
Cc: Chris, cip-dev

I'm going to add support to project-X for the Renesas iwg20m board
which is equipped with an armv7 chip.
I have noticed that you added support for beaglebone and cyclone on
the deby-armv7 folder [1].

I have a few questions:
- Why do you have two directories "linux-cip" and "linux-cip2" that are almost
identical?
- I can see some xserver-related definitions on the board's
configuration file. Are those necessary?

Thanks,
Daniel

[1]
https://gitlab.com/cip-playground/project-x/tree/master/deby-armv7


_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...


Project-X (minimal root filesystem) : rewrite and renesas iwg20m board support

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi,

I've been working on a minimal root filesystem made with "deby".
The code is here and it includes BSP meta layers for qemux86-64, Beaglebone black,
Renesas iwg20m board and CycloneV.

https://gitlab.com/cip-playground/project-x/tree/master/deby

The meta-cip-common layer is where we put the packages that will be included
for all targets. The BSP meta-layers contain settings related to the architecture of
the processor, and Linux/u-boot configuration.

Currently, I have tested qemux86-64 and Renesas iwg20m. Both of them worked fine
so in the next step I will try to run tests on them using B@D.
# Beaglebone should work fine, but I haven't tested it yet.

For Cyclone V, I need a kernel repository.
Koguchi-san: could you create it on https://gitlab.com/cip-playground/linux-cip-cyclonev

Finally, for U-boot I need repositories to fetch the sources.
Should we have separate repositories for each board? For example:
https://gitlab.com/cip-playground/u-boot-iwg20m
https://gitlab.com/cip-playground/u-boot-cyclonev

Thanks,
Daniel


Re: CIP testing project: outcome of the OSSJ

Chris Paterson
 

Hello,


From: cip-dev-bounces@... [mailto:cip-dev-
bounces@...] On Behalf Of Daniel Sangorrin
Sent: 07 July 2017 03:38

Hi Agustin,

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Agustin
Benito Bethencourt
Sent: Friday, July 07, 2017 12:30 AM
To: cip-dev@...
Subject: Re: [cip-dev] CIP testing project: outcome of the OSSJ

Hi,

On 14/06/17 17:28, Agustin Benito Bethencourt wrote:
I plan to submit a talk about our progress in the testing front for
ELCE. Action 2:
https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptest
ing
I just submitted a technical talk in which Ben H. and myself will be
talking about kernel maintenance & testing using the CIP work as
example. Let's see if it gets approved.

If Chris, both Daniels or others have something to report about in the
kernel maintenance/testing front related with CIP, maybe you can help
us to deliver the talk.
I'll have a think about what we could add.

Regards, Chris


Sure, I think I will have several things that can be presented during the talk
and a demo.

Thanks,
Daniel


Best regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: running health checks from behind a web proxy

Robert Marshall <robert.marshall@...>
 

Thanks - hope it works for you, hold off on closing that issue for the
moment, there's one other sub issue that I've just created a MR

https://gitlab.com/cip-project/cip-testing/board-at-desk-single-dev/merge_requests/34

that needs addressing before it can be closed.

Robert

"Daniel Sangorrin" <daniel.sangorrin@...> writes:

Thanks Robert, I will try today and see if it works.
# I'll close the gitlab issue in that case.

-----Original Message-----
From: cip-dev-bounces@... [mailto:cip-dev-bounces@...] On Behalf Of Robert Marshall
Sent: Wednesday, July 05, 2017 11:19 PM
To: cip dev
Subject: [cip-dev] running health checks from behind a web proxy

There is a known issue with b@d when running a lava QEMU health check
from behind a web proxy.

When attempting to retrieve the kernel, it produces the error

Invalid job data:
["HTTPSConnectionPool(host='images.validation.linaro.org', port=443):
Max retries exceeded with url: /kvm/standard/stretch-2.img.gz
(Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection
object at 0x7f430c9b9c50>: Failed to establish a new connection: [Errno -5] No address associated with hostname',))"]

see:
https://gitlab.com/cip-project/cip-testing/testing/issues/99

As b@d is intended to use locally built artefacts and the default QEMU health
check uses a remote kernel, a suggested work around for this test would be to copy
https://images.validation.linaro.org/kvm/standard/stretch-2.img.gz
locally to /var/www/images/kernel-ci/qemu (a new directory)
and alter the health check to use the url
http://localhost:8010/qemu/stretch-2.img.gz

which should avoid the use of any web proxies.

You'll probably need a fairly clean copy of the VM with plenty of free
disk space to manage the extra copy of the kernel.

Thoughts? Hoping to discuss this further at tomorrow's open meeting.

Robert
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: Project-X (minimal root filesystem) for renesas board

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Agustin, Chris

-----Original Message-----
From: cip-dev-bounces@... [mailto:cip-dev-bounces@...] On Behalf Of Agustin Benito Bethencourt
Sent: Thursday, June 29, 2017 5:21 PM
To: cip-dev@...
Subject: Re: [cip-dev] Project-X (minimal root filesystem) for renesas board

Hi,

On 29/06/17 02:37, Daniel Sangorrin wrote:
Hi Koguchi-san,

-----Original Message-----
From: 小口琢夫 / KOGUCHI,TAKUO [mailto:takuo.koguchi.sw@...]
Sent: Wednesday, June 28, 2017 6:08 PM
To: 'Daniel Sangorrin'; cip-dev@...
Cc: 'Chris Paterson'
Subject: RE: RE: Project-X (minimal root filesystem) for renesas board

Daniel-san,

I think this is not a good approach. We would need to have a new linux-cip folder for each
release.
Let make it clear. Will you please describe your recommendation?
Yes, please see below.

Patches for the cyclone board should be on its own CIP kernel repository (where you can
merge cip releases and add tags). Then, we can choose which version we want by
specifying the repository and tag/commit_id.
Good point. But CIP kernel repository is curerntly used for release assuming it is tested. And CycloneV is not supported by CIP at
this
moment. So I put the patches in the yocto project way.
I didn't mean to put it on Ben's CIP repository rather on github. This way you can better maintain your "out-of-tree" cyclone V
patches
and merge (do not rebase please) changes from Ben's CIP kernel regularly. In other words, do the same as Renesas is doing at [1].

[1] https://github.com/renesas-rz/renesas-cip
In order to have all the cip related code in one place, it would be
good, if anybody is using github, that at least there is a mirror of
that repo in gitlab. When we start automating builds/test, that would be
helpful.
Agustin: I don't mind, but is this necessary?.
Chris: Will you create another repository for u-boot?

Thanks,
Daniel





I don't think it is necessary since the CIP root filesystem only supports a few packages.
Do you mind if I rewrite this and other unnecessary definitions?
I am happy if you go ahead and fix it!
OK, thanks. I will also separate Beaglebone from Cyclone V.

Thanks,
Daniel

Best regards,
Takuo Koguchi



-----Original Message-----
From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: Wednesday, June 28, 2017 5:52 PM
To: 小口琢夫 / KOGUCHI,TAKUO; cip-dev@...
Cc: 'Chris Paterson'
Subject: [!]RE: Project-X (minimal root filesystem) for renesas board

Ho Koguchi-san

-----Original Message-----
From: 小口琢夫 / KOGUCHI,TAKUO [mailto:takuo.koguchi.sw@...]
Sent: Wednesday, June 28, 2017 5:35 PM
To: Daniel Sangorrin; cip-dev@...
Cc: 'Chris Paterson'
Subject: RE: Project-X (minimal root filesystem) for renesas board

Hi Daniel-san,

I have a few questions:
- Why do you have two directories "linux-cip" and "linux-cip2" that are almost
identical?

linux-cip directory is for linux-4.4.55-cip3.
linux-cip2 is for the previous release and it is not necessary if you update linux-cip.
I think this is not a good approach. We would need to have a new linux-cip folder for each
release.

Patches for the cyclone board should be on its own CIP kernel repository (where you can
merge cip releases and add tags). Then, we can choose which version we want by
specifying the repository and tag/commit_id.

- I can see some xserver-related definitions on the board's
configuration file. Are those necessary?
beaglebone.conf is based on poky/meta-yocto-bsp/conf/machine.
xserver-related definition was inculude in the original. I am not sure if it is necessary.
I don't think it is necessary since the CIP root filesystem only supports a few packages.
Do you mind if I rewrite this and other unnecessary definitions?

Thanks,
Daniel



Takuo Koguchi


-----Original Message-----
From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: Wednesday, June 28, 2017 4:05 PM
To: cip-dev@...; 小口琢夫 / KOGUCHI,TAKUO
Cc: 'Chris Paterson'
Subject: [!]Project-X (minimal root filesystem) for renesas board

Hi Koguchi-san,
Cc: Chris, cip-dev

I'm going to add support to project-X for the Renesas iwg20m board
which is equipped with an armv7 chip.
I have noticed that you added support for beaglebone and cyclone on
the deby-armv7 folder [1].

I have a few questions:
- Why do you have two directories "linux-cip" and "linux-cip2" that are almost
identical?
- I can see some xserver-related definitions on the board's
configuration file. Are those necessary?

Thanks,
Daniel

[1]
https://gitlab.com/cip-playground/project-x/tree/master/deby-armv7


_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: CIP testing project: outcome of the OSSJ

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Agustin,

-----Original Message-----
From: cip-dev-bounces@... [mailto:cip-dev-bounces@...] On Behalf Of Agustin Benito Bethencourt
Sent: Friday, July 07, 2017 12:30 AM
To: cip-dev@...
Subject: Re: [cip-dev] CIP testing project: outcome of the OSSJ

Hi,

On 14/06/17 17:28, Agustin Benito Bethencourt wrote:
I plan to submit a talk about our progress in the testing front for
ELCE. Action 2:
https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting
I just submitted a technical talk in which Ben H. and myself will be
talking about kernel maintenance & testing using the CIP work as
example. Let's see if it gets approved.

If Chris, both Daniels or others have something to report about in the
kernel maintenance/testing front related with CIP, maybe you can help us
to deliver the talk.
Sure, I think I will have several things that can be presented during the talk
and a demo.

Thanks,
Daniel


Best regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: running health checks from behind a web proxy

Daniel Sangorrin <daniel.sangorrin@...>
 

Thanks Robert, I will try today and see if it works.
# I'll close the gitlab issue in that case.

-----Original Message-----
From: cip-dev-bounces@... [mailto:cip-dev-bounces@...] On Behalf Of Robert Marshall
Sent: Wednesday, July 05, 2017 11:19 PM
To: cip dev
Subject: [cip-dev] running health checks from behind a web proxy

There is a known issue with b@d when running a lava QEMU health check
from behind a web proxy.

When attempting to retrieve the kernel, it produces the error

Invalid job data:
["HTTPSConnectionPool(host='images.validation.linaro.org', port=443):
Max retries exceeded with url: /kvm/standard/stretch-2.img.gz
(Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection
object at 0x7f430c9b9c50>: Failed to establish a new connection: [Errno -5] No address associated with hostname',))"]

see:
https://gitlab.com/cip-project/cip-testing/testing/issues/99

As b@d is intended to use locally built artefacts and the default QEMU health
check uses a remote kernel, a suggested work around for this test would be to copy
https://images.validation.linaro.org/kvm/standard/stretch-2.img.gz
locally to /var/www/images/kernel-ci/qemu (a new directory)
and alter the health check to use the url
http://localhost:8010/qemu/stretch-2.img.gz

which should avoid the use of any web proxies.

You'll probably need a fairly clean copy of the VM with plenty of free
disk space to manage the extra copy of the kernel.

Thoughts? Hoping to discuss this further at tomorrow's open meeting.

Robert
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: New repos for tests and logs

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

On 29/06/17 11:40, Agustin Benito Bethencourt wrote:
Hi,

three new repositories has been created:

* https://gitlab.com/cip-project/cip-testing/imported-kernel-tests

For those third party tests we will use to test the CIP kernel

* https://gitlab.com/cip-project/cip-testing/CIP-kernel-test-logs

For the canonical logs we will compare results against.

* https://gitlab.com/cip-project/cip-kernel-tests

Test developed within the CIP project under CIP approved licenses.
A new repository has been created to mirror some kernelci frontend config files that we use so we can control which upstream changes should be applied when. It is called kernelci-frontend-config

Link: https://gitlab.com/cip-project/cip-testing/kernelci-frontend-config/tree/master

Best Regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...


Re: CIP testing project: outcome of the OSSJ

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

On 14/06/17 17:28, Agustin Benito Bethencourt wrote:
I plan to submit a talk about our progress in the testing front for
ELCE. Action 2:
https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting
I just submitted a technical talk in which Ben H. and myself will be talking about kernel maintenance & testing using the CIP work as example. Let's see if it gets approved.

If Chris, both Daniels or others have something to report about in the kernel maintenance/testing front related with CIP, maybe you can help us to deliver the talk.

Best regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...


stable/linux-4.4.y build: 199 builds: 0 failed, 199 passed, 4 warnings (v4.4.76)

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

please see below an example of a report sent to the kernel-build-reports@... of the latest LTS kernel version.

As you know, kernelci is mainly targeting kernel developers, not kernel maintainers. I suspect that Ben H. and Daniel W. will suggest changes in this report, specially when we add specific tests to our "CIP suite". I think this is a great reference though.


-------- Forwarded Message --------
Subject: stable/linux-4.4.y build: 199 builds: 0 failed, 199 passed, 4
warnings (v4.4.76)
Date: Wed, 05 Jul 2017 08:59:44 -0700 (PDT)
From: kernelci.org bot <bot@...>
To: kernel-build-reports@...



stable/linux-4.4.y build: 199 builds: 0 failed, 199 passed, 4 warnings
(v4.4.76) *stable/linux-4.4.y build: 199 builds: 0 failed, 199 passed, 4
warnings (v4.4.76)*
Full Build Summary:
https://kernelci.org/build/stable/branch/linux-4.4.y/kernel/v4.4.76/
Tree: stable
Branch: linux-4.4.y
Git Describe: v4.4.76
Git Commit: 4282d39575bf17daedc18f2fe01ca349830a6e99
Git URL:
http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
<https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=4282d39575bf17daedc18f2fe01ca349830a6e99>
Built: 4 unique architectures

*Warnings Detected:*

x86: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
defconfig+CONFIG_KASAN=y
<https://kernelci.org/build/id/595d084059b514da801baba7/> 4 warnings
<https://storage.kernelci.org/stable/linux-4.4.y/v4.4.76/x86/defconfig+CONFIG_KASAN=y/build-warnings.log>



Warnings summary:
1 net/wireless/nl80211.c:5096:1: warning: the frame size of 2064 bytes
is larger than 2048 bytes [-Wframe-larger-than=]
1 net/wireless/nl80211.c:3859:1: warning: the frame size of 2168 bytes
is larger than 2048 bytes [-Wframe-larger-than=]
1 net/wireless/nl80211.c:1728:1: warning: the frame size of 5640 bytes
is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/tty/vt/keyboard.c:1470:1: warning: the frame size of 2344
bytes is larger than 2048 bytes [-Wframe-larger-than=]

*Detailed per-defconfig build reports:*

*acs5k_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*acs5k_tiny_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*allmodconfig+CONFIG_OF=n* (x86) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*allnoconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*allnoconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*allnoconfig* (x86) — PASS, 0 errors, 0 warnings, 0 section mismatches

*allnoconfig* (arm64) — PASS, 0 errors, 0 warnings, 0 section mismatches

*am200epdkit_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*ar7_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*assabet_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*at91_dt_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*ath79_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*axm55xx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*badge4_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*bcm2835_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*bcm47xx_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*bcm63xx_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*bcm_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*bigsur_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*bmips_be_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*bmips_stb_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*capcella_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*cavium_octeon_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*cerfcube_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*ci20_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*clps711x_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*cm_x2xx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*cm_x300_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*cns3420vb_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*cobalt_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*colibri_pxa270_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*colibri_pxa300_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*collie_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*corgi_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*davinci_all_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*db1xxx_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*decstation_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*defconfig* (arm64) — PASS, 0 errors, 0 warnings, 0 section mismatches

*defconfig+CONFIG_CPU_BIG_ENDIAN=y* (arm64) — PASS, 0 errors, 0
warnings, 0 section mismatches

*defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y* (arm64) — PASS, 0 errors, 0
warnings, 0 section mismatches

*defconfig+CONFIG_KASAN=y* (x86) — PASS, 0 errors, 4 warnings, 0 section
mismatches

Warnings:
net/wireless/nl80211.c:3859:1: warning: the frame size of 2168 bytes is
larger than 2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:5096:1: warning: the frame size of 2064 bytes is
larger than 2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:1728:1: warning: the frame size of 5640 bytes is
larger than 2048 bytes [-Wframe-larger-than=]
drivers/tty/vt/keyboard.c:1470:1: warning: the frame size of 2344 bytes
is larger than 2048 bytes [-Wframe-larger-than=]

*defconfig+CONFIG_LKDTM=y* (mips) — PASS, 0 errors, 0 warnings, 0
section mismatches

*defconfig+CONFIG_LKDTM=y* (x86) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*defconfig+CONFIG_LKDTM=y* (arm64) — PASS, 0 errors, 0 warnings, 0
section mismatches

*defconfig+CONFIG_OF_UNITTEST=y* (x86) — PASS, 0 errors, 0 warnings, 0
section mismatches

*defconfig+CONFIG_OF_UNITTEST=y* (arm64) — PASS, 0 errors, 0 warnings, 0
section mismatches

*defconfig+CONFIG_RANDOMIZE_BASE=y* (arm64) — PASS, 0 errors, 0
warnings, 0 section mismatches

*defconfig+kvm_guest* (x86) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*dove_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*e55_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*ebsa110_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*efm32_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*em_x270_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*ep93xx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*eseries_pxa_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*exynos_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*ezx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*footbridge_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*fuloong2e_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*gpr_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*h3600_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*h5000_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*hackkit_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*hisi_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*i386_defconfig* (x86) — PASS, 0 errors, 0 warnings, 0 section mismatches

*imote2_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*imx_v4_v5_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*imx_v6_v7_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*integrator_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*iop13xx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*iop32x_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*iop33x_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*ip22_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*ip27_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*ip28_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*ip32_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*ixp4xx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*jazz_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*jmr3927_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*jornada720_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*keystone_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*ks8695_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*lart_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*lasat_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*lemote2f_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*loongson3_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*lpc18xx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*lpc32xx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*lpd270_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*ls1b_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*lubbock_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*magician_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*mainstone_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*malta_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*malta_kvm_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*malta_kvm_guest_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0
section mismatches

*malta_qemu_32r6_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0
section mismatches

*maltaaprp_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*maltasmvp_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*maltasmvp_eva_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*maltaup_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*maltaup_xpa_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*markeins_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*mini2440_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*mips_paravirt_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*mmp2_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*moxart_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*mpc30x_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*msp71xx_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*mtx1_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*multi_v5_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*multi_v7_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*multi_v7_defconfig+CONFIG_ARM_LPAE=y* (arm) — PASS, 0 errors, 0
warnings, 0 section mismatches

*multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y* (arm) — PASS, 0 errors, 0
warnings, 0 section mismatches

*multi_v7_defconfig+CONFIG_EFI=y* (arm) — PASS, 0 errors, 0 warnings, 0
section mismatches

*multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y* (arm) — PASS, 0
errors, 0 warnings, 0 section mismatches

*multi_v7_defconfig+CONFIG_LKDTM=y* (arm) — PASS, 0 errors, 0 warnings,
0 section mismatches

*multi_v7_defconfig+CONFIG_PROVE_LOCKING=y* (arm) — PASS, 0 errors, 0
warnings, 0 section mismatches

*multi_v7_defconfig+CONFIG_SMP=n* (arm) — PASS, 0 errors, 0 warnings, 0
section mismatches

*multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y*
(arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*mv78xx0_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*mvebu_v5_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*mvebu_v7_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*mvebu_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y* (arm) — PASS, 0 errors, 0
warnings, 0 section mismatches

*mxs_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*neponset_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*netwinder_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*netx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*nhk8815_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*nlm_xlp_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*nlm_xlr_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*nuc910_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*nuc950_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*nuc960_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*omap1_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*omap2plus_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*orion5x_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*palmz72_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*pcm027_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*pistachio_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*pleb_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*pnx8335_stb225_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0
section mismatches

*prima2_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*pxa168_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*pxa255-idp_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*pxa3xx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*pxa910_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*qcom_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*qi_lb60_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*raumfeld_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*rb532_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*rbtx49xx_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*realview-smp_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*realview_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*rm200_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*rpc_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*rt305x_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*s3c2410_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*s3c6400_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*s5pv210_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*sama5_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*sb1250_swarm_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*sead3_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*sead3micro_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*shannon_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*shmobile_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*simpad_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*socfpga_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*spear13xx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*spear3xx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*spear6xx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*spitz_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*stm32_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*sunxi_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*tb0219_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*tb0226_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*tb0287_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*tct_hammer_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*tegra_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*tinyconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*tinyconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*tinyconfig* (x86) — PASS, 0 errors, 0 warnings, 0 section mismatches

*tinyconfig* (arm64) — PASS, 0 errors, 0 warnings, 0 section mismatches

*trizeps4_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*u300_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*u8500_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*versatile_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*versatile_defconfig+CONFIG_OF_UNITTEST=y* (arm) — PASS, 0 errors, 0
warnings, 0 section mismatches

*vexpress_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*vf610m4_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*viper_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*vt8500_v6_v7_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*workpad_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*x86_64_defconfig* (x86) — PASS, 0 errors, 0 warnings, 0 section mismatches

*xcep_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*xilfpga_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*xway_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*zeus_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*zx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


For more info write to <info@... <mailto:info@...>>


--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...


Re: LAVA health checks

Chris Paterson
 

Hello Agustin,

From: cip-dev-bounces@... [mailto:cip-dev-
bounces@...] On Behalf Of Agustin Benito Bethencourt
Sent: 05 July 2017 14:20

Hi,

one of the tasks that the CIP testing team has been performing since before
the B@D release is a daily LAVA health check using the CIP kernel and BBB[2].

What is a health check?

According to LAVA documentation[1]...

"A health check is a special type of test job, designed to validate that the a
test device and the infrastructure around it are suitable for running LAVA
tests. Health checks jobs are run periodically to check for equipment and/or
infrastructure failures that may have happened. [...]"

So we are using this daily health check as "validation test" for B@D in our
default (for now) set up, that is B@D running on Linux + CIP kernel
+ BBB.

So on top of the testing that Ben H. does as maintainer, the CIP testing
team is booting the kernel on the BBB using B@D on daily basis. On the
positive side, this health check can be reproduced by others. But still
we are providing limited value since results are not shared.

Action 2 is the next milestone, in which we want to use B@D to test the
kernel (first, then a simple system) in a fully decentralised
environment (some would call it architecture).

The initial step is for B@D to be able to send mails (reports)
automatically to the cip-test-results mailing list. With this feature,
we could collaborate in ensuring the B@D is ready to test the CIP kernel
on complementary environments like:
* Using Renesas boards
* Running B@D on Windows10

on daily basis.

But sharing the results in the CIP context is far from enough. We need
to ensure transparently that any of us is:
1. using the same tests...
2. to test the same CIP system...
3. on the same boards...
4. with the same tool set...
5. under the same environment...
6. producing the same reports...
7. based on the same logs.
Thank you for raising this point. You are of course correct.


During our Thursday meetings (remember they are open so please join us)
we are starting to think about how we can use the health check concept
to "validate" points 2 to 5. This is a very interesting challenge that
we believe we can solve to great extend assuming a "fully distributed
testing service architecture"..
I should be able to attend this week.

Kind regards, Chris


[1] https://validation.linaro.org/static/docs/v2/healthchecks.html
[2] BBB - BeagleBone Black

Best Regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev

9221 - 9240 of 9574