Date   

[PATCH 4.4.y-cip 06/10] ARM: dts: r8a7744-iwg20m: Add SPI NOR support

Lad Prabhakar
 

From: Biju Das <biju.das@bp.renesas.com>

commit e259e04748e2798a747d9c363ded50514b15a7b9 upstream.

Add support for the SPI NOR device used to boot up the system
to the iWave RZ/G1N Qseven System On Module DT.

Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
arch/arm/boot/dts/r8a7744-iwg20m.dtsi | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7744-iwg20m.dtsi b/arch/arm/boot/dts/r8a7744-iwg20m.dtsi
index 503583e..82ee3c1 100644
--- a/arch/arm/boot/dts/r8a7744-iwg20m.dtsi
+++ b/arch/arm/boot/dts/r8a7744-iwg20m.dtsi
@@ -36,6 +36,11 @@
function = "mmc";
};

+ qspi_pins: qspi {
+ groups = "qspi_ctrl", "qspi_data2";
+ function = "qspi";
+ };
+
sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
@@ -53,6 +58,27 @@
status = "okay";
};

+&qspi {
+ pinctrl-0 = <&qspi_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ /* WARNING - This device contains the bootloader. Handle with care. */
+ flash: flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+ spi-tx-bus-width = <2>;
+ spi-rx-bus-width = <2>;
+ m25p,fast-read;
+ spi-cpol;
+ spi-cpha;
+ };
+};
+
&sdhi0 {
pinctrl-0 = <&sdhi0_pins>;
pinctrl-names = "default";
--
2.7.4


[PATCH 4.4.y-cip 05/10] ARM: dts: r8a7744: Add MSIOF[012] support

Lad Prabhakar
 

From: Biju Das <biju.das@bp.renesas.com>

commit 491e70588805a8895bff6ac5a626c8bb481fea1c upstream.

Add the DT nodes needed by MSIOF[012] interfaces to the SoC dtsi.

Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
(changed clocks and power-domains properties, removed resets property)
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
arch/arm/boot/dts/r8a7744.dtsi | 45 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7744.dtsi b/arch/arm/boot/dts/r8a7744.dtsi
index b6517c3..12d698c 100644
--- a/arch/arm/boot/dts/r8a7744.dtsi
+++ b/arch/arm/boot/dts/r8a7744.dtsi
@@ -934,6 +934,51 @@
status = "disabled";
};

+ msiof0: spi@e6e20000 {
+ compatible = "renesas,msiof-r8a7744",
+ "renesas,rcar-gen2-msiof";
+ reg = <0 0xe6e20000 0 0x0064>;
+ interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp0_clks R8A7744_CLK_MSIOF0>;
+ dmas = <&dmac0 0x51>, <&dmac0 0x52>,
+ <&dmac1 0x51>, <&dmac1 0x52>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&cpg_clocks>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ msiof1: spi@e6e10000 {
+ compatible = "renesas,msiof-r8a7744",
+ "renesas,rcar-gen2-msiof";
+ reg = <0 0xe6e10000 0 0x0064>;
+ interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp2_clks R8A7744_CLK_MSIOF1>;
+ dmas = <&dmac0 0x55>, <&dmac0 0x56>,
+ <&dmac1 0x55>, <&dmac1 0x56>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&cpg_clocks>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ msiof2: spi@e6e00000 {
+ compatible = "renesas,msiof-r8a7744",
+ "renesas,rcar-gen2-msiof";
+ reg = <0 0xe6e00000 0 0x0064>;
+ interrupts = <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp2_clks R8A7744_CLK_MSIOF2>;
+ dmas = <&dmac0 0x41>, <&dmac0 0x42>,
+ <&dmac1 0x41>, <&dmac1 0x42>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&cpg_clocks>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
can0: can@e6e80000 {
compatible = "renesas,can-r8a7744",
"renesas,rcar-gen2-can";
--
2.7.4


[PATCH 4.4.y-cip 04/10] ARM: dts: r8a7744: Add QSPI support

Lad Prabhakar
 

From: Biju Das <biju.das@bp.renesas.com>

commit 0faadd5a410533d3a75601b607ee5a4110b754f4 upstream.

Add the DT node for the QSPI interface to the SoC dtsi.

Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
(changed clocks and power-domains property, removed resets property)
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
arch/arm/boot/dts/r8a7744.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7744.dtsi b/arch/arm/boot/dts/r8a7744.dtsi
index 425915a..b6517c3 100644
--- a/arch/arm/boot/dts/r8a7744.dtsi
+++ b/arch/arm/boot/dts/r8a7744.dtsi
@@ -595,6 +595,21 @@
status = "disabled";
};

+ qspi: spi@e6b10000 {
+ compatible = "renesas,qspi-r8a7744", "renesas,qspi";
+ reg = <0 0xe6b10000 0 0x2c>;
+ interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp9_clks R8A7744_CLK_QSPI_MOD>;
+ dmas = <&dmac0 0x17>, <&dmac0 0x18>,
+ <&dmac1 0x17>, <&dmac1 0x18>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&cpg_clocks>;
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
scifa0: serial@e6c40000 {
compatible = "renesas,scifa-r8a7744",
"renesas,rcar-gen2-scifa", "renesas,scifa";
--
2.7.4


[PATCH 4.4.y-cip 03/10] ARM: dts: r8a7744: Add TPU support

Lad Prabhakar
 

From: Biju Das <biju.das@bp.renesas.com>

commit eb83d144978e9f21aaa1372d75b50f3eec22ed48 upstream.

Add TPU support to SoC DT.

Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
(updated clock and power-domains property. removed resets property)
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
arch/arm/boot/dts/r8a7744.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7744.dtsi b/arch/arm/boot/dts/r8a7744.dtsi
index 79c71ef..425915a 100644
--- a/arch/arm/boot/dts/r8a7744.dtsi
+++ b/arch/arm/boot/dts/r8a7744.dtsi
@@ -260,6 +260,15 @@
reg = <0 0xe6060000 0 0x250>;
};

+ tpu: pwm@e60f0000 {
+ compatible = "renesas,tpu-r8a7744", "renesas,tpu";
+ reg = <0 0xe60f0000 0 0x148>;
+ clocks = <&mstp3_clks R8A7744_CLK_TPU0>;
+ power-domains = <&cpg_clocks>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
apmu@e6152000 {
compatible = "renesas,r8a7744-apmu", "renesas,apmu";
reg = <0 0xe6152000 0 0x188>;
--
2.7.4


[PATCH 4.4.y-cip 02/10] ARM: dts: r8a7744: Add PWM SoC support

Lad Prabhakar
 

From: Biju Das <biju.das@bp.renesas.com>

commit cebc31e8b59445aaf84b8810ff76b2fcc246fea2 upstream.

Add the definitions for pwm[0123456] to the SoC dtsi.

Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
(updated clocks and power-domains property.removed resets property)
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
arch/arm/boot/dts/r8a7744.dtsi | 63 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7744.dtsi b/arch/arm/boot/dts/r8a7744.dtsi
index cf7d8fe..79c71ef 100644
--- a/arch/arm/boot/dts/r8a7744.dtsi
+++ b/arch/arm/boot/dts/r8a7744.dtsi
@@ -847,6 +847,69 @@
status = "disabled";
};

+ pwm0: pwm@e6e30000 {
+ compatible = "renesas,pwm-r8a7744", "renesas,pwm-rcar";
+ reg = <0 0xe6e30000 0 0x8>;
+ clocks = <&mstp5_clks R8A7744_CLK_PWM>;
+ power-domains = <&cpg_clocks>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm1: pwm@e6e31000 {
+ compatible = "renesas,pwm-r8a7744", "renesas,pwm-rcar";
+ reg = <0 0xe6e31000 0 0x8>;
+ clocks = <&mstp5_clks R8A7744_CLK_PWM>;
+ power-domains = <&cpg_clocks>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm2: pwm@e6e32000 {
+ compatible = "renesas,pwm-r8a7744", "renesas,pwm-rcar";
+ reg = <0 0xe6e32000 0 0x8>;
+ clocks = <&mstp5_clks R8A7744_CLK_PWM>;
+ power-domains = <&cpg_clocks>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm3: pwm@e6e33000 {
+ compatible = "renesas,pwm-r8a7744", "renesas,pwm-rcar";
+ reg = <0 0xe6e33000 0 0x8>;
+ clocks = <&mstp5_clks R8A7744_CLK_PWM>;
+ power-domains = <&cpg_clocks>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm4: pwm@e6e34000 {
+ compatible = "renesas,pwm-r8a7744", "renesas,pwm-rcar";
+ reg = <0 0xe6e34000 0 0x8>;
+ clocks = <&mstp5_clks R8A7744_CLK_PWM>;
+ power-domains = <&cpg_clocks>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm5: pwm@e6e35000 {
+ compatible = "renesas,pwm-r8a7744", "renesas,pwm-rcar";
+ reg = <0 0xe6e35000 0 0x8>;
+ clocks = <&mstp5_clks R8A7744_CLK_PWM>;
+ power-domains = <&cpg_clocks>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm6: pwm@e6e36000 {
+ compatible = "renesas,pwm-r8a7744", "renesas,pwm-rcar";
+ reg = <0 0xe6e36000 0 0x8>;
+ clocks = <&mstp5_clks R8A7744_CLK_PWM>;
+ power-domains = <&cpg_clocks>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
can0: can@e6e80000 {
compatible = "renesas,can-r8a7744",
"renesas,rcar-gen2-can";
--
2.7.4


[PATCH 4.4.y-cip 01/10] ARM: dts: r8a7744: Add VSP support

Lad Prabhakar
 

From: Biju Das <biju.das@bp.renesas.com>

commit eddcbe813dd3c8247840859bf4d04b3423d35f8f upstream.

Add VSP support to SoC DT.

Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
(dropped resets property. changed clocks and power-domains properties.
added vsp device configuration)
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
arch/arm/boot/dts/r8a7744.dtsi | 42 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7744.dtsi b/arch/arm/boot/dts/r8a7744.dtsi
index 91e032a..cf7d8fe 100644
--- a/arch/arm/boot/dts/r8a7744.dtsi
+++ b/arch/arm/boot/dts/r8a7744.dtsi
@@ -1277,6 +1277,48 @@
power-domains = <&cpg_clocks>;
};

+ vsp@fe928000 {
+ compatible = "renesas,vsp1";
+ reg = <0 0xfe928000 0 0x8000>;
+ interrupts = <GIC_SPI 267 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp1_clks R8A7744_CLK_VSP1_S>;
+ power-domains = <&cpg_clocks>;
+
+ renesas,has-lut;
+ renesas,has-sru;
+ renesas,#rpf = <5>;
+ renesas,#uds = <1>;
+ renesas,#wpf = <4>;
+ };
+
+ vsp@fe930000 {
+ compatible = "renesas,vsp1";
+ reg = <0 0xfe930000 0 0x8000>;
+ interrupts = <GIC_SPI 246 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp1_clks R8A7744_CLK_VSP1_DU0>;
+ power-domains = <&cpg_clocks>;
+
+ renesas,has-lif;
+ renesas,has-lut;
+ renesas,#rpf = <4>;
+ renesas,#uds = <1>;
+ renesas,#wpf = <1>;
+ };
+
+ vsp@fe938000 {
+ compatible = "renesas,vsp1";
+ reg = <0 0xfe938000 0 0x8000>;
+ interrupts = <GIC_SPI 247 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp1_clks R8A7744_CLK_VSP1_DU1>;
+ power-domains = <&cpg_clocks>;
+
+ renesas,has-lif;
+ renesas,has-lut;
+ renesas,#rpf = <4>;
+ renesas,#uds = <1>;
+ renesas,#wpf = <1>;
+ };
+
du: display@feb00000 {
compatible = "renesas,du-r8a7744";
reg = <0 0xfeb00000 0 0x40000>,
--
2.7.4


[PATCH 4.4.y-cip 00/10] Renesas RZ/G1N extend peripherals supported by platform

Lad Prabhakar
 

This patch series adds support for following peripherals supported by RZ/G1N:
1: VSP
2: PWM
3: TPU
4: QSPI
5: MSIOF
6: xHCI
7: PCiec
8: NOR flash for iwg20m

This patch series is based on linux-4.4.y-cip and all the patches in this
series are cherry-picked from upstream apart from "usb: host: xhci-plat: Add r8a7744 support"
patch.

Biju Das (9):
ARM: dts: r8a7744: Add VSP support
ARM: dts: r8a7744: Add PWM SoC support
ARM: dts: r8a7744: Add TPU support
ARM: dts: r8a7744: Add QSPI support
ARM: dts: r8a7744: Add MSIOF[012] support
ARM: dts: r8a7744-iwg20m: Add SPI NOR support
dt-bindings: usb-xhci: Document r8a7744 support
ARM: dts: r8a7744: Add xhci support
ARM: dts: r8a7744: Add PCIe Controller device node

Lad Prabhakar (1):
usb: host: xhci-plat: Add r8a7744 support

Documentation/devicetree/bindings/usb/usb-xhci.txt | 3 +-
arch/arm/boot/dts/r8a7744-iwg20m.dtsi | 26 +++
arch/arm/boot/dts/r8a7744.dtsi | 219 +++++++++++++++++++++
drivers/usb/host/xhci-plat.c | 7 +-
4 files changed, 252 insertions(+), 3 deletions(-)

--
2.7.4


Supplier of Valves

WORLDS VALVE <tjwdsv@...>
 

Hi Sir/Madam,

Glad to hear that you are on the market for valves, we specialize in this field for 13 years with the strength of  FLANGED BRONZE BUTTERFLY VALVES with good quality and pretty competitive price.

 

 

Also we have our own professional designers to meet any of your requirements.

If you are interested in,Please let me know.

 

Best Regards!

 

 

Huang Dekai

____________________________

Tianjin Worlds Valve co., ltd.

www.wdsvalve.com

www.worldsvalve.com

Tel:0086-13682070288
Add:No.25,Fuhui Road,Jinnan District,Tianjin, China


Re: [cip-core] Package Proposal #2 (Minimum base packages in Debian)

Kazuhiro Hayashi
 

Hello CIP Core members,

Thank you for your replies.

I need to wait for replies of Codethink, Hitachi, and Moxa,
so would like to postpone the due date to
January 31th (Fri)
(Lunar New Year holiday until Jan 29th)

Codethink
Cybertrust (Agreed #2)
Hitachi
Moxa
Renesas (Agreed #2)
Siemens (Agreed #2)
Toshiba (Agreed #2)

Best regards,
Kazu

-----Original Message-----
From: cip-dev [mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Takehisa Katayama
Sent: Thursday, January 23, 2020 5:07 PM
To: cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] [cip-core] Package Proposal #2 (Minimum base packages in Debian)

Hi Kazu-san,

Please reply with you opinion, agree or disagree.
Renesas agree.

Thanks.

Best regards,
Takehisa Katayama.



On 2020/01/21 9:52, kazuhiro3.hayashi@toshiba.co.jp wrote:
Hello CIP Core members,

Due Date: January 20th (The next TSC meeting)
If you have not yet replied to this proposal, please send us your opinion by
January 23th (By the next IRC meeting)

Best regards,
Kazu


Hello CIP Core members,

I created a simple package proposal for the packages that are installed in the "minimum base system" of Debian.
These packages are installed by
$ debootstrap --variant=minbase buster ...

It consists of 58 source packages and 84 binary packages, including all run-time dependencies.

The common reason to propose:
"This package is included in the minimum base system of Debian (debootstrap --variant=minbase),
which is essential for all Debian binary package based systems"


I would like to start the "review" phase (Phase 2) of the attached package proposal.
https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc/pdp.md#phase-2-proposal-review

Please reply with you opinion, agree or disagree.
If you cannot agree to add specific packages, please show the reasons as well.

Due Date: January 20th (The next TSC meeting)

We have only 2-3 working days for this review, but
I think it may be enough to agree or disagree the very simple reason above.
(We can extend this due date if more time required for reviews, please let me know if any requests)

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


Re: gitlab Test artifacts

Chris Paterson
 

Hello Quirin,

From: Gylstorff Quirin <quirin.gylstorff@siemens.com>
Sent: 23 January 2020 09:32

Hi Chris,

Is there a reason to upload the artifacts from gitlab to aws. Currently
the artifacts in gitlab do not expire and are public accessible.
Currently the artifacts (Kernel image/DTBs) from a 'build' job are stored as artifacts in GitLab so that they are easily available for 'test' jobs to use.
These test jobs then upload the artifacts to AWS where they can be accessed by the LAVA labs.

Why don't the LAVA labs just fetch the binaries from GitLab? Good question.
Partly because CIP was already using AWS and partly because I never got around to trying.


For example
https://gitlab.com/cip-project/cip-kernel/linux-cip/-/jobs/270427371

If only aws should be used as longt erm storage then maybe we should add
an expire date or use caches instead of artifacts for the gitlab ci builds.
The benefit of using artifacts over caches in GitLab is that objects stored as artifacts can be easily accessed by users through the GitLab website or API.
Perhaps useful if someone wants to run some tests locally, and easier to do then finding the appropriate files in AWS.

Yes, there should probably be an expiry on these artifacts (artifacts:expire_in), but as the storage is all controlled/payed for by GitLab it's not a direct issue for CIP.
I'll add a 1 month limit for now.

One thing I haven't tried yet is playing around with using a cache for build objects to speed up build times, perhaps useful to store the SSTATE CACHE from OE builds.

Kind regards, Chris


Kind regards,
Quirin


gitlab Test artifacts

Quirin Gylstorff
 

Hi Chris,

Is there a reason to upload the artifacts from gitlab to aws. Currently the artifacts in gitlab do not expire and are public accessible.

For example https://gitlab.com/cip-project/cip-kernel/linux-cip/-/jobs/270427371

If only aws should be used as longt erm storage then maybe we should add an expire date or use caches instead of artifacts for the gitlab ci builds.

Kind regards,
Quirin


Re: CIP IRC weekly meeting today

masashi.kudo@...
 

Hi, Chen-Yu san,

Thanks for sharing your status!
Then, see you next week!

Best regards,
--
M. Kudo

-----Original Message-----
From: Chen-Yu Tsai <wens@kernel.org>
Sent: Thursday, January 23, 2020 5:34 PM
To: 工藤 雅司(CTJ) <masashi.kudo@cybertrust.co.jp>
Cc: cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] CIP IRC weekly meeting today

Hi,

On Thu, Jan 23, 2020 at 6:55 AM <masashi.kudo@cybertrust.co.jp> wrote:

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00
starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&m
onth=11&day=28&hour=9&min=0&sec=0&p1=241&p2=137&p3=179&p4=136&p5=37&p6
=248

US-West US-East UK DE TW JP
01:00 04:00 09:00 10:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last week's meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/01/cip.2020-01-16-09.00
.log.html

Agenda:

* Action item
1. Combine rootfilesystem with kselftest binary - Iwamatsu-san 2.
Document a process on how to add tests to the CIP test setup -
patersonc 3. Arrangement of F2F Kernel Meeting in Nuremberg -
masashi910 4. Add config for BBB to both 4.4 and 4.19 (done for
qemux86-64) - Iwamatsu-san

* Kernel maintenance updates
* Kernel testing
* CIP Core
* Software update
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.
I won't be attending today's meeting.

Nothing much on my end. I reviewed a couple merge requests from Ben regarding CVEs. Three of the new ones are resolved; the last is related to ashmem in staging which is probably only used with Android.

There are some data updates to classify-failed-patches that I haven't pushed out. Nothing looks critical this week.

Regards
ChenYu


Re: CIP IRC weekly meeting today

Chen-Yu Tsai <wens@...>
 

Hi,

On Thu, Jan 23, 2020 at 6:55 AM <masashi.kudo@cybertrust.co.jp> wrote:

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=11&day=28&hour=9&min=0&sec=0&p1=241&p2=137&p3=179&p4=136&p5=37&p6=248

US-West US-East UK DE TW JP
01:00 04:00 09:00 10:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last week's meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/01/cip.2020-01-16-09.00.log.html

Agenda:

* Action item
1. Combine rootfilesystem with kselftest binary - Iwamatsu-san
2. Document a process on how to add tests to the CIP test setup - patersonc
3. Arrangement of F2F Kernel Meeting in Nuremberg - masashi910
4. Add config for BBB to both 4.4 and 4.19 (done for qemux86-64) - Iwamatsu-san

* Kernel maintenance updates
* Kernel testing
* CIP Core
* Software update
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.
I won't be attending today's meeting.

Nothing much on my end. I reviewed a couple merge requests from Ben
regarding CVEs. Three of the new ones are resolved; the last is related
to ashmem in staging which is probably only used with Android.

There are some data updates to classify-failed-patches that I haven't
pushed out. Nothing looks critical this week.

Regards
ChenYu


Re: [cip-core] Package Proposal #2 (Minimum base packages in Debian)

Takehisa Katayama
 

Hi Kazu-san,

Please reply with you opinion, agree or disagree.
Renesas agree.

Thanks.

Best regards,
Takehisa Katayama.



On 2020/01/21 9:52, kazuhiro3.hayashi@toshiba.co.jp wrote:
Hello CIP Core members,

Due Date: January 20th (The next TSC meeting)
If you have not yet replied to this proposal, please send us your opinion by
January 23th (By the next IRC meeting)

Best regards,
Kazu


Hello CIP Core members,

I created a simple package proposal for the packages that are installed in the "minimum base system" of Debian.
These packages are installed by
$ debootstrap --variant=minbase buster ...

It consists of 58 source packages and 84 binary packages, including all run-time dependencies.

The common reason to propose:
"This package is included in the minimum base system of Debian (debootstrap --variant=minbase),
which is essential for all Debian binary package based systems"


I would like to start the "review" phase (Phase 2) of the attached package proposal.
https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc/pdp.md#phase-2-proposal-review

Please reply with you opinion, agree or disagree.
If you cannot agree to add specific packages, please show the reasons as well.

Due Date: January 20th (The next TSC meeting)

We have only 2-3 working days for this review, but
I think it may be enough to agree or disagree the very simple reason above.
(We can extend this due date if more time required for reviews, please let me know if any requests)

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


Re: RESUME REQUEST: [cip-core] Package Proposal #1 (Security packages)

punit1.agrawal@...
 

Thank you for your comments, Yoshida-san. Follow up comments inline.

Kento Yoshida <kento.yoshida.wz@renesas.com> writes:

Hello and thank you for your comment, Punit,

-----Original Message-----
From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
Sent: Monday, January 20, 2020 7:29 PM
To: Kento Yoshida <kento.yoshida.wz@renesas.com>
Cc: cip-dev@lists.cip-project.org; kazuhiro3.hayashi@toshiba.co.jp;
cip-security@lists.cip-project.org
Subject: Re: [cip-dev] RESUME REQUEST: [cip-core] Package Proposal #1 (Security
packages)

Hello Yoshida-san,

Kento Yoshida <kento.yoshida.wz@renesas.com> writes:

Hello,

I would like to resume our proposal from security working group.
As you know, Kazu has modified the script to generate a proposal and posted the
minimum base system proposal, and then I created the new proposal.

The difference from the original (rev01) proposal is below:
1. We remove 'duplicity', 'google-authenticator', 'pam-shield' and 'suricata' in the
new proposal because they have an issue such as non-well maintained, python
version, too much dependencies and so on. We'll separately propose them after
solved these issues.
2. The new proposal shows all source package as flat. Thanks to the new script,
Kazu!
3. Actually several packages overlap with the proposed packages for minimum
base system in Debian, so I added comment them like that.

@kazuhiro3.hayashi@toshiba.co.jp,
Would you check this proposal and set the due date to review it?

Please reply if you have any comments or questions.
I have a comment about packages in the proposal that depend on hardware /
system features -

* Some packages in the proposal depend on special purpose hardware to
provide their functionality. e.g., TPM.

In systems, where TPM is not present (or similar functionality is
provided by alternate mechanisms), the TPM related packages will not
be useful. e.g., the non-x86 platforms in the CIP reference hardware
list.

* Similarly, some packages require the system to be connected to the
network.

In both of these situations, I am wondering what is the impact on compliance? Is
there a need to also define minimal set of hardware features expected from
reference hardware to be able to meet compliance requirements?
How each reference hardware satisfies the requirements should be
considered by each reference hardware provider.
Agreed.

But without an explicit statement of the requirement, how can a hardware
vendor wanting to develop system for CIP users know what features to
enable in their system?

If we provide hardware mechanisms similar with TPM to protect
credentials and authentications, we can meet compliance requirements.
TPM2 specification is more than 2000 pages long with many features and
functions. I believe the IEC standard requires a subset of this
functionality. The Security WG maybe intimately familiar with the
required features but for the reviewers on this list, there isn't any
criteria to use for evaluation.

Stating these functional requirements explicitly will serve the dual
purpose of -

* Provide an objective criteria for evaluating the package proposal (and
discuss alternatives)

* Give hardware / system vendors the features / functions needed by CIP
users.

What do you think?

TPM related packages are options in only systems where TPM is
implemented as you said. If supporting these packages require too much
costs, the necessity of them will diminish. Actually the standard
lists TPM as a typical example, so we thought it will be useful to
maintain TPM related packages for many users, but their necessities
depend on supporting cost.
I see - thanks for the background of the TPM-related packages in the
proposal.


To help review the package list (and also discuss alternatives), it would help to
define the underlying functionality that is required in more detail, e.g., secure key
storage, verified boot, etc. It'll make it possible review the proposal more
concretely.
[...]


CIP IRC weekly meeting today

masashi.kudo@...
 

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=11&day=28&hour=9&min=0&sec=0&p1=241&p2=137&p3=179&p4=136&p5=37&p6=248

US-West US-East UK DE TW JP
01:00 04:00 09:00 10:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last week's meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/01/cip.2020-01-16-09.00.log.html

Agenda:

* Action item
1. Combine rootfilesystem with kselftest binary - Iwamatsu-san
2. Document a process on how to add tests to the CIP test setup - patersonc
3. Arrangement of F2F Kernel Meeting in Nuremberg - masashi910
4. Add config for BBB to both 4.4 and 4.19 (done for qemux86-64) - Iwamatsu-san

* Kernel maintenance updates
* Kernel testing
* CIP Core
* Software update
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.


Re: RESUME REQUEST: [cip-core] Package Proposal #1 (Security packages)

Kento Yoshida
 

Hello and thank you for your comment, Punit,

-----Original Message-----
From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
Sent: Monday, January 20, 2020 7:29 PM
To: Kento Yoshida <kento.yoshida.wz@renesas.com>
Cc: cip-dev@lists.cip-project.org; kazuhiro3.hayashi@toshiba.co.jp;
cip-security@lists.cip-project.org
Subject: Re: [cip-dev] RESUME REQUEST: [cip-core] Package Proposal #1 (Security
packages)

Hello Yoshida-san,

Kento Yoshida <kento.yoshida.wz@renesas.com> writes:

Hello,

I would like to resume our proposal from security working group.
As you know, Kazu has modified the script to generate a proposal and posted the
minimum base system proposal, and then I created the new proposal.

The difference from the original (rev01) proposal is below:
1. We remove 'duplicity', 'google-authenticator', 'pam-shield' and 'suricata' in the
new proposal because they have an issue such as non-well maintained, python
version, too much dependencies and so on. We'll separately propose them after
solved these issues.
2. The new proposal shows all source package as flat. Thanks to the new script,
Kazu!
3. Actually several packages overlap with the proposed packages for minimum
base system in Debian, so I added comment them like that.

@kazuhiro3.hayashi@toshiba.co.jp,
Would you check this proposal and set the due date to review it?

Please reply if you have any comments or questions.
I have a comment about packages in the proposal that depend on hardware /
system features -

* Some packages in the proposal depend on special purpose hardware to
provide their functionality. e.g., TPM.

In systems, where TPM is not present (or similar functionality is
provided by alternate mechanisms), the TPM related packages will not
be useful. e.g., the non-x86 platforms in the CIP reference hardware
list.

* Similarly, some packages require the system to be connected to the
network.

In both of these situations, I am wondering what is the impact on compliance? Is
there a need to also define minimal set of hardware features expected from
reference hardware to be able to meet compliance requirements?
How each reference hardware satisfies the requirements should be considered by each reference hardware provider.
If we provide hardware mechanisms similar with TPM to protect credentials and authentications, we can meet compliance requirements.
TPM related packages are options in only systems where TPM is implemented as you said. If supporting these packages require too much costs, the necessity of them will diminish.
Actually the standard lists TPM as a typical example, so we thought it will be useful to maintain TPM related packages for many users, but their necessities depend on supporting cost.

To help review the package list (and also discuss alternatives), it would help to
define the underlying functionality that is required in more detail, e.g., secure key
storage, verified boot, etc. It'll make it possible review the proposal more
concretely.

Thoughts?

Thanks,
Punit

[...]


Re: RESUME REQUEST: [cip-core] Package Proposal #1 (Security packages)

Kazuhiro Hayashi
 

Hello Kent, and reviewers,

[...]
In order to clearly show the differences of my proposal #2 and your proposal,
it might be better to create additional yml file where the duplicated packages are dropped.
I will try to create this data next week :)
I attached this file.
Please note that the packages duplicated with the proposal #2 are removed from this file.

As the first step, it's better to start our reviews from
the 15 "top-level" packages in the first section of the attachment.
Other packages are just dependencies of these packages.

Best regards,
Kazu



@kazuhiro3.hayashi@toshiba.co.jp,
Would you check this proposal and set the due date to review it?
The proposal #2 is now proceeding in parallel so it's a bit difficult to decide
but how about setting it to Jan 27th?

Best regards,
Kazu


Please reply if you have any comments or questions.

Kind regards,
Kent

-----Original Message-----
From: kazuhiro3.hayashi@toshiba.co.jp <kazuhiro3.hayashi@toshiba.co.jp>
Sent: Friday, December 20, 2019 6:59 PM
To: jan.kiszka@siemens.com; Kento Yoshida <kento.yoshida.wz@renesas.com>;
cip-dev@lists.cip-project.org; dinesh.kumar@toshiba-tsip.com
Subject: RE: [cip-dev] [cip-core] Package Proposal #1 (Security packages)

Hello,

On 20.12.19 03:25, Kento Yoshida wrote:
Thank you for your feedback, Jan.

Why still chrony, why not simply systemd timers? Legacy?
We agree that systemd-timesyncd is sufficient for users who need only SNTP
client functionality.
The reason we want to add Chrony to our core packages is to support
various use cases, and because Chrony is recognized
by CII as being a superior secure NTP implementation.
https://www.coreinfrastructure.org/blogs/securing-network-time/

Since the CII aims to invest in core infrastructure, providing funding for
fundamental projects, I think "chrony"
would be more secure and sustainable.
Oops, I actually confused cron and chrony here. Interestingly, the
question "can't systemd do that?" remained valid :).

I agree to pick the more mature solution for this purpose.

suricata:
bin_pkgs:
suricata:
depends:
- dpkg
- python
- python-simplejson
I'm missing the new dependencies in the top-list. Didn't we agree on listing
them flat?
This, e.g., pulls python, currently even v2 - anything but a
trivial package. Or did I miss that we have this in
our list already?

@kazuhiro3.hayashi@toshiba.co.jp and @Dinesh Kumar, Do you need a
script modification to address this issue?
We need to reconsider the format of proposal.yml (and scripts as well).
It seems not to be reviewed enough.

Actually, proposals for run-time dependencies package of top-lists
are still in preparation and are under investigation
in the security working group.
The automatic outputs of the script have been used as it is for the
dependencies package displayed in this proposal.

We can only decide about package sets which have their runtime
dependencies already fulfilled with the existing package set (where is
that now, BTW?) or include these dependencies in the set.
I'm assuming the "existing package set" is the list of packages that are already
accepted by CIP.
If so, there is no such list because this is the first proposal.

Also, it's difficult for me to agree with the opinion that "all runtime dependencies
must be fullfilled with the existing package set" because
1) Some dependency (binary) packages are not functionally necessary
from the CIP's long-term support point of view (debconf,
debian-archive-keyring, etc.)
2) The list including all dependencies may become big for CIP's "OSBL"
(e.g. If following this, the security package proposal pulls around 90 packages
finally)

I only checked
suricata because of the outstanding python dependency, but there might
be more issue. This needs to be checked carefully again.
Yes, we need to share the concrete examples of packages, PDP steps, and the
format of yml.
I will prepare this and will share in the next week.

So, please suspend this proposal process until requirements of all members
become clear.

Kazu


Jan


Best regards,
Kent
-----Original Message-----
From: cip-dev <cip-dev-bounces@lists.cip-project.org> On Behalf Of
Jan Kiszka
Sent: Thursday, December 19, 2019 7:48 PM
To: kazuhiro3.hayashi@toshiba.co.jp; cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security
packages)

On 09.12.19 14:54, kazuhiro3.hayashi@toshiba.co.jp wrote:
Hello CIP Core members,

I would like to start the "review" phase (Phase 2) of the attached package
proposal.
https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc
/pd
p.md#phase-2-proposal-review

The packages are proposed by CIP security WG to satisfy their required
features.
See the "reason" fields in the proposal for more details.

Please reply with you opinion, agree or disagree.
If you cannot agree to add specific packages, please show the reasons as well.

Due Date: December 23rd
(We can extend this due date if more time required for reviews,
please let me know if any requests)
[...]

chrony:
bin_pkgs:
chrony:
depends:
- init-system-helpers
- adduser
- iproute2
- lsb-base
- ucf
- libc6
- libcap2
- libedit2
- libnettle6
- libseccomp2
in_target: 'True'
n_cve: '10'
reason: For supporting IEC-62443-4-2 certification for CR 2.11, 2.11(1)
security_criteria: network::server, network::service
Why still chrony, why not simply systemd timers? Legacy?

suricata:
bin_pkgs:
suricata:
depends:
- dpkg
- python
- python-simplejson
I'm missing the new dependencies in the top-list. Didn't we agree on
listing them flat? This, e.g., pulls python,
currently even
v2 - anything but a trivial package. Or did I miss that we have this in our list
already?

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate
Competence Center Embedded Linux
_______________________________________________
Cip-security mailing list
Cip-security@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-security


Re: [cip-core] Package Proposal #2 (Minimum base packages in Debian)

Kazuhiro Hayashi
 

Hello CIP Core members,

Due Date: January 20th (The next TSC meeting)
If you have not yet replied to this proposal, please send us your opinion by
January 23th (By the next IRC meeting)

Best regards,
Kazu


Hello CIP Core members,

I created a simple package proposal for the packages that are installed in the "minimum base system" of Debian.
These packages are installed by
$ debootstrap --variant=minbase buster ...

It consists of 58 source packages and 84 binary packages, including all run-time dependencies.

The common reason to propose:
"This package is included in the minimum base system of Debian (debootstrap --variant=minbase),
which is essential for all Debian binary package based systems"


I would like to start the "review" phase (Phase 2) of the attached package proposal.
https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc/pdp.md#phase-2-proposal-review

Please reply with you opinion, agree or disagree.
If you cannot agree to add specific packages, please show the reasons as well.

Due Date: January 20th (The next TSC meeting)

We have only 2-3 working days for this review, but
I think it may be enough to agree or disagree the very simple reason above.
(We can extend this due date if more time required for reviews, please let me know if any requests)

Best regards,
Kazu


Re: RESUME REQUEST: [cip-core] Package Proposal #1 (Security packages)

Kazuhiro Hayashi
 

Hello,

On 17.01.20 14:14, kazuhiro3.hayashi@toshiba.co.jp wrote:
Hello Kent,

[...]
3. Actually several packages overlap with the proposed packages for minimum base system in Debian, so I added comment
them like that.
Thank you for taking time to check this...
In order to clearly show the differences of my proposal #2 and your proposal,
it might be better to create additional yml file where the duplicated packages are dropped.
I will try to create this data next week :)


@kazuhiro3.hayashi@toshiba.co.jp,
Would you check this proposal and set the due date to review it?
The proposal #2 is now proceeding in parallel so it's a bit difficult to decide
but how about setting it to Jan 27th?
As I'm not in the house next week, I will not be able to comment on the
new list, nor vote. In any case, one week might be ok for a short,
obvious list. But if we are talking about a list of dozens of packages,
that will be too short.
Thank you for your reply.

I would like to change the due date to
Feb 5th (two weeks + 3 days)
Regarding security packages, I guess more discussions about
the technical requirements of the security standard would be required,
so this change might not be enough too though.

Kazu


Jan


Best regards,
Kazu


Please reply if you have any comments or questions.

Kind regards,
Kent

-----Original Message-----
From: kazuhiro3.hayashi@toshiba.co.jp <kazuhiro3.hayashi@toshiba.co.jp>
Sent: Friday, December 20, 2019 6:59 PM
To: jan.kiszka@siemens.com; Kento Yoshida <kento.yoshida.wz@renesas.com>;
cip-dev@lists.cip-project.org; dinesh.kumar@toshiba-tsip.com
Subject: RE: [cip-dev] [cip-core] Package Proposal #1 (Security packages)

Hello,

On 20.12.19 03:25, Kento Yoshida wrote:
Thank you for your feedback, Jan.

Why still chrony, why not simply systemd timers? Legacy?
We agree that systemd-timesyncd is sufficient for users who need only SNTP
client functionality.
The reason we want to add Chrony to our core packages is to support
various use cases, and because Chrony is recognized
by CII as being a superior secure NTP implementation.
https://www.coreinfrastructure.org/blogs/securing-network-time/

Since the CII aims to invest in core infrastructure, providing funding for
fundamental projects, I think "chrony"
would be more secure and sustainable.
Oops, I actually confused cron and chrony here. Interestingly, the
question "can't systemd do that?" remained valid :).

I agree to pick the more mature solution for this purpose.

suricata:
bin_pkgs:
suricata:
depends:
- dpkg
- python
- python-simplejson
I'm missing the new dependencies in the top-list. Didn't we agree on listing
them flat?
This, e.g., pulls python, currently even v2 - anything but a
trivial package. Or did I miss that we have this in
our list already?

@kazuhiro3.hayashi@toshiba.co.jp and @Dinesh Kumar, Do you need a
script modification to address this issue?
We need to reconsider the format of proposal.yml (and scripts as well).
It seems not to be reviewed enough.

Actually, proposals for run-time dependencies package of top-lists
are still in preparation and are under investigation
in the security working group.
The automatic outputs of the script have been used as it is for the
dependencies package displayed in this proposal.

We can only decide about package sets which have their runtime
dependencies already fulfilled with the existing package set (where is
that now, BTW?) or include these dependencies in the set.
I'm assuming the "existing package set" is the list of packages that are already
accepted by CIP.
If so, there is no such list because this is the first proposal.

Also, it's difficult for me to agree with the opinion that "all runtime dependencies
must be fullfilled with the existing package set" because
1) Some dependency (binary) packages are not functionally necessary
from the CIP's long-term support point of view (debconf,
debian-archive-keyring, etc.)
2) The list including all dependencies may become big for CIP's "OSBL"
(e.g. If following this, the security package proposal pulls around 90 packages
finally)

I only checked
suricata because of the outstanding python dependency, but there might
be more issue. This needs to be checked carefully again.
Yes, we need to share the concrete examples of packages, PDP steps, and the
format of yml.
I will prepare this and will share in the next week.

So, please suspend this proposal process until requirements of all members
become clear.

Kazu


Jan


Best regards,
Kent
-----Original Message-----
From: cip-dev <cip-dev-bounces@lists.cip-project.org> On Behalf Of
Jan Kiszka
Sent: Thursday, December 19, 2019 7:48 PM
To: kazuhiro3.hayashi@toshiba.co.jp; cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security
packages)

On 09.12.19 14:54, kazuhiro3.hayashi@toshiba.co.jp wrote:
Hello CIP Core members,

I would like to start the "review" phase (Phase 2) of the attached package
proposal.
https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc
/pd
p.md#phase-2-proposal-review

The packages are proposed by CIP security WG to satisfy their required
features.
See the "reason" fields in the proposal for more details.

Please reply with you opinion, agree or disagree.
If you cannot agree to add specific packages, please show the reasons as well.

Due Date: December 23rd
(We can extend this due date if more time required for reviews,
please let me know if any requests)
[...]

chrony:
bin_pkgs:
chrony:
depends:
- init-system-helpers
- adduser
- iproute2
- lsb-base
- ucf
- libc6
- libcap2
- libedit2
- libnettle6
- libseccomp2
in_target: 'True'
n_cve: '10'
reason: For supporting IEC-62443-4-2 certification for CR 2.11, 2.11(1)
security_criteria: network::server, network::service
Why still chrony, why not simply systemd timers? Legacy?

suricata:
bin_pkgs:
suricata:
depends:
- dpkg
- python
- python-simplejson
I'm missing the new dependencies in the top-list. Didn't we agree on
listing them flat? This, e.g., pulls python,
currently even
v2 - anything but a trivial package. Or did I miss that we have this in our list
already?

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate
Competence Center Embedded Linux
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

2841 - 2860 of 7061