Hello Agustin,

From: cip-dev-bounces@... [mailto:cip-dev-
bounces@...] On Behalf Of Chris Paterson
Sent: 07 July 2017 11:19

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.

As long as the binaries don't include Renesas' proprietary libraries for graphics or multimedia [1] we are happy for CIP to distribute them as per option 1) above.

For the Kernel, this can be based on renesas-cip [2]. For the RFS, as meta-renesas-cip-private [3] is not open I would recommend that the output from Project-X is used.


[1] http://elinux.org/RZ-G/Boards/Yocto_2.0#Preliminary_steps "2. Download the proprietary Multimedia and Graphics evaluation libraries for RZ/G from Renesas"
[2] https://github.com/renesas-rz/renesas-cip
[3] https://github.com/renesas-rz/meta-renesas-cip-private

Kind regards, Chris

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

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

Hello Yoshi-san,

From: cip-dev-bounces@... [mailto:cip-dev-
bounces@...] On Behalf Of KOBAYASHI Yoshitake
Sent: 07 July 2017 14:07

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.

Agreed. We intend to follow the proper process when backporting to the actual CIP Kernel.

The repository above is just a quick release to allow users to get the iWave RZ/G1M board up and running for now. Most of the patches haven't come from upstream as there is no upstream support for the iWave RZ/G1M board yet (in progress).

Kind regards, Chris

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

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

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

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

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

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

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

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

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

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