Date   

CIP testing-kernel maintenance weekly meeting: moved to Thu 15:30 UK time.

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

Hi,

in order to better accommodate the meeting to Ben Hutchings availability, so he can attend on regular basis, we have moved the Thursday meeting from the morning to 15:30 UK (summer) time.

Please remember you can attend through video chat: https://plus.google.com/hangouts/_/codethink.co.uk/team-event-cip?hceid=YWd1c3Rpbi5iZW5pdG9AY29kZXRoaW5rLmNvLnVr.m6jv292u7masvpa1lb221rom1g&authuser=0

We can always have a meeting in the morning if anybody from Asia is attending.

Best Regards

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


[PATCH 3/3] ARM: shmobile: document iW-RainboW-G20D-Qseven-RZG1M board

Chris Paterson
 

From: Biju Das <biju.das@...>

Document the iW-RainboW-G20D-Qseven-RZG1M device tree bindings,
listing it as a supported board.

Signed-off-by: Biju Das <biju.das@...>
Reviewed-by: Chris Paterson <chris.paterson2@...>
Reviewed-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit 9086120f8b883034940e5228c83824ed21999537)
Signed-off-by: Chris Paterson <chris.paterson2@...>
---
Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index 90b6bd8..7ec024c 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -49,6 +49,8 @@ Boards:
compatible = "renesas,gose", "renesas,r8a7793"
- Henninger
compatible = "renesas,henninger", "renesas,r8a7791"
+ - iWave Systems RZ/G1M Qseven Development Platform (iW-RainboW-G20D-Qseven)
+ compatible = "iwave,g20d", "iwave,g20m", "renesas,r8a7743"
- iWave Systems RZ/G1M Qseven System On Module (iW-RainboW-G20M-Qseven)
compatible = "iwave,g20m", "renesas,r8a7743"
- Koelsch (RTP0RC7791SEB00010S)
--
1.9.1


[PATCH 2/3] ARM: shmobile: document iW-RainboW-G20M-Qseven-RZG1M system on module

Chris Paterson
 

From: Biju Das <biju.das@...>

Document the iW-RainboW-G20M-Qseven-RZG1M device tree bindings,
listing it as a supported system on module.

Signed-off-by: Biju Das <biju.das@...>
Reviewed-by: Chris Paterson <chris.paterson2@...>
Reviewed-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit 427bc40375df765b6146ce917d5a3d3832482935)
Signed-off-by: Chris Paterson <chris.paterson2@...>
---
Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index b29d9c7..90b6bd8 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -49,6 +49,8 @@ Boards:
compatible = "renesas,gose", "renesas,r8a7793"
- Henninger
compatible = "renesas,henninger", "renesas,r8a7791"
+ - iWave Systems RZ/G1M Qseven System On Module (iW-RainboW-G20M-Qseven)
+ compatible = "iwave,g20m", "renesas,r8a7743"
- Koelsch (RTP0RC7791SEB00010S)
compatible = "renesas,koelsch", "renesas,r8a7791"
- Kyoto Microcomputer Co. KZM-A9-Dual
--
1.9.1


[PATCH 1/3] of: Add vendor prefix for iWave Systems Technologies Pvt. Ltd

Chris Paterson
 

From: Biju Das <biju.das@...>

This patch adds vendor prefix for iWave Systems Technologies Pvt. Ltd.
Website: http://www.iwavesystems.com/

Signed-off-by: Biju Das <biju.das@...>
Reviewed-by: Chris Paterson <chris.paterson2@...>
Acked-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Rob Herring <robh@...>
(cherry picked from commit 9b6782e7f0efc2bf483e000b95fc7c06322a0703)
Signed-off-by: Chris Paterson <chris.paterson2@...>

Conflicts:
Documentation/devicetree/bindings/vendor-prefixes.txt

Signed-off-by: Chris Paterson <chris.paterson2@...>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 55df1d4..6264752 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -119,6 +119,7 @@ intercontrol Inter Control Group
invensense InvenSense Inc.
isee ISEE 2007 S.L.
isil Intersil
+iwave iWave Systems Technologies Pvt. Ltd.
jedec JEDEC Solid State Technology Association
karo Ka-Ro electronics GmbH
keymile Keymile GmbH
--
1.9.1


[PATCH 0/3] Add iWave RZ/G1M documentation

Chris Paterson
 

This series adds iWave to the vendor list, and documents the iWave RZ/G1M
board.

Patches based on linux-4.4.y-cip 7bac4ad.

Biju Das (3):
of: Add vendor prefix for iWave Systems Technologies Pvt. Ltd
ARM: shmobile: document iW-RainboW-G20M-Qseven-RZG1M system on module
ARM: shmobile: document iW-RainboW-G20D-Qseven-RZG1M board

Documentation/devicetree/bindings/arm/shmobile.txt | 4 ++++
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
2 files changed, 5 insertions(+)

--
1.9.1


Re: Procedure to use B@D in Windows 10

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

Hi Robert,

On 19 July 2017 14:01:13 CEST, Robert Marshall <robert.marshall@...> wrote:
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.
Congratulations for this accomplishment.


The wiki has been updated to document these steps.
So the former 5 steps documentation now includes the specific steps to take if you are a Windows 10 user. There is no separate documentation since most of the instructions to execute are the same in both cases (Windows and Linux).


Robert
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


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

Ben Hutchings <ben.hutchings@...>
 

On Wed, 2017-07-19 at 13:59 +0000, Biju Das wrote:
[...]
Then I think I should just make this change:

Subject: CIP: Build essential clock driver for Renesas RZ/G1 platforms
[...]
Right?
Yes. That is correct.
I've applied this.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


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

Biju Das <biju.das@...>
 

-----Original Message-----
From: Ben Hutchings [mailto:ben.hutchings@...]
Sent: 19 July 2017 14:54
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 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?
Yes. That is correct.

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

8241 - 8260 of 8627