Date   

[PATCH 05/14] clk: shmobile: Document r8a7743 MSTP clock support

Biju Das <biju.das@...>
 

Signed-off-by: Biju Das <biju.das@...>
---
Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt | 1 +
1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt
index 16ed181..f444798 100644
--- a/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt
+++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt
@@ -13,6 +13,7 @@ Required Properties:
- "renesas,r7s72100-mstp-clocks" for R7S72100 (RZ) MSTP gate clocks
- "renesas,r8a73a4-mstp-clocks" for R8A73A4 (R-Mobile APE6) MSTP gate clocks
- "renesas,r8a7740-mstp-clocks" for R8A7740 (R-Mobile A1) MSTP gate clocks
+ - "renesas,r8a7743-mstp-clocks" for R8A7743 (RZ/G1M) MSTP gate clocks
- "renesas,r8a7778-mstp-clocks" for R8A7778 (R-Car M1) MSTP gate clocks
- "renesas,r8a7779-mstp-clocks" for R8A7779 (R-Car H1) MSTP gate clocks
- "renesas,r8a7790-mstp-clocks" for R8A7790 (R-Car H2) MSTP gate clocks
--
1.9.1


[PATCH 04/14] clk: shmobile: Document r8a7743 CPG DIV6 clock support

Biju Das <biju.das@...>
 

Signed-off-by: Biju Das <biju.das@...>
---
Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt | 1 +
1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt
index 38dcf03..2990615 100644
--- a/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt
+++ b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt
@@ -9,6 +9,7 @@ Required Properties:
- compatible: Must be one of the following
- "renesas,r8a73a4-div6-clock" for R8A73A4 (R-Mobile APE6) DIV6 clocks
- "renesas,r8a7740-div6-clock" for R8A7740 (R-Mobile A1) DIV6 clocks
+ - "renesas,r8a7743-div6-clock" for R8A7743 (RZ/G1M) DIV6 clocks
- "renesas,r8a7790-div6-clock" for R8A7790 (R-Car H2) DIV6 clocks
- "renesas,r8a7791-div6-clock" for R8A7791 (R-Car M2-W) DIV6 clocks
- "renesas,r8a7793-div6-clock" for R8A7793 (R-Car M2-N) DIV6 clocks
--
1.9.1


[PATCH 03/14] clk: shmobile: Document r8a7743 CPG clock support

Biju Das <biju.das@...>
 

Document r8a7743 CPG clock support.

Signed-off-by: Biju Das <biju.das@...>
---
Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt | 1 +
1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
index 2a9a8ed..986b8a1 100644
--- a/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
+++ b/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
@@ -8,6 +8,7 @@ CPG Module Stop (MSTP) Clocks.
Required Properties:

- compatible: Must be one of
+ - "renesas,r8a7743-cpg-clocks" for the r8a7743 CPG
- "renesas,r8a7790-cpg-clocks" for the r8a7790 CPG
- "renesas,r8a7791-cpg-clocks" for the r8a7791 CPG
- "renesas,r8a7793-cpg-clocks" for the r8a7793 CPG
--
1.9.1


[PATCH 02/14] ARM: shmobile: r8a7743: Add clock index macros for DT sources

Biju Das <biju.das@...>
 

Add macros usable by device tree sources to reference r8a7743 clocks by
index.

This is based on the work done by Laurent Pinchart for the r8a7791 SoC.

Signed-off-by: Biju Das <biju.das@...>
---
include/dt-bindings/clock/r8a7743-clock.h | 166 ++++++++++++++++++++++++++++++
1 file changed, 166 insertions(+)
create mode 100644 include/dt-bindings/clock/r8a7743-clock.h

diff --git a/include/dt-bindings/clock/r8a7743-clock.h b/include/dt-bindings/clock/r8a7743-clock.h
new file mode 100644
index 0000000..a5c7e38
--- /dev/null
+++ b/include/dt-bindings/clock/r8a7743-clock.h
@@ -0,0 +1,166 @@
+/*
+ * Copyright (C) 2017 Renesas Electronics Corp.
+ * Copyright 2013 Ideas On Board SPRL
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_R8A7743_H__
+#define __DT_BINDINGS_CLOCK_R8A7743_H__
+
+/* CPG */
+#define R8A7743_CLK_MAIN 0
+#define R8A7743_CLK_PLL0 1
+#define R8A7743_CLK_PLL1 2
+#define R8A7743_CLK_PLL3 3
+#define R8A7743_CLK_LB 4
+#define R8A7743_CLK_QSPI 5
+#define R8A7743_CLK_SDH 6
+#define R8A7743_CLK_SD0 7
+#define R8A7743_CLK_Z 8
+#define R8A7743_CLK_RCAN 9
+
+/* MSTP0 */
+#define R8A7743_CLK_MSIOF0 0
+
+/* MSTP1 */
+#define R8A7743_CLK_VCP0 1
+#define R8A7743_CLK_VPC0 3
+#define R8A7743_CLK_ADG 6
+#define R8A7743_CLK_TSIF0 8
+#define R8A7743_CLK_TMU1 11
+#define R8A7743_CLK_3DG 12
+#define R8A7743_CLK_2DDMAC 15
+#define R8A7743_CLK_FDP1_1 18
+#define R8A7743_CLK_FDP1_0 19
+#define R8A7743_CLK_TMU3 21
+#define R8A7743_CLK_TMU2 22
+#define R8A7743_CLK_CMT0 24
+#define R8A7743_CLK_TMU0 25
+#define R8A7743_CLK_VSP1_DU1 27
+#define R8A7743_CLK_VSP1_DU0 28
+#define R8A7743_CLK_VSP1_S 31
+
+/* MSTP2 */
+#define R8A7743_CLK_SCIFA2 2
+#define R8A7743_CLK_SCIFA1 3
+#define R8A7743_CLK_SCIFA0 4
+#define R8A7743_CLK_MSIOF2 5
+#define R8A7743_CLK_SCIFB0 6
+#define R8A7743_CLK_SCIFB1 7
+#define R8A7743_CLK_MSIOF1 8
+#define R8A7743_CLK_SCIFB2 16
+#define R8A7743_CLK_SYS_DMAC1 18
+#define R8A7743_CLK_SYS_DMAC0 19
+
+/* MSTP3 */
+#define R8A7743_CLK_TPU0 4
+#define R8A7743_CLK_SDHI3 11
+#define R8A7743_CLK_SDHI2 12
+#define R8A7743_CLK_SDHI0 14
+#define R8A7743_CLK_MMCIF0 15
+#define R8A7743_CLK_IIC0 18
+#define R8A7743_CLK_PCIEC 19
+#define R8A7743_CLK_IIC1 23
+#define R8A7743_CLK_SSUSB 28
+#define R8A7743_CLK_CMT1 29
+#define R8A7743_CLK_USBDMAC0 30
+#define R8A7743_CLK_USBDMAC1 31
+
+/* MSTP4 */
+#define R8A7743_CLK_RWDT 4
+#define R8A7743_CLK_USB_DDM 6
+#define R8A7743_CLK_IRQC 7
+#define R8A7743_CLK_INTC_SYS 8
+
+/* MSTP5 */
+#define R8A7743_CLK_AUDIO_DMAC1 1
+#define R8A7743_CLK_AUDIO_DMAC0 2
+#define R8A7743_CLK_THERMAL 22
+#define R8A7743_CLK_PWM 23
+#define R8A7743_CLK_BOOT_ROM 26
+
+/* MSTP7 */
+#define R8A7743_CLK_USB_EHCI 3
+#define R8A7743_CLK_HSUSB 4
+#define R8A7743_CLK_HSCIF2 13
+#define R8A7743_CLK_SCIF5 14
+#define R8A7743_CLK_SCIF4 15
+#define R8A7743_CLK_HSCIF1 16
+#define R8A7743_CLK_HSCIF0 17
+#define R8A7743_CLK_SCIF3 18
+#define R8A7743_CLK_SCIF2 19
+#define R8A7743_CLK_SCIF1 20
+#define R8A7743_CLK_SCIF0 21
+#define R8A7743_CLK_DU1 23
+#define R8A7743_CLK_DU0 24
+#define R8A7743_CLK_LVDS0 26
+
+/* MSTP8 */
+#define R8A7743_CLK_IPMMU_SGX 0
+#define R8A7743_CLK_VIN2 9
+#define R8A7743_CLK_VIN1 10
+#define R8A7743_CLK_VIN0 11
+#define R8A7743_CLK_ETHERAVB 12
+#define R8A7743_CLK_ETHER 13
+#define R8A7743_CLK_SATA1 14
+#define R8A7743_CLK_SATA0 15
+#define R8A7743_CLK_DCU 30
+
+/* MSTP9 */
+#define R8A7743_CLK_GPIO7 4
+#define R8A7743_CLK_GPIO6 5
+#define R8A7743_CLK_GPIO5 7
+#define R8A7743_CLK_GPIO4 8
+#define R8A7743_CLK_GPIO3 9
+#define R8A7743_CLK_GPIO2 10
+#define R8A7743_CLK_GPIO1 11
+#define R8A7743_CLK_GPIO0 12
+#define R8A7743_CLK_RCAN1 15
+#define R8A7743_CLK_RCAN0 16
+#define R8A7743_CLK_QSPI_MOD 17
+#define R8A7743_CLK_I2C5 25
+#define R8A7743_CLK_IICDVFS 26
+#define R8A7743_CLK_I2C4 27
+#define R8A7743_CLK_I2C3 28
+#define R8A7743_CLK_I2C2 29
+#define R8A7743_CLK_I2C1 30
+#define R8A7743_CLK_I2C0 31
+
+/* MSTP10 */
+#define R8A7743_CLK_SSI_ALL 5
+#define R8A7743_CLK_SSI9 6
+#define R8A7743_CLK_SSI8 7
+#define R8A7743_CLK_SSI7 8
+#define R8A7743_CLK_SSI6 9
+#define R8A7743_CLK_SSI5 10
+#define R8A7743_CLK_SSI4 11
+#define R8A7743_CLK_SSI3 12
+#define R8A7743_CLK_SSI2 13
+#define R8A7743_CLK_SSI1 14
+#define R8A7743_CLK_SSI0 15
+#define R8A7743_CLK_SCU_ALL 17
+#define R8A7743_CLK_SCU_DVC1 18
+#define R8A7743_CLK_SCU_DVC0 19
+#define R8A7743_CLK_SCU_CTU1_MIX1 20
+#define R8A7743_CLK_SCU_CTU0_MIX0 21
+#define R8A7743_CLK_SCU_SRC9 22
+#define R8A7743_CLK_SCU_SRC8 23
+#define R8A7743_CLK_SCU_SRC7 24
+#define R8A7743_CLK_SCU_SRC6 25
+#define R8A7743_CLK_SCU_SRC5 26
+#define R8A7743_CLK_SCU_SRC4 27
+#define R8A7743_CLK_SCU_SRC3 28
+#define R8A7743_CLK_SCU_SRC2 29
+#define R8A7743_CLK_SCU_SRC1 30
+#define R8A7743_CLK_SCU_SRC0 31
+
+/* MSTP11 */
+#define R8A7743_CLK_SCIFA3 6
+#define R8A7743_CLK_SCIFA4 7
+#define R8A7743_CLK_SCIFA5 8
+
+#endif /* __DT_BINDINGS_CLOCK_R8A7743_H__ */
--
1.9.1


[PATCH 01/14] ARM: dts: r8a7743: initial SoC device tree

Biju Das <biju.das@...>
 

The initial r8A7743 SoC device tree including CPU0, GIC and timer.

Signed-off-by: Biju Das <biju.das@...>
---
arch/arm/boot/dts/r8a7743.dtsi | 56 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)
create mode 100644 arch/arm/boot/dts/r8a7743.dtsi

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
new file mode 100644
index 0000000..8575a2f
--- /dev/null
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -0,0 +1,56 @@
+/*
+ * Device Tree Source for the r8a7743 SoC
+ *
+ * Copyright (C) 2017 Renesas Electronics Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+ compatible = "renesas,r8a7743";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0>;
+ clock-frequency = <1500000000>;
+ };
+ };
+
+ gic: interrupt-controller@f1001000 {
+ compatible = "arm,gic-400";
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0 0xf1001000 0 0x1000>,
+ <0 0xf1002000 0 0x1000>,
+ <0 0xf1004000 0 0x2000>,
+ <0 0xf1006000 0 0x2000>;
+ interrupts = <1 9 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_HIGH)>;
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <1 13 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <1 14 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <1 11 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <1 10 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>;
+ };
+};
--
1.9.1


[PATCH 00/14] Add Device tree support for iWave G20D-Q7 board

Biju Das <biju.das@...>
 

This patch series aims to add initial SoC DT/Clock and iWave G20D-Q7
DT.

The clock patch is based on the similar work done on r8a7791(R-Car M2)
SoC.

This series has been tested against linux-cip tag v4.4.y-cip master branch.

Biju Das (8):
ARM: dts: r8a7743: initial SoC device tree
ARM: shmobile: r8a7743: Add clock index macros for DT sources
clk: shmobile: Document r8a7743 CPG clock support
clk: shmobile: Document r8a7743 CPG DIV6 clock support
clk: shmobile: Document r8a7743 MSTP clock support
ARM: dts: r8a7743: Add clocks
ARM: dts: iwg20m: Add iWave RZG1M Qseven SOM
ARM: dts: iwg20d-q7: Add support for iWave G20D-Q7 board based on
RZ/G1M

Sergei Shtylyov (4):
ARM: dts: r8a7743: add SYS-DMAC support
ARM: dts: r8a7743: add [H]SCIF{A|B} support
ARM: dts: r8a7743: add Ether support
ARM: dts: r8a7743: add IRQC support

Simon Horman (2):
ARM: shmobile: defconfig: Enable r8a774[35] SoCs
ARM: multi_v7_defconfig: Enable r8a774[35] SoCs

.../bindings/clock/renesas,cpg-div6-clocks.txt | 1 +
.../bindings/clock/renesas,cpg-mstp-clocks.txt | 1 +
.../clock/renesas,rcar-gen2-cpg-clocks.txt | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/r8a7743-iwg20d-q7.dts | 25 +
arch/arm/boot/dts/r8a7743-iwg20m.dtsi | 29 +
arch/arm/boot/dts/r8a7743.dtsi | 871 +++++++++++++++++++++
arch/arm/configs/multi_v7_defconfig | 2 +
arch/arm/configs/shmobile_defconfig | 2 +
include/dt-bindings/clock/r8a7743-clock.h | 166 ++++
10 files changed, 1099 insertions(+)
create mode 100644 arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
create mode 100644 arch/arm/boot/dts/r8a7743-iwg20m.dtsi
create mode 100644 arch/arm/boot/dts/r8a7743.dtsi
create mode 100644 include/dt-bindings/clock/r8a7743-clock.h

--
1.9.1


How to back-port upstream BSP patches to CIP kernel

Jan Kiszka
 

Hi Ben,

after getting basically all patches for our Quark-based IOT2000 device
into upstream, I did the exercise of constructing a corresponding CIP
queue from that. The result is an almost 60 patches long series. Now I
was wondering if that is palatable for the CIP kernel and if I'm using
the right back-port approaches in all cases. Here is queue, first of all:

https://github.com/siemens/linux/commits/queues/iot2000-cip
(just ignore the "iot2000-hack" tip)

There are a number of (presumably) non-brainer patches. But then there
are also more invasive back-ports that pulled some refactorings, such as

- serial exar split-out
- support for platform device properties
- GPIO API extension (converts gpiochip_add into a static inline wrapper
around gpiochip_add_data -> module ABI change)
- the whole series of EFI capsule changes

Besides looking at the concrete case of this queue, I was wondering if
some general guidelines for back-porting changes from upstream could be
derived from that.

Thanks in advance,
Jan

PS: I can send the series, likely in chunks, in a couple of weeks, once
I had a chance to test the stuff on real hw (out of reach right now).

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


Re: B@D support Renesas iwg20m board - issue

Robert Marshall <robert.marshall@...>
 

"Binh Thanh. Nguyen" <binh.nguyen.uw@...> writes:

Hello all,

I am trying to add support healthcheck for Renesas iwg20m board into
[1]. My current healthcheck is just simply boot up the board (no
deploy and test definition).
And I still meet one issue with that booting action. The issue is
whenever I run healthcheck, It always run soft-reboot and
failed. 'reboot' command is just supported after booting board. So if
I booted the board first, then run the healthcheck, it will pass.

Anyone have advices for me?
Hi

I've seen errors on the soft reboot with the beagle bone black which go
away the next time it is run. Have you tried this more than once - does
it consistently fail?

Thanks for the patches

I've always run HC tests with the BB black on an already booted board, do
you need to do any preparation to get the health check to run in this
case?

Robert


Please find my patches to apply for [1] in attached files.

[1] https://gitlab.com/cip-project/cip-testing/board-at-desk-single-dev/

Below is the log:

start: 0 validate
device may need manual intervention to reboot validate duration: 0.00
start: 1 uboot-action (max 120s)
start: 1.1 uboot-prepare-kernel (max 120s) uboot-prepare-kernel duration: 0.00
start: 1.2 uboot-from-media (max 120s)
uboot-from-media duration: 0.00
start: 1.3 uboot-overlay (max 120s)
Parsed boot commands: setenv autoload no; setenv initrd_high
'0xffffffff'; setenv fdt_high '0xffffffff'; setenv bootargs
'console=ttySC0,115200n8 vmalloc=384M root=/dev/mmcblk0p2 '; setenv
loadkernel 'fatload mmc 2:1 0x40007fc0 uImage'; setenv loadfdt
'fatload mmc 2:1 0x40f00000 r8a7743-iwg20m.dtb'; setenv bootcmd 'run
loadkernel; run loadfdt; bootm 0x40007fc0 - 0x40f00000'; run bootcmd
uboot-overlay duration: 0.00
start: 1.4 connect-device (max 120s)
connect-device Connecting to device using 'telnet localhost 8020'
connect-device duration: 0.00
start: 1.5 uboot-retry (max 120s)
start: 1.5.1 reboot-device (max 120s)
start: 1.5.1.1 soft-reboot (max 120s)
reboot
reboot
reboot -n
reboot -n
reboot -n -f
reboot -n -f
soft-reboot: Wait for prompt Restarting system. 120 seconds Trying ::1...
Connected to localhost.
Escape character is '^]'.
ser2net port 8020 device /dev/ttyUSB0 [115200 N81] (Debian GNU/Linux)
case: soft-reboot
definition: lava
result: fail
level: 1.5.1.1
duration: 120.000326157
extra: ...
soft-reboot timed out after 120 seconds
soft-reboot timed out after 120 seconds
uboot-retry failed: 1 of 2 attempts. 'soft-reboot timed out after 120 seconds'
start: 1.5.1 reboot-device (max 120s)
start: 1.5.1.1 soft-reboot (max 120s)
...

Best regards,
Binh Nguyen




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


B@D support Renesas iwg20m board - issue

Binh Thanh. Nguyen <binh.nguyen.uw@...>
 

Hello all,

I am trying to add support healthcheck for Renesas iwg20m board into [1]. My current healthcheck is just simply boot up the board (no deploy and test definition).
And I still meet one issue with that booting action. The issue is whenever I run healthcheck, It always run soft-reboot and failed. 'reboot' command is just supported after booting board. So if I booted the board first, then run the healthcheck, it will pass.

Anyone have advices for me?

Please find my patches to apply for [1] in attached files.

[1] https://gitlab.com/cip-project/cip-testing/board-at-desk-single-dev/

Below is the log:

start: 0 validate
device may need manual intervention to reboot validate duration: 0.00
start: 1 uboot-action (max 120s)
start: 1.1 uboot-prepare-kernel (max 120s) uboot-prepare-kernel duration: 0.00
start: 1.2 uboot-from-media (max 120s)
uboot-from-media duration: 0.00
start: 1.3 uboot-overlay (max 120s)
Parsed boot commands: setenv autoload no; setenv initrd_high '0xffffffff'; setenv fdt_high '0xffffffff'; setenv bootargs 'console=ttySC0,115200n8 vmalloc=384M root=/dev/mmcblk0p2 '; setenv loadkernel 'fatload mmc 2:1 0x40007fc0 uImage'; setenv loadfdt 'fatload mmc 2:1 0x40f00000 r8a7743-iwg20m.dtb'; setenv bootcmd 'run loadkernel; run loadfdt; bootm 0x40007fc0 - 0x40f00000'; run bootcmd uboot-overlay duration: 0.00
start: 1.4 connect-device (max 120s)
connect-device Connecting to device using 'telnet localhost 8020'
connect-device duration: 0.00
start: 1.5 uboot-retry (max 120s)
start: 1.5.1 reboot-device (max 120s)
start: 1.5.1.1 soft-reboot (max 120s)
reboot
reboot
reboot -n
reboot -n
reboot -n -f
reboot -n -f
soft-reboot: Wait for prompt Restarting system. 120 seconds Trying ::1...
Connected to localhost.
Escape character is '^]'.
ser2net port 8020 device /dev/ttyUSB0 [115200 N81] (Debian GNU/Linux)
case: soft-reboot
definition: lava
result: fail
level: 1.5.1.1
duration: 120.000326157
extra: ...
soft-reboot timed out after 120 seconds
soft-reboot timed out after 120 seconds
uboot-retry failed: 1 of 2 attempts. 'soft-reboot timed out after 120 seconds'
start: 1.5.1 reboot-device (max 120s)
start: 1.5.1.1 soft-reboot (max 120s)
...

Best regards,
Binh Nguyen


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

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Chris,

-----Original Message-----
From: Chris Paterson [mailto:Chris.Paterson2@...]
Sent: Thursday, August 03, 2017 10:19 PM
To: Daniel Sangorrin; 'Agustin Benito Bethencourt'
Cc: cip-dev@...
Subject: RE: [cip-dev] Project-X (minimal root filesystem) for renesas board

Hello Daniel, all,

From: cip-dev-bounces@... [mailto:cip-dev-bounces@...
project.org] On Behalf Of Daniel Sangorrin
Sent: 07 July 2017 03:41

Hi Agustin, Chris

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

Hi,

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

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

Daniel-san,

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

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

[1] https://github.com/renesas-rz/renesas-cip
In order to have all the cip related code in one place, it would be
good, if anybody is using github, that at least there is a mirror of
that repo in gitlab. When we start automating builds/test, that would
be helpful.
Agustin: I don't mind, but is this necessary?.
Chris: Will you create another repository for u-boot?
Sorry for the delay.

u-boot source for the RZ/G1-M iWave platform is now available [1].

We've tested this using the gcc-arm-none-eabi-5_4-2016q3 [2] compiler:

export PATH=/opt/gcc-arm-none-eabi-5_4-2016q3/bin:$PATH
export CROSS_COMPILE=arm-none-eabi-
export ARCH=arm
make iwg20m_q7_config
make

The u-boot binary can be loaded onto the platform using JTAG or by writing it to the eMMC (be very careful though as this overwrites
the current u-boot, so if it goes wrong you'll need JTAG to un-brick the board). Instructions can be found in the Software User Guide
included on the CD which comes with the platform.


[1] https://github.com/renesas-rz/renesas-u-boot-cip/tree/2013.01.01/rzg1-iwave
[2] https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads

Kind regards, Chris
Thank you!

I have updated the project-x with the u-boot definitions.
I'm a bit scared of bricking the board and not being able to recover because
I probably don't have an appropriate JTAG ICE/cable. For that reason, I will
leave the flashing part for the future.

Thanks,
Daniel

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

Thanks,
Daniel

Best regards,
Takuo Koguchi



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

Ho Koguchi-san

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

Hi Daniel-san,

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

linux-cip directory is for linux-4.4.55-cip3.
linux-cip2 is for the previous release and it is not necessary if you
update linux-cip.

I think this is not a good approach. We would need to have a new
linux-cip folder for each release.

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

- I can see some xserver-related definitions on the board's
configuration file. Are those necessary?
beaglebone.conf is based on poky/meta-yocto-bsp/conf/machine.
xserver-related definition was inculude in the original. I am not sure if
it is necessary.

I don't think it is necessary since the CIP root filesystem only supports a
few packages.
Do you mind if I rewrite this and other unnecessary definitions?

Thanks,
Daniel



Takuo Koguchi


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

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

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

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

Thanks,
Daniel

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


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

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


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

Chris Paterson
 

Hello Daniel, all,

From: cip-dev-bounces@... [mailto:cip-dev-bounces@...
project.org] On Behalf Of Daniel Sangorrin
Sent: 07 July 2017 03:41

Hi Agustin, Chris

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

Hi,

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

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

Daniel-san,

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

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

[1] https://github.com/renesas-rz/renesas-cip
In order to have all the cip related code in one place, it would be
good, if anybody is using github, that at least there is a mirror of
that repo in gitlab. When we start automating builds/test, that would
be helpful.
Agustin: I don't mind, but is this necessary?.
Chris: Will you create another repository for u-boot?
Sorry for the delay.

u-boot source for the RZ/G1-M iWave platform is now available [1].

We've tested this using the gcc-arm-none-eabi-5_4-2016q3 [2] compiler:

export PATH=/opt/gcc-arm-none-eabi-5_4-2016q3/bin:$PATH
export CROSS_COMPILE=arm-none-eabi-
export ARCH=arm
make iwg20m_q7_config
make

The u-boot binary can be loaded onto the platform using JTAG or by writing it to the eMMC (be very careful though as this overwrites the current u-boot, so if it goes wrong you'll need JTAG to un-brick the board). Instructions can be found in the Software User Guide included on the CD which comes with the platform.


[1] https://github.com/renesas-rz/renesas-u-boot-cip/tree/2013.01.01/rzg1-iwave
[2] https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads

Kind regards, Chris


Thanks,
Daniel





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

Thanks,
Daniel

Best regards,
Takuo Koguchi



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

Ho Koguchi-san

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

Hi Daniel-san,

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

linux-cip directory is for linux-4.4.55-cip3.
linux-cip2 is for the previous release and it is not necessary if you
update linux-cip.

I think this is not a good approach. We would need to have a new
linux-cip folder for each release.

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

- I can see some xserver-related definitions on the board's
configuration file. Are those necessary?
beaglebone.conf is based on poky/meta-yocto-bsp/conf/machine.
xserver-related definition was inculude in the original. I am not sure if
it is necessary.

I don't think it is necessary since the CIP root filesystem only supports a
few packages.
Do you mind if I rewrite this and other unnecessary definitions?

Thanks,
Daniel



Takuo Koguchi


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

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

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

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

Thanks,
Daniel

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


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

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


Re: CIP testing project. Action 2. Data flow diagram draft

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

Hi,

On 03/08/17 01:49, Daniel Sangorrin wrote:
Hi Agustín,

-----Original Message-----
From: cip-dev-bounces@... [mailto:cip-dev-bounces@...] On Behalf Of Agustin Benito Bethencourt
Sent: Thursday, August 03, 2017 12:23 AM
To: cip-dev@...
Subject: [cip-dev] CIP testing project. Action 2. Data flow diagram draft

Hi,

please find attached an initial version of the data flow chart of the
testing project using B@D. This is a high level view (level 0).
Looks good. Maybe the test maintainer also wants to check the test results.
I first had the maintainers (kernel and tests) both checking the results but I changed it to focus on the testing data flow only, not on the maintainers/maintenance data flow. It is arguable though.


I will try in the coming days to go down one level to provide more
detail. Hopefully I will be able to improve the look and field too. Any
designer around ? :-)
The colours are a bit dull, I suggest increasing the saturation.
I think the diagram is too colourful, too bright, it has too much contrast. In coming versions I will try to improve it.



Any feedback is welcome.
Thanks for the comments


You can find info about data flow diagrams in these links:
* Examples:
https://www.visual-paradigm.com/tutorials/data-flow-diagram-example-food-ordering-system.jsp
* Symbols:
https://www.lucidchart.com/pages/data-flow-diagram/data-flow-diagram-symbols
* Definition: https://en.wikipedia.org/wiki/Data_flow_diagram

Saludos
Saludos ;)
Daniel

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

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


Re: CIP testing project. Action 2. Data flow diagram draft

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Agustín,

-----Original Message-----
From: cip-dev-bounces@... [mailto:cip-dev-bounces@...] On Behalf Of Agustin Benito Bethencourt
Sent: Thursday, August 03, 2017 12:23 AM
To: cip-dev@...
Subject: [cip-dev] CIP testing project. Action 2. Data flow diagram draft

Hi,

please find attached an initial version of the data flow chart of the
testing project using B@D. This is a high level view (level 0).
Looks good. Maybe the test maintainer also wants to check the test results.

I will try in the coming days to go down one level to provide more
detail. Hopefully I will be able to improve the look and field too. Any
designer around ? :-)
The colours are a bit dull, I suggest increasing the saturation.


Any feedback is welcome.

You can find info about data flow diagrams in these links:
* Examples:
https://www.visual-paradigm.com/tutorials/data-flow-diagram-example-food-ordering-system.jsp
* Symbols:
https://www.lucidchart.com/pages/data-flow-diagram/data-flow-diagram-symbols
* Definition: https://en.wikipedia.org/wiki/Data_flow_diagram

Saludos
Saludos ;)
Daniel

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


CIP testing project. Action 2. Data flow diagram draft

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

Hi,

please find attached an initial version of the data flow chart of the testing project using B@D. This is a high level view (level 0).

I will try in the coming days to go down one level to provide more detail. Hopefully I will be able to improve the look and field too. Any designer around ? :-)

Any feedback is welcome.

You can find info about data flow diagrams in these links:
* Examples: https://www.visual-paradigm.com/tutorials/data-flow-diagram-example-food-ordering-system.jsp
* Symbols: https://www.lucidchart.com/pages/data-flow-diagram/data-flow-diagram-symbols
* Definition: https://en.wikipedia.org/wiki/Data_flow_diagram

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


Re: Kernel maintenance and CIP testing report weeks 28, 29 and 30

Robert Marshall <robert.marshall@...>
 

Hi, some comments on the individual issues below.

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

Dear CIP friends,

this is the report of the major actions related with those activities
led by Codethink Ltd. Some of the reported topics were already
communicated through this mailing list.

++ Kernel maintenance

1. Backported of the basic support for the Renesas board (family) has
been merged.

2. The first round of kernel features review has been provided. Some
feedback is still pending. Ben H. participated in the CIP TSC
bi-weekly call.

3. Now we need to define the next steps in the kernel maintenance front.

4. As usual, Ben H. is contributing to the upstream 4.4 LTS cycle.

++ CIP Testing

1. E-mail configuration in LAVA is done. Robert Marshall is publishing
the outcome of the basic health checks in the cip-testing-results
mailing list. Feel free to join:
https://lists.cip-project.org/mailman/listinfo/cip-testing-results The
documentation for CIP members to send reports through mail is work in
progress. https://gitlab.com/cip-project/cip-testing/testing/issues/102
Some documentation has been added to the wiki detailing how to set this up
I'll be adding more information there.


2. B@D now works on a W10 machine with little additional
configurations. Both, Windows and Linux users share the same
installations and configuration steps except when specifically
mentioned. Waiting to receive feedback from
Members. https://gitlab.com/cip-project/cip-testing/testing/issues/106

3. A change in git://git.linaro.org/qa/test-definitions.git had a
major impact in B@D. It has been fixed
now. https://gitlab.com/cip-project/cip-testing/testing/issues/116

4. There is progress in using B@D behind a web
proxy. https://gitlab.com/cip-project/cip-testing/testing/issues/99

5. Robert has started the trials to update the LAVA version shipped
with B@D. It includes several fixed to issues we are facing plus
several improvements we will need in the near
future. https://gitlab.com/cip-project/cip-testing/testing/issues/114
I have a provisioned box with the latest version of lava - however there
are problems with authentication that I'm currently investigating.

Once that is working I expect to look at how to attach health check
results to LAVA notifications
https://gitlab.com/cip-project/cip-testing/testing/issues/118

and then consider the issues involved in allowing users who are not the
original tester to import those results into their own B@D instance.

We will also need to investigate how tests and be signed and how LAVA
will verify those signatures.


Robert


6. Other topics

* Some weeks ago we reported to the LAVA team an issue that has
already been fixed upstream. Another good reason for updating
LAVA. https://gitlab.com/cip-project/cip-testing/testing/issues/84

* Several issues has been fixed like tickets #112, #92

* As reported, new repositories has been created and
populated. https://gitlab.com/cip-project/cip-testing/testing/issues/100
** We are starting to populate CIP-kernel-test-logs repository as a
first step towards publishing the "passed test" logs in a public repo
in order to compare the logs from tests done by other Members.

* There is no room for celebrating the CIP workshop at ELCE during the
even. We will need to include it the previous day, right after the CIP
TSC f2f meeting.

* At least Agustin B.B. and Ben H. will attend to ELCE.


Kernel maintenance and CIP testing report weeks 28, 29 and 30

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

Dear CIP friends,

this is the report of the major actions related with those activities led by Codethink Ltd. Some of the reported topics were already communicated through this mailing list.

++ Kernel maintenance

1. Backported of the basic support for the Renesas board (family) has been merged.

2. The first round of kernel features review has been provided. Some feedback is still pending. Ben H. participated in the CIP TSC bi-weekly call.

3. Now we need to define the next steps in the kernel maintenance front.

4. As usual, Ben H. is contributing to the upstream 4.4 LTS cycle.

++ CIP Testing

1. E-mail configuration in LAVA is done. Robert Marshall is publishing the outcome of the basic health checks in the cip-testing-results mailing list. Feel free to join: https://lists.cip-project.org/mailman/listinfo/cip-testing-results The documentation for CIP members to send reports through mail is work in progress. https://gitlab.com/cip-project/cip-testing/testing/issues/102

2. B@D now works on a W10 machine with little additional configurations. Both, Windows and Linux users share the same installations and configuration steps except when specifically mentioned. Waiting to receive feedback from Members. https://gitlab.com/cip-project/cip-testing/testing/issues/106

3. A change in git://git.linaro.org/qa/test-definitions.git had a major impact in B@D. It has been fixed now. https://gitlab.com/cip-project/cip-testing/testing/issues/116

4. There is progress in using B@D behind a web proxy. https://gitlab.com/cip-project/cip-testing/testing/issues/99

5. Robert has started the trials to update the LAVA version shipped with B@D. It includes several fixed to issues we are facing plus several improvements we will need in the near future. https://gitlab.com/cip-project/cip-testing/testing/issues/114

6. Other topics

* Some weeks ago we reported to the LAVA team an issue that has already been fixed upstream. Another good reason for updating LAVA. https://gitlab.com/cip-project/cip-testing/testing/issues/84

* Several issues has been fixed like tickets #112, #92

* As reported, new repositories has been created and populated. https://gitlab.com/cip-project/cip-testing/testing/issues/100
** We are starting to populate CIP-kernel-test-logs repository as a first step towards publishing the "passed test" logs in a public repo in order to compare the logs from tests done by other Members.

* There is no room for celebrating the CIP workshop at ELCE during the even. We will need to include it the previous day, right after the CIP TSC f2f meeting.

* At least Agustin B.B. and Ben H. will attend to ELCE.

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


Re: Kernel feature support - core features and debugging

Hidehiro Kawai
 

Hi Ben,

Thanks for the consideration and suggestion.

From: Ben Hutchings
Performance events (CONFIG_PERF_EVENTS) provide a significant attack
surface and generally allow unprivileged users to crash the system. If
you do need them enabled in production - which I can understand - you
might want to apply the Grsecurity/Debian/Android patch that disables
use by unprivileged users.
Is it difficult to support for super long term? I think it is up to
users to enable it or not.

User namespaces (CONFIG_USER_NS) open up a huge attack surface to
unprivileged users, which has resulted in a large number of privilege
escalation vulnerabilities. This is enabled in the plathome_obsvx1,
siemens_iot2000 and siemens_server configs. Do you need it?
I'm not sure how vulnerable it is, but I think we may want to adopt the
same approach with the CONFIG_PERF_EVENTS case.
https://github.com/copperhead/linux-hardened/commit/358b303ebdc0b4a74b66a41ddfd2a69322d5404a.patch

Best regards,

Hidehiro Kawai
Hitachi, Ltd. Research & Development Group


Re: Kernel feature support - architecture options and drivers

Hidehiro Kawai
 

Hello Ben,

I'm sorry for the late reply.

From: Behalf Of Ben Hutchings
nouveau (CONFIG_DRM_NOUVEAU) is enabled in the hitachi_omap config. I'm
not sure how this could be useful in an OMAP system, and I don't expect
the driver to be supportable. Please disable it.
e100 (CONFIG_E100) and e1000 (CONFIG_E1000) drivers are enabled in
several configs (hitachi_omap, plathome_obsvx1, siemens_server) but are
not maintained upstream. (Don't confuse e1000 with e1000e, which is for
PCI Express and is still maintained.) Please disable them.
These drivers are not used. We'll simply disable them.

USB-attached network drivers (CONFIG_USB_USBNET) are enabled in several
configs (hitachi_omap, toshiba_tegra, plathome_obsvx1) but few of them
seem to be properly maintained upstream. Do you need them?
It is used as a convenient network interface for engineering.
If it is difficult to support them for super long term, we don't mind
too much even if CIP doesn't support them.

KVM (CONFIG_VIRTUALIZATION) adds a large attack surface (guest-to-host)
and is likely to be hard to maintain in the long term. Several of the
configurations (hitachi_omap, plathome_obsvx1, siemens_iot2000,
siemens_server) enable this. Do you need it?
It is not used at this point, but may be need in the future.

As long as we don't use KVM to build up a multi tenant VM service,
i.e. all users are the same legitimate user, the security risk of
guest-to-host attack will not become higher. So with regard to the
security risk, it will not be a problem for some use cases.

/dev/kmem (CONFIG_DEVKMEM) is only rarely needed for kernel debugging,
but is enabled in many configs. Please disable it.

/dev/mem (CONFIG_DEVMEM) is needed by some userland drivers, though UIO
provides a cleaner way to do this. Please check whether you can disable
it.
I tried to grep executable files in /usr/{bin,sbin}, and I found multiple
commands which may access /dev/mem. But I'm not sure how much impact
disabling /dev/mem has on us. We also use /dev/mem for a user land
driver, but we will be able to reimplement it via UIO.


By the way, I think that `supporting a feature' is not the same as
`enabling a feature'. Does `please disable it' mean that this is a
suggestion for a secure config, or imply that CIP shouldn't support
this feature?

Best regards,

Hidehiro Kawai
Hitachi, Ltd. Research & Development Group


Re: change to the git://git.linaro.org/qa/test-definitions.git repos breaks the BBB health check

Robert Marshall <robert.marshall@...>
 

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

Hi,

A change yesterday to the git://git.linaro.org/qa/test-definitions.git
repos, removing obsolete directories, has removed the ubuntu one that the
b@d BBB health check used so that the default beaglebone health check will
now fail. We're working on a fix!
The repos versions of the beaglebone black tests have been updated with
a valid test. If you have an already provisioned box you will need to
manually change the tests/bbb* files with this diff:


from: git
- path: ubuntu/smoke-tests-basic.yaml
+ path: common/dt-selftests.yaml
name: smoke-tests


Robert


change to the git://git.linaro.org/qa/test-definitions.git repos breaks the BBB health check

Robert Marshall <robert.marshall@...>
 

Hi,

A change yesterday to the git://git.linaro.org/qa/test-definitions.git
repos, removing obsolete directories, has removed the ubuntu one that the
b@d BBB health check used so that the default beaglebone health check will
now fail. We're working on a fix!

Robert

9281 - 9300 of 9694