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


Robert

I've released Linux version 4.4.75-cip6. This adds the fixes from
stable versions 4.4.70-4.4.75 inclusive, plus two regression fixes that
were missing from the 4.4 stable branch. I reviewed those fixes, but
have only done very basic manual testing of the result.

(I also tagged a version 4.4.75-cip5 which doesn't include the two extra
fixes.)

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.

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.

Robert

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.

Best Regards

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

Hi,

as a results of the work we have done to take control over building the CIP kernel and initramfs, we have introduced in our critical content path a fourth wiki page[1], so now we have five.[2]

This wiki page describes how to create an initramfs with BusyBox for the Beaglebone Black and how to build the CIP Kernel with Kernel CI.

[1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipsystembuildhowto
[2] https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting#action-1board-at-desk-single-developer-b-d

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

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.

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

Hi Koguchi-san,

Hello Agustin,

Thank you for your feedback, apologies for the delayed response.

From: Agustin Benito Bethencourt [mailto:agustin.benito@...]
Sent: 20 June 2017 18:06

Hi Chris,

I think I mentioned before some of the below arguments when this topic
was risen months ago. It is a good time to publish them here.

On 20/06/17 17:18, Ben Hutchings wrote:

On Tue, 2017-06-20 at 09:12 +0000, Chris Paterson wrote:

Hello Ben,

Do you have a plan for when future releases of the CIP Kernel will be
made?

It would be good to have a fixed release cadence or roadmap, so
people using the Kernel can plan their activities accordingly.

I expect to release about every month, and whenever there's an urgent
security update (which there will be soon, for the "stack clash" issue).

I would like to keep flexibility here, that is, do not tight ourselves to releases
yet for a variety of reasons. These are the main ones I can think of right now:

* We are in an LTS phase. Defining a cadence at this point might reinforce the
idea that our kernel maintenance process is somehow different than LTS
when, except for a few packages, it is not yet. That was intentional.

* I would like to be able to consistently test the kernel, even with a single
test, before claiming to make releases, that is, before making a public
commitment on any delivery process. The expectations can be higher that
we can commit to.

* We do not know at this point what the maintenance cycle is going to be
from the kernel community. I am not suggesting that we have to follow it,
but before defining our cadence, I would have a clear idea about what
upstream will do.

* A kernel release for SLTS has severe implications in other areas, like the
testing tools, testing results, tests, etc. We need also to freeze/store/release
them, together with the build instructions, metadata, artifacts, source
code.... In other words, we need to define what "a release" means for CIP
and how much effort requires.

This is a good point. I guess I was referring to rebasing the CIP Kernel itself to the latest LTS tag, and when this would be done. E.g. LTS tag + x weeks?

* With the above and the fact that we are starting to put effort in -RT, I
wonder if we will talk about releasing the CIP kernel or we will talk about
releasing the CIP platform (assuming that at the beginning the kernel is the
main bit).

I think that the CIP Kernel could/should be updated constantly, like LTS is now.

Periodically a complete 'CIP platform' release should be made. I think this should be done to a schedule so that users of the CIP project can plan their activities accordingly.

Defining a release today might play against us in a year or two.

Once this said, if Members require at this point a cadence, we will provide
one but I think that sticking to LTS cycle until Feb'18 and assuming that we will
catch up every 4-8 weeks is the way to go. Once the 4.4 maintainer is
published, let's talk to him/her and take decisions.

Is there a specific reason why you need a cadence now beyond what LTS
provides? I am trying to understand the details in order to think about a
solution for Renesas compatible with the above.

Is there an actual release cycle for LTS? As far as I can see, new releases are made randomly.

Kind regards, Chris

Best Regards

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

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?

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 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!

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

Ho Koguchi-san

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


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

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

Hello Daniel,

From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: 28 June 2017 04:07

Hi Chris,

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Chris
Paterson
Sent: Tuesday, June 20, 2017 5:49 PM
To: cip-dev@...
Subject: [cip-dev] Renesas dev CIP repository announcement

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
<http://www.iwavesystems.com/rz-g1m-qseven-
development-kit.html>

I just wanted to tell you that I managed to build and boot the CIP kernel on
the iwg20m board from tftpboot.

The only problem I had was that the original u-boot environment (kernel
3.10) used /dev/mmcblk2p2, whereas for kernel CIP 4.4 (using the same
original filesystem) I had to change that to root=/dev/mmcblk0p2.

Thank you for pointing this out. I'm afraid that everyone will need to make this change if using the supplied u-boot env. Sorry I missed this.

Apart from that:
- the upper blue usb 3 connector doesn't seem to work. (it didn't work
either on the factory kernel 3.10)

The RZ/G1M only supports one channel of USB3.0. The carrier board is used for other SoC SOM modules, hence there are some connectors that will not work either due to lack of support or multiplexing - SATA, HDMI, the upper USB3.0 port.

For full details, please see the "QsevenDevKit-HardwareUserGuide" which should have come with the platform on a CD.

You can also see the block diagram on the iWave website [3].

- reboot doesn't seem to work (it works on the factory kernel 3.10).

This is a known issue that we currently have a workaround for. For development we could add this to [4], but it's a bit ugly.

By the way, do you have some test script to check that every module is
working fine?

Not at the moment, we are currently working on adding support for the CIP test framework, but this won't be ready for a while yet I'm afraid.


[3] http://www.iwavesystems.com/downloads//products/cpu-modules/renesas/rz-g1m-q7-som/g20d-rz-g1m-som-block-diagram-R1.1.pdf
[4] https://github.com/renesas-rz/renesas-cip

Kind regards, Chris

Thanks,
Daniel

Hi Chris,

Dear CIP friends,

I should have sent this report last week but I was travelling.

For those of you who are not following our work closely at gitlab.com here is a summary of the main work that Don, Robert and myself have been doing.

* Supporting B@D 0.9.1 Release through cip-dev Mailing List & #cip channel.
** Updated CIP Diagram and tweaked documentation to enhance clarity and accuracy.
** Provided support to Daniel Wagner. Thanks you for your contributions.

* Emailing of test results to a mailing list. Created a manual method, now working on automated method.

* Generating a CIP initramfs for use in our VM and how to build one from scratch.

* Linaro changed the links to their build artifacts - Uploaded updated tests-0.1.tgz to download site that contain new links.

* Request process to get some additional repositories we will need for the Action 2.
** The new mailing list for sharing test results is already in place. As soon as we can share test results we will publish it.

The coming weeks we will keep working on setting up the test results reporting, testing B@D on Windows, setting up the new repositories and define how the reports should look like.

Best Regards

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

Hello Ben.

Thank you for the quick feedback.

Kind regards, Chris

Hi Chris,

I think I mentioned before some of the below arguments when this topic was risen months ago. It is a good time to publish them here.

On 20/06/17 17:18, Ben Hutchings wrote:

On Tue, 2017-06-20 at 09:12 +0000, Chris Paterson wrote:

Hello Ben,

Do you have a plan for when future releases of the CIP Kernel will be
made?

It would be good to have a fixed release cadence or roadmap, so people
using the Kernel can plan their activities accordingly.

I expect to release about every month, and whenever there's an urgent
security update (which there will be soon, for the "stack clash" issue).

I would like to keep flexibility here, that is, do not tight ourselves to releases yet for a variety of reasons. These are the main ones I can think of right now:

* We are in an LTS phase. Defining a cadence at this point might reinforce the idea that our kernel maintenance process is somehow different than LTS when, except for a few packages, it is not yet. That was intentional.

* I would like to be able to consistently test the kernel, even with a single test, before claiming to make releases, that is, before making a public commitment on any delivery process. The expectations can be higher that we can commit to.

* We do not know at this point what the maintenance cycle is going to be from the kernel community. I am not suggesting that we have to follow it, but before defining our cadence, I would have a clear idea about what upstream will do.

* A kernel release for SLTS has severe implications in other areas, like the testing tools, testing results, tests, etc. We need also to freeze/store/release them, together with the build instructions, metadata, artifacts, source code.... In other words, we need to define what "a release" means for CIP and how much effort requires.

* With the above and the fact that we are starting to put effort in -RT, I wonder if we will talk about releasing the CIP kernel or we will talk about releasing the CIP platform (assuming that at the beginning the kernel is the main bit).

Defining a release today might play against us in a year or two.

Once this said, if Members require at this point a cadence, we will provide one but I think that sticking to LTS cycle until Feb'18 and assuming that we will catch up every 4-8 weeks is the way to go. Once the 4.4 maintainer is published, let's talk to him/her and take decisions.

Is there a specific reason why you need a cadence now beyond what LTS provides? I am trying to understand the details in order to think about a solution for Renesas compatible with the above.

Best Regards

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

On Tue, 2017-06-20 at 09:12 +0000, Chris Paterson wrote:

Hello Ben,

Do you have a plan for when future releases of the CIP Kernel will be
made?

It would be good to have a fixed release cadence or roadmap, so people
using the Kernel can plan their activities accordingly.

I expect to release about every month, and whenever there's an urgent
security update (which there will be soon, for the "stack clash" issue).

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.

On Tue, 2017-06-20 at 14:53 +0000, Chris Paterson wrote:

Hello Ben,

I hope the move went okay.

Thanks. It didn't entirely, but the worst is over.

I plan to start backporting some patches to the CIP Kernel soon, to
begin adding support for the Renesas CIP reference platform.

I’ve had a look at [1] and have a few of queries…

1)

11. It or an equivalent fix must already exist in Linus' tree (upstream).

Is this rule set in stone? Or can patches that have been accepted into
the relevant maintainer’s branches be backported?

Positive: We don’t have to wait up to 10 weeks for the new merge window before backporting patches
Negative: There is a small chance that the patches will be rebased in the move from linux-next to linux

I think it would be fine to relax this for new hardware support. There
isn't the same risk of regression if the kernel didn't support the
hardware before.

2)
For submitting patches, I assume you would like them sent to cip-dev?

Yes. You can send a git pull request, but I would like to see the
patches on the list even then.

3)
For patches that add support for a new platform, would you like them
submitted in small series, as they were upstreamed? Or in one big pull
request once major support for the platform has been added upstream?

Shorter series are more easy for me to digest.

Ben.

[1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance

--
Ben Hutchings
Software Developer, Codethink Ltd.