Date   

Re: Was: Software updates comparison

daniel.sangorrin@...
 

Hi Stefano,

Thanks a lot for the clarifications.
# Christian (Siemens) had already informed us about part of the progress.

From: Stefano Babic <sbabic@denx.de>
[...]
- depends on libubootenv which needs to be rebuilt for each target.

This was a well known issue and source of several conflicts in the past.
Thanks to a customer of mines, I have implemented a new libubootenv
library that is hardware independent and fixes this issue. Not only, this could
allow in future to extend it and introduce security features, like signed
environment:

https://github.com/sbabic/libubootenv

The library must be explicitely activated in SWUpdate's configuration, it will
become the default in future.
Sounds great.
I think that SZ Lin (Moxa) was already preparing a Debian package.
If the new library is mature enough then we should enable it by default.

- hard to manage updates from v1 to v5 directly

This is also a topic I had on my desk - as it is possible to read in your
comparison / research, this can be solved if SWUpdate and CASync can be
combined. But to make things correct, SWUpdate should well integrate
CASync and uses it as library - this requires some changes in CASync, too. I
had a draft design about this, but due to the complexity / effort, the project
asking for delta-update decided in another direction. There is currently no
further work in SWUpdate in this direction.
Thanks for the update!
Was transforming CASync into a library the complex part that you mention?

Best regards,
Daniel


Best regards,
Stefano

--
================================================================
=====
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
================================================================
=====


Re: [PATCH 4.19.y] dt-bindings: irqchip: renesas-irqc: Document r8a774c0 support

Biju Das <biju.das@...>
 

-----Original Message-----
From: Biju Das
Sent: 15 April 2019 10:37
To: Biju Das <biju.das@bp.renesas.com>; cip-dev@lists.cip-project.org; Pavel
Machek <pavel@denx.de>
Cc: Chris Paterson <Chris.Paterson2@renesas.com>; Fabrizio Castro
<fabrizio.castro@bp.renesas.com>
Subject: RE: [PATCH 4.19.y] dt-bindings: irqchip: renesas-irqc: Document
r8a774c0 support

Hi Pavel,

I am not seeing this patch on 4.19.y-cip? Is this patch ok to you?

Regards,
Biju

-----Original Message-----
From: Biju Das <biju.das@bp.renesas.com>
Sent: 29 March 2019 08:52
To: cip-dev@lists.cip-project.org
Cc: Chris Paterson <Chris.Paterson2@renesas.com>; Biju Das
<biju.das@bp.renesas.com>; Fabrizio Castro
<fabrizio.castro@bp.renesas.com>
Subject: [PATCH 4.19.y] dt-bindings: irqchip: renesas-irqc: Document
r8a774c0 support

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

Document RZ/G2E (R8A774C0) SoC bindings.

Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> (cherry picked from
commit 24105bf4d10485143f8e26337cda8bcb7f6e6da5)
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
---

Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.tx
t |
1 +
1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/interrupt-
controller/renesas,irqc.txt
b/Documentation/devicetree/bindings/interrupt-
controller/renesas,irqc.txt
index a046ed3..c974b83 100644
--- a/Documentation/devicetree/bindings/interrupt-
controller/renesas,irqc.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,i
+++ rq
+++ c.txt
@@ -14,6 +14,7 @@ Required properties:
- "renesas,irqc-r8a7793" (R-Car M2-N)
- "renesas,irqc-r8a7794" (R-Car E2)
- "renesas,intc-ex-r8a774a1" (RZ/G2M)
+ - "renesas,intc-ex-r8a774c0" (RZ/G2E)
- "renesas,intc-ex-r8a7795" (R-Car H3)
- "renesas,intc-ex-r8a7796" (R-Car M3-W)
- "renesas,intc-ex-r8a77965" (R-Car M3-N)
--
2.7.4


Re: [PATCH 4.19.y] dt-bindings: irqchip: renesas-irqc: Document r8a774c0 support

Biju Das <biju.das@...>
 

Hi Pavel,

I am not seeing this patch on 4.19.y-cip? Is this patch ok to you?

Regards,
Biju

-----Original Message-----
From: Biju Das <biju.das@bp.renesas.com>
Sent: 29 March 2019 08:52
To: cip-dev@lists.cip-project.org
Cc: Chris Paterson <Chris.Paterson2@renesas.com>; Biju Das
<biju.das@bp.renesas.com>; Fabrizio Castro
<fabrizio.castro@bp.renesas.com>
Subject: [PATCH 4.19.y] dt-bindings: irqchip: renesas-irqc: Document
r8a774c0 support

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

Document RZ/G2E (R8A774C0) SoC bindings.

Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> (cherry picked from
commit 24105bf4d10485143f8e26337cda8bcb7f6e6da5)
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
---
Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt |
1 +
1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/interrupt-
controller/renesas,irqc.txt b/Documentation/devicetree/bindings/interrupt-
controller/renesas,irqc.txt
index a046ed3..c974b83 100644
--- a/Documentation/devicetree/bindings/interrupt-
controller/renesas,irqc.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,irq
+++ c.txt
@@ -14,6 +14,7 @@ Required properties:
- "renesas,irqc-r8a7793" (R-Car M2-N)
- "renesas,irqc-r8a7794" (R-Car E2)
- "renesas,intc-ex-r8a774a1" (RZ/G2M)
+ - "renesas,intc-ex-r8a774c0" (RZ/G2E)
- "renesas,intc-ex-r8a7795" (R-Car H3)
- "renesas,intc-ex-r8a7796" (R-Car M3-W)
- "renesas,intc-ex-r8a77965" (R-Car M3-N)
--
2.7.4


Re: Renesas patches was Re: [PATCH 4.19y 01/10] pinctrl: sh-pfc: r8a77990: Add CAN pins, groups and functions

Fabrizio Castro <fabrizio.castro@...>
 

Hello Pavel,

-----Original Message-----
From: Pavel Machek <pavel@denx.de>
Sent: 12 April 2019 21:29
To: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Cc: Pavel Machek <pavel@denx.de>; cip-dev@lists.cip-project.org; Biju Das <biju.das@bp.renesas.com>
Subject: Renesas patches was Re: [cip-dev] [PATCH 4.19y 01/10] pinctrl: sh-pfc: r8a77990: Add CAN pins, groups and functions

Hi!

Current status of the tree is at:

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.19.y-cip

Could the patches that depend on each other go into one series? If it is
hard identifying what depends on what, maybe the best way forward is to
create a big series on top of 64729dc0be4847961550cdcca4ddc66adf556aaa
with all patches you have pending. Your patches seem to be in good shape,
so applying it should not be a big deal.
I went through the emails on the cip-dev mailing list and I could find all the
necessary patches this patch depends on, this patch applies cleanly once
its dependencies have been applied, so perhaps we should do what you are
suggesting, which is sending you another big series to apply on top of the
current branch.
Actually, that would create an even bigger confusion at this point, so I am going to wait
for you guys to work this out for now.
Good news -- I believe we managed to sort it out.

Tree at

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.19.y-cip

should now be up-to-date with your patches. If you could run any
tests and verify things look sane, it would be great.
Thank you for your efforts! I can confirm all of the patches have been applied and things look sane.

Thanks,
Fab


Best regards,
Pavel

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


Re: Was: Software updates comparison

Scott V. Kamp <scottk@...>
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Stefano Babic <sbabic@denx.de> wrote:
Hi Daniel,

Hi,

I have added a Software updates comparison report to our wiki:
https://wiki.linuxfoundation.org/civilinfrastructureplatform/cip_comparison_report

I actually find this comparison surprisingly lacking from a
security and methodology stand point given that its quite
limited, and leaves out other well know and not so well known. I
am sure we dont need to mention the likes of Balena and
Mender..... I was quite surprised to see RAUC, as it is not so
well known however... your missing ostree, tuf and uptane .. and
honestly from a security standpoint this combination far
surpasses any of the previously mentioned in methodology and
implementation. Along with OTA Community Edition, it is by far
the best solution, far more so then hawkbit, swupdate and TUF

https://uptane.github.io/
https://github.com/advancedtelematic/...
https://github.com/advancedtelematic/...



This comparison is mostly based on other comparisons reports, experience from CIP members and from reading the documentation.

For this initial iteration we decided to prepare a prototype using SWUpdate+librsync (for the binary deltas) and ISAR. Having said that, the CIP Software updates workgroup is open to other methods and contributions (specially in the form of patches). Our aim is to provide guidance and reference code/metadata for CIP users to update their devices using existing OSS update tools.

If you think that information in the comparison is not accurate or you want to complement it please let me know.
Thanks for the document - I am mainly interested on the good
and bad points about SWpdate and I can put a couple of details:

Bad points

- depends on libubootenv which needs to be rebuilt for each target.

This was a well known issue and source of several conflicts in
the past. Thanks to a customer of mines, I have implemented a
new libubootenv library that is hardware independent and fixes
this issue. Not only, this could allow in future to extend it
and introduce security features, like signed environment:

https://github.com/sbabic/libubootenv

The library must be explicitely activated in SWUpdate's
configuration, it will become the default in future.

- hard to manage updates from v1 to v5 directly

This is also a topic I had on my desk - as it is possible to
read in your comparison / research, this can be solved if
SWUpdate and CASync can be combined. But to make things
correct, SWUpdate should well integrate CASync and uses it as
library - this requires some changes in CASync, too. I had a
draft design about this, but due to the complexity
/ effort, the project asking for delta-update decided in another
direction. There is currently no further work in SWUpdate in
this direction.

Best regards,
Stefano
- --
Sent using Mailpile, Free Software from www.mailpile.is

-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEED83jmcaGxJZGGerGKdK9XRgP+iUFAlyz3o0ACgkQKdK9XRgP
+iVBZAv/a9kHLyHdZUbZA1EiJE0WaLwmmD+lp07A9s2cPfNTf5px/8DtbYPrLhm9
s+atSMbrWUl1R7v1hmZ6tPmZpXAOz+EJgknoRr40+FlBIgF/MZvnq29Zg91igKcG
ZEHJq1AJl68dzm5O70DGoMIrxZ/k2WAeElZ+JPR7aN7RiYCNm4qTwvt/QLpNwmuT
Hr+sDZvWbomGd/VwuXuttW6o/Lpq1al9GljmedBsycBcPCWkc6G7eupyoNSTNmli
jKvwlxx/5loapVDMuI+l2cQX6MVVTSrhqGxhB1w2SFmZBsWDgFV/snds9rK4Q6KE
SS4sLsM2PxrFK/fRFHHUzUPc4thmnRHOp0XOR3+qRen2MyVeQxJjlouTBn9nCSOy
wy5zh10QAMboC0H5HARnS4fWOrwpwEfFPX16s+uSMbF36JJMyqokk23Z5asxQTV8
+YBV9tJch1U311BUG4zS8yTKm1kRSDbGQs21V5xxPirKhsFTepwgLfwbTSK+cxjk
MyCZR5wM
=7PB7
-----END PGP SIGNATURE-----


Re: [PATCH 4.19.y] arm64: renesas: Enable GPIOLIB to allow GPIO driver selection

Nobuhiro Iwamatsu
 

Hi, Biju.

-----Original Message-----
From: cip-dev-bounces@lists.cip-project.org
[mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Biju Das
Sent: Friday, April 5, 2019 4:55 PM
To: cip-dev@lists.cip-project.org
Cc: Biju Das <biju.das@bp.renesas.com>
Subject: [cip-dev] [PATCH 4.19.y] arm64: renesas: Enable GPIOLIB to allow
GPIO driver selection

From: Takeshi Kihara <takeshi.kihara.df@renesas.com>

The R-Car GPIO driver cannot be enabled when Renesas SoC's ARCH configs
(ARCH_RENESAS, ARCH_R8A7795, ARCH_R8A7796 and ARCH_R8A77965) are
enabled only.

As GPIOs are a critical resource for proper operation on Renesas platforms,
this patch selects GPIOLIB, just like is done for other SoC vendors, and
on Renesas arm32 SoCs.

Reported-by: Alexandru Gheorghe <Alexandru_Gheorghe@mentor.com>
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
[geert: Improve patch description]
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

(cherry picked from commit 9374eee32b666c92cf821a98eb3aeaa0bf4d5dd5)
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
I applied this patch, thanks.

Best regards,
Nobuhiro


Re: Was: Software updates comparison

Info <info@...>
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Stefano Babic <sbabic@denx.de> wrote:
Hi Daniel,

Hi,

I have added a Software updates comparison report to our wiki:
https://wiki.linuxfoundation.org/civilinfrastructureplatform/cip_comparison_report
I actually find this comparison surprisingly lacking from a
security and methodology stand point given that its quite
limited, and leaves out other well know and not so well known. I
am sure we dont need to mention the likes of Balena and
Mender..... I was quite surprised to see RAUC, as it is not so
well known however... your missing ostree, tuf and uptane .. and
honestly from a security standpoint this combination far
surpasses any of the previously mentioned in methodology and
implementation. Along with OTA Community Edition, it is by far
the best solution, far more so then hawkbit, swupdate and TUF

https://uptane.github.io/
https://github.com/advancedtelematic/ota-community-edition
https://github.com/advancedtelematic/aktualizr


This comparison is mostly based on other comparisons reports, experience from CIP members and from reading the documentation.

For this initial iteration we decided to prepare a prototype using SWUpdate+librsync (for the binary deltas) and ISAR. Having said that, the CIP Software updates workgroup is open to other methods and contributions (specially in the form of patches). Our aim is to provide guidance and reference code/metadata for CIP users to update their devices using existing OSS update tools.

If you think that information in the comparison is not accurate or you want to complement it please let me know.
Thanks for the document - I am mainly interested on the good
and bad points about SWpdate and I can put a couple of details:

Bad points

- depends on libubootenv which needs to be rebuilt for each target.

This was a well known issue and source of several conflicts in
the past. Thanks to a customer of mines, I have implemented a
new libubootenv library that is hardware independent and fixes
this issue. Not only, this could allow in future to extend it
and introduce security features, like signed environment:

https://github.com/sbabic/libubootenv

The library must be explicitely activated in SWUpdate's
configuration, it will become the default in future.

- hard to manage updates from v1 to v5 directly

This is also a topic I had on my desk - as it is possible to
read in your comparison / research, this can be solved if
SWUpdate and CASync can be combined. But to make things
correct, SWUpdate should well integrate CASync and uses it as
library - this requires some changes in CASync, too. I had a
draft design about this, but due to the complexity
/ effort, the project asking for delta-update decided in another
direction. There is currently no further work in SWUpdate in
this direction.

Best regards,
Stefano
- --
Sent using Mailpile, Free Software from www.mailpile.is

-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEEu1jhkyGqo2gz54+mOQO0cdlUo7MFAlyzXdsACgkQOQO0cdlU
o7NWCQv+J7i7SevPTWa2qcIzQZzQEViXe9eATi+n68J3ZETC3Gqm0nFzzUPObryU
dOGbp8t5mf02RT8ppPLkCTA/sLxmVJOEBAzWErVA1y6KQzaTkmZe4y+iSrX0E87s
Fl8giVRiXT2cxq3s1uLhfo3X0GWT/DJqTHdNc8X8OFkoyYTzDh6HiYqWMungplyC
SQnzzfPGZkFECoaZUaepkzWvYILIJN7vCta5NeDKSTaYsbdyfpY9vDZRi7eCgmNw
WfxS4qcW4IEaNZ647AUa0LAYRhMJgMqOmUICuOuoyVd2nx7tU6ZtsQMTpD+2lu40
hcvu2Ew2Hcn/If1UhaWJL2sGlfRY4T8wVdz/UdP8bRK1cTqXEBKbexIPFmcOwhPM
wix0E8DbbhPoQR/tefJolnK7UPj5x7aoMsYWayvnE2VkKYhbGu3e5CaqElIakpdt
xZtiZUqvqHUrrhVhnIlUIfCA4nhMFY+0xTP13Gvgxl+4Ai75QN/Rtw0xFQxktjSI
AiCfvh8G
=ownp
-----END PGP SIGNATURE-----


Was: Software updates comparison

Stefano Babic <sbabic@...>
 

Hi Daniel,

Hi,

I have added a Software updates comparison report to our wiki:
https://wiki.linuxfoundation.org/civilinfrastructureplatform/cip_comparison_report

This comparison is mostly based on other comparisons reports, experience from CIP members and from reading the documentation.

For this initial iteration we decided to prepare a prototype using SWUpdate+librsync (for the binary deltas) and ISAR. Having said that, the CIP Software updates workgroup is open to other methods and contributions (specially in the form of patches). Our aim is to provide guidance and reference code/metadata for CIP users to update their devices using existing OSS update tools.

If you think that information in the comparison is not accurate or you want to complement it please let me know.
Thanks for the document - I am mainly interested on the good and bad
points about SWpdate and I can put a couple of details:

Bad points

- depends on libubootenv which needs to be rebuilt for each target.

This was a well known issue and source of several conflicts in the past.
Thanks to a customer of mines, I have implemented a new libubootenv
library that is hardware independent and fixes this issue. Not only,
this could allow in future to extend it and introduce security features,
like signed environment:

https://github.com/sbabic/libubootenv

The library must be explicitely activated in SWUpdate's configuration,
it will become the default in future.

- hard to manage updates from v1 to v5 directly

This is also a topic I had on my desk - as it is possible to read in
your comparison / research, this can be solved if SWUpdate and CASync
can be combined. But to make things correct, SWUpdate should well
integrate CASync and uses it as library - this requires some changes in
CASync, too. I had a draft design about this, but due to the complexity
/ effort, the project asking for delta-update decided in another
direction. There is currently no further work in SWUpdate in this direction.

Best regards,
Stefano

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
=====================================================================


Renesas patches was Re: [PATCH 4.19y 01/10] pinctrl: sh-pfc: r8a77990: Add CAN pins, groups and functions

Pavel Machek
 

Hi!

Current status of the tree is at:

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.19.y-cip

Could the patches that depend on each other go into one series? If it is
hard identifying what depends on what, maybe the best way forward is to
create a big series on top of 64729dc0be4847961550cdcca4ddc66adf556aaa
with all patches you have pending. Your patches seem to be in good shape,
so applying it should not be a big deal.
I went through the emails on the cip-dev mailing list and I could find all the
necessary patches this patch depends on, this patch applies cleanly once
its dependencies have been applied, so perhaps we should do what you are
suggesting, which is sending you another big series to apply on top of the
current branch.
Actually, that would create an even bigger confusion at this point, so I am going to wait
for you guys to work this out for now.
Good news -- I believe we managed to sort it out.

Tree at

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.19.y-cip

should now be up-to-date with your patches. If you could run any
tests and verify things look sane, it would be great.

Best regards,
Pavel

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


Re: isar error log

Ben Hutchings <ben.hutchings@...>
 

On Fri, 2019-04-12 at 13:37 +0200, Henning Schild wrote:
[...]
Just had a look at a ubuntu 16.04. It does support the fs but it is
not mounted. So a pseudo-code patch for the docker entry could be:

if not mounted
 if grep binfmt_misc /proc/filesystems
  mount
 else
  echo "Get a real and recent distro"
 fi
fi
Actual code should be something like:

if ! mountpoint -q /proc/sys/fs/binfmt_misc \
&& ! mount -t binfmt_misc binfmt_misc /proc/sys/fs/binfmt_misc; then
echo >&2 "E: Unable to mount binfmt_misc"
exit 1
fi

Ben.

--
Ben Hutchings, Software Developer   Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom


Re: Supported kernel and Debian versions in Isar

Ben Hutchings <ben.hutchings@...>
 

On Thu, 2019-04-11 at 08:33 +0000, kazuhiro3.hayashi@toshiba.co.jp wrote:
[...]
Do you any plans to provide the kernel recipes for all CIP versions (4.4, 4.19, ...) in master branch
and validate them with all Debian versions?
I guess that the supported combinations would be limited to practical ones.
For examples:
4.4 + stretch => SUPPORTED
4.4 + buster => NOT SUPPORTED
4.4 + bullseye => NOT SUPPORTED
That makes sense to me.

4.19 + stretch => SUPPORTED
4.19 + buster => NOT SUPPORTED
That should be supported as Debian's official kernel packages for
buster are based on 4.19.

4.19 + bullseye => SUPPORTED(?)
[...]

That should be supportable - Debian generally tries to support partial
upgrades including upgrading all of userland without the kernel, so
bullseye userland should be compatible with 4.19.

Ben.

--
Ben Hutchings, Software Developer   Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom


Re: isar error log

Henning Schild <henning.schild@...>
 

Am Thu, 11 Apr 2019 14:42:03 +0200
schrieb "[ext] Jan Kiszka" <jan.kiszka@siemens.com>:

On 11.04.19 12:13, daniel.sangorrin@toshiba.co.jp wrote:
-----Original Message-----
From: cip-dev-bounces@lists.cip-project.org
<cip-dev-bounces@lists.cip-project.org> On Behalf Of
daniel.sangorrin@toshiba.co.jp Sent: Thursday, April 11, 2019 7:06
PM To: jan.kiszka@siemens.com
Cc: kas-devel@googlegroups.com; isar-users@googlegroups.com;
cip-dev@lists.cip-project.org Subject: Re: [cip-dev] isar error log

-----Original Message-----
From: Jan Kiszka <jan.kiszka@siemens.com>
Sent: Thursday, April 11, 2019 6:16 PM
To: sangorrin daniel(サンゴリン ダニエル ○SWC□OST)
<daniel.sangorrin@toshiba.co.jp> Cc:
cip-dev@lists.cip-project.org; isar-users@googlegroups.com;
kas-devel@googlegroups.com Subject: Re: isar error log

On 11.04.19 11:08, daniel.sangorrin@toshiba.co.jp wrote:
From: Jan Kiszka <jan.kiszka@siemens.com>
On 03.04.19 02:56, daniel.sangorrin@toshiba.co.jp wrote:
Hi Jan,

Yes I am following the Readme.

The docker image id for kasproject/kas-isar is 9e9fe44e68d3 (I
am using kas-docker script). And I am
using

That's the same version I have, and it works for me.

kas-docker --isar build kas.yml:board-qemu-amd64.yml

Yes, it seems there are multiple errors:
/proc/sys/fs/binfmt_misc/register: Invalid argument
/test-dev-null: Permission denied

Probably this is a bug or misconfiguration in Ubuntu. I will
try to figure it out.
Adding kas-devel: Would be interesting to understand this so
that we can fix it or at least document a workaround. Maybe you
need to be in some privileged group in order to use privileged
docker containers? That's how things work on SUSE.

No one around is using Ubuntu, so that distro is likely a blind
spot for our testing.
OK, so I figured out that Ubuntu 16.04 was using the service
"binfmt-support", not "systemd-binfmt". For that reason, the
"systemd-binfmt" service was inactive. However, "binfmt-support"
is working fine. I also checked that the post-install script of
the qemu-user-static package had run correctly and there were
binfmt configuration files at /var/lib/binfmts/
But what prevented the container to tune the host kernel
according to its needs? That is the intended resolution for the
host not having the same settings as the container (or any at
all).
To be honest I don't really know what binfmt is all about yet, so
I can't even understand what you mean about "tuning the kernel".
https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html


By the way, I managed to update to the latest Ubuntu 4.4 kernel
(145) and the problem persists. I tried to reinstall
qemu-user-static etc but still fails humm .
Also i just tested on Ubuntu 18.04 and there I can build with ISAR
without problems. So I might just leave it unsolved and update to
18.04...
This might be a hint.
On Ubuntu 18.04 I can see "qemu-alpha" on /proc/sys/fs/binfmt_misc,
but on Ubuntu 16.04 it isn't there. When running kas-docker, the
first error is about not being able to
close /proc/sys/fs/binfmt_misc/register (invalid argument) and the
second is about qemu-alpha.
Maybe /proc/sys/fs/binfmt_misc is not mounted into the container
under Ubuntu 16.04, even if that is privileged.
Just had a look at a ubuntu 16.04. It does support the fs but it is
not mounted. So a pseudo-code patch for the docker entry could be:

if not mounted
if grep binfmt_misc /proc/filesystems
mount
else
echo "Get a real and recent distro"
fi
fi

Henning

Jan


Re: Supported kernel and Debian versions in Isar

Jan Kiszka
 

On 12.04.19 08:05, kazuhiro3.hayashi@toshiba.co.jp wrote:
Enabling buster should be straightforward, Isar works with it already.
Great, how can I know that the buster is officially enabled in
isar-cip-core?

When someone writes the patch(es) :). It's kas magic, I don't think we need
more.
I'm interested in what kind of variables is appropriate to provide the "options" with kas.
The most simple way I can guess is that:

* Provide another distro conf (e.g. cip-core_4.19_buster.conf) with the followings
require conf/distro/debian-buster.conf
...
PREFERRED_VERSION_linux-cip ?= "4.19.%"
PREFERRED_VERSION_linux-cip-rt ?= "4.19.%"
...
* Change the default "distro" in kas.yml
-distro: cip-core
+distro: cip-core_4.19_buster
* The current combination (4.4 + stretch) still available by setting
KAS_DISTRO="cip-core" (or should be renamed to "cip-core_4.4_stretch" ?)

If no objections or other ideas, I would like to create a simple patch to do that.
I would do the following:

- define distro/cip-core_stretch.conf and distro/cip-core_buster.conf
- maybe redefine distro/cip-core.conf as link to stretch today that is going to move to
buster once that was released and validated (similar to the default kernel story)
- define PREFERRED_VERSION_linux-cip to 4.19, maybe in a cip-core-common.conf
- allow override via kas fragments:
- distro: cip-core_buster
- PREFERRED_VERSION_linux-cip[-rt] = "4.4.%"


In addition, I'm also interested in the appropriate name for "distro"
because I'm just considering the branch name for the tiny profile (deby).
My first idea is the above. After it's decided,,
we can share the common names for specifying the version combinations between the both profiles.
I think appending the distro version name to the "cip-core" like above is a reasonable approach.

Jan

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


Re: [PATCH 4.19.y 01/17] clocksource/drivers/sh_cmt: Convert to SPDX identifiers

Pavel Machek
 

On Mon 2019-04-01 10:58:00, Fabrizio Castro wrote:
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

commit efad01173717b0d0ad8a7dc91cc447f19d8447f3 upstream.

This patch updates license to use SPDX-License-Identifier instead of verbose
license text.
Thanks, I applied the series.

Strictly speaking patches 1, 4, 16 only alter whitespace, so they
would not be welcome under -stable rules. OTOH they clearly do not
break anything, and ammount of surrounding changes means taking them
is easier than not taking them... so I took them.

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Re: [PATCH 4.19y 01/10] pinctrl: sh-pfc: r8a77990: Add CAN pins, groups and functions

Pavel Machek
 

On Mon 2019-04-01 14:55:38, Fabrizio Castro wrote:
From: Takeshi Kihara <takeshi.kihara.df@renesas.com>

commit c1e5bd286fe501992165608551f889ec69f5901a upstream.

This patch adds CAN{0,1} pins, groups and functions to the R8A77990 SoC.

Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Thanks, I applied the series.


--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Re: [PATCH 4.19.y 1/4] dt-bindings: PCI: rcar: Add device tree support for r8a774c0

Pavel Machek
 

On Fri 2019-03-29 08:32:34, Fabrizio Castro wrote:
Add PCIe support for the RZ/G2E (a.k.a. R8A774C0).

Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
(cherry picked from commit 2e2b7615e310994b4d59c98b7d114449a9f019e5)
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Thanks, I applied the series.
Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Re: [PATCH 4.19.y 1/9] i2c: sh_mobile: document support for r8a77990 (R-Car E3)

Pavel Machek
 

On Wed 2019-03-27 12:13:01, Biju Das wrote:
From: Simon Horman <horms+renesas@verge.net.au>

Document support for the IIC code for the r8a77990 (R-Car E3).

It is not considered compatible with existing fallback bindings
due to the documented absence of automatic transmission registers.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
(cherry picked from commit fca34b910ddc556c51294d58287f7c33863dddef)
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Thanks, I applied the series.
Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Re: Supported kernel and Debian versions in Isar

Kazuhiro Hayashi
 

-----Original Message-----
From: Jan Kiszka [mailto:jan.kiszka@siemens.com]
Sent: Thursday, April 11, 2019 9:15 PM
To: hayashi kazuhiro(林 和宏 ○SWC□OST)
<kazuhiro3.hayashi@toshiba.co.jp>
Cc: cip-dev@lists.cip-project.org
Subject: Re: Supported kernel and Debian versions in Isar

On 11.04.19 13:39, kazuhiro3.hayashi@toshiba.co.jp wrote:
Hi,

-----Original Message-----
From: Jan Kiszka [mailto:jan.kiszka@siemens.com]
Sent: Thursday, April 11, 2019 6:02 PM
To: hayashi kazuhiro(林 和宏 ○SWC□OST)
<kazuhiro3.hayashi@toshiba.co.jp>
Cc: cip-dev@lists.cip-project.org
Subject: Re: Supported kernel and Debian versions in Isar

On 11.04.19 10:33, kazuhiro3.hayashi@toshiba.co.jp wrote:
Hello Jan,

Do you have any policies about the version combinations of CIP kernel
and Debian supported in Isar?

Currently, Isar seems to support 4.4 CIP + stretch/buster:
https://github.com/ilbers/isar/blob/master/meta-isar/recipes-kernel/li
nux/linux-cip_4.4.166-cip29.bb

That's just an example for a custom kernel recipe.

https://github.com/ilbers/isar/blob/master/doc/user_manual.md#getting-
started

isar-cip-core additionally supports 4.19:
https://gitlab.com/cip-project/cip-core/isar-cip-core/tree/master/reci
pes-kernel/linux
but "linux-cip" is default to 4.4.
https://gitlab.com/cip-project/cip-core/isar-cip-core/commit/02fdfbd03
ec994d8282de4851293687116a7f311

Yes, that was a conservative choice we should change.
OK.
I would like to confirm the meaning of "change" (override or add) in the
following questions.
I mean: Set the default to 4.19, leave an option (e.g. a kas config fragment)
to switch back to 4.4.



Do you any plans to provide the kernel recipes for all CIP versions
(4.4,
4.19, ...) in master branch
and validate them with all Debian versions?
All (released) versions exist already, validation is the key now. We
do
not have isar-cip-core hooked up with our test labs yet. I only started
artifact generation, but only for the combinations 4.4-rt with BBB and
IPC227E. We should add 4.19 as well, and then we need tests. I'm low
on
bandwidth to look into the test hook-up myself ATM, unfortunately, but
I
will at least try to finish the uploading (more variants, upload of rootfs
as well, not only bootable image - or can the latter be used for LAVA
as
well?)
Thank you for the information.
The current Debian version used in the above testing is stretch?
After the buster released, are you planning to validate all of the
followings with isar-cip-core?

4.4-rt + stretch + BBB/ IPC227E
4.19-rt + stretch + BBB/ IPC227E
4.4-rt + buster + BBB/ IPC227E
4.19-rt + buster + BBB/ IPC227E
That would be the plan. Of course, the more variables we add, the more we
need to think about designing our test matrix, rather than just fully
populating it.
I also want to consider the test matrix (for the both generic and tiny profiles) and
share the current state with CIP developers so that we can easily understand
which combinations are now tested and which ones we can contribute.
I would like to summarize such information later.




I guess that the supported combinations would be limited to practical
ones.
For examples:
4.4 + stretch => SUPPORTED
4.4 + buster => NOT SUPPORTED
4.4 + bullseye => NOT SUPPORTED
4.19 + stretch => SUPPORTED
4.19 + buster => NOT SUPPORTED
4.19 + bullseye => SUPPORTED(?)
You meant
4.19 + buster => SUPPORTED
4.19 + bullseye => SUPPORTED(?)

Yes for buster, specifically when it is released. I don't think we need
to rush with the next release then.
OK.
What do you think about the targets of validation in future?

In Isar, we can choose any Debian versions available in
https://github.com/ilbers/isar/tree/master/meta/conf/distro (now
stretch & buster)
In isar-cip-core, we can choose any kernel versions available in
https://gitlab.com/cip-project/cip-core/isar-cip-core/tree/master/reci
pes-kernel/linux
but now isar-cip-core only provides one version combination specified
by
https://gitlab.com/cip-project/cip-core/isar-cip-core/blob/master/conf
/distro/cip-core.conf
When the new CIP kernel version or Debian version released,
will isar-cip-core overriede "distro/cip-core.conf" for the specific
version combination and validate?
e.g. 4.4 + stretch => 4.19 + buster => 5.xx + bullseye => ...
or, will add new files like "cip-core_2.conf", "cip-core_3.conf", ...
to provide multiple version combinations?
e.g.
cip-core.conf: 4.4 + stretch
cip-core_2.conf: 4.19 + buster
cip-core_3.conf: 5.xx + bullseye
...
As I said above, we will soon hit a point we will have to reduce our test
matrix again and rely on some version being indirectly tested via a similar
combination. E.g. if you test all generic features of a kernel version
against a specific Debian version on a specific board, the chances are fairly
high that those will also work on other boards. So the need to test all
Debian versions on all boards is rather low.
Agreed.
It would be nice if the verified version combinations + target board
and what kind of test cases are used for these verifications.
For example, if I've tested LTP with 4.19+buster+BBB,
people who see the test matrix might be able to know at least
the basic APIs of 4.19+buster has been verified for other boards.



Enabling buster should be straightforward, Isar works with it already.
Great, how can I know that the buster is officially enabled in
isar-cip-core?

When someone writes the patch(es) :). It's kas magic, I don't think we need
more.
I'm interested in what kind of variables is appropriate to provide the "options" with kas.
The most simple way I can guess is that:

* Provide another distro conf (e.g. cip-core_4.19_buster.conf) with the followings
require conf/distro/debian-buster.conf
...
PREFERRED_VERSION_linux-cip ?= "4.19.%"
PREFERRED_VERSION_linux-cip-rt ?= "4.19.%"
...
* Change the default "distro" in kas.yml
-distro: cip-core
+distro: cip-core_4.19_buster
* The current combination (4.4 + stretch) still available by setting
KAS_DISTRO="cip-core" (or should be renamed to "cip-core_4.4_stretch" ?)

If no objections or other ideas, I would like to create a simple patch to do that.

In addition, I'm also interested in the appropriate name for "distro"
because I'm just considering the branch name for the tiny profile (deby).
My first idea is the above. After it's decided,,
we can share the common names for specifying the version combinations between the both profiles.

Kazu


Jan

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


Re: [PATCH 1/4] pinctrl: sh-pfc: Reduce kernel size for narrow VIN channels

Nobuhiro Iwamatsu
 

Hi, Biju.

-----Original Message-----
From: cip-dev-bounces@lists.cip-project.org
[mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Biju Das
Sent: Friday, March 22, 2019 7:29 PM
To: cip-dev@lists.cip-project.org
Cc: Biju Das <biju.das@bp.renesas.com>
Subject: [cip-dev] [PATCH 1/4] pinctrl: sh-pfc: Reduce kernel size for
narrow VIN channels

From: Geert Uytterhoeven <geert+renesas@glider.be>

Some VIN channels support less than 24 lanes. As union vin_data always
consumes space for 24 lanes, this wastes memory.

Hence introduce new smaller unions vin_data12 and vin_data16, to
accommodate VIN channels with only 12 or 16 lanes.

This reduces the static pin controller driver size by 320 bytes for R-Car
V2H, and by 96 bytes for R-Car E2.
I applied this series, thanks.

Best regards,
Nobuhiro


Re: isar error log

Jan Kiszka
 

On 11.04.19 12:13, daniel.sangorrin@toshiba.co.jp wrote:
-----Original Message-----
From: cip-dev-bounces@lists.cip-project.org <cip-dev-bounces@lists.cip-project.org> On Behalf Of
daniel.sangorrin@toshiba.co.jp
Sent: Thursday, April 11, 2019 7:06 PM
To: jan.kiszka@siemens.com
Cc: kas-devel@googlegroups.com; isar-users@googlegroups.com; cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] isar error log

-----Original Message-----
From: Jan Kiszka <jan.kiszka@siemens.com>
Sent: Thursday, April 11, 2019 6:16 PM
To: sangorrin daniel(サンゴリン ダニエル ○SWC□OST) <daniel.sangorrin@toshiba.co.jp>
Cc: cip-dev@lists.cip-project.org; isar-users@googlegroups.com; kas-devel@googlegroups.com
Subject: Re: isar error log

On 11.04.19 11:08, daniel.sangorrin@toshiba.co.jp wrote:
From: Jan Kiszka <jan.kiszka@siemens.com>
On 03.04.19 02:56, daniel.sangorrin@toshiba.co.jp wrote:
Hi Jan,

Yes I am following the Readme.

The docker image id for kasproject/kas-isar is 9e9fe44e68d3 (I am using kas-docker script). And I am
using

That's the same version I have, and it works for me.

kas-docker --isar build kas.yml:board-qemu-amd64.yml

Yes, it seems there are multiple errors:
/proc/sys/fs/binfmt_misc/register: Invalid argument
/test-dev-null: Permission denied

Probably this is a bug or misconfiguration in Ubuntu. I will try to figure it out.
Adding kas-devel: Would be interesting to understand this so that we can fix it
or at least document a workaround. Maybe you need to be in some privileged group
in order to use privileged docker containers? That's how things work on SUSE.

No one around is using Ubuntu, so that distro is likely a blind spot for our
testing.
OK, so I figured out that Ubuntu 16.04 was using the service "binfmt-support", not "systemd-binfmt".
For that reason, the "systemd-binfmt" service was inactive. However, "binfmt-support" is working fine.
I also checked that the post-install script of the qemu-user-static package had run correctly
and there were binfmt configuration files at /var/lib/binfmts/
But what prevented the container to tune the host kernel according to its needs?
That is the intended resolution for the host not having the same settings as the
container (or any at all).
To be honest I don't really know what binfmt is all about yet, so I can't even understand what you mean about
"tuning the kernel".
https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html


By the way, I managed to update to the latest Ubuntu 4.4 kernel (145) and the problem persists. I tried to reinstall
qemu-user-static etc but still fails humm
.
Also i just tested on Ubuntu 18.04 and there I can build with ISAR without problems. So I might just leave it
unsolved and update to 18.04...
This might be a hint.
On Ubuntu 18.04 I can see "qemu-alpha" on /proc/sys/fs/binfmt_misc, but on Ubuntu 16.04 it isn't there.
When running kas-docker, the first error is about not being able to close /proc/sys/fs/binfmt_misc/register (invalid argument)
and the second is about qemu-alpha.
Maybe /proc/sys/fs/binfmt_misc is not mounted into the container under Ubuntu 16.04, even if that is privileged.

Jan

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

5401 - 5420 of 7505