Date   

Re: Was: Software updates comparison

Info <info@...>
 

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

Stefano Babic <sbabic@...> 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@...
=====================================================================


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@... 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@...>:

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

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

On 11.04.19 11:08, daniel.sangorrin@... wrote:
From: Jan Kiszka <jan.kiszka@...>
On 03.04.19 02:56, daniel.sangorrin@... 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@... 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@...>

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

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@...>
Signed-off-by: Marek Vasut <marek.vasut+renesas@...>
Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
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@...>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@...>
Reviewed-by: Geert Uytterhoeven <geert+renesas@...>
Reviewed-by: Rob Herring <robh@...>
Reviewed-by: Simon Horman <horms+renesas@...>
(cherry picked from commit 2e2b7615e310994b4d59c98b7d114449a9f019e5)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
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@...>

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@...>
Reviewed-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Wolfram Sang <wsa@...>
(cherry picked from commit fca34b910ddc556c51294d58287f7c33863dddef)
Signed-off-by: Biju Das <biju.das@...>
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@...]
Sent: Thursday, April 11, 2019 9:15 PM
To: hayashi kazuhiro(林 和宏 ○SWC□OST)
<kazuhiro3.hayashi@...>
Cc: cip-dev@...
Subject: Re: Supported kernel and Debian versions in Isar

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

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

On 11.04.19 10:33, kazuhiro3.hayashi@... 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@...
[mailto:cip-dev-bounces@...] On Behalf Of Biju Das
Sent: Friday, March 22, 2019 7:29 PM
To: cip-dev@...
Cc: Biju Das <biju.das@...>
Subject: [cip-dev] [PATCH 1/4] pinctrl: sh-pfc: Reduce kernel size for
narrow VIN channels

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

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@... wrote:
-----Original Message-----
From: cip-dev-bounces@... <cip-dev-bounces@...> On Behalf Of
daniel.sangorrin@...
Sent: Thursday, April 11, 2019 7:06 PM
To: jan.kiszka@...
Cc: kas-devel@...; isar-users@...; cip-dev@...
Subject: Re: [cip-dev] isar error log

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

On 11.04.19 11:08, daniel.sangorrin@... wrote:
From: Jan Kiszka <jan.kiszka@...>
On 03.04.19 02:56, daniel.sangorrin@... 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


Re: Supported kernel and Debian versions in Isar

Jan Kiszka
 

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

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

On 11.04.19 10:33, kazuhiro3.hayashi@... 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 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/recipes-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.


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.

Jan

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


Re: Supported kernel and Debian versions in Isar

Kazuhiro Hayashi
 

Hi,

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

On 11.04.19 10:33, kazuhiro3.hayashi@... 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.



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


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/recipes-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
...


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?

Kazu


Jan

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


Re: [PATCH 1/5] dt-bindings: net: ravb: Add support for r8a774c0 SoC

Pavel Machek
 

On Fri 2019-03-22 09:56:17, Biju Das wrote:
From: Fabrizio Castro <fabrizio.castro@...>

Document RZ/G2E (R8A774C0) SoC bindings.

Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Geert Uytterhoeven <geert+renesas@...>
Reviewed-by: Simon Horman <horms+renesas@...>
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@...>
Signed-off-by: David S. Miller <davem@...>
(cherry picked from commit 1811caa0cf91320baff40c82cbb157c772cfd365)
Signed-off-by: Biju Das <biju.das@...>
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 01/11] pinctrl: sh-pfc: r8a77990: Add Audio clock pins, groups and functions

Pavel Machek
 

On Fri 2019-03-22 09:40:00, Biju Das wrote:
From: Takeshi Kihara <takeshi.kihara.df@...>

This patch adds AUDIO_CLK{A,B,C}, AUDIO_CLKOUT, AUDIO_CLKOUT{1,2,3}
pins, groups and functions to the R8A77990 SoC.
Applied the series. Thanks!

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


Re: isar error log

daniel.sangorrin@...
 

-----Original Message-----
From: cip-dev-bounces@... <cip-dev-bounces@...> On Behalf Of
daniel.sangorrin@...
Sent: Thursday, April 11, 2019 7:06 PM
To: jan.kiszka@...
Cc: kas-devel@...; isar-users@...; cip-dev@...
Subject: Re: [cip-dev] isar error log

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

On 11.04.19 11:08, daniel.sangorrin@... wrote:
From: Jan Kiszka <jan.kiszka@...>
On 03.04.19 02:56, daniel.sangorrin@... 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".

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.

Thanks,
Daniel



Jan


I am going to try with Ubuntu 18.04 (which worked fine for Suzuki-san) and then try to compare both.

Thanks,
Daniel







Thanks
Jan

-----Original Message-----
From: Jan Kiszka <jan.kiszka@...>
Sent: Tuesday, April 2, 2019 3:14 PM
To: sangorrin daniel(サンゴリン ダニエル ○SWC□OST) <daniel.sangorrin@...>
Cc: cip-dev@...; isar-users@...
Subject: Re: isar error log

On 02.04.19 05:17, daniel.sangorrin@... wrote:
Hi Jan,

I am trying to show CIP Core ISAR to some guys in Linaro Connect but I also met a binfmt related error.
It's supposed to be fixed in the :latest kas-isar image. Are you using that?

I am using Ubuntu 16.04. Do you have a hint on how to solve this problem?
I already installed qemu-user-static. The system service for binfmt seems to fail.

Thanks,
Daniel

update-binfmts: warning: unable to close
/proc/sys/fs/binfmt_misc/register: Invalid argument
update-binfmts: warning: unable to enable binary format qemu-aarch64
update-binfmts: exiting due to previous errors
That indeed indicate broken binfmt settings.

2019-04-01 15:37:22 - INFO - kas 1.0 started
2019-04-01 15:37:22 - INFO - /repo$ git rev-parse --show-toplevel
2019-04-01 15:37:22 - INFO - /repo$ git rev-parse --show-toplevel
2019-04-01 15:37:22 - INFO - /repo$ git rev-parse --show-toplevel
2019-04-01 15:37:22 - INFO - Using /repo as root for repository cip-core
2019-04-01 15:37:22 - INFO - /work/isar$ git cat-file -t
ee5518cc6ecdade53dcafabfbb40ba4b0c505777
2019-04-01 15:37:22 - INFO - Repository isar already contains
ee5518cc6ecdade53dcafabfbb40ba4b0c505777 as commit
2019-04-01 15:37:22 - INFO - /repo$ git rev-parse --show-toplevel
2019-04-01 15:37:22 - INFO - Using /repo as root for repository cip-core
2019-04-01 15:37:22 - INFO - /work/isar$ git status -s
2019-04-01 15:37:22 - INFO - /work/isar$ git rev-parse --verify HEAD
2019-04-01 15:37:22 - INFO - ee5518cc6ecdade53dcafabfbb40ba4b0c505777
2019-04-01 15:37:22 - INFO - Repo isar has already been checked out with correct refspec.
Nothing
to do.
2019-04-01 15:37:22 - INFO - /repo$ git rev-parse --show-toplevel
2019-04-01 15:37:22 - INFO - Using /repo as root for repository cip-core
2019-04-01 15:37:22 - INFO - /work/isar$ /tmp/tmp9u5m9ths /work/build
2019-04-01 15:37:22 - INFO - /repo$ git rev-parse --show-toplevel
2019-04-01 15:37:22 - INFO - Using /repo as root for repository cip-core
2019-04-01 15:37:22 - INFO - /repo$ git rev-parse --show-toplevel
2019-04-01 15:37:22 - INFO - Using /repo as root for repository cip-core
2019-04-01 15:37:22 - INFO - /work/build$ /work/isar/bitbake/bin/bitbake -k -c build
cip-core-image
Loading cache: 100%
|#################################################################
#################################################################
####| Time: 0:00:00 Loaded 19 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies Initialising
tasks: 100%
|#################################################################
####
############################################################|
Time:
0:00:00
NOTE: Executing RunQueue Tasks
ERROR: isar-bootstrap-target-1.0-r0 do_bootstrap: Function failed:
do_bootstrap (log file is located at
/work/build/tmp/work/cip-core-amd64/isar-bootstrap-target/temp/log.do_
bootstrap.77)
ERROR: Logfile of failure stored in:
/work/build/tmp/work/cip-core-amd64/isar-bootstrap-target/temp/log.do_
bootstrap.77
Log data follows:
| DEBUG: Executing shell function do_bootstrap
| W: Target architecture is the same as host architecture; disabling
| QEMU support
| I: Running command: debootstrap --arch amd64 --verbose
| --variant=minbase --include=locales
| --components=main,contrib,non-free stretch
| /work/build/tmp/work/cip-core-amd64/isar-bootstrap-target/rootfs
| http://ftp.de.debian.org/debian
| /usr/sbin/debootstrap: 1454: /usr/sbin/debootstrap: cannot create
| /work/build/tmp/work/cip-core-amd64/isar-bootstrap-target/rootfs/tes
| t-dev-null: Permission denied
| E: Cannot install into target
| '/work/build/tmp/work/cip-core-amd64/isar-bootstrap-target/rootfs'
| mounted with noexec or nodev
Hmm, there are more strange errors. Could it be that you forgot the "--isar"
after "kas-docker"? That would mean you are trying to run unprivileged which is doomed to fail.

| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_bootstrap (log file is located at
| /work/build/tmp/work/cip-core-amd64/isar-bootstrap-target/temp/log.d
| o_bootstrap.77)
ERROR: Task (/work/isar/meta/recipes-core/isar-bootstrap/isar-bootstrap-target.bb:do_bootstrap)
failed
with exit code '1'
ERROR: isar-bootstrap-host-1.0-r0 do_bootstrap: Function failed:
do_bootstrap (log file is located at
/work/build/tmp/work/cip-core-amd64/isar-bootstrap-host-debian-stretch
-amd64/temp/log.do_bootstrap.79)
ERROR: Logfile of failure stored in:
/work/build/tmp/work/cip-core-amd64/isar-bootstrap-host-debian-stretch
-amd64/temp/log.do_bootstrap.79
Log data follows:
| DEBUG: Executing shell function do_bootstrap
| W: Target architecture is the same as host architecture; disabling
| QEMU support
| I: Running command: debootstrap --arch amd64 --verbose
| --variant=minbase --include=locales
| --components=main,contrib,non-free stretch
| /work/build/tmp/work/cip-core-amd64/isar-bootstrap-host-debian-stret
| ch-amd64/rootfs http://ftp.de.debian.org/debian
| /usr/sbin/debootstrap: 1454: /usr/sbin/debootstrap: cannot create
| /work/build/tmp/work/cip-core-amd64/isar-bootstrap-host-debian-stret
| ch-amd64/rootfs/test-dev-null: Permission denied
| E: Cannot install into target
| '/work/build/tmp/work/cip-core-amd64/isar-bootstrap-host-debian-stre
| tch-amd64/rootfs' mounted with noexec or nodev
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_bootstrap (log file is located at
| /work/build/tmp/work/cip-core-amd64/isar-bootstrap-host-debian-stret
| ch-amd64/temp/log.do_bootstrap.79)
ERROR: Task (/work/isar/meta/recipes-core/isar-bootstrap/isar-bootstrap-host.bb:do_bootstrap)
failed
with exit code '1'

$ systemctl status systemd-binfmt.service ● systemd-binfmt.service -
Set Up Additional Binary Formats
Loaded: loaded (/lib/systemd/system/systemd-binfmt.service; static; vendor preset: enabled)
Active: inactive (dead)
Condition: start condition failed at Tue 2019-04-02 08:04:31 +07; 2h 1min ago
none of the trigger conditions were met
Docs: man:systemd-binfmt.service(8)
man:binfmt.d(5)
https://www.kernel.org/doc/Documentation/binfmt_misc.txt
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
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: isar error log

daniel.sangorrin@...
 

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

On 11.04.19 11:08, daniel.sangorrin@... wrote:
From: Jan Kiszka <jan.kiszka@...>
On 03.04.19 02:56, daniel.sangorrin@... 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".

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

Thanks,
Daniel






Jan


I am going to try with Ubuntu 18.04 (which worked fine for Suzuki-san) and then try to compare both.

Thanks,
Daniel







Thanks
Jan

-----Original Message-----
From: Jan Kiszka <jan.kiszka@...>
Sent: Tuesday, April 2, 2019 3:14 PM
To: sangorrin daniel(サンゴリン ダニエル ○SWC□OST) <daniel.sangorrin@...>
Cc: cip-dev@...; isar-users@...
Subject: Re: isar error log

On 02.04.19 05:17, daniel.sangorrin@... wrote:
Hi Jan,

I am trying to show CIP Core ISAR to some guys in Linaro Connect but I also met a binfmt related error.
It's supposed to be fixed in the :latest kas-isar image. Are you using that?

I am using Ubuntu 16.04. Do you have a hint on how to solve this problem?
I already installed qemu-user-static. The system service for binfmt seems to fail.

Thanks,
Daniel

update-binfmts: warning: unable to close
/proc/sys/fs/binfmt_misc/register: Invalid argument
update-binfmts: warning: unable to enable binary format qemu-aarch64
update-binfmts: exiting due to previous errors
That indeed indicate broken binfmt settings.

2019-04-01 15:37:22 - INFO - kas 1.0 started
2019-04-01 15:37:22 - INFO - /repo$ git rev-parse --show-toplevel
2019-04-01 15:37:22 - INFO - /repo$ git rev-parse --show-toplevel
2019-04-01 15:37:22 - INFO - /repo$ git rev-parse --show-toplevel
2019-04-01 15:37:22 - INFO - Using /repo as root for repository cip-core
2019-04-01 15:37:22 - INFO - /work/isar$ git cat-file -t
ee5518cc6ecdade53dcafabfbb40ba4b0c505777
2019-04-01 15:37:22 - INFO - Repository isar already contains
ee5518cc6ecdade53dcafabfbb40ba4b0c505777 as commit
2019-04-01 15:37:22 - INFO - /repo$ git rev-parse --show-toplevel
2019-04-01 15:37:22 - INFO - Using /repo as root for repository cip-core
2019-04-01 15:37:22 - INFO - /work/isar$ git status -s
2019-04-01 15:37:22 - INFO - /work/isar$ git rev-parse --verify HEAD
2019-04-01 15:37:22 - INFO - ee5518cc6ecdade53dcafabfbb40ba4b0c505777
2019-04-01 15:37:22 - INFO - Repo isar has already been checked out with correct refspec.
Nothing
to do.
2019-04-01 15:37:22 - INFO - /repo$ git rev-parse --show-toplevel
2019-04-01 15:37:22 - INFO - Using /repo as root for repository cip-core
2019-04-01 15:37:22 - INFO - /work/isar$ /tmp/tmp9u5m9ths /work/build
2019-04-01 15:37:22 - INFO - /repo$ git rev-parse --show-toplevel
2019-04-01 15:37:22 - INFO - Using /repo as root for repository cip-core
2019-04-01 15:37:22 - INFO - /repo$ git rev-parse --show-toplevel
2019-04-01 15:37:22 - INFO - Using /repo as root for repository cip-core
2019-04-01 15:37:22 - INFO - /work/build$ /work/isar/bitbake/bin/bitbake -k -c build
cip-core-image
Loading cache: 100%
|#################################################################
#################################################################
####| Time: 0:00:00 Loaded 19 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies Initialising
tasks: 100%
|#################################################################
####
############################################################|
Time:
0:00:00
NOTE: Executing RunQueue Tasks
ERROR: isar-bootstrap-target-1.0-r0 do_bootstrap: Function failed:
do_bootstrap (log file is located at
/work/build/tmp/work/cip-core-amd64/isar-bootstrap-target/temp/log.do_
bootstrap.77)
ERROR: Logfile of failure stored in:
/work/build/tmp/work/cip-core-amd64/isar-bootstrap-target/temp/log.do_
bootstrap.77
Log data follows:
| DEBUG: Executing shell function do_bootstrap
| W: Target architecture is the same as host architecture; disabling
| QEMU support
| I: Running command: debootstrap --arch amd64 --verbose
| --variant=minbase --include=locales
| --components=main,contrib,non-free stretch
| /work/build/tmp/work/cip-core-amd64/isar-bootstrap-target/rootfs
| http://ftp.de.debian.org/debian
| /usr/sbin/debootstrap: 1454: /usr/sbin/debootstrap: cannot create
| /work/build/tmp/work/cip-core-amd64/isar-bootstrap-target/rootfs/tes
| t-dev-null: Permission denied
| E: Cannot install into target
| '/work/build/tmp/work/cip-core-amd64/isar-bootstrap-target/rootfs'
| mounted with noexec or nodev
Hmm, there are more strange errors. Could it be that you forgot the "--isar"
after "kas-docker"? That would mean you are trying to run unprivileged which is doomed to fail.

| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_bootstrap (log file is located at
| /work/build/tmp/work/cip-core-amd64/isar-bootstrap-target/temp/log.d
| o_bootstrap.77)
ERROR: Task (/work/isar/meta/recipes-core/isar-bootstrap/isar-bootstrap-target.bb:do_bootstrap)
failed
with exit code '1'
ERROR: isar-bootstrap-host-1.0-r0 do_bootstrap: Function failed:
do_bootstrap (log file is located at
/work/build/tmp/work/cip-core-amd64/isar-bootstrap-host-debian-stretch
-amd64/temp/log.do_bootstrap.79)
ERROR: Logfile of failure stored in:
/work/build/tmp/work/cip-core-amd64/isar-bootstrap-host-debian-stretch
-amd64/temp/log.do_bootstrap.79
Log data follows:
| DEBUG: Executing shell function do_bootstrap
| W: Target architecture is the same as host architecture; disabling
| QEMU support
| I: Running command: debootstrap --arch amd64 --verbose
| --variant=minbase --include=locales
| --components=main,contrib,non-free stretch
| /work/build/tmp/work/cip-core-amd64/isar-bootstrap-host-debian-stret
| ch-amd64/rootfs http://ftp.de.debian.org/debian
| /usr/sbin/debootstrap: 1454: /usr/sbin/debootstrap: cannot create
| /work/build/tmp/work/cip-core-amd64/isar-bootstrap-host-debian-stret
| ch-amd64/rootfs/test-dev-null: Permission denied
| E: Cannot install into target
| '/work/build/tmp/work/cip-core-amd64/isar-bootstrap-host-debian-stre
| tch-amd64/rootfs' mounted with noexec or nodev
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_bootstrap (log file is located at
| /work/build/tmp/work/cip-core-amd64/isar-bootstrap-host-debian-stret
| ch-amd64/temp/log.do_bootstrap.79)
ERROR: Task (/work/isar/meta/recipes-core/isar-bootstrap/isar-bootstrap-host.bb:do_bootstrap) failed
with exit code '1'

$ systemctl status systemd-binfmt.service ● systemd-binfmt.service -
Set Up Additional Binary Formats
Loaded: loaded (/lib/systemd/system/systemd-binfmt.service; static; vendor preset: enabled)
Active: inactive (dead)
Condition: start condition failed at Tue 2019-04-02 08:04:31 +07; 2h 1min ago
none of the trigger conditions were met
Docs: man:systemd-binfmt.service(8)
man:binfmt.d(5)
https://www.kernel.org/doc/Documentation/binfmt_misc.txt
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
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

7501 - 7520 of 9599