Date   

[PATCH 4.19.y-cip 02/12] dt-bindings: can: rcar_can: Complete documentation for RZ/G2[EM]

Lad Prabhakar
 

From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>

commit 8cb7ec14188649cf2151464050413e2814fd7cf1 upstream.

Add missing RZ/G2[EM] CANFD clock specific documentation.

Fixes: 868b7c0f43e61f22 ("dt-bindings: can: rcar_can: Add r8a774a1 support")
Fixes: d703a52eb1ebeeba ("dt-bindings: can: rcar_can: Add r8a774c0 support")
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
[fab: discarded reference to r8a77965 while backporting to v4.19.y-cip]
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
Documentation/devicetree/bindings/net/can/rcar_can.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
index 2301331..aede950 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
@@ -31,7 +31,7 @@ Required properties:
- pinctrl-0: pin control group to be used for this controller.
- pinctrl-names: must be "default".

-Required properties for R8A7795 and R8A7796:
+Required properties for R8A774A1, R8A774C0, R8A7795, and R8A7796:
For the denoted SoCs, "clkp2" can be CANFD clock. This is a div6 clock and can
be used by both CAN and CAN FD controller at the same time. It needs to be
scaled to maximum frequency if any of these controllers use it. This is done
--
2.7.4


[PATCH 4.19.y-cip 01/12] dt-bindings: can: rcar_can: document r8a77965 support

Lad Prabhakar
 

From: Eugeniu Rosca <rosca.eugeniu@gmail.com>

commit 4f145f14f6b98b5aa0dd91bdae518b3f24f74b37 upstream.

Document the support for rcar_can on R8A77965 SoC devices.
Add R8A77965 to the list of SoCs which require the "assigned-clocks" and
"assigned-clock-rates" properties (thanks, Sergei).

Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
[fab: discarded r8a77965 specfic support]
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
Documentation/devicetree/bindings/net/can/rcar_can.txt | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
index e1d428a..2301331 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
@@ -31,11 +31,10 @@ Required properties:
- pinctrl-0: pin control group to be used for this controller.
- pinctrl-names: must be "default".

-Required properties for "renesas,can-r8a7795" and "renesas,can-r8a7796"
-compatible:
-In R8A7795 and R8A7796 SoCs, "clkp2" can be CANFD clock. This is a div6 clock
-and can be used by both CAN and CAN FD controller at the same time. It needs to
-be scaled to maximum frequency if any of these controllers use it. This is done
+Required properties for R8A7795 and R8A7796:
+For the denoted SoCs, "clkp2" can be CANFD clock. This is a div6 clock and can
+be used by both CAN and CAN FD controller at the same time. It needs to be
+scaled to maximum frequency if any of these controllers use it. This is done
using the below properties:

- assigned-clocks: phandle of clkp2(CANFD) clock.
--
2.7.4


[PATCH 4.19.y-cip 00/12] Renesas RZ/G2E backport IPA support along with minor fixes

Lad Prabhakar
 

This patch series intends to do the following:
1: Add IPA support
2: Update the CAN bindings
3: Fix display node range
4: Minor tweaks for sorting the nodes
5: Use any protocol available in kernel for ip instead of dhcp
6: Cleanup CPU compatibles

This patch series is based on linux-4.19.y-cip and all the patches in this
series are cherry-picked from upstream.

Biju Das (2):
arm64: dts: renesas: r8a774c0: Create thermal zone to support IPA
arm64: dts: renesas: r8a774c0: Add dynamic power coefficient

Eugeniu Rosca (1):
dt-bindings: can: rcar_can: document r8a77965 support

Fabrizio Castro (3):
dt-bindings: can: rcar_can: Complete documentation for RZ/G2[EM]
arm64: dts: renesas: r8a774c0: Add missing assigned-clocks for CAN[01]
arm64: dts: renesas: r8a774c0: cat874: Add definition for 12V
regulator

Geert Uytterhoeven (1):
arm64: dts: renesas: r8a774c0: Fix register range of display node

Jacopo Mondi (1):
arm64: dts: renesas: Update 'vsps' properties for readability

Magnus Damm (1):
arm64: dts: renesas: Use ip=on for bootargs

Robin Murphy (1):
arm64: dts: renesas: r8a774c0: Clean up CPU compatibles

Yoshihiro Kaneko (2):
thermal: rcar_thermal: update calculation formula for R-Car Gen3 SoCs
arm64: dts: renesas: r8a774c0: cat874: Sort nodes

.../devicetree/bindings/net/can/rcar_can.txt | 9 +++--
arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts | 39 +++++++++++++---------
arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 36 +++++++++++++++-----
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 +-
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 2 +-
arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 2 +-
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 2 +-
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 2 +-
drivers/thermal/rcar_thermal.c | 11 +++++-
9 files changed, 70 insertions(+), 35 deletions(-)

--
2.7.4


Re: RT Testing

Pavel Machek
 

Hi!

Addressing this email to all of you as both RT and CIP Core are involved.

I started to look into RT testing in more detail today.

I've created an RT configuration for the RZ/G1 boards:
https://gitlab.com/patersonc/cip-kernel-config/blob/chris/add_renesas_rt_configs/4.4.y-cip-rt/arm/renesas_shmobile-rt_defconfig
I'll do something similar for the RZ/G2 boards soon.

Built it with linux-4.4.y-cip-rt and run cyclic test:
https://lava.ciplatform.org/scheduler/job/9828
Times look okay to an rt-untrained eye:
T: 0 ( 1169) P:98 I:1000 C: 59993 Min: 13 Act: 16 Avg: 16 Max: 33

Compared to a run with linux-4.4.y-cip:
https://lava.ciplatform.org/scheduler/job/9829
T: 0 ( 938) P:98 I:1000 C: 6000 Min: 1618 Act: 9604 Avg: 9603 Max: 14550

Pavel, does the above look okay/useful to you? Or is cyclictest not worth running unless there is some load on the system?
Even basic cyclictest is good to have, but it would be really good to
have some kind of background load. I'd expect latency to raise by
factor of 3 in make -j 5 of kernel.

I tried to come up with simpler test reproducing comparable latencies,
but I did not get there. This creates cca factor of two for me:

cat /dev/urandom | head -c 10000000 | gzip -9 - > delme.random.gz
echo "Initial phase done"
for A in `seq 222`; do
( zcat delme.random.gz | gzip -9 - | zcat > /dev/null; echo -n [$A done] ) &
done

What is easily available on the test systems? gzip? python? bzip2?

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: RT Testing

Chris Paterson
 

Hello Daniel,

From: Daniel Wagner <wagi@monom.org>
Sent: 16 January 2020 09:25

Hi Chris,

On Tue, Jan 14, 2020 at 05:01:54PM +0000, Chris Paterson wrote:
Hello Pavel, Hayashi-san, Jan, Daniel,

Addressing this email to all of you as both RT and CIP Core are involved.

I started to look into RT testing in more detail today.
Welcome on board :)

I've created an RT configuration for the RZ/G1 boards:
https://gitlab.com/patersonc/cip-kernel-
config/blob/chris/add_renesas_rt_configs/4.4.y-cip-rt/arm/renesas_shmobile-
rt_defconfig
I'll do something similar for the RZ/G2 boards soon.
I am using merge_config.sh to build the configuration. There are some
catches but generally it works good. I've hacked a small tool for
automization around it. With this the configuration is allways
generated from scratch using kconfig.
Not a bad idea. I'll give it a go. Do you have an 'RT' config fragment you can share?
I guess it depends on what approach the Kernel maintainers would rather take.

Maintainers: Do we want dedicated RT configurations for CIP? Or just try and apply RT to all configurations (or a sub-selection) in cip-kernel-configs?


Built it with linux-4.4.y-cip-rt and run cyclic test:
https://lava.ciplatform.org/scheduler/job/9828
Times look okay to an rt-untrained eye:
T: 0 ( 1169) P:98 I:1000 C: 59993 Min: 13 Act: 16 Avg: 16 Max: 33

Compared to a run with linux-4.4.y-cip:
https://lava.ciplatform.org/scheduler/job/9829
T: 0 ( 938) P:98 I:1000 C: 6000 Min: 1618 Act: 9604 Avg: 9603 Max: 14550

Pavel, does the above look okay/useful to you? Or is cyclictest not worth
running unless there is some load on the system?

Without load, it's not that interesting.

Currently there is an issue with the way that the cyclic test case
results are shown (i.e. they aren't) in LAVA due to a change [0]
made to Linaro's cyclictest.sh.
My current test suite for LAVA contains these here:

rt_suites = ['0_jd-hackbench',
'0_jd-compile',
'0_jd-stress_ptrace',
'0_cyclicdeadline',
'0_cyclictest',
'0_pi-stress',
'0_pmqtest',
'0_ptsematest',
'0_rt-migrate-test',
'0_signaltest',
'0_sigwaittest',
'0_svsematest']


That means that the test parsing now depends on Python, which isn't included
in the cip-core RFS [1] that is currently being used.

Sorry about that. I am changed this so that the test are marked failed
if a value is seen higher as the maximum. Again, I am using my hack
script to read out the results from the test and use coloring for it:

$ srt-build c2d jobs result
0_jd-hackbench t1-max-latency : pass 11.00
0_jd-hackbench t1-avg-latency : pass 2.37
0_jd-hackbench t1-min-latency : pass 1.00
0_jd-hackbench t0-max-latency : pass 10.00
0_jd-hackbench t0-avg-latency : pass 2.31
0_jd-hackbench t0-min-latency : pass 1.00
0_jd-compile t1-max-latency : pass 14.00
0_jd-compile t1-avg-latency : pass 3.37
0_jd-compile t1-min-latency : pass 1.00
0_jd-compile t0-max-latency : pass 14.00
0_jd-compile t0-avg-latency : pass 3.37
0_jd-compile t0-min-latency : pass 1.00
0_jd-stress_ptrace t1-max-latency : pass 7.00
0_jd-stress_ptrace t1-avg-latency : pass 2.19
0_jd-stress_ptrace t1-min-latency : pass 2.00
0_jd-stress_ptrace t0-max-latency : pass 9.00
0_jd-stress_ptrace t0-avg-latency : pass 2.22
0_jd-stress_ptrace t0-min-latency : pass 2.00
0_cyclicdeadline t1-max-latency : fail 3462.00
0_cyclicdeadline t1-avg-latency : pass 1594.00
0_cyclicdeadline t1-min-latency : pass 1.00
0_cyclicdeadline t0-max-latency : fail 3470.00
0_cyclicdeadline t0-avg-latency : pass 1602.00
0_cyclicdeadline t0-min-latency : pass 8.00
0_cyclictest t1-max-latency : pass 11.00
0_cyclictest t1-avg-latency : pass 2.00
0_cyclictest t1-min-latency : pass 1.00
0_cyclictest t0-max-latency : pass 13.00
0_cyclictest t0-avg-latency : pass 3.00
0_cyclictest t0-min-latency : pass 1.00
0_pi-stress pi-stress : pass 0.00
0_pmqtest t3-2-max-latency : pass 13.00
0_pmqtest t3-2-avg-latency : pass 4.00
0_pmqtest t3-2-min-latency : pass 2.00
0_pmqtest t1-0-max-latency : pass 23.00
0_pmqtest t1-0-avg-latency : pass 4.00
0_pmqtest t1-0-min-latency : pass 2.00
0_ptsematest t3-2-max-latency : pass 11.00
0_ptsematest t3-2-avg-latency : pass 3.00
0_ptsematest t3-2-min-latency : pass 2.00
0_ptsematest t1-0-max-latency : pass 14.00
0_ptsematest t1-0-avg-latency : pass 3.00
0_ptsematest t1-0-min-latency : pass 2.00
0_rt-migrate-test t2-p98-avg : pass 11.00
0_rt-migrate-test t2-p98-tot : pass 581.00
0_rt-migrate-test t2-p98-min : pass 9.00
0_rt-migrate-test t2-p98-max : pass 28.00
0_rt-migrate-test t1-p97-avg : pass 13.00
0_rt-migrate-test t1-p97-tot : pass 654.00
0_rt-migrate-test t1-p97-min : pass 8.00
0_rt-migrate-test t1-p97-max : pass 34.00
0_rt-migrate-test t0-p96-avg : pass 19213.00
0_rt-migrate-test t0-p96-tot : pass 960652.00
0_rt-migrate-test t0-p96-min : pass 13.00
0_rt-migrate-test t0-p96-max : pass 20031.00
0_signaltest t0-max-latency : pass 29.00
0_signaltest t0-avg-latency : pass 8.00
0_signaltest t0-min-latency : pass 4.00
0_sigwaittest t3-2-max-latency : pass 16.00
0_sigwaittest t3-2-avg-latency : pass 4.00
0_sigwaittest t3-2-min-latency : pass 2.00
0_sigwaittest t1-0-max-latency : pass 24.00
0_sigwaittest t1-0-avg-latency : pass 4.00
0_sigwaittest t1-0-min-latency : pass 2.00
0_svsematest t3-2-max-latency : pass 13.00
0_svsematest t3-2-avg-latency : pass 4.00
0_svsematest t3-2-min-latency : pass 2.00
0_svsematest t1-0-max-latency : pass 13.00
0_svsematest t1-0-avg-latency : pass 4.00
0_svsematest t1-0-min-latency : pass 2.00
0_smoke-tests linux-posix-lsb_release: pass
0_smoke-tests linux-posix-lscpu : pass
0_smoke-tests linux-posix-ifconfig: pass
0_smoke-tests linux-posix-vmstat : pass
0_smoke-tests linux-posix-uname : pass
0_smoke-tests linux-posix-pwd : pass
0_smoke-tests linux-posix-lsb_release: pass
0_smoke-tests linux-posix-lscpu : pass
0_smoke-tests linux-posix-ifconfig: pass
0_smoke-tests linux-posix-vmstat : pass
0_smoke-tests linux-posix-uname : pass
0_smoke-tests linux-posix-pwd : pass
0_smoke-tests linux-posix-lsb_release: pass
0_smoke-tests linux-posix-lscpu : pass
0_smoke-tests linux-posix-ifconfig: pass
0_smoke-tests linux-posix-vmstat : pass
0_smoke-tests linux-posix-uname : pass
0_smoke-tests linux-posix-pwd : pass
0_smoke-tests linux-posix-lsb_release: pass
0_smoke-tests linux-posix-lscpu : pass
0_smoke-tests linux-posix-ifconfig: pass
0_smoke-tests linux-posix-vmstat : pass
0_smoke-tests linux-posix-uname : pass
0_smoke-tests linux-posix-pwd : pass


Trying to figure out from the web interface of LAVA is a bit
combersome.

Do either of the CIP Core profiles include Python support?

Linaro test-definitions [2] have the following tests marked within the preempt-
rt scope:
cyclicdeadline/cyclicdeadline.yaml
pmqtest/pmqtest.yaml
rt-migrate-test/rt-migrate-test.yaml
cyclictest/cyclictest.yaml
svsematest/svsematest.yaml
pi-stress/pi-stress.yaml
signaltest/signaltest.yaml
ptsematest/ptsematest.yaml
sigwaittest/sigwaittest.yaml
hackbench/hackbench.yaml
ltp-realtime/ltp-realtime.yaml
See above.

Which of the above would be valuable to run on CIP RT Kernels?
Basically you want to run all of the tests in rt-tests.
Does the RT project currently do (or have plans to do) the same?
https://ci-rt.linutronix.de/RT-Test/ seems to indicate that only cyclictest is run (with and without hackbench).


A while back Daniel Wagner also did some work on a Jitterdebugger
test [3], but it hasn't been merged yet and I'm not sure what the
current status is. Any updates Daniel?
Yeah, I was holding a bit back until I am happy with my setup and
workflow. One of the major limitations with the current
test-definitions is the difficulties to setup background workload. To
make it short, I am not too happy with my current version but it
works.
Okay.


Is anyone able to provide RT config/defconfigs for the x86 and arm
boards in the Mentor lab? Or BBB, QEMU etc.? (assuming that the
hardware is suitable).
If you are interested in my configs I have configs for ARMv7 (bbb),
ARMv8 (RPi3) and x86_64 via my hacktool. It also builds the kernel
because I didn't setup kernelci for it, so in short I get a complete
config, build, test setup via 'srt-build bbb lava'
Maybe just the 'RT' config fragment will be enough.

Thanks, Chris


Thanks,
Daniel


Re: RT Testing

Kazuhiro Hayashi
 

Hello Daniel,

Hi,

On Thu, Jan 16, 2020 at 06:54:54AM +0000,
kazuhiro3.hayashi@toshiba.co.jp wrote:
BTW, it would be better to confirm which Python version (2.7 or 3) that cyclictest.sh depends on.
Do you know anything about this?
cyclictest.sh uses automated/lib/parse_rt_tests_results.py to parse
the results. The python code runs with either Python2 or Python3

$ python3 -m py_compile ./automated/lib/parse_rt_tests_results.py
$ python2 -m py_compile ./automated/lib/parse_rt_tests_results.py
Thank you for the information.
Relieved to know that no dependency on specific python version :)

Thanks,
Kazu


Thanks,
Daniel


Re: RT Testing

Chris Paterson
 

Hello,

From: kazuhiro3.hayashi@toshiba.co.jp <kazuhiro3.hayashi@toshiba.co.jp>
Sent: 16 January 2020 06:55

Hello Chris,

Thank you for your updates!

Hello Pavel, Hayashi-san, Jan, Daniel,
[...]

Currently there is an issue with the way that the cyclic test case results are
shown (i.e. they aren't) in LAVA due to
a change [0] made to Linaro's cyclictest.sh.
That means that the test parsing now depends on Python, which isn't included
in the cip-core RFS [1] that is currently
being used.

Do either of the CIP Core profiles include Python support?
At the moment, we've just started creating the supported package list, so I
cannot clearly say Yes.
However, at least, the both profiles can create an image including python only
for testing
because the python packages are already provided in upstream projects (isar,
meta-debian).
Okay. I'm thinking that we aren't going to be able to escape having a separate 'testing' version of CIP-Core, based on ISAR on the assumption that it has more supported packages then Deby.

Or not use CIP-Core for testing the Kernel as punit suggested ??


Whether CIP Core provides Python packages or not depends on
what kind of packages will be proposed (requested) by CIP WGs in future.
Currently, several packages which depend on Python packages would be
included in the next proposal from security WG (under review now).

BTW, it would be better to confirm which Python version (2.7 or 3) that
cyclictest.sh depends on.
Do you know anything about this?
Either version (thanks Daniel).

Presumably we'd want to target Python 3 though if that's what the world is moving to?

Kind regards, Chris


Kazu


Linaro test-definitions [2] have the following tests marked within the preempt-
rt scope:
cyclicdeadline/cyclicdeadline.yaml
pmqtest/pmqtest.yaml
rt-migrate-test/rt-migrate-test.yaml
cyclictest/cyclictest.yaml
svsematest/svsematest.yaml
pi-stress/pi-stress.yaml
signaltest/signaltest.yaml
ptsematest/ptsematest.yaml
sigwaittest/sigwaittest.yaml
hackbench/hackbench.yaml
ltp-realtime/ltp-realtime.yaml

Which of the above would be valuable to run on CIP RT Kernels?

A while back Daniel Wagner also did some work on a Jitterdebugger test [3],
but it hasn't been merged yet and I'm not
sure what the current status is. Any updates Daniel?

Is anyone able to provide RT config/defconfigs for the x86 and arm boards in
the Mentor lab? Or BBB, QEMU etc.? (assuming
that the hardware is suitable).


[0]
https://github.com/Linaro/test-
definitions/commit/4b5c46f275632932b3045f2ee16ad9cae5bb482d#diff-
c724b852b75aefda2cc3
505c4517828dR50
[1] https://s3-us-west-2.amazonaws.com/download.cip-project.org/cip-
core/iwg20m/core-image-minimal-iwg20m.tar.gz
[2] https://github.com/Linaro/test-definitions/blob/master/automated/linux
[3] https://github.com/igaw/test-definitions/blob/preempt-
rt/automated/linux/jitterdebugger/jitterdebugger.yaml

Kind regards, Chris


Re: RT Testing

Daniel Wagner <wagi@...>
 

Hi Chris,

On Tue, Jan 14, 2020 at 05:01:54PM +0000, Chris Paterson wrote:
Hello Pavel, Hayashi-san, Jan, Daniel,
Addressing this email to all of you as both RT and CIP Core are involved.
I started to look into RT testing in more detail today.
Welcome on board :)

I've created an RT configuration for the RZ/G1 boards:
https://gitlab.com/patersonc/cip-kernel-config/blob/chris/add_renesas_rt_configs/4.4.y-cip-rt/arm/renesas_shmobile-rt_defconfig
I'll do something similar for the RZ/G2 boards soon.
I am using merge_config.sh to build the configuration. There are some
catches but generally it works good. I've hacked a small tool for
automization around it. With this the configuration is allways
generated from scratch using kconfig.

Built it with linux-4.4.y-cip-rt and run cyclic test:
https://lava.ciplatform.org/scheduler/job/9828
Times look okay to an rt-untrained eye:
T: 0 ( 1169) P:98 I:1000 C: 59993 Min: 13 Act: 16 Avg: 16 Max: 33
Compared to a run with linux-4.4.y-cip:
https://lava.ciplatform.org/scheduler/job/9829
T: 0 ( 938) P:98 I:1000 C: 6000 Min: 1618 Act: 9604 Avg: 9603 Max: 14550
Pavel, does the above look okay/useful to you? Or is cyclictest not worth running unless there is some load on the system?
Without load, it's not that interesting.

Currently there is an issue with the way that the cyclic test case
results are shown (i.e. they aren't) in LAVA due to a change [0]
made to Linaro's cyclictest.sh.
My current test suite for LAVA contains these here:

rt_suites = ['0_jd-hackbench',
'0_jd-compile',
'0_jd-stress_ptrace',
'0_cyclicdeadline',
'0_cyclictest',
'0_pi-stress',
'0_pmqtest',
'0_ptsematest',
'0_rt-migrate-test',
'0_signaltest',
'0_sigwaittest',
'0_svsematest']


That means that the test parsing now depends on Python, which isn't included in the cip-core RFS [1] that is currently being used.
Sorry about that. I am changed this so that the test are marked failed
if a value is seen higher as the maximum. Again, I am using my hack
script to read out the results from the test and use coloring for it:

$ srt-build c2d jobs result
0_jd-hackbench t1-max-latency : pass 11.00
0_jd-hackbench t1-avg-latency : pass 2.37
0_jd-hackbench t1-min-latency : pass 1.00
0_jd-hackbench t0-max-latency : pass 10.00
0_jd-hackbench t0-avg-latency : pass 2.31
0_jd-hackbench t0-min-latency : pass 1.00
0_jd-compile t1-max-latency : pass 14.00
0_jd-compile t1-avg-latency : pass 3.37
0_jd-compile t1-min-latency : pass 1.00
0_jd-compile t0-max-latency : pass 14.00
0_jd-compile t0-avg-latency : pass 3.37
0_jd-compile t0-min-latency : pass 1.00
0_jd-stress_ptrace t1-max-latency : pass 7.00
0_jd-stress_ptrace t1-avg-latency : pass 2.19
0_jd-stress_ptrace t1-min-latency : pass 2.00
0_jd-stress_ptrace t0-max-latency : pass 9.00
0_jd-stress_ptrace t0-avg-latency : pass 2.22
0_jd-stress_ptrace t0-min-latency : pass 2.00
0_cyclicdeadline t1-max-latency : fail 3462.00
0_cyclicdeadline t1-avg-latency : pass 1594.00
0_cyclicdeadline t1-min-latency : pass 1.00
0_cyclicdeadline t0-max-latency : fail 3470.00
0_cyclicdeadline t0-avg-latency : pass 1602.00
0_cyclicdeadline t0-min-latency : pass 8.00
0_cyclictest t1-max-latency : pass 11.00
0_cyclictest t1-avg-latency : pass 2.00
0_cyclictest t1-min-latency : pass 1.00
0_cyclictest t0-max-latency : pass 13.00
0_cyclictest t0-avg-latency : pass 3.00
0_cyclictest t0-min-latency : pass 1.00
0_pi-stress pi-stress : pass 0.00
0_pmqtest t3-2-max-latency : pass 13.00
0_pmqtest t3-2-avg-latency : pass 4.00
0_pmqtest t3-2-min-latency : pass 2.00
0_pmqtest t1-0-max-latency : pass 23.00
0_pmqtest t1-0-avg-latency : pass 4.00
0_pmqtest t1-0-min-latency : pass 2.00
0_ptsematest t3-2-max-latency : pass 11.00
0_ptsematest t3-2-avg-latency : pass 3.00
0_ptsematest t3-2-min-latency : pass 2.00
0_ptsematest t1-0-max-latency : pass 14.00
0_ptsematest t1-0-avg-latency : pass 3.00
0_ptsematest t1-0-min-latency : pass 2.00
0_rt-migrate-test t2-p98-avg : pass 11.00
0_rt-migrate-test t2-p98-tot : pass 581.00
0_rt-migrate-test t2-p98-min : pass 9.00
0_rt-migrate-test t2-p98-max : pass 28.00
0_rt-migrate-test t1-p97-avg : pass 13.00
0_rt-migrate-test t1-p97-tot : pass 654.00
0_rt-migrate-test t1-p97-min : pass 8.00
0_rt-migrate-test t1-p97-max : pass 34.00
0_rt-migrate-test t0-p96-avg : pass 19213.00
0_rt-migrate-test t0-p96-tot : pass 960652.00
0_rt-migrate-test t0-p96-min : pass 13.00
0_rt-migrate-test t0-p96-max : pass 20031.00
0_signaltest t0-max-latency : pass 29.00
0_signaltest t0-avg-latency : pass 8.00
0_signaltest t0-min-latency : pass 4.00
0_sigwaittest t3-2-max-latency : pass 16.00
0_sigwaittest t3-2-avg-latency : pass 4.00
0_sigwaittest t3-2-min-latency : pass 2.00
0_sigwaittest t1-0-max-latency : pass 24.00
0_sigwaittest t1-0-avg-latency : pass 4.00
0_sigwaittest t1-0-min-latency : pass 2.00
0_svsematest t3-2-max-latency : pass 13.00
0_svsematest t3-2-avg-latency : pass 4.00
0_svsematest t3-2-min-latency : pass 2.00
0_svsematest t1-0-max-latency : pass 13.00
0_svsematest t1-0-avg-latency : pass 4.00
0_svsematest t1-0-min-latency : pass 2.00
0_smoke-tests linux-posix-lsb_release: pass
0_smoke-tests linux-posix-lscpu : pass
0_smoke-tests linux-posix-ifconfig: pass
0_smoke-tests linux-posix-vmstat : pass
0_smoke-tests linux-posix-uname : pass
0_smoke-tests linux-posix-pwd : pass
0_smoke-tests linux-posix-lsb_release: pass
0_smoke-tests linux-posix-lscpu : pass
0_smoke-tests linux-posix-ifconfig: pass
0_smoke-tests linux-posix-vmstat : pass
0_smoke-tests linux-posix-uname : pass
0_smoke-tests linux-posix-pwd : pass
0_smoke-tests linux-posix-lsb_release: pass
0_smoke-tests linux-posix-lscpu : pass
0_smoke-tests linux-posix-ifconfig: pass
0_smoke-tests linux-posix-vmstat : pass
0_smoke-tests linux-posix-uname : pass
0_smoke-tests linux-posix-pwd : pass
0_smoke-tests linux-posix-lsb_release: pass
0_smoke-tests linux-posix-lscpu : pass
0_smoke-tests linux-posix-ifconfig: pass
0_smoke-tests linux-posix-vmstat : pass
0_smoke-tests linux-posix-uname : pass
0_smoke-tests linux-posix-pwd : pass


Trying to figure out from the web interface of LAVA is a bit
combersome.

Do either of the CIP Core profiles include Python support?
Linaro test-definitions [2] have the following tests marked within the preempt-rt scope:
cyclicdeadline/cyclicdeadline.yaml
pmqtest/pmqtest.yaml
rt-migrate-test/rt-migrate-test.yaml
cyclictest/cyclictest.yaml
svsematest/svsematest.yaml
pi-stress/pi-stress.yaml
signaltest/signaltest.yaml
ptsematest/ptsematest.yaml
sigwaittest/sigwaittest.yaml
hackbench/hackbench.yaml
ltp-realtime/ltp-realtime.yaml
See above.

Which of the above would be valuable to run on CIP RT Kernels?
Basically you want to run all of the tests in rt-tests.

A while back Daniel Wagner also did some work on a Jitterdebugger
test [3], but it hasn't been merged yet and I'm not sure what the
current status is. Any updates Daniel?
Yeah, I was holding a bit back until I am happy with my setup and
workflow. One of the major limitations with the current
test-definitions is the difficulties to setup background workload. To
make it short, I am not too happy with my current version but it
works.

Is anyone able to provide RT config/defconfigs for the x86 and arm
boards in the Mentor lab? Or BBB, QEMU etc.? (assuming that the
hardware is suitable).
If you are interested in my configs I have configs for ARMv7 (bbb),
ARMv8 (RPi3) and x86_64 via my hacktool. It also builds the kernel
because I didn't setup kernelci for it, so in short I get a complete
config, build, test setup via 'srt-build bbb lava'

Thanks,
Daniel


Re: RT Testing

Daniel Wagner <wagi@...>
 

Hi,

On Thu, Jan 16, 2020 at 06:54:54AM +0000, kazuhiro3.hayashi@toshiba.co.jp wrote:
BTW, it would be better to confirm which Python version (2.7 or 3) that cyclictest.sh depends on.
Do you know anything about this?
cyclictest.sh uses automated/lib/parse_rt_tests_results.py to parse
the results. The python code runs with either Python2 or Python3

$ python3 -m py_compile ./automated/lib/parse_rt_tests_results.py
$ python2 -m py_compile ./automated/lib/parse_rt_tests_results.py

Thanks,
Daniel


Re: CIP IRC weekly meeting today

Nobuhiro Iwamatsu
 

Hi,

I cannot attend the IRC meeting today.

-----Original Message-----
From: cip-dev [mailto:cip-dev-bounces@lists.cip-project.org] On Behalf
Of masashi.kudo@cybertrust.co.jp
Sent: Thursday, January 16, 2020 8:16 AM
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] CIP IRC weekly meeting today

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=3
7&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-09-09.
00.log.html

Agenda:

* Action item
1. Combine rootfilesystem with kselftest binary - Iwamatsu-san
I tested on LAVA. But not finished.
https://lava.ciplatform.org/scheduler/job/9499


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 qemux86-64 and BBB to both 4.4 and 4.19 - Iwamatsu-san
Qemux86-64's config already merged to cip-kernel-config.
BBB config is under testing. Please keep this A.I.


* 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,
Best regards,
Nobuhiro


Obtain full set of source code for cip image

Dennis Semakin <insane79@...>
 

Hi guys.
May be my email will be a little bit off-topic for this mail list, but I really have no idea where should I ask. I'm kernel and system developer and prefer ML :)
I'm interesting in building secure images for embedded devices using CIP project.
However obviously the preferred and one of the famous build system for this I believe is Yocto(Poky/BitBake).

I have goggled that it looks like there is a number of approaches (tools, frameworks) that provides such functionality: to build image for certain device using sources (e.g. Linux kernel) but inside Yocto build system.
They are ISAR and Deby. But I haven't found how the source code repository is configured in ISAR and Deby, e.g. where from it gets source code and how to modify URL for it.

The main goal:
- Build safety operating system from CIP-project source code/

The main question:
- Is it possible to change URL for userland packages for source code repository when build? E.g. for cip-kernel there's BitBake recipe (.bb file) where kernel URI is specified
, I mean userland - CIP Core Pakages, or there is only one way to build the image, just use existing scripts (kas, docker, etc...) and all work to fetching source code is hidden?
Why ISAR does not provide any way to change it (source code database)? At least I haven't found it.

Thanks in advance.

Br,
Denis Semakin.


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

Kazuhiro Hayashi
 

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: RT Testing

Kazuhiro Hayashi
 

Hello Chris,

Thank you for your updates!

Hello Pavel, Hayashi-san, Jan, Daniel,
[...]

Currently there is an issue with the way that the cyclic test case results are shown (i.e. they aren't) in LAVA due to
a change [0] made to Linaro's cyclictest.sh.
That means that the test parsing now depends on Python, which isn't included in the cip-core RFS [1] that is currently
being used.

Do either of the CIP Core profiles include Python support?
At the moment, we've just started creating the supported package list, so I cannot clearly say Yes.
However, at least, the both profiles can create an image including python only for testing
because the python packages are already provided in upstream projects (isar, meta-debian).

Whether CIP Core provides Python packages or not depends on
what kind of packages will be proposed (requested) by CIP WGs in future.
Currently, several packages which depend on Python packages would be
included in the next proposal from security WG (under review now).

BTW, it would be better to confirm which Python version (2.7 or 3) that cyclictest.sh depends on.
Do you know anything about this?

Kazu


Linaro test-definitions [2] have the following tests marked within the preempt-rt scope:
cyclicdeadline/cyclicdeadline.yaml
pmqtest/pmqtest.yaml
rt-migrate-test/rt-migrate-test.yaml
cyclictest/cyclictest.yaml
svsematest/svsematest.yaml
pi-stress/pi-stress.yaml
signaltest/signaltest.yaml
ptsematest/ptsematest.yaml
sigwaittest/sigwaittest.yaml
hackbench/hackbench.yaml
ltp-realtime/ltp-realtime.yaml

Which of the above would be valuable to run on CIP RT Kernels?

A while back Daniel Wagner also did some work on a Jitterdebugger test [3], but it hasn't been merged yet and I'm not
sure what the current status is. Any updates Daniel?

Is anyone able to provide RT config/defconfigs for the x86 and arm boards in the Mentor lab? Or BBB, QEMU etc.? (assuming
that the hardware is suitable).


[0]
https://github.com/Linaro/test-definitions/commit/4b5c46f275632932b3045f2ee16ad9cae5bb482d#diff-c724b852b75aefda2cc3
505c4517828dR50
[1] https://s3-us-west-2.amazonaws.com/download.cip-project.org/cip-core/iwg20m/core-image-minimal-iwg20m.tar.gz
[2] https://github.com/Linaro/test-definitions/blob/master/automated/linux
[3] https://github.com/igaw/test-definitions/blob/preempt-rt/automated/linux/jitterdebugger/jitterdebugger.yaml

Kind regards, Chris


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-09-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 qemux86-64 and BBB to both 4.4 and 4.19 - 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.


RT Testing

Chris Paterson
 

Hello Pavel, Hayashi-san, Jan, Daniel,

Addressing this email to all of you as both RT and CIP Core are involved.

I started to look into RT testing in more detail today.

I've created an RT configuration for the RZ/G1 boards:
https://gitlab.com/patersonc/cip-kernel-config/blob/chris/add_renesas_rt_configs/4.4.y-cip-rt/arm/renesas_shmobile-rt_defconfig
I'll do something similar for the RZ/G2 boards soon.

Built it with linux-4.4.y-cip-rt and run cyclic test:
https://lava.ciplatform.org/scheduler/job/9828
Times look okay to an rt-untrained eye:
T: 0 ( 1169) P:98 I:1000 C: 59993 Min: 13 Act: 16 Avg: 16 Max: 33

Compared to a run with linux-4.4.y-cip:
https://lava.ciplatform.org/scheduler/job/9829
T: 0 ( 938) P:98 I:1000 C: 6000 Min: 1618 Act: 9604 Avg: 9603 Max: 14550

Pavel, does the above look okay/useful to you? Or is cyclictest not worth running unless there is some load on the system?

Currently there is an issue with the way that the cyclic test case results are shown (i.e. they aren't) in LAVA due to a change [0] made to Linaro's cyclictest.sh.
That means that the test parsing now depends on Python, which isn't included in the cip-core RFS [1] that is currently being used.

Do either of the CIP Core profiles include Python support?

Linaro test-definitions [2] have the following tests marked within the preempt-rt scope:
cyclicdeadline/cyclicdeadline.yaml
pmqtest/pmqtest.yaml
rt-migrate-test/rt-migrate-test.yaml
cyclictest/cyclictest.yaml
svsematest/svsematest.yaml
pi-stress/pi-stress.yaml
signaltest/signaltest.yaml
ptsematest/ptsematest.yaml
sigwaittest/sigwaittest.yaml
hackbench/hackbench.yaml
ltp-realtime/ltp-realtime.yaml

Which of the above would be valuable to run on CIP RT Kernels?

A while back Daniel Wagner also did some work on a Jitterdebugger test [3], but it hasn't been merged yet and I'm not sure what the current status is. Any updates Daniel?

Is anyone able to provide RT config/defconfigs for the x86 and arm boards in the Mentor lab? Or BBB, QEMU etc.? (assuming that the hardware is suitable).


[0] https://github.com/Linaro/test-definitions/commit/4b5c46f275632932b3045f2ee16ad9cae5bb482d#diff-c724b852b75aefda2cc3505c4517828dR50
[1] https://s3-us-west-2.amazonaws.com/download.cip-project.org/cip-core/iwg20m/core-image-minimal-iwg20m.tar.gz
[2] https://github.com/Linaro/test-definitions/blob/master/automated/linux
[3] https://github.com/igaw/test-definitions/blob/preempt-rt/automated/linux/jitterdebugger/jitterdebugger.yaml

Kind regards, Chris


Re: [cip-core] Update PDP to 3.0 (was: RE: [cip-core] Package Proposal #1 (Security packages))

Kento Yoshida
 

Please try if you need :)
It's convenience for us. Thank you.

The security working group will have a bi-weekly meeting tomorrow, and we'll decide the packages that are proposed as the proposal of this time.
I'll create the proposal using the following option after that meeting.

Kent

-----Original Message-----
From: kazuhiro3.hayashi@toshiba.co.jp <kazuhiro3.hayashi@toshiba.co.jp>
Sent: Tuesday, January 14, 2020 1:26 PM
To: Kento Yoshida <kento.yoshida.wz@renesas.com>; jan.kiszka@siemens.com;
cip-dev@lists.cip-project.org; dinesh.kumar@toshiba-tsip.com
Subject: RE: [cip-dev] [cip-core] Update PDP to 3.0 (was: RE: [cip-core] Package
Proposal #1 (Security packages))

Hello Kent, Dinesh,

Here is a minor update of generate-proposal.py:
"-a" option is newly supported to append packages to the existing proposal file.
$ ./generate-proposal.py -a existing-proposal.yml

It may be useful when users want to restart creating proposal from an existing
incomplete file, or append several packages to an existing proposal file which
another person created, etc.

PDP revision is updated to 3.1, but all functions are compatible with 3.0.
If a same source package is appended by -a option, the old proposal information in
the existing-proposal will be overwritten.

Please try if you need :)

Best regards,
Kazu


Hi,

Could you try the updated script to create a new proposal including
the origin 21 security packages + their dependencies?
Sure. Now, the security working group is re-checking the proposed packages and
their dependency.
Actually, our original proposal consisted of a non-well-maintained package.
In addition, as Jan mentioned, there was also waste such as both python 2.7 and
3 are included.
We are preparing a proposal without these defect.

Best regards,
Kent
-----Original Message-----
From: kazuhiro3.hayashi@toshiba.co.jp
<kazuhiro3.hayashi@toshiba.co.jp>
Sent: Thursday, January 9, 2020 9:05 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] Update PDP to 3.0 (was: RE:
[cip-core] Package Proposal #1 (Security packages))

Hello,

PDP and the helper scripts have been updated to 3.0.

* Add a rule to satisfy all run-time dependencies for the proposed
binary packages

https://gitlab.com/cip-project/cip-core/cip-pkglist/commit/6867b5b41b
cf618d4b
e3955f302df8dbb3114050#c284394f3826d472fb70f72e2ef4ef9fe9606660_8
0
_78
* Add a script (check_deps.py) to check the dependencies
* (Minor update): Caching CVE and apt data to reduce the
initialization time of generate-proposal.py

Kent, Dinesh,

Could you try the updated script to create a new proposal including
the origin 21 security packages + their dependencies?

Please let me know if you find some issues.

Best regards,
Kazu


Hello CIP core members,

If you have any objections about the following approach, please let
me know *by the next IRC meeting (on Jan 9th)*.

We are already updating cip-pkglist based on the following approach
and will create the new "proposal.yml" for the security packages ASAP.

Best regards,
Kazu


Hello Jan, Kent, and all CIP core members,

Anyway, I will create and share a sample of proposal.yml with
the flat package set, please review that and confirm if it
matches your opinion of
the "CIP maintained packages".

I would like to confirm that the following solution can satisfy our
requirements.

Examples:
* proposal*.yml: The package proposal file that a proposer is
creating using
"generate-proposal.py"
* pkglist_buster.yml: Existing "supported" package list, that was
created/updated before (See the attached files. All information
except "bin_pkgs" are dropped to simplify.)

Solution:
0. Use the same YML format as Kent's proposal (Don't change the
current YML format) 1. Add a new script "check-deps.py" to check
if binary
packages in "depends:" are included in
either "proposal.yml" or "pkglist_buster.yml"
2. "generate-proposal.py" runs "check-deps.py" at the end and
proposer needs
to
add more packages to "proposal.yml" if unmet dependencies are
reported
by "check-deps.py"
3. The proposer can request the package proposal only if
"check-deps.py" reports nothing

In the attached examples, the initial proposal "proposal1.yml"
has an unmet
dependency (= lsb-base).
"check-deps.py" reports this then the proposer add "lsb-base"
source package and binary package to the second proposal
"proposal2.yml", which satisfies all run-time dependencies so can be
proposed to cip-dev.

What do you think?
If OK, we will update the scripts in
https://gitlab.com/cip-project/cip-core/cip-pkglist
based on the above solution.

Best regards,
Kazu


Hello Jan and CIP core members,

Hi all,

On 20.12.19 10:58, kazuhiro3.hayashi@toshiba.co.jp wrote:
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.
Then let's define that base (minimal debootstrap) first
before adding further packages.
OK, let's start from defining this base.



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.)
Anything that a Debian package requires needs to be present -
otherwise the package becomes broken. I can't imagine we want
to propose that to our users. Weaker dependencies are obviously
optional.

Yes, anything required by Debian package needs to be "present",
but it is not always necessary to "maintain" their source (e.g.
Request them to Debian Extended LTS).

I think that there are two kinds in our "support" levels:
(1) Just make the package available (present) in CIP at least
10 years
(2) (1) + Keep watching the latest bugs and security issues and
fixing them aggressively I was understanding that the CIP
package list we are discussing is for clarifying the packages like (2).
However, if no one in CIP care about the difference between (1)
and (2), we should simply define the package list including all
binary package
dependencies, like Jan mentioned.


If we should run into a package that seems to require more
than it should, let's improve it by proposing a break-up
upstream. Or by repackaging it in meta-debian /
isar-cip-core. But that should come first before proposing it here.
It would be better if the both profiles can have such improved
packages, but actually changing upstream (Debian) takes much
time and effort and repackaging by ourselves may bring big
impacts to package compatibilities, especially in the generic profile.


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)
Anything in that range still seems reasonable from a
maintenance perspective - provided there are no "challenging"
packages included. But we should still check if that number
is seriously needed,
though.

OK, let's discuss about this number in the future proposal.

Anyway, I will create and share a sample of proposal.yml with
the flat package set, please review that and confirm if it
matches your opinion of
the "CIP maintained packages".

Kazu


Jan


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
/ma ster/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

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


Re: [cip-core] Update PDP to 3.0 (was: RE: [cip-core] Package Proposal #1 (Security packages))

Kazuhiro Hayashi
 

Hello Kent, Dinesh,

Here is a minor update of generate-proposal.py:
"-a" option is newly supported to append packages to the existing proposal file.
$ ./generate-proposal.py -a existing-proposal.yml

It may be useful when users want to restart creating proposal from an existing incomplete file,
or append several packages to an existing proposal file which another person created, etc.

PDP revision is updated to 3.1, but all functions are compatible with 3.0.
If a same source package is appended by -a option, the old proposal information
in the existing-proposal will be overwritten.

Please try if you need :)

Best regards,
Kazu


Hi,

Could you try the updated script to create a new proposal including the origin 21
security packages + their dependencies?
Sure. Now, the security working group is re-checking the proposed packages and their dependency.
Actually, our original proposal consisted of a non-well-maintained package.
In addition, as Jan mentioned, there was also waste such as both python 2.7 and 3 are included.
We are preparing a proposal without these defect.

Best regards,
Kent
-----Original Message-----
From: kazuhiro3.hayashi@toshiba.co.jp <kazuhiro3.hayashi@toshiba.co.jp>
Sent: Thursday, January 9, 2020 9:05 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] Update PDP to 3.0 (was: RE: [cip-core] Package
Proposal #1 (Security packages))

Hello,

PDP and the helper scripts have been updated to 3.0.

* Add a rule to satisfy all run-time dependencies for the proposed binary packages

https://gitlab.com/cip-project/cip-core/cip-pkglist/commit/6867b5b41bcf618d4b
e3955f302df8dbb3114050#c284394f3826d472fb70f72e2ef4ef9fe9606660_80
_78
* Add a script (check_deps.py) to check the dependencies
* (Minor update): Caching CVE and apt data to reduce the initialization time of
generate-proposal.py

Kent, Dinesh,

Could you try the updated script to create a new proposal including the origin 21
security packages + their dependencies?

Please let me know if you find some issues.

Best regards,
Kazu


Hello CIP core members,

If you have any objections about the following approach, please let me
know *by the next IRC meeting (on Jan 9th)*.

We are already updating cip-pkglist based on the following approach
and will create the new "proposal.yml" for the security packages ASAP.

Best regards,
Kazu


Hello Jan, Kent, and all CIP core members,

Anyway, I will create and share a sample of proposal.yml with the
flat package set, please review that and confirm if it matches your opinion of
the "CIP maintained packages".

I would like to confirm that the following solution can satisfy our requirements.

Examples:
* proposal*.yml: The package proposal file that a proposer is creating using
"generate-proposal.py"
* pkglist_buster.yml: Existing "supported" package list, that was
created/updated before (See the attached files. All information
except "bin_pkgs" are dropped to simplify.)

Solution:
0. Use the same YML format as Kent's proposal (Don't change the
current YML format) 1. Add a new script "check-deps.py" to check if binary
packages in "depends:" are included in
either "proposal.yml" or "pkglist_buster.yml"
2. "generate-proposal.py" runs "check-deps.py" at the end and proposer needs
to
add more packages to "proposal.yml" if unmet dependencies are reported
by "check-deps.py"
3. The proposer can request the package proposal only if
"check-deps.py" reports nothing

In the attached examples, the initial proposal "proposal1.yml" has an unmet
dependency (= lsb-base).
"check-deps.py" reports this then the proposer add "lsb-base" source
package and binary package to the second proposal "proposal2.yml",
which satisfies all run-time dependencies so can be proposed to cip-dev.

What do you think?
If OK, we will update the scripts in
https://gitlab.com/cip-project/cip-core/cip-pkglist
based on the above solution.

Best regards,
Kazu


Hello Jan and CIP core members,

Hi all,

On 20.12.19 10:58, kazuhiro3.hayashi@toshiba.co.jp wrote:
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.
Then let's define that base (minimal debootstrap) first before
adding further packages.
OK, let's start from defining this base.



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.)
Anything that a Debian package requires needs to be present -
otherwise the package becomes broken. I can't imagine we want to
propose that to our users. Weaker dependencies are obviously optional.
Yes, anything required by Debian package needs to be "present",
but it is not always necessary to "maintain" their source (e.g.
Request them to Debian Extended LTS).

I think that there are two kinds in our "support" levels:
(1) Just make the package available (present) in CIP at least 10
years
(2) (1) + Keep watching the latest bugs and security issues and
fixing them aggressively I was understanding that the CIP package
list we are discussing is for clarifying the packages like (2).
However, if no one in CIP care about the difference between (1)
and (2), we should simply define the package list including all binary package
dependencies, like Jan mentioned.


If we should run into a package that seems to require more than
it should, let's improve it by proposing a break-up upstream. Or
by repackaging it in meta-debian / isar-cip-core. But that
should come first before proposing it here.
It would be better if the both profiles can have such improved
packages, but actually changing upstream (Debian) takes much time
and effort and repackaging by ourselves may bring big impacts to
package compatibilities, especially in the generic profile.


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)
Anything in that range still seems reasonable from a maintenance
perspective - provided there are no "challenging" packages
included. But we should still check if that number is seriously needed,
though.

OK, let's discuss about this number in the future proposal.

Anyway, I will create and share a sample of proposal.yml with the
flat package set, please review that and confirm if it matches your opinion of
the "CIP maintained packages".

Kazu


Jan


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/ma
ster/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

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


Re: [isar-cip-core PATCH] classes/wic-targz-img: add dependency between targz-img and wic-img

Jan Kiszka
 

On 09.01.20 15:30, Q. Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@siemens.com>
Add a dependency between targz_image and wic_image to avoid
an error during the generation of the targz image as wic modifies
the rootfs.
Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
---
classes/wic-targz-img.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/classes/wic-targz-img.bbclass b/classes/wic-targz-img.bbclass
index 4e9f89d..1327840 100644
--- a/classes/wic-targz-img.bbclass
+++ b/classes/wic-targz-img.bbclass
@@ -11,3 +11,5 @@
inherit wic-img
inherit targz-img
+
+addtask do_targz_image after do_wic_image
Applied to next, thanks.

Jan

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


Re: [isar-cip-core PATCH v2 0/5] Use cip-kernel-config for images

Jan Kiszka
 

On 09.01.20 09:52, Q. Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@siemens.com>
Use the kernel_defconfigs
from https://gitlab.com/cip-project/cip-kernel/cip-kernel-config
to build the images for rzg2m, iwg20m and simatic-ipc227e.
The final patch is necessary until isar upstream will apply it.
Version 2:
- Add the missing protocol to download the repository cip-kernel-config
Quirin Gylstorff (5):
recipes-kernel/linux: allow the usage of the cip-kernel-config
Use renesas-config for hihope-rzg2m
Use renesas_shmobile_defconfig for iwg20m
Use siemens_ipc227e_defconfig for simatic-ipc227e
kas: patch isar for iwg20m with kernel 4.4
conf/machine/hihope-rzg2m.conf | 3 +-
conf/machine/iwg20m.conf | 2 +
conf/machine/simatic-ipc227e.conf | 2 +
...d-path-to-image-for-arm-kernels-4.12.patch | 37 +++++++++++++++++++
kas.yml | 9 ++++-
recipes-kernel/linux/linux-cip-common.inc | 18 +++++++--
6 files changed, 65 insertions(+), 6 deletions(-)
create mode 100644 isar-patches/0001-linux-custom-add-path-to-image-for-arm-kernels-4.12.patch
Applied to next, just minimally massaged the style of patch 1.

Thanks,
Jan

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


[isar-cip-core PATCH] ci: Adjust deploy-cip-core.sh to new kernel build

Jan Kiszka
 

From: Jan Kiszka <jan.kiszka@siemens.com>

The path structure has changed, multiple times by now in fact.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
scripts/deploy-cip-core.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/deploy-cip-core.sh b/scripts/deploy-cip-core.sh
index e5c09ef..b8a1cd3 100755
--- a/scripts/deploy-cip-core.sh
+++ b/scripts/deploy-cip-core.sh
@@ -39,5 +39,5 @@ aws s3 cp --no-progress $KERNEL_IMAGE s3://download.cip-project.org/cip-core/$TA
aws s3 cp --no-progress $BASE_PATH-initrd.img s3://download.cip-project.org/cip-core/$TARGET/

if [ -n "$DTB" ]; then
- aws s3 cp --no-progress build/tmp/work/cip-core-*/linux-cip-*/repack/linux-image/usr/lib/linux-image-*/$DTB s3://download.cip-project.org/cip-core/$TARGET/
+ aws s3 cp --no-progress build/tmp/work/cip-core-*/linux-cip/*/linux-cip-*/debian/linux-image-cip/usr/lib/linux-image-*/$DTB s3://download.cip-project.org/cip-core/$TARGET/
fi
--
2.16.4


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

4201 - 4220 of 8370