Date   

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


Re: about branch of meta-debian in cip-core/deby

Kazuhiro Hayashi
 

Dear Fujita-san, and CIP-core members

Sorry for my late reply, but I would like to re-open this discussion
to prepare uploading the latest Deby to cip-core repository.

However, it may not clear CIP has decided or not that each kernel
version sticks to specific version of the other OSSs.
Some people around me say that OSSs included in cip-core will keep
these versions and maintained by CIP.
For example, they believe openssl 1.0.1t will be used when kernel
4.4-cip is running.
This may not right assumption.

Is there any material explaining the update policy of cip-core?
I have not seen such policy.
Probably, it has not been clarified yet.

In my understanding, the targets of CIP(-core)'s support are the followings at least:

Kernel:
linux-4.4.y-cip & -rt
linux-4.19.y-cip & -rt
Debian:
Debian 8 (jessie)
Debian 9 (stretch)
Debian 10 (buster)
... and every version in future

However, I think that there is no decision in CIP about the combination of
the above kernel versions and Debian versions, which should be supported by CIP.
This implicitly shows that all combinations could be supported, but
it's quite hard to test and maintain all of them.
I guess that the practical version combinations are very limited actually.

I would like to confirm opinions about this in Isar later.


If the both tiny(deby) and generic profile(isar) are based on the same
CIP kernel and Debian versions, we can use such common branch name above.
If not, or no benefit for users to use the common branch name,
I would like to simply use "morty" and "master" in deby repository.
Using different version for tiny and generic may be confusing.
In my opinion, tiny should be the subset of generic profile.
Thank you for your opinion.
Regarding the supported package list, I agree that tiny should be subset of generic.
In order to use the common version (branch name) in tiny and generic,
and to concentrate our efforts on well-used cases,,
we need to make a decision about the supported version combinations between CIP kernel and Debian.

Regards,
Kazu

-----Original Message-----
From: Kazuhiro Fujita [mailto:kazuhiro.fujita.jg@renesas.com]
Sent: Tuesday, March 19, 2019 2:52 PM
To: hayashi kazuhiro(林 和宏 ○SWC□OST)
<kazuhiro3.hayashi@toshiba.co.jp>; sangorrin daniel(サンゴリン ダニエル
○SWC□OST) <daniel.sangorrin@toshiba.co.jp>;
nobuhiro.iwamatsu@miraclelinux.com
Cc: jan.kiszka@siemens.com; cip-dev@lists.cip-project.org
Subject: RE: about branch of meta-debian in cip-core/deby

Hello Hayashi-san,

-----Original Message-----
From: kazuhiro3.hayashi@toshiba.co.jp
<kazuhiro3.hayashi@toshiba.co.jp>
Sent: Monday, March 18, 2019 10:52 AM
To: Kazuhiro Fujita <kazuhiro.fujita.jg@renesas.com>;
daniel.sangorrin@toshiba.co.jp; nobuhiro.iwamatsu@miraclelinux.com
Cc: jan.kiszka@siemens.com; cip-dev@lists.cip-project.org
Subject: RE: about branch of meta-debian in cip-core/deby

Hello Fujita-san,
CC: Jan

In case the morty branch will be replaced by the master, current users
will automatically switch to the master without knowing the change?
No, user can not automatically migrate from morty to master without
knowing the changes
because several specifications about recipe development has been deferent
between them.

Therefore, regarding deby repository, it would be better to provide
branches
Agreed.

"morty" and "master" as follows:
Current New
master(poky:morty-based) => morty
- => master(poky:master-based)
jethro => remove? (no longer maintained in
meta-
debian)

I would like to know if we need to the common branch name in cip-core.
For example: cip-core-v1(4.4+Debian8/9?),
cip-core-v2(4.19+Debian10), ...

Common branch name like cip-core-xx will help many users to understand
which branch they should use.

However, it may not clear CIP has decided or not that each kernel
version sticks to specific version of the other OSSs.
Some people around me say that OSSs included in cip-core will keep
these versions and maintained by CIP.
For example, they believe openssl 1.0.1t will be used when kernel
4.4-cip is running.
This may not right assumption.

Is there any material explaining the update policy of cip-core?


If the both tiny(deby) and generic profile(isar) are based on the same
CIP kernel and Debian versions, we can use such common branch name above.
If not, or no benefit for users to use the common branch name,
I would like to simply use "morty" and "master" in deby repository.
Using different version for tiny and generic may be confusing.
In my opinion, tiny should be the subset of generic profile.

Kind regards,
Fujita



Kind regards,
Kazu

-----Original Message-----
From: Kazuhiro Fujita [mailto:kazuhiro.fujita.jg@renesas.com]
Sent: Friday, March 15, 2019 11:39 AM
To: hayashi kazuhiro(林 和宏 ○SWC□OST)
<kazuhiro3.hayashi@toshiba.co.jp>; sangorrin daniel(サンゴリン ダニ
エル
○SWC□OST) <daniel.sangorrin@toshiba.co.jp>;
nobuhiro.iwamatsu@miraclelinux.com
Cc: cip-dev@lists.cip-project.org
Subject: RE: about branch of meta-debian in cip-core/deby

Hello Hayashi-san,

Should we keep the morty branch and add contents of master to another
cip-
core branch, or just replace the morty by the master?
In case the morty branch will be replaced by the master, current users
will automatically switch to the master without knowing the change?

Regards,
Fujita


-----Original Message-----
From: cip-dev-bounces@lists.cip-project.org
<cip-dev-bounces@lists.cip-
project.org> On Behalf Of kazuhiro3.hayashi@toshiba.co.jp
Sent: Thursday, March 14, 2019 7:09 PM
To: daniel.sangorrin@toshiba.co.jp;
nobuhiro.iwamatsu@miraclelinux.com
Cc: cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] about branch of meta-debian in cip-core/deby

Iwamatsu-san, Daniel,

It provides debian 8 packages in OE/recipe. Is there any reason
to
choose morty/debian 8?
In my understanding, this is the initial repository which was created
when the master branch (Debian 10 based) didn't exist yet.
We are planning to update it to the current master branch.

I have another question about how to do that.
Should we keep the morty branch and add contents of master to another
cip-
core branch,
or just replace the morty by the master?

Regards,
Kazu

-----Original Message-----
From: cip-dev-bounces@lists.cip-project.org
[mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of
daniel.sangorrin@toshiba.co.jp
Sent: Thursday, March 14, 2019 2:52 PM
To: nobuhiro.iwamatsu@miraclelinux.com
Cc: cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] about branch of meta-debian in cip-core/deby

Iwamatsu-san,

-----Original Message-----
From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu@miraclelinux.com>
Sent: Wednesday, March 13, 2019 4:38 PM
To: sangorrin daniel(サンゴリン ダニエル ○SWC□OST)
<daniel.sangorrin@toshiba.co.jp>
Cc: cip-dev@lists.cip-project.org
Subject: about branch of meta-debian in cip-core/deby

Hi, Daniel.

I have a question about about branch of meta-debian in cip-
core/deby.

The meta-debian branch used by cip-core/deby is morty.
It provides debian 8 packages in OE/recipe. Is there any reason
to
choose morty/debian 8?
Is the reason why the mata-debian master branch is still in
development?
Will you/we switch to the master branch when Debian 10 is
released?

Yes, that's correct.

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


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

Biju Das <biju.das@...>
 

Hi Nobuhiro-San,

-----Original Message-----
From: Biju Das
Sent: 11 April 2019 07:55
To: nobuhiro1.iwamatsu@toshiba.co.jp; cip-dev@lists.cip-project.org
Cc: Chris Paterson <Chris.Paterson2@renesas.com>; Fabrizio Castro
<fabrizio.castro@bp.renesas.com>
Subject: RE: [cip-dev] [PATCH 1/9] arm64: dts: renesas: r8a774c0: Add
secondary CA53 CPU core


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'.
Yes, you are correct, as per the below link.

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

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.

Regards,
Biju


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

Biju Das <biju.das@...>
 

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.

Regards,
Biju


CIP IRC weekly meeting today

SZ Lin (林上智) <SZ.Lin@...>
 

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=4&day=11&hour=9&min=0&sec=0&p1=241&p2=137&p3=179&p4=136&p5=37&p6=248

US-West US-East UK DE TW JP
02:00 05:00 10:00 11:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Agenda:

* AI review
#action Send email to Daniel for SW update update – szlin
-> Done
#action Daniel has to upload to the wiki the SW updates tool comparison document
-> Done
#action Send discussion of deby naming to cip-dev - Kazu
#action The review results from Pavel will be confirmed - Iwamatsu-san

* Kernel maintenance updates
* Kernel testing
* CIP Core
* Software update
* AOB

The meeting will take 30 min although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,

SZ Lin, Moxa.


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

Nobuhiro Iwamatsu
 

Hi, Fabrizio

-----Original Message-----
From: cip-dev-bounces@lists.cip-project.org
[mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Fabrizio
Castro
Sent: Wednesday, April 10, 2019 6:17 PM
To: Pavel Machek <pavel@denx.de>
Cc: cip-dev@lists.cip-project.org; Biju Das <biju.das@bp.renesas.com>
Subject: Re: [cip-dev] [PATCH 4.19y 01/10] pinctrl: sh-pfc: r8a77990:
Add CAN pins, groups and functions

Hello Pavel,

Thank you for your feedback.

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

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>
This does not apply. My kernel still has:

- struct sh_pfc_pin_group common[117];
while this expects... way higher number. I tried to look at pending
patches in patchwork, that maybe if I tried to apply everything it
would work, but could not get that to work, either.

Current status of the tree is at:

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/lo
g/
?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.
Pavel and I are reviewing the patch now.
Although we share patches, we have such a problem because we do not consider the dependencies of each series.
The patch review by two people has just begun, so I think there are many problems. The kernel team will talk about this.

Pavel, do you have comment about this?

If possible, it would be helpful if you could write a patch series dependency on the cover letter of series.

Best regards,
Nobuhiro


Thanks,
Fab


Thanks and sorry for confusion,
Pavel
Best regards,
Nobuhiro

@@ -3475,7 +3504,7 @@ static const unsigned int vin5_clk_b_mux[] =
{
};

static const struct {
- struct sh_pfc_pin_group common[238];
+ struct sh_pfc_pin_group common[241];
struct sh_pfc_pin_group automotive[0]; } pinmux_groups = {
.common = {
@@ -3504,6 +3533,9 @@ static const struct {


--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev


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

Nobuhiro Iwamatsu
 

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.

Best regards,
Nobuhiro


Re: [PATCH 1/9] clk: renesas: Add r8a774c0 CPG Core Clock Definitions

Nobuhiro Iwamatsu
 

Hi,

-----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 12:12 AM
To: cip-dev@lists.cip-project.org
Cc: Biju Das <biju.das@bp.renesas.com>
Subject: [cip-dev] [PATCH 1/9] clk: renesas: Add r8a774c0 CPG Core Clock
Definitions

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

Add all RZ/G2E (a.k.a. R8A774C0) Clock Pulse Generator Core Clock Outputs,
as listed in Table 8.2g ("List of Clocks
[RZ/G2E]") of the RZ/G2 Hardware User's Manual.

I applied this series, thanks.

Best regards,
Nobuhiro


Re: [PATCH 4.19.y 6/9] arm64: dts: renesas: r8a774c0: Add I2C and IIC-DVFS support

Nobuhiro Iwamatsu
 

Hi,

-----Original Message-----
From: Pavel Machek [mailto:pavel@denx.de]
Sent: Wednesday, April 10, 2019 5:17 PM
To: iwamatsu nobuhiro(岩松 信洋 ○SWC□OST)
<nobuhiro1.iwamatsu@toshiba.co.jp>
Cc: biju.das@bp.renesas.com; pavel@denx.de;
cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] [PATCH 4.19.y 6/9] arm64: dts: renesas: r8a774c0:
Add I2C and IIC-DVFS support

On Wed 2019-04-10 08:09:14, nobuhiro1.iwamatsu@toshiba.co.jp wrote:
Hi, Biju.

This patch "arm64: dts: renesas: Initial device tree for r8a774c0"
have "arch/arm64/boot/dts/renesas/r8a774c0.dtsi"

https://lists.cip-project.org/pipermail/cip-dev/2019-March/001917.ht
ml

Do you want me to send it again?
You do not need to send.
This patch has been reviewed and committed to linux-4.19.y-cip branch
by me.
Thank you!

But I don't see anything new at
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/
. Did you forget to push or is it still processing?
I was pushing to gitlab. I pushed to kernel.org about 1 hours ago.
Sorry for this.

Best regards,
Nobuhiro

5421 - 5440 of 7505