Date   

[PATCH 3/6] sh-sci: document R8A7743/5 support

Biju Das <biju.das@...>
 

From: Sergei Shtylyov <sergei.shtylyov@...>

Renesas RZ/G SoC also have the SCIF, SCIFA, SCIFB, and HSCIF ports and
they seem compatible with the R-Car gen2 SoC in this respect...
Document RZ/G1[ME] (also known as R8A774[35]) SoC bindings.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@...>
Acked-by: Simon Horman <horms+renesas@...>
Acked-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>
(cherry picked from commit c03e1b8703a4a0c8bac7f6b65d8fcb539ec62d82)
Signed-off-by: Biju Das <biju.das@...>
---
Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
index 73f825e..cbcfdc0 100644
--- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
+++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
@@ -9,6 +9,14 @@ Required properties:
- "renesas,scifb-r8a73a4" for R8A73A4 (R-Mobile APE6) SCIFB compatible UART.
- "renesas,scifa-r8a7740" for R8A7740 (R-Mobile A1) SCIFA compatible UART.
- "renesas,scifb-r8a7740" for R8A7740 (R-Mobile A1) SCIFB compatible UART.
+ - "renesas,scif-r8a7743" for R8A7743 (RZ/G1M) SCIF compatible UART.
+ - "renesas,scifa-r8a7743" for R8A7743 (RZ/G1M) SCIFA compatible UART.
+ - "renesas,scifb-r8a7743" for R8A7743 (RZ/G1M) SCIFB compatible UART.
+ - "renesas,hscif-r8a7743" for R8A7743 (RZ/G1M) HSCIF compatible UART.
+ - "renesas,scif-r8a7745" for R8A7745 (RZ/G1E) SCIF compatible UART.
+ - "renesas,scifa-r8a7745" for R8A7745 (RZ/G1E) SCIFA compatible UART.
+ - "renesas,scifb-r8a7745" for R8A7745 (RZ/G1E) SCIFB compatible UART.
+ - "renesas,hscif-r8a7745" for R8A7745 (RZ/G1E) HSCIF compatible UART.
- "renesas,scif-r8a7778" for R8A7778 (R-Car M1) SCIF compatible UART.
- "renesas,scif-r8a7779" for R8A7779 (R-Car H1) SCIF compatible UART.
- "renesas,scif-r8a7790" for R8A7790 (R-Car H2) SCIF compatible UART.
--
1.9.1


[PATCH 2/6] DT: irqchip: renesas-irqc: document R8A7743/5 support

Biju Das <biju.das@...>
 

From: Sergei Shtylyov <sergei.shtylyov@...>

Renesas RZ/G SoC have the R-Car gen2 compatible IRQC interrupt controllers.
Document RZ/G1[ME] (also known as R8A774[35]) SoC bindings.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@...>
Acked-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Rob Herring <robh@...>
(cherry picked from commit 87e5fc99b0280b492724cc7f2d8d9ad37b980087)
Signed-off-by: Biju Das <biju.das@...>
---
.../devicetree/bindings/interrupt-controller/renesas,irqc.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt
index ae5054c..e3f052d 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt
@@ -1,10 +1,12 @@
-DT bindings for the R-Mobile/R-Car interrupt controller
+DT bindings for the R-Mobile/R-Car/RZ/G interrupt controller

Required properties:

- compatible: has to be "renesas,irqc-<soctype>", "renesas,irqc" as fallback.
Examples with soctypes are:
- "renesas,irqc-r8a73a4" (R-Mobile APE6)
+ - "renesas,irqc-r8a7743" (RZ/G1M)
+ - "renesas,irqc-r8a7745" (RZ/G1E)
- "renesas,irqc-r8a7790" (R-Car H2)
- "renesas,irqc-r8a7791" (R-Car M2-W)
- "renesas,irqc-r8a7792" (R-Car V2H)
--
1.9.1


[PATCH 1/6] sh_eth: add R8A7743/5 support

Biju Das <biju.das@...>
 

From: Sergei Shtylyov <sergei.shtylyov@...>

Add support for the first two members of the Renesas RZ/G family, RZ/G1M/E
(also known as R8A7743/5). The Ether core is the same as in the R-Car gen2
SoCs, so will share the code/data with them...

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@...>
Acked-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: David S. Miller <davem@...>
(cherry picked from commit c099ff3cdb9dd2281dee3dc4ef89fec1c516df22)
Signed-off-by: Biju Das <biju.das@...>
---
Documentation/devicetree/bindings/net/sh_eth.txt | 2 ++
drivers/net/ethernet/renesas/Kconfig | 2 +-
drivers/net/ethernet/renesas/sh_eth.c | 2 ++
3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/sh_eth.txt b/Documentation/devicetree/bindings/net/sh_eth.txt
index 2f6ec85..0115c85 100644
--- a/Documentation/devicetree/bindings/net/sh_eth.txt
+++ b/Documentation/devicetree/bindings/net/sh_eth.txt
@@ -5,6 +5,8 @@ interface contains.

Required properties:
- compatible: "renesas,gether-r8a7740" if the device is a part of R8A7740 SoC.
+ "renesas,ether-r8a7743" if the device is a part of R8A7743 SoC.
+ "renesas,ether-r8a7745" if the device is a part of R8A7745 SoC.
"renesas,ether-r8a7778" if the device is a part of R8A7778 SoC.
"renesas,ether-r8a7779" if the device is a part of R8A7779 SoC.
"renesas,ether-r8a7790" if the device is a part of R8A7790 SoC.
diff --git a/drivers/net/ethernet/renesas/Kconfig b/drivers/net/ethernet/renesas/Kconfig
index 270c4c9..0f86521 100644
--- a/drivers/net/ethernet/renesas/Kconfig
+++ b/drivers/net/ethernet/renesas/Kconfig
@@ -27,7 +27,7 @@ config SH_ETH
Renesas SuperH Ethernet device driver.
This driver supporting CPUs are:
- SH7619, SH7710, SH7712, SH7724, SH7734, SH7763, SH7757,
- R8A7740, R8A777x and R8A779x.
+ R8A7740, R8A774x, R8A777x and R8A779x.

config RAVB
tristate "Renesas Ethernet AVB support"
diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
index 480f3da..c04b4ea 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -3055,6 +3055,8 @@ static struct sh_eth_plat_data *sh_eth_parse_dt(struct device *dev)

static const struct of_device_id sh_eth_match_table[] = {
{ .compatible = "renesas,gether-r8a7740", .data = &r8a7740_data },
+ { .compatible = "renesas,ether-r8a7743", .data = &r8a779x_data },
+ { .compatible = "renesas,ether-r8a7745", .data = &r8a779x_data },
{ .compatible = "renesas,ether-r8a7778", .data = &r8a777x_data },
{ .compatible = "renesas,ether-r8a7779", .data = &r8a777x_data },
{ .compatible = "renesas,ether-r8a7790", .data = &r8a779x_data },
--
1.9.1


[PATCH 0/6] Basic SoC support for r8a7743/r8a7745

Biju Das <biju.das@...>
 

This series aims to add basic SoC support for
r8a7743/r8a7745. All the patches in this series
are cherry-picked from the upstream kernel.

This series has been tested against linux-cip tag v4.4.75-cip6.

Laurent Pinchart (1):
ARM: shmobile: Consolidate R8A7743 and R8A779[234] machine definitions

Sergei Shtylyov (5):
sh_eth: add R8A7743/5 support
DT: irqchip: renesas-irqc: document R8A7743/5 support
sh-sci: document R8A7743/5 support
ARM: shmobile: r8a7743: basic SoC support
ARM: shmobile: r8a7745: basic SoC support

Documentation/devicetree/bindings/arm/shmobile.txt | 4 +++
.../bindings/interrupt-controller/renesas,irqc.txt | 4 ++-
Documentation/devicetree/bindings/net/sh_eth.txt | 2 ++
.../bindings/serial/renesas,sci-serial.txt | 8 ++++++
arch/arm/mach-shmobile/Kconfig | 8 ++++++
arch/arm/mach-shmobile/Makefile | 2 --
arch/arm/mach-shmobile/setup-r8a7793.c | 33 ----------------------
arch/arm/mach-shmobile/setup-r8a7794.c | 33 ----------------------
arch/arm/mach-shmobile/setup-rcar-gen2.c | 33 ++++++++++++++++++++++
drivers/net/ethernet/renesas/Kconfig | 2 +-
drivers/net/ethernet/renesas/sh_eth.c | 2 ++
11 files changed, 61 insertions(+), 70 deletions(-)
delete mode 100644 arch/arm/mach-shmobile/setup-r8a7793.c
delete mode 100644 arch/arm/mach-shmobile/setup-r8a7794.c

--
1.9.1


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

Jan Kiszka
 

On 2017-07-11 09:00, Daniel Sangorrin wrote:
-----Original Message-----
From: Jan Kiszka [mailto:jan.kiszka@...]
Sent: Tuesday, July 11, 2017 3:42 PM
To: Daniel Sangorrin; cip-dev@...
Cc: 'kas-devel'
Subject: Re: [cip-dev] Project-X (minimal root filesystem) : rewrite and renesas iwg20m board support

On 2017-07-11 08:34, Daniel Sangorrin wrote:
Hi Jan,

-----Original Message-----
From: Jan Kiszka [mailto:jan.kiszka@...]
Sent: Tuesday, July 11, 2017 3:20 PM
To: Daniel Sangorrin; cip-dev@...
Cc: kas-devel
Subject: Re: [cip-dev] Project-X (minimal root filesystem) : rewrite and renesas iwg20m board support

On 2017-07-11 01:36, Daniel Sangorrin wrote:
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.
Yesterday I managed to build the qemux86-64 meta layer using the following
kas project configuration. Could you check it please?

https://gitlab.com/cip-playground/project-x/commit/de611ae06040f6e426d3c5d1b77eb20b4af31a19
Looks good. You should just set version to 0.10 and use yesterday's
release. You can pull the corresponding docker image from
https://hub.docker.com/r/kasproject/, and there should be a pip package
as well soon.
That was fast. I was using the next branch and built the Dockerfile included in kas.

I had to create a daemon.json to set overlay2 as the storage driver, pass the USER_ID variable,
We should probably suggest to call "USER_ID=$(id -u) docker run ..." -
it there a way to achieve this in an easier way? Still learning all this
docker stuff.
I was using the -e flag:
docker run -e USER_ID=`id -u $USER` -it kas sh
Err, right, that's what I meant.


volume mount the project-x folder and manually set the proxy settings (for some reason using
build-args didn't work for me).
Hmm, they should, I'm using them for builds all the time (along with
corresponding settings for the docker daemon).
Are you sure you didn't set them somewhere else in the docker configuration?
As far as I can see the Dockerfile is not using any ARG instruction at all.
Yes, I'm sure. I've just written the doc for a product SDK, and that
uses no further settings as well, see
https://github.com/siemens/meta-iot2000/blob/jan/staging/README.md#docker-build.

Jan

--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux


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

Daniel Sangorrin <daniel.sangorrin@...>
 

-----Original Message-----
From: Jan Kiszka [mailto:jan.kiszka@...]
Sent: Tuesday, July 11, 2017 3:42 PM
To: Daniel Sangorrin; cip-dev@...
Cc: 'kas-devel'
Subject: Re: [cip-dev] Project-X (minimal root filesystem) : rewrite and renesas iwg20m board support

On 2017-07-11 08:34, Daniel Sangorrin wrote:
Hi Jan,

-----Original Message-----
From: Jan Kiszka [mailto:jan.kiszka@...]
Sent: Tuesday, July 11, 2017 3:20 PM
To: Daniel Sangorrin; cip-dev@...
Cc: kas-devel
Subject: Re: [cip-dev] Project-X (minimal root filesystem) : rewrite and renesas iwg20m board support

On 2017-07-11 01:36, Daniel Sangorrin wrote:
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.
Yesterday I managed to build the qemux86-64 meta layer using the following
kas project configuration. Could you check it please?

https://gitlab.com/cip-playground/project-x/commit/de611ae06040f6e426d3c5d1b77eb20b4af31a19
Looks good. You should just set version to 0.10 and use yesterday's
release. You can pull the corresponding docker image from
https://hub.docker.com/r/kasproject/, and there should be a pip package
as well soon.
That was fast. I was using the next branch and built the Dockerfile included in kas.

I had to create a daemon.json to set overlay2 as the storage driver, pass the USER_ID variable,
We should probably suggest to call "USER_ID=$(id -u) docker run ..." -
it there a way to achieve this in an easier way? Still learning all this
docker stuff.
I was using the -e flag:
docker run -e USER_ID=`id -u $USER` -it kas sh

volume mount the project-x folder and manually set the proxy settings (for some reason using
build-args didn't work for me).
Hmm, they should, I'm using them for builds all the time (along with
corresponding settings for the docker daemon).
Are you sure you didn't set them somewhere else in the docker configuration?
As far as I can see the Dockerfile is not using any ARG instruction at all.

Does it still make a difference to set BB_NUMBER_THREADS and
PARALLEL_MAKE? I'm seeing full CPU usage without it as well. I'm always
looking for reasonable defaults we can set (?=) from kas automatically.
BB_DISKMON_DIRS should likely be included, I was adding it as well already.
You know better than me ;)
I just checked the latest ref manual and apparently OE automatically sets them up.
Ah, good to know. The parallel things, or even also DISKMON?
The parallel things. BB_DISKMON_DIRS seems to be disabled by default.

Thanks,
Daniel


Jan

--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux


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

Jan Kiszka
 

On 2017-07-11 08:34, Daniel Sangorrin wrote:
Hi Jan,

-----Original Message-----
From: Jan Kiszka [mailto:jan.kiszka@...]
Sent: Tuesday, July 11, 2017 3:20 PM
To: Daniel Sangorrin; cip-dev@...
Cc: kas-devel
Subject: Re: [cip-dev] Project-X (minimal root filesystem) : rewrite and renesas iwg20m board support

On 2017-07-11 01:36, Daniel Sangorrin wrote:
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.
Yesterday I managed to build the qemux86-64 meta layer using the following
kas project configuration. Could you check it please?

https://gitlab.com/cip-playground/project-x/commit/de611ae06040f6e426d3c5d1b77eb20b4af31a19
Looks good. You should just set version to 0.10 and use yesterday's
release. You can pull the corresponding docker image from
https://hub.docker.com/r/kasproject/, and there should be a pip package
as well soon.
That was fast. I was using the next branch and built the Dockerfile included in kas.

I had to create a daemon.json to set overlay2 as the storage driver, pass the USER_ID variable,
We should probably suggest to call "USER_ID=$(id -u) docker run ..." -
it there a way to achieve this in an easier way? Still learning all this
docker stuff.

volume mount the project-x folder and manually set the proxy settings (for some reason using
build-args didn't work for me).
Hmm, they should, I'm using them for builds all the time (along with
corresponding settings for the docker daemon).


Does it still make a difference to set BB_NUMBER_THREADS and
PARALLEL_MAKE? I'm seeing full CPU usage without it as well. I'm always
looking for reasonable defaults we can set (?=) from kas automatically.
BB_DISKMON_DIRS should likely be included, I was adding it as well already.
You know better than me ;)
I just checked the latest ref manual and apparently OE automatically sets them up.
Ah, good to know. The parallel things, or even also DISKMON?

Jan

--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux


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

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Jan,

-----Original Message-----
From: Jan Kiszka [mailto:jan.kiszka@...]
Sent: Tuesday, July 11, 2017 3:20 PM
To: Daniel Sangorrin; cip-dev@...
Cc: kas-devel
Subject: Re: [cip-dev] Project-X (minimal root filesystem) : rewrite and renesas iwg20m board support

On 2017-07-11 01:36, Daniel Sangorrin wrote:
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.
Yesterday I managed to build the qemux86-64 meta layer using the following
kas project configuration. Could you check it please?

https://gitlab.com/cip-playground/project-x/commit/de611ae06040f6e426d3c5d1b77eb20b4af31a19
Looks good. You should just set version to 0.10 and use yesterday's
release. You can pull the corresponding docker image from
https://hub.docker.com/r/kasproject/, and there should be a pip package
as well soon.
That was fast. I was using the next branch and built the Dockerfile included in kas.

I had to create a daemon.json to set overlay2 as the storage driver, pass the USER_ID variable,
volume mount the project-x folder and manually set the proxy settings (for some reason using
build-args didn't work for me).

Does it still make a difference to set BB_NUMBER_THREADS and
PARALLEL_MAKE? I'm seeing full CPU usage without it as well. I'm always
looking for reasonable defaults we can set (?=) from kas automatically.
BB_DISKMON_DIRS should likely be included, I was adding it as well already.
You know better than me ;)
I just checked the latest ref manual and apparently OE automatically sets them up.

Thanks,
Daniel


Jan

--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux


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

Jan Kiszka
 

On 2017-07-11 01:36, Daniel Sangorrin wrote:
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.
Yesterday I managed to build the qemux86-64 meta layer using the following
kas project configuration. Could you check it please?

https://gitlab.com/cip-playground/project-x/commit/de611ae06040f6e426d3c5d1b77eb20b4af31a19
Looks good. You should just set version to 0.10 and use yesterday's
release. You can pull the corresponding docker image from
https://hub.docker.com/r/kasproject/, and there should be a pip package
as well soon.

Does it still make a difference to set BB_NUMBER_THREADS and
PARALLEL_MAKE? I'm seeing full CPU usage without it as well. I'm always
looking for reasonable defaults we can set (?=) from kas automatically.
BB_DISKMON_DIRS should likely be included, I was adding it as well already.

Jan

--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux


About the U-Boot policy

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi all,

# Chris, I wanted to discuss about the U-Boot policy last night during the online meeting but somehow I missed the URL change.

We have had some discussions about U-boot for a while but I would like to achieve some consensus about what
we should do about it.

U-boot is a rather big project that resembles the Linux kernel in some aspects. For example, unlike generic software
(e.g. openssh) a big bunch of its code is hardware dependent. U-boot releases have a cadence of 2 months (for
example v2017.07 was released on Mon, 10 July 2017) but there is no LTS project as far as I know. The closest to an LTS
project that I know of is the U-Boot packages maintained by distros (e.g. Debian) , which seem (see changelog [1]) to
focus on bug fixing and backporting new hardware support.

I'm going to throw some mud at the wall and see what sticks after our discussion.

1. Should we focus on supporting our reference boards only?
Sangorrin: yes.

2. Should all reference boards use the same source code base line?
Sangorrin: yes, unless the porting effort for a board is too complicated in which case we are better off providing a separate repo.

3. In case the answer to question 2 is 'yes': what's the base line that we should use?
Sangorrin: the source code from a Debian u-boot package that better supports our current reference boards and CIP kernel.

4. Should we focus on backporting security/bug fixes, or new HW support?
Sangorrin: No. I think that we should only make sure that our reference boards are able to boot the CIP kernel during its lifetime.

5. Should we upstream our fixes?
Sangorrin: Yes. For future maintainability and as a quality assurance step. But while the patches are getting accepted we should also have our own repos on gitlab's playground.

6. What functionality in U-Boot is important for us?
Sangorrin: network support for tftpboot would be great to have. Specially for debugging and for the CI tests.

Please add your answers!

Thanks,
Daniel

[1] http://metadata.ftp-master.debian.org/changelogs/main/u/u-boot/u-boot_2014.10+dfsg1-5_changelog

-----Original Message-----
From: Chris Paterson [mailto:Chris.Paterson2@...]
Sent: Friday, July 07, 2017 6:00 PM
From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: 07 July 2017 09:51
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.

I'm not sure what maintenance is required for u-boot





Kind regards, Chris


Thanks,
Daniel


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

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Jan,

-----Original Message-----
From: Jan Kiszka [mailto:jan.kiszka@...]
Sent: Friday, July 07, 2017 7:40 PM
To: Daniel Sangorrin; cip-dev@...
Subject: Re: [cip-dev] Project-X (minimal root filesystem) : rewrite and renesas iwg20m board support

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.
Cool. By the way, I put all of the layers under /deby so that you could
create the isar version under the /isar folder.


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.
Yesterday I managed to build the qemux86-64 meta layer using the following
kas project configuration. Could you check it please?

https://gitlab.com/cip-playground/project-x/commit/de611ae06040f6e426d3c5d1b77eb20b4af31a19

Thanks,
Daniel



Jan

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


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

Chris Paterson
 

Hello Agustin,

From: cip-dev-bounces@... [mailto:cip-dev-
bounces@...] On Behalf Of 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


Re: Renesas dev CIP repository announcement

Chris Paterson
 

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


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

Yoshitake Kobayashi
 

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

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

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

Hi,

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

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

Daniel-san,

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

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

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

Two considerations:

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

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

Best regards,
Yoshi



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

Thanks,
Daniel





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

Thanks,
Daniel

Best regards,
Takuo Koguchi



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

Ho Koguchi-san

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

Hi Daniel-san,

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

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

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

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

Thanks,
Daniel



Takuo Koguchi


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

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

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

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

Thanks,
Daniel

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


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


Re: Renesas dev CIP repository announcement

Yoshitake Kobayashi
 

Hi Chris and all,

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

(cherry picked from commit UPSTREAM_COMMIT_ID)

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

Best regards,
Yoshi

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



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



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



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



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





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

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



Kind regards, Chris



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


Kernel maintenance and CIP testing report weeks 25 to 27

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

Hi,

Kernel maintenance

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

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

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

Testing

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

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

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

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

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

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


Other topics

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

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

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

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


Re: B@D on Windows 10

Robert Marshall <robert.marshall@...>
 

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

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

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

Briefly the current issues/state is as follows:

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

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

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

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

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

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

Robert


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

Jan Kiszka
 

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

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

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

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

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

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

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

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

Jan

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


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

Chris Paterson
 

Hello Agustin,

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

Hi Chris,

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

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

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

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

Kind regards, Chris


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


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

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

Hi Chris,

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

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

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

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

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

8261 - 8280 of 8627