Date   

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

Ben Hutchings <ben.hutchings@...>
 

On Wed, 2017-07-19 at 08:24 +0000, Biju Das wrote:
[...]
Actually, there's something not quite right here. With just
CONFIG_ARCH_R8A7743 and CONFIG_ARCH_R8A7745 enabled (but no other R-
Car
platforms) I get:
The patches are for Basic SoC support. Next I am planning Clock driver, then DT support for SoC, then Board DTS
and then Enabling the config option(CONFIG_ARCH_R8A7743 and CONFIG_ARCH_R8A7745) .

arch/arm/mach-shmobile/built-in.o: In function `rcar_gen2_timer_init':
/home/bwh/ln001-cip/kernel/arch/arm/mach-shmobile/setup-rcar-gen2.c:131:
undefined reference to `rcar_gen2_clocks_init'

There seems to have been a lot of refactoring of drivers/clk/{shmobile,renesas}
since 4.4 so I'm not sure how this should be fixed.
Current upstreamed RZ/G1M clock driver uses the new Renesas CPG/MSSR clock driver frame work.
Backporting requires lot of refactoring of drivers/clk/{shmobile,renesas}.
So I don't think backporting the RZ/G1M clock driver is the right choice.
OK.

However r8a7743( RZ/G1M) is identical to r8a7791(RCar-M2) platform. We ported r8a7743( RZ/G1M) clk driver based on this.
The current patch series, which I submitted is tested with this clk driver.
Then I think I should just make this change:

Subject: CIP: Build essential clock driver for Renesas RZ/G1 platforms

In mainline, clk-rcar-gen2 is selected by CONFIG_CLK_RCAR_GEN2 but
here there is no such common config symbol and we need to select
it for each platform.

Signed-off-by: Ben Hutchings <ben.hutchings@...>
---
drivers/clk/shmobile/Makefile | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/clk/shmobile/Makefile b/drivers/clk/shmobile/Makefile
index 97c71c885e4f..b339c0b6bb2f 100644
--- a/drivers/clk/shmobile/Makefile
+++ b/drivers/clk/shmobile/Makefile
@@ -2,6 +2,8 @@ obj-$(CONFIG_ARCH_EMEV2) += clk-emev2.o
obj-$(CONFIG_ARCH_R7S72100) += clk-rz.o
obj-$(CONFIG_ARCH_R8A73A4) += clk-r8a73a4.o
obj-$(CONFIG_ARCH_R8A7740) += clk-r8a7740.o
+obj-$(CONFIG_ARCH_R8A7743) += clk-rcar-gen2.o
+obj-$(CONFIG_ARCH_R8A7745) += clk-rcar-gen2.o
obj-$(CONFIG_ARCH_R8A7778) += clk-r8a7778.o
obj-$(CONFIG_ARCH_R8A7779) += clk-r8a7779.o
obj-$(CONFIG_ARCH_R8A7790) += clk-rcar-gen2.o
--- END ---

Right?

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Procedure to use B@D in Windows 10

Robert Marshall <robert.marshall@...>
 

The 0.9.1 release box of B@D has been successfully imported into Windows
10 and both a QEMU and BBB health check have been run on that virtual machine.
This setup also works when provisioning a box from a clone of the git repository.

The steps to get B@D running on Windows 10 are as follows:

- Install the guest additions `vagrant plugin install vagrant-vbguest`
- Install rsync/ssh/git in cygwin.
- core.autocrlf=input is needed in the git settings for the scripts to
run under the Debian of the virtual machine.
- Once the vm is up then in virtualbox add a USB filter for the FTDI device.
- For kernelci access you need to use either Firefox or Chrome - the Microsoft
browsers will not work.
- You may need the vagrant scp command (if you wish to copy other files
onto the VM) if so -
vagrant plugin install vagrant-scp
- setup mybbb.dat to use the IP address of the VM rather than that of
the host.

The wiki has been updated to document these steps.

Robert


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

Biju Das <biju.das@...>
 

-----Original Message-----
From: Ben Hutchings [mailto:ben.hutchings@...]
Sent: 18 July 2017 16:58
To: Biju Das <biju.das@...>
Cc: Chris Paterson <Chris.Paterson2@...>; cip-dev@...
project.org
Subject: Re: [PATCH 0/6] Basic SoC support for r8a7743/r8a7745

On Tue, 2017-07-18 at 16:30 +0100, Ben Hutchings wrote:
On Wed, 2017-07-12 at 10:21 +0100, Biju Das wrote:
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.
These all look good to me, so I've applied these to the
linux-4.4.y-cip branch. Are you going to add more driver support
(e.g. ravb, xhci-rcar) and device tree sources?
Actually, there's something not quite right here. With just
CONFIG_ARCH_R8A7743 and CONFIG_ARCH_R8A7745 enabled (but no other R-
Car
platforms) I get:
The patches are for Basic SoC support. Next I am planning Clock driver, then DT support for SoC, then Board DTS
and then Enabling the config option(CONFIG_ARCH_R8A7743 and CONFIG_ARCH_R8A7745) .

arch/arm/mach-shmobile/built-in.o: In function `rcar_gen2_timer_init':
/home/bwh/ln001-cip/kernel/arch/arm/mach-shmobile/setup-rcar-gen2.c:131:
undefined reference to `rcar_gen2_clocks_init'

There seems to have been a lot of refactoring of drivers/clk/{shmobile,renesas}
since 4.4 so I'm not sure how this should be fixed.
Current upstreamed RZ/G1M clock driver uses the new Renesas CPG/MSSR clock driver frame work.
Backporting requires lot of refactoring of drivers/clk/{shmobile,renesas}.
So I don't think backporting the RZ/G1M clock driver is the right choice.

However r8a7743( RZ/G1M) is identical to r8a7791(RCar-M2) platform. We ported r8a7743( RZ/G1M) clk driver based on this.
The current patch series, which I submitted is tested with this clk driver.


Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.


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

Ben Hutchings <ben.hutchings@...>
 

On Tue, 2017-07-18 at 16:30 +0100, Ben Hutchings wrote:
On Wed, 2017-07-12 at 10:21 +0100, Biju Das wrote:
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.
These all look good to me, so I've applied these to the linux-4.4.y-cip
branch. Are you going to add more driver support (e.g. ravb, xhci-rcar)
and device tree sources?
Actually, there's something not quite right here. With just
CONFIG_ARCH_R8A7743 and CONFIG_ARCH_R8A7745 enabled (but no other R-Car
platforms) I get:

arch/arm/mach-shmobile/built-in.o: In function `rcar_gen2_timer_init':
/home/bwh/ln001-cip/kernel/arch/arm/mach-shmobile/setup-rcar-gen2.c:131: undefined reference to `rcar_gen2_clocks_init'

There seems to have been a lot of refactoring of
drivers/clk/{shmobile,renesas} since 4.4 so I'm not sure how this should
be fixed.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


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

Ben Hutchings <ben.hutchings@...>
 

On Wed, 2017-07-12 at 10:21 +0100, Biju Das wrote:
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.
These all look good to me, so I've applied these to the linux-4.4.y-cip
branch. Are you going to add more driver support (e.g. ravb, xhci-rcar)
and device tree sources?

Ben.

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
--
Ben Hutchings
Software Developer, Codethink Ltd.


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: Thursday, July 13, 2017 3:37 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-13 02:12, Daniel Sangorrin wrote:
Hi Jan,

-----Original Message-----
From: Jan Kiszka [mailto:jan.kiszka@...]
Sent: Wednesday, July 12, 2017 6:13 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 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.
hmmm, I think that you made a small mistake in the kas documentation [1]. You wrote that
http_proxy should be passed as a build-arg but as I said there is no ARG instruction in the
Dockerfile.
No, also that works: It won't leave the proxy settings behind in the
image, but it allows to build it behind a proxy.

We don't want to generate "proxified" images that will then only work in
a very specific environment. We are coming from there, it was a mess.
The image we have now can be fed into a CI build, and you only need to
configure the specific proxies at project level. Works nicely with our
corporate gitlab infrastructure.
OK, I understand your approach.

By the way ARG does not leave any settings behind (ENV does).
I was just confused because I thought that all available build-args had
to be declared on the Dockerfile through the ARG instruction.

In the past, not doing so would throw an error. From the current docker
documentation [1], it seems that that has changed and now it should
only throw a warning:
"If a user specifies a build argument that was not defined in the Dockerfile,
the build outputs a warning. [Warning] One or more build-args [foo] were not consumed."

Strange enough, I didn't see any warnings either. I wonder if the documentation
is outdated.

In any case, the kas documentation does not mention anything about setting the
variables on "docker run" so it might be a good idea to provide the information
form the meta-iot2000's README

If you are building from within a proxy-restricted network, make sure the settings are available via the standard environment variables and add

-e http_proxy=$http_proxy -e https_proxy=$https_proxy \
-e ftp_proxy=$ftp_proxy -e no_proxy=$no_proxy

Thanks,
Daniel

[1] https://docs.docker.com/engine/reference/builder/#arg




Sorry I didn't know that you could use --build-arg
without defining an ARG instruction in the Dockerfile. It's not very clearly documented
on the docker website.

On the user's guide you mention "docker run -it kasproject/kas:<version> sh"

or bind-mount the project into the container. See https://hub.docker.com/r/kasproject for all available images."
Still it might be helpful

-e http_proxy=$http_proxy -e https_proxy=$https_proxy \
-e ftp_proxy=$ftp_proxy -e no_proxy=$no_proxy





Jan


In the meta-iot2000 link you are setting the proxy variables as environment variables using
'docker run -e http_proxy=$http_proxy' which does work indeed.>
[1] https://kas.readthedocs.io/en/latest/devguide.html

Thanks,
Daniel



--
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-13 02:12, Daniel Sangorrin wrote:
Hi Jan,

-----Original Message-----
From: Jan Kiszka [mailto:jan.kiszka@...]
Sent: Wednesday, July 12, 2017 6:13 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 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.
hmmm, I think that you made a small mistake in the kas documentation [1]. You wrote that
http_proxy should be passed as a build-arg but as I said there is no ARG instruction in the
Dockerfile.
No, also that works: It won't leave the proxy settings behind in the
image, but it allows to build it behind a proxy.

We don't want to generate "proxified" images that will then only work in
a very specific environment. We are coming from there, it was a mess.
The image we have now can be fed into a CI build, and you only need to
configure the specific proxies at project level. Works nicely with our
corporate gitlab infrastructure.

Jan


In the meta-iot2000 link you are setting the proxy variables as environment variables using
'docker run -e http_proxy=$http_proxy' which does work indeed.>
[1] https://kas.readthedocs.io/en/latest/devguide.html

Thanks,
Daniel



--
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: Wednesday, July 12, 2017 6:13 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 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.
hmmm, I think that you made a small mistake in the kas documentation [1]. You wrote that
http_proxy should be passed as a build-arg but as I said there is no ARG instruction in the
Dockerfile.

In the meta-iot2000 link you are setting the proxy variables as environment variables using
'docker run -e http_proxy=$http_proxy' which does work indeed.

[1] https://kas.readthedocs.io/en/latest/devguide.html

Thanks,
Daniel


Re: About the U-Boot policy

Chris Paterson
 

Hello Daniel,

From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: 11 July 2017 02:04

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.
Sorry we missed you!


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.
Thank you for resuming the conversation.


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



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.
Chris: Ideally yes, but currently I don't think all of the reference boards are in mainline u-boot, and I'm not sure CIP should be doing/funding the upstreaming of the reference boards. This should ideally be done by the board vendors.
One option could be to create a cip-u-boot repo and manually add support for the different boards, but obviously this work would need to be repeated if we were ever to upgrade the base u-boot version for future CIP releases.



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.
Chris: Given the resources and aims of the project, I think you are right. We should just make sure that the platform boots. Many production devices probably won't use u-boot in the field anyway, at least not our version.



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.
Chris: Yes, this will help us in the future if we are to upgrade versions.



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.
Chris: In addition, being able to boot from mmc/usb will help with demo work.

Kind regards, Chris



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


[PATCH 6/6] ARM: shmobile: r8a7745: basic SoC support

Biju Das <biju.das@...>
 

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

Add minimal support for the RZ/G1E (R8A7745) SoC.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@...>
Reviewed-by: Geert Uytterhoeven <geert+renesas@...>
Acked-by: Rob Herring <robh@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit 47802fd7c7c4735ddaf004e0f61371dcaa86f4ad)
Signed-off-by: Biju Das <biju.das@...>
---
Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
arch/arm/mach-shmobile/Kconfig | 4 ++++
arch/arm/mach-shmobile/setup-rcar-gen2.c | 1 +
3 files changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index 07b5818..b29d9c7 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -15,6 +15,8 @@ SoCs:
compatible = "renesas,r8a7740"
- RZ/G1M (R8A77430)
compatible = "renesas,r8a7743"
+ - RZ/G1E (R8A77450)
+ compatible = "renesas,r8a7745"
- R-Car M1A (R8A77781)
compatible = "renesas,r8a7778"
- R-Car H1 (R8A77790)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 09929a3..602fc2d 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -68,6 +68,10 @@ config ARCH_R8A7743
bool "RZ/G1M (R8A77430)"
select ARCH_RCAR_GEN2

+config ARCH_R8A7745
+ bool "RZ/G1E (R8A77450)"
+ select ARCH_RCAR_GEN2
+
config ARCH_R8A7778
bool "R-Car M1A (R8A77781)"
select ARCH_RCAR_GEN1
diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c b/arch/arm/mach-shmobile/setup-rcar-gen2.c
index 3b5f6ac..3911716 100644
--- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
@@ -221,6 +221,7 @@ MACHINE_END

static const char * const rz_g1_boards_compat_dt[] __initconst = {
"renesas,r8a7743",
+ "renesas,r8a7745",
NULL,
};

--
1.9.1


[PATCH 5/6] ARM: shmobile: Consolidate R8A7743 and R8A779[234] machine definitions

Biju Das <biju.das@...>
 

From: Laurent Pinchart <laurent.pinchart+renesas@...>

The four SoCs use identical machine operations, consolidate them into
two machine definitions in a single file.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@...>
Tested-by: Simon Horman <horms+renesas@...>
Reviewed-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit a0c4e2ccb31540f8972d8f36d32ace6b30e88e0f)
Signed-off-by: Biju Das <biju.das@...>

Conflicts:
arch/arm/mach-shmobile/Makefile
[modified]:arch/arm/mach-shmobile/setup-rcar-gen2.c
---
arch/arm/mach-shmobile/Makefile | 3 ---
arch/arm/mach-shmobile/setup-r8a7743.c | 34 --------------------------------
arch/arm/mach-shmobile/setup-r8a7793.c | 33 -------------------------------
arch/arm/mach-shmobile/setup-r8a7794.c | 33 -------------------------------
arch/arm/mach-shmobile/setup-rcar-gen2.c | 32 ++++++++++++++++++++++++++++++
5 files changed, 32 insertions(+), 103 deletions(-)
delete mode 100644 arch/arm/mach-shmobile/setup-r8a7743.c
delete mode 100644 arch/arm/mach-shmobile/setup-r8a7793.c
delete mode 100644 arch/arm/mach-shmobile/setup-r8a7794.c

diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 2db5912..4620202 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -9,13 +9,10 @@ obj-y := timer.o
obj-$(CONFIG_ARCH_SH73A0) += setup-sh73a0.o
obj-$(CONFIG_ARCH_R8A73A4) += setup-r8a73a4.o
obj-$(CONFIG_ARCH_R8A7740) += setup-r8a7740.o
-obj-$(CONFIG_ARCH_R8A7743) += setup-r8a7743.o
obj-$(CONFIG_ARCH_R8A7778) += setup-r8a7778.o
obj-$(CONFIG_ARCH_R8A7779) += setup-r8a7779.o pm-r8a7779.o
obj-$(CONFIG_ARCH_R8A7790) += setup-r8a7790.o
obj-$(CONFIG_ARCH_R8A7791) += setup-r8a7791.o
-obj-$(CONFIG_ARCH_R8A7793) += setup-r8a7793.o
-obj-$(CONFIG_ARCH_R8A7794) += setup-r8a7794.o
obj-$(CONFIG_ARCH_EMEV2) += setup-emev2.o
obj-$(CONFIG_ARCH_R7S72100) += setup-r7s72100.o

diff --git a/arch/arm/mach-shmobile/setup-r8a7743.c b/arch/arm/mach-shmobile/setup-r8a7743.c
deleted file mode 100644
index a7ecb82..0000000
--- a/arch/arm/mach-shmobile/setup-r8a7743.c
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * r8a7743 processor support
- *
- * Copyright (C) 2016 Cogent Embedded, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation; of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#include <linux/init.h>
-
-#include <asm/mach/arch.h>
-
-#include "common.h"
-#include "rcar-gen2.h"
-
-static const char * const r8a7743_boards_compat_dt[] __initconst = {
- "renesas,r8a7743",
- NULL,
-};
-
-DT_MACHINE_START(R8A7743_DT, "Generic R8A7743 (Flattened Device Tree)")
- .init_early = shmobile_init_delay,
- .init_time = rcar_gen2_timer_init,
- .init_late = shmobile_init_late,
- .reserve = rcar_gen2_reserve,
- .dt_compat = r8a7743_boards_compat_dt,
-MACHINE_END
diff --git a/arch/arm/mach-shmobile/setup-r8a7793.c b/arch/arm/mach-shmobile/setup-r8a7793.c
deleted file mode 100644
index 5fce87f..0000000
--- a/arch/arm/mach-shmobile/setup-r8a7793.c
+++ /dev/null
@@ -1,33 +0,0 @@
-/*
- * r8a7793 processor support
- *
- * Copyright (C) 2015 Ulrich Hecht
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#include <linux/init.h>
-#include <asm/mach/arch.h>
-
-#include "common.h"
-#include "rcar-gen2.h"
-
-static const char * const r8a7793_boards_compat_dt[] __initconst = {
- "renesas,r8a7793",
- NULL,
-};
-
-DT_MACHINE_START(R8A7793_DT, "Generic R8A7793 (Flattened Device Tree)")
- .init_early = shmobile_init_delay,
- .init_time = rcar_gen2_timer_init,
- .init_late = shmobile_init_late,
- .reserve = rcar_gen2_reserve,
- .dt_compat = r8a7793_boards_compat_dt,
-MACHINE_END
diff --git a/arch/arm/mach-shmobile/setup-r8a7794.c b/arch/arm/mach-shmobile/setup-r8a7794.c
deleted file mode 100644
index d2b0930..0000000
--- a/arch/arm/mach-shmobile/setup-r8a7794.c
+++ /dev/null
@@ -1,33 +0,0 @@
-/*
- * r8a7794 processor support
- *
- * Copyright (C) 2014 Renesas Electronics Corporation
- * Copyright (C) 2014 Ulrich Hecht
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#include <linux/of_platform.h>
-#include "common.h"
-#include "rcar-gen2.h"
-#include <asm/mach/arch.h>
-
-static const char * const r8a7794_boards_compat_dt[] __initconst = {
- "renesas,r8a7794",
- NULL,
-};
-
-DT_MACHINE_START(R8A7794_DT, "Generic R8A7794 (Flattened Device Tree)")
- .init_early = shmobile_init_delay,
- .init_late = shmobile_init_late,
- .init_time = rcar_gen2_timer_init,
- .reserve = rcar_gen2_reserve,
- .dt_compat = r8a7794_boards_compat_dt,
-MACHINE_END
diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c b/arch/arm/mach-shmobile/setup-rcar-gen2.c
index 9eccde3..3b5f6ac 100644
--- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
@@ -24,6 +24,7 @@
#include <linux/memblock.h>
#include <linux/of.h>
#include <linux/of_fdt.h>
+#include <linux/of_platform.h>
#include <asm/mach/arch.h>
#include "common.h"
#include "rcar-gen2.h"
@@ -199,3 +200,34 @@ void __init rcar_gen2_reserve(void)
&rcar_gen2_dma_contiguous, true);
#endif
}
+
+static const char * const rcar_gen2_boards_compat_dt[] __initconst = {
+ /*
+ * R8A7790 and R8A7791 can't be handled here as long as they need SMP
+ * initialization fallback.
+ */
+ "renesas,r8a7793",
+ "renesas,r8a7794",
+ NULL,
+};
+
+DT_MACHINE_START(RCAR_GEN2_DT, "Generic R-Car Gen2 (Flattened Device Tree)")
+ .init_early = shmobile_init_delay,
+ .init_late = shmobile_init_late,
+ .init_time = rcar_gen2_timer_init,
+ .reserve = rcar_gen2_reserve,
+ .dt_compat = rcar_gen2_boards_compat_dt,
+MACHINE_END
+
+static const char * const rz_g1_boards_compat_dt[] __initconst = {
+ "renesas,r8a7743",
+ NULL,
+};
+
+DT_MACHINE_START(RZ_G1_DT, "Generic RZ/G1 (Flattened Device Tree)")
+ .init_early = shmobile_init_delay,
+ .init_late = shmobile_init_late,
+ .init_time = rcar_gen2_timer_init,
+ .reserve = rcar_gen2_reserve,
+ .dt_compat = rz_g1_boards_compat_dt,
+MACHINE_END
--
1.9.1


[PATCH 4/6] ARM: shmobile: r8a7743: basic SoC support

Biju Das <biju.das@...>
 

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

Add minimal support for the RZ/G1M (R8A7743) SoC.

Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@...>.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@...>
Reviewed-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit e920565a1cc4a352719b42ba5e83d952a9a26507)
Signed-off-by: Biju Das <biju.das@...>
---
Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
arch/arm/mach-shmobile/Kconfig | 4 +++
arch/arm/mach-shmobile/Makefile | 1 +
arch/arm/mach-shmobile/setup-r8a7743.c | 34 ++++++++++++++++++++++
4 files changed, 41 insertions(+)
create mode 100644 arch/arm/mach-shmobile/setup-r8a7743.c

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index 40bb9007..07b5818 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -13,6 +13,8 @@ SoCs:
compatible = "renesas,r8a73a4"
- R-Mobile A1 (R8A77400)
compatible = "renesas,r8a7740"
+ - RZ/G1M (R8A77430)
+ compatible = "renesas,r8a7743"
- R-Car M1A (R8A77781)
compatible = "renesas,r8a7778"
- R-Car H1 (R8A77790)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 88734a5..09929a3 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -64,6 +64,10 @@ config ARCH_R8A7740
select ARCH_RMOBILE
select RENESAS_INTC_IRQPIN

+config ARCH_R8A7743
+ bool "RZ/G1M (R8A77430)"
+ select ARCH_RCAR_GEN2
+
config ARCH_R8A7778
bool "R-Car M1A (R8A77781)"
select ARCH_RCAR_GEN1
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index a65c80ac..2db5912 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -9,6 +9,7 @@ obj-y := timer.o
obj-$(CONFIG_ARCH_SH73A0) += setup-sh73a0.o
obj-$(CONFIG_ARCH_R8A73A4) += setup-r8a73a4.o
obj-$(CONFIG_ARCH_R8A7740) += setup-r8a7740.o
+obj-$(CONFIG_ARCH_R8A7743) += setup-r8a7743.o
obj-$(CONFIG_ARCH_R8A7778) += setup-r8a7778.o
obj-$(CONFIG_ARCH_R8A7779) += setup-r8a7779.o pm-r8a7779.o
obj-$(CONFIG_ARCH_R8A7790) += setup-r8a7790.o
diff --git a/arch/arm/mach-shmobile/setup-r8a7743.c b/arch/arm/mach-shmobile/setup-r8a7743.c
new file mode 100644
index 0000000..a7ecb82
--- /dev/null
+++ b/arch/arm/mach-shmobile/setup-r8a7743.c
@@ -0,0 +1,34 @@
+/*
+ * r8a7743 processor support
+ *
+ * Copyright (C) 2016 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation; of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/init.h>
+
+#include <asm/mach/arch.h>
+
+#include "common.h"
+#include "rcar-gen2.h"
+
+static const char * const r8a7743_boards_compat_dt[] __initconst = {
+ "renesas,r8a7743",
+ NULL,
+};
+
+DT_MACHINE_START(R8A7743_DT, "Generic R8A7743 (Flattened Device Tree)")
+ .init_early = shmobile_init_delay,
+ .init_time = rcar_gen2_timer_init,
+ .init_late = shmobile_init_late,
+ .reserve = rcar_gen2_reserve,
+ .dt_compat = r8a7743_boards_compat_dt,
+MACHINE_END
--
1.9.1


[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

8321 - 8340 of 8699