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@...

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

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@...

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

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

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:

Hi Agustin, Chris

Hi Agustin,

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

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@...

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@...

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@...

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

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

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.

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"..

[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@...

Hi,

On 05/07/17 02:44, Daniel Sangorrin wrote:

Can someone confirm the above results, please? Now that Robert is the
only person working on the testing front, double checking his results by
other companies/contributors becomes almost imperative.

Unfortunately I don't have a Windows 10 machine to test it.
But if the proxy problem is fixed has been fixed I can try instralling B@D again
on my Ubuntu machine.

It should be the next one on our bug list.

Best Regards


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

Hi Agustin,

Hi,

On 2017-07-04 15:18, Agustin Benito Bethencourt wrote:

Dear CIP friends,
please check below. This is a use case we will meet in a few weeks/months. It is important to see others walking the same route.

My simple tests are running now thanks to the help of the nice people from the #linaro-lava chat.

1) Crazy me decided to use upstream u-boot 2017.05 instead of running some ancient version from 2014;)

1.1) which happens to have a different AUTOBOOT_PROMPT than the one Lava expects "Press SPACE to abort autoboot in %d seconds\n" instead of "Hit any key to stop autoboot" so (since) I would like to be able to stay as close as possible to upstream LAVA 2017.06 I patched u-boot[1]. Note that this could be fixed with LAVA as well - interrupt_prompt: {{ interrupt_prompt|default('Hit any key to stop autoboot') }}

1.2) also the SYS_PROMPT of upstream u-boot is different than the one expected by LAVA and again I made a u-boot patch[2]. Note that this could be fixed with LAVA as well - {% set bootloader_prompt = bootloader_prompt|default('U-Boot') %}

2) After some searching it turned out that LAVA set some funny variables in u-boot which made my kernel crash. (Crazy me decided to use a 4.9.x uImage without baked in address).

Adding this:
{% set base_high_limits = false %}
to my bbb03.jinja2 file fixed it.

... obviously ;)

Regards,

Robert

[1] https://github.com/RobertBerger/meta-mainline/blob/pyro-training-v4.9.x/u-boot-wic-bsp/recipes-bsp/u-boot/2017.05/beagle-bone-black/0002-default-AUTOBOOT_PROMPT-for-LAVA.patch
[2] https://github.com/RobertBerger/meta-mainline/blob/pyro-training-v4.9.x/u-boot-wic-bsp/recipes-bsp/u-boot/2017.05/beagle-bone-black/0003-SYS_PROMPT-LAVA-compatible.patch

Dear CIP friends,

please check below. This is a use case we will meet in a few weeks/months. It is important to see others walking the same route.


-------- Forwarded Message --------
Subject: [Lava-users] OE/Yocto testcase
Date: Mon, 3 Jul 2017 20:19:31 +0300
From: Robert Berger <lava.users.mailinglist@...>
To: Lava-users@...

Hi,

I succeeded in running the example Lava tests[1][2] on a Beagle Bone
Black in my lab.

Now I would like to test a core-image-minimal I built with Yocto and
cooked up something like this[3][4].

The result is unfortunately this[5].

I guess one of the problems I have is this:

lava-test: # ls -l /lava-38/
export SHELL=/bin/sh
/lava-38/bin/lava-test-runner /lava-38/0ls: cannot access '/lava-38/':
No such file or directory
lava-test: # export SHELL=/bin/sh
lava-test: # /lava-38/bin/lava-test-runner /lava-38/0
-sh: /lava-38/bin/lava-test-runner: No such file or directory

Regards,

Robert


[1]
https://validation.linaro.org/static/docs/v2/examples/test-jobs/standard-armmp-ramdisk-bbb.yaml
[2]
https://validation.linaro.org/static/docs/v2/examples/test-jobs/standard-armmp-nfs-bbb.yaml

[3]
https://github.com/RobertBerger/git.linaro.org-lava-team-refactoring/blob/master/bbb-core-image-minimal-1.yaml
[4]
https://github.com/RobertBerger/git.linaro.org-qa-test-definitions/blob/master/openembedded/smoke-tests-basic-core-image-minimal.yaml

[5] https://pastebin.com/14pjxhiN
_______________________________________________
Lava-users mailing list
Lava-users@...
https://lists.linaro.org/mailman/listinfo/lava-users

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

Hi,

On 04/07/17 11:32, Robert Marshall wrote:

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

Can someone confirm the above results, please? Now that Robert is the only person working on the testing front, double checking his results by other companies/contributors becomes almost imperative.

Thank you Robert, good progress this week.

As usual, you can also meet us at #cip in freenode.

- We are still in progress of creating and testing a local initiramfs
and configuring the FTDI connection correctly


Robert
_______________________________________________
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@...