Date   

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


Re: Supported kernel and Debian versions in Isar

Jan Kiszka
 

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



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@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: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 1811caa0cf91320baff40c82cbb157c772cfd365)
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: [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@renesas.com>

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

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@siemens.com>
Sent: Tuesday, April 2, 2019 3:14 PM
To: sangorrin daniel(サンゴリン ダニエル ○SWC□OST) <daniel.sangorrin@toshiba.co.jp>
Cc: cip-dev@lists.cip-project.org; isar-users@googlegroups.com
Subject: Re: isar error log

On 02.04.19 05:17, daniel.sangorrin@toshiba.co.jp 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@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: isar error log

daniel.sangorrin@...
 

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

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@siemens.com>
Sent: Tuesday, April 2, 2019 3:14 PM
To: sangorrin daniel(サンゴリン ダニエル ○SWC□OST) <daniel.sangorrin@toshiba.co.jp>
Cc: cip-dev@lists.cip-project.org; isar-users@googlegroups.com
Subject: Re: isar error log

On 02.04.19 05:17, daniel.sangorrin@toshiba.co.jp 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


Re: [PATCH 1/9] arm64: dts: renesas: r8a774c0: Add secondary CA53 CPU core

Nobuhiro Iwamatsu
 

Hi, Biju.

2019年4月11日(木) 15:55 Biju Das <biju.das@bp.renesas.com>:


Hi Nobuhiro-San,

Thanks for the feedback.

Regards,
Biju

-----Original Message-----
From: nobuhiro1.iwamatsu@toshiba.co.jp
<nobuhiro1.iwamatsu@toshiba.co.jp>
Sent: 11 April 2019 00:14
To: Biju Das <biju.das@bp.renesas.com>; cip-dev@lists.cip-project.org
Subject: RE: [cip-dev] [PATCH 1/9] arm64: dts: renesas: r8a774c0: Add
secondary CA53 CPU core

Hi, Diju.

-----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 6:19 PM
To: cip-dev@lists.cip-project.org
Cc: Biju Das <biju.das@bp.renesas.com>
Subject: [cip-dev] [PATCH 1/9] arm64: dts: renesas: r8a774c0: Add
secondary CA53 CPU core

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

Add a device node for the second Cortex-A53 CPU core on the Renesas
RZ/G2E (a.k.a r8a774c0) SoC, and adjust the interrupt delivery masks
for the ARM Generic Interrupt Controller and Architectured Timer.
I think that 'Architected Timer' is correct, not 'Architectured Timer'.
If my point is correct, I will fix and apply the commit message.

Other patches are looks good to me.
I believe it is correct. see the link below.

https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/arch_timer.txt

Already the cherry-picked patch from upstream is reviewed by wider people.
So I believe it is not good to change the commit messages or ordering of patches.

We have upstreamed RZ/G2[ME] patches in specific order. So we expect the same order in cip kernel as well.
Like SoC definitions,SYSC,RST,CLK,Pinctrl , SoC DTSI,Board DTSI and the rest of the drivers.

We may be wrong. So please correct us if we are wrong.
I do not intend to change the patch application order.
However, since our CIP kernel needs to be maintained on a long-term,
I think it is better to fix the problems that we noticed and include the
corrected content in the commit message.


Regards,
Biju
Best regards,
Nobuhiro


Re: isar error log

Jan Kiszka
 

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

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@siemens.com>
Sent: Tuesday, April 2, 2019 3:14 PM
To: sangorrin daniel(サンゴリン ダニエル ○SWC□OST) <daniel.sangorrin@toshiba.co.jp>
Cc: cip-dev@lists.cip-project.org; isar-users@googlegroups.com
Subject: Re: isar error log

On 02.04.19 05:17, daniel.sangorrin@toshiba.co.jp 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


Re: isar error log

daniel.sangorrin@...
 

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/

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@siemens.com>
Sent: Tuesday, April 2, 2019 3:14 PM
To: sangorrin daniel(サンゴリン ダニエル ○SWC□OST) <daniel.sangorrin@toshiba.co.jp>
Cc: cip-dev@lists.cip-project.org; isar-users@googlegroups.com
Subject: Re: isar error log

On 02.04.19 05:17, daniel.sangorrin@toshiba.co.jp 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


Re: Supported kernel and Debian versions in Isar

Jan Kiszka
 

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/linux/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/recipes-kernel/linux
but "linux-cip" is default to 4.4.
https://gitlab.com/cip-project/cip-core/isar-cip-core/commit/02fdfbd03ec994d8282de4851293687116a7f311
Yes, that was a conservative choice we should change.


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

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.

Enabling buster should be straightforward, Isar works with it already.

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
 

4.19 + buster => NOT SUPPORTED
Sorry I would like to correct the examples:

4.4 + stretch => SUPPORTED
4.4 + buster => NOT SUPPORTED
4.4 + bullseye => NOT SUPPORTED
4.19 + stretch => SUPPORTED
4.19 + buster => SUPPORTED
4.19 + bullseye => SUPPORTED(?)
...

-----Original Message-----
From: cip-dev-bounces@lists.cip-project.org
[mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of
kazuhiro3.hayashi@toshiba.co.jp
Sent: Thursday, April 11, 2019 5:33 PM
To: jan.kiszka@siemens.com
Cc: cip-dev@lists.cip-project.org
Subject: [cip-dev] Supported kernel and Debian versions in Isar

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

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
4.19 + stretch => SUPPORTED
4.19 + buster => NOT SUPPORTED
4.19 + bullseye => SUPPORTED(?)
...

As the background, please refer to the following discussion if you need:
https://lists.cip-project.org/pipermail/cip-dev/2019-April/002074.html

Regards,
Kazu


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


Supported kernel and Debian versions in Isar

Kazuhiro Hayashi
 

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/linux/linux-cip_4.4.166-cip29.bb
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/recipes-kernel/linux
but "linux-cip" is default to 4.4.
https://gitlab.com/cip-project/cip-core/isar-cip-core/commit/02fdfbd03ec994d8282de4851293687116a7f311

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
4.19 + stretch => SUPPORTED
4.19 + buster => NOT SUPPORTED
4.19 + bullseye => SUPPORTED(?)
...

As the background, please refer to the following discussion if you need:
https://lists.cip-project.org/pipermail/cip-dev/2019-April/002074.html

Regards,
Kazu

5421 - 5440 of 7513