Date   

[PATCH 2/2] ARM: dts: r8a7743: Add PMU device node

Patryk Mungai <patryk.mungai-ndungu.kx@...>
 

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

Commit fe60e933b053f00e53cd01fe323f25ebe8fecd52 upstream.

Enable support for the ARM Performance Monitor Units in the Cortex-A15
CPU cores on RZ/G1M by adding a device node for the PMU.

New Linux output:

hw perfevents: enabled with armv7_cortex_a15 PMU driver, 7 counters available

Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Simon Horman <horms+renesas@...>

[Backport to CIP]
Signed-off-by: Patryk Mungai <patryk.mungai-ndungu.kx@...>
Reviewed-by: Chris Paterson <Chris.Paterson2@...>
---
arch/arm/boot/dts/r8a7743.dtsi | 7 +++++++
1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index c78de96..264c8e0 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -76,6 +76,13 @@
};
};

+ pmu {
+ compatible = "arm,cortex-a15-pmu";
+ interrupts-extended = <&gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu0>, <&cpu1>;
+ };
+
soc {
compatible = "simple-bus";
interrupt-parent = <&gic>;
--
2.7.4


[PATCH 1/2] ARM: dts: r8a7745: Add PMU device node

Patryk Mungai <patryk.mungai-ndungu.kx@...>
 

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

Commit 9562a6b1d0f6a287f5dda16a4538526c59408927 upstream.

Enable support for the ARM Performance Monitor Units in the Cortex-A7
CPU cores on RZ/G1E by adding a device node for the PMU.

New Linux output:

hw perfevents: enabled with armv7_cortex_a7 PMU driver, 5 counters available

Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Simon Horman <horms+renesas@...>

[Backport to CIP]
Signed-off-by: Patryk Mungai <patryk.mungai-ndungu.kx@...>
Reviewed-by: Chris Paterson <Chris.Paterson2@...>
---
arch/arm/boot/dts/r8a7745.dtsi | 7 +++++++
1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 69b383c..54b556b 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -93,6 +93,13 @@
};
};

+ pmu {
+ compatible = "arm,cortex-a7-pmu";
+ interrupts-extended = <&gic GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu0>, <&cpu1>;
+ };
+
soc {
compatible = "simple-bus";
interrupt-parent = <&gic>;
--
2.7.4


[PATCH 0/2] Add PMU support to iwg2[02]m

Patryk Mungai <patryk.mungai-ndungu.kx@...>
 

Backport PMU support for iwg2[02]m to the CIP Kernel from mainline.

Geert Uytterhoeven (2):
ARM: dts: r8a7745: Add PMU device node
ARM: dts: r8a7743: Add PMU device node

arch/arm/boot/dts/r8a7743.dtsi | 7 +++++++
arch/arm/boot/dts/r8a7745.dtsi | 7 +++++++
2 files changed, 14 insertions(+)

--
2.7.4


wiki updates

Daniel Sangorrin <daniel.sangorrin@...>
 

Hello all,

I have added a few updates to the wiki [1]. In particular:
- Added a link to the kernel configuration files sent by all members
- Added links to Ben's kernel configuration suggestions.
- Added a link to our new patchwork website (thanks Chris!)

Best regards,
Daniel

[1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance#maintenance-scope


Re: [PATCH] ARM: dts: r8a77(43|9[013]): Add missing OPP properties for CPUs

岩松信洋 <nobuhiro.iwamatsu@...>
 

Hi, Chris.

Thanks for update and resend patch.

2018年10月12日(金) 5:40 Chris Paterson <chris.paterson2@...>:

From: Viresh Kumar <viresh.kumar@...>

commit 8199e49ff1f654bbe8bed90fd6710bc097a89d02 upstream.

The OPP properties, like "operating-points", should either be present
for all the CPUs of a cluster or none. If these are present only for a
subset of CPUs of a cluster then things will start falling apart as soon
as the CPUs are brought online in a different order. For example, this
will happen because the operating system looks for such properties in
the CPU node it is trying to bring up, so that it can create an OPP
table.

Add such missing properties.

Fix other missing properties (like, clock latency, voltage tolerance,
etc) as well to make it all work.

Signed-off-by: Viresh Kumar <viresh.kumar@...>
Reviewed-by: Simon Horman <horms+renesas@...>
Signed-off-by: Simon Horman <horms+renesas@...>

[Backport to CIP: dropped changes to r8a779[013] SoCs dtsi]
Signed-off-by: Patryk Mungai <patryk.mungai-ndungu.kx@...>
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
LGTM. I've applied this, thanks.

Best regards,
Nobuhiro
---
Resending this patch to test patchwork (and because it needs reviewing).
---
arch/arm/boot/dts/r8a7743.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index c78de96bfc29e47a..f41e3a5cdf9c053d 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -66,7 +66,16 @@
reg = <1>;
clock-frequency = <1500000000>;
clocks = <&cpg_clocks R8A7743_CLK_Z>;
+ clock-latency = <300000>; /* 300 us */
next-level-cache = <&L2_CA15>;
+
+ /* kHz - uV - OPPs unknown yet */
+ operating-points = <1500000 1000000>,
+ <1312500 1000000>,
+ <1125000 1000000>,
+ < 937500 1000000>,
+ < 750000 1000000>,
+ < 375000 1000000>;
};

L2_CA15: cache-controller-0 {
--
1.9.1

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


CIP-dev IRC weekly meeting log: week 41

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

Hi,

Please find the logs of CIP meeting last week in below link:

https://irclogs.baserock.org/cip/%23cip.2018-10-11.log.html#t2018-10-11T08:00:07

We have 2 action items:

#action iwamatsu will review the CIP patch - https://lists.cip-project.org/pipermail/cip-dev/2018-September/001552.html
#action sangorrin will create wiki pages for CIP kernel configuration

SZ Lin, Moxa


cip-dev Patchwork

Chris Paterson
 

Hello all,

 

We now have a working instance of Patchwork for the cip-dev mailing list.

 

From the Patchwork documentation:

“Patchwork is a patch tracking system for community-based projects. It is intended to make the patch management process easier for both the project’s contributors and maintainers, leaving time for the more important (and more interesting) stuff.

 

Patches that have been sent to a mailing list are ‘caught’ by the system, and appear on a web page. Any comments posted that reference the patch are appended to the patch page too. The project’s maintainer can then scan through the list of patches, marking each with a certain state, such as Accepted, Rejected or Under Review. Old patches can be sent to the archive or deleted.”

 

Submitted patches should automatically be picked up and listed on kernel.org [1].

 

Full documentation on how to use Patchwork is available on readthedocs [2].

 

Acked-by/Reviewed-by/Tested-by tags should automatically be picked up through cip-dev.

 

Maintainers can mark patches as accepted/rejected/under review etc. If you’d like to be a maintainer please let myself or Iwamatsu-san know.

 

 

[1] https://patchwork.kernel.org/project/cip-dev/list/

[2] https://patchwork.readthedocs.io/en/latest/

 

Kind regards, Chris


[PATCH] ARM: dts: r8a77(43|9[013]): Add missing OPP properties for CPUs

Chris Paterson
 

From: Viresh Kumar <viresh.kumar@...>

commit 8199e49ff1f654bbe8bed90fd6710bc097a89d02 upstream.

The OPP properties, like "operating-points", should either be present
for all the CPUs of a cluster or none. If these are present only for a
subset of CPUs of a cluster then things will start falling apart as soon
as the CPUs are brought online in a different order. For example, this
will happen because the operating system looks for such properties in
the CPU node it is trying to bring up, so that it can create an OPP
table.

Add such missing properties.

Fix other missing properties (like, clock latency, voltage tolerance,
etc) as well to make it all work.

Signed-off-by: Viresh Kumar <viresh.kumar@...>
Reviewed-by: Simon Horman <horms+renesas@...>
Signed-off-by: Simon Horman <horms+renesas@...>

[Backport to CIP: dropped changes to r8a779[013] SoCs dtsi]
Signed-off-by: Patryk Mungai <patryk.mungai-ndungu.kx@...>
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
---
Resending this patch to test patchwork (and because it needs reviewing).
---
arch/arm/boot/dts/r8a7743.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index c78de96bfc29e47a..f41e3a5cdf9c053d 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -66,7 +66,16 @@
reg = <1>;
clock-frequency = <1500000000>;
clocks = <&cpg_clocks R8A7743_CLK_Z>;
+ clock-latency = <300000>; /* 300 us */
next-level-cache = <&L2_CA15>;
+
+ /* kHz - uV - OPPs unknown yet */
+ operating-points = <1500000 1000000>,
+ <1312500 1000000>,
+ <1125000 1000000>,
+ < 937500 1000000>,
+ < 750000 1000000>,
+ < 375000 1000000>;
};

L2_CA15: cache-controller-0 {
--
1.9.1


CIP kernel IRC weekly meeting today

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

Hi All,

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

US-West US-East  UK    DE     TW     JP
01:00    04:00   09:00   10:00   16:00   17:00

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

Agenda:
* AI review
- AI: patersonc will apply patchwork for CIP kernel maintenance team
* Kernel maintenance updates
* Kernel testing
* 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


Re: Kernel configurations in the CIP project

Nicholas Mc Guire <der.herr@...>
 

On Mon, Oct 08, 2018 at 02:33:32PM +0200, Jan Kiszka wrote:
On 05.10.18 06:10, Nicholas Mc Guire wrote:
On Thu, Oct 04, 2018 at 02:51:46PM +0100, Ben Hutchings wrote:
On Wed, 2018-10-03 at 08:33 +0900, Daniel Sangorrin wrote:
Hello Lukas,

-----Original Message-----
From: cip-dev-bounces@...
Hi Robert,

If I recall our conversation and follow the discussion on cip-dev correctly, you are still
maintaining the test builds and infrastructure from the CIP project, right?

Could you provide to Markus Kreidl, Nicholas McGuire (see CC) and me the kernel
configurations you use in the test builds for the different CIP members?
Not sure about the configs that Robert uses for testing, but the configurations from CIP members can be found here.
https://gitlab.com/cip-project/cip-kernel/cip-kernel-config
[...]

I think these are the configurations that Lukas needs - they are the
configurations that should be used for determining whether commits are
relevant to CIP.
ok - we started playing with them the siemens iot config seems very large to me is that
a designed config or did that "happen" ?
The IOT2000 is an open platform, and that naturally brings in the need to
have more features preconfigured than one would selected in a dedicated
devices, e.g. drivers for pluggable devices.
ok - but that makes the evaluation of actual impact quite hard
so it would be very helpful to have a realistic reference example for
a particular use-case if that is possible. The current configuration
will give a very pesemistic view of the potential impact. Do you know
if there is some Use-Case that we could use as a comparison ?

thx!
hofrat


CIP Reference Board Wiki pages

Chris Paterson
 

Hello all,

 

FYI I have created a new Wiki page [1] that details our current selection of reference platforms. Hopefully I have got the list correct (I wasn’t too sure on the naming).

 

I have also added specific details for the RZ/G1M platform [2], including how to build the CIP Kernel and Renesas BSP.

 

Please feel free to amend/suggest improvements as you see fit!

 

[1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipreferencehardware

[2] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipreferencehardware/iwg20m

 

Kind regards, Chris


Re: Kernel configurations in the CIP project

Jan Kiszka
 

On 05.10.18 06:10, Nicholas Mc Guire wrote:
On Thu, Oct 04, 2018 at 02:51:46PM +0100, Ben Hutchings wrote:
On Wed, 2018-10-03 at 08:33 +0900, Daniel Sangorrin wrote:
Hello Lukas,

-----Original Message-----
From: cip-dev-bounces@...
Hi Robert,

If I recall our conversation and follow the discussion on cip-dev correctly, you are still
maintaining the test builds and infrastructure from the CIP project, right?

Could you provide to Markus Kreidl, Nicholas McGuire (see CC) and me the kernel
configurations you use in the test builds for the different CIP members?
Not sure about the configs that Robert uses for testing, but the configurations from CIP members can be found here.
https://gitlab.com/cip-project/cip-kernel/cip-kernel-config
[...]

I think these are the configurations that Lukas needs - they are the
configurations that should be used for determining whether commits are
relevant to CIP.
ok - we started playing with them the siemens iot config seems very large to me is that
a designed config or did that "happen" ?
The IOT2000 is an open platform, and that naturally brings in the need to have more features preconfigured than one would selected in a dedicated devices, e.g. drivers for pluggable devices.

Jan

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


CIP-dev IRC weekly meeting log: week 40

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

Hi,

 

Sorry for the late, please find the logs of CIP meeting last week in below link:

 

https://irclogs.baserock.org/cip/%23cip.2018-10-04.log.html#t2018-10-04T08:00:06

 

We have 1 action item:

 

#action patersonc will apply patchwork for CIP kernel maintenance team

 

SZ Lin, Moxa

 


cip-dev progress report weeks 39-40

Robert Marshall <robert.marshall@...>
 

Hi! Reporting on the Codethink CIP testing development over the
past 2 weeks.

CIP kernel testing

- A provisioned box with the latest master is in preparation and
should be available early next week.

Renesas Board

- The iwg20m board now works reliably with board at desk an MR
having been made and accepted - thanks to Nguyen for assistance with this.

Health Checks
- Regular health checks are now performed with the iwg20m board as
well as the beaglebone.

Robert
--
Robert Marshall, Software Developer Codethink Ltd
Telephone: +44 7762 840 414 3rd Floor, Dale House, 35 Dale Street
https://www.codethink.co.uk/ MANCHESTER, M1 2HF. United Kingdom


Re: Kernel configurations in the CIP project

Nicholas Mc Guire <der.herr@...>
 

On Thu, Oct 04, 2018 at 02:51:46PM +0100, Ben Hutchings wrote:
On Wed, 2018-10-03 at 08:33 +0900, Daniel Sangorrin wrote:
Hello Lukas,

-----Original Message-----
From: cip-dev-bounces@...
Hi Robert,

If I recall our conversation and follow the discussion on cip-dev correctly, you are still
maintaining the test builds and infrastructure from the CIP project, right?

Could you provide to Markus Kreidl, Nicholas McGuire (see CC) and me the kernel
configurations you use in the test builds for the different CIP members?
Not sure about the configs that Robert uses for testing, but the configurations from CIP members can be found here.
https://gitlab.com/cip-project/cip-kernel/cip-kernel-config
[...]

I think these are the configurations that Lukas needs - they are the
configurations that should be used for determining whether commits are
relevant to CIP.
ok - we started playing with them the siemens iot config seems very large to me is that
a designed config or did that "happen" ?

thx!
hofrat


Re: Kernel configurations in the CIP project

Lukas Bulwahn <Lukas.Bulwahn@...>
 

On 2018-10-04, 15:52, "Ben Hutchings" <ben.hutchings@...> wrote:

On Wed, 2018-10-03 at 08:33 +0900, Daniel Sangorrin wrote:
> Hello Lukas,
>
> > -----Original Message-----
> > From: cip-dev-bounces@...
> > Hi Robert,
> >
> > If I recall our conversation and follow the discussion on cip-dev correctly, you are still
> > maintaining the test builds and infrastructure from the CIP project, right?
> >
> > Could you provide to Markus Kreidl, Nicholas McGuire (see CC) and me the kernel
> > configurations you use in the test builds for the different CIP members?
>
> Not sure about the configs that Robert uses for testing, but the configurations from CIP members can be found here.
> https://gitlab.com/cip-project/cip-kernel/cip-kernel-config
[...]

I think these are the configurations that Lukas needs - they are the
configurations that should be used for determining whether commits are
relevant to CIP.

Thanks for all the responses. I believe Markus Kreidl is already looking how he can produce useful information for the cip releases and those configs.


Lukas


Re: Kernel feature support

Ben Hutchings <ben.hutchings@...>
 

On Sat, 2018-03-31 at 07:56 +0000, Wes Huang (黃淵河) wrote:
Hi,
 
Sorry for the late reply.
 
Please find attached a Moxa kernel configuration using CIP kernel
4.4.
And sorry for this extremely late response.

I will recommend disabling various features. I recognise that you may
have applications that already require the features, and it may be
impractical to change that. But you should consider seriously that
they may reduce the long-term security and reliability of those
applications.

Filesystems: I recommend disabling btrfs (CONFIG_BTRFS_FS), ceph
(CONFIG_CEPH_LIB, CONFIG_CEPH_FS), cifs (CONFIG_CIFS_FS), nfs
(CONFIG_NFS_FS, CONFIG_NFSD), ntfs (CONFIG_NTFS_FS), and xfs
(CONFIG_XFS_FS), for the reasons given in
<https://lists.cip-project.org/pipermail/cip-dev/2017-May/000263.html>.
I would add to that list afs (CONFIG_AFS_FS), coda (CONFIG_CODA_FS),
gfs2 (CONFIG_GFS2_FS), ncpfs (CONFIG_NCPFS_FS), and ocfs2
(CONFIG_OCFS2_FS) which have the same issue as the other network
filesystems.

Network protocols: I recommend disabling batman-adv
(CONFIG_BATMAN_ADV), dcb (CONFIG_DCB), hsr (CONFIG_HSR), phonet
(CONFIG_PHONET), sctp (CONFIG_IP_SCTP), for the reasons given in
<https://lists.cip-project.org/pipermail/cip-dev/2017-May/000263.html>.
I would now add to the list dccp (CONFIG_IP_DCCP), which has a poor
security record.

Storage drivers: I recommend disabling dm-cache (CONFIG_DM_CACHE),
dm-switch (CONFIG_DM_SWITCH), MD multipath (CONFIG_MD_MULTIPATH) for
the reasons given in
<https://lists.cip-project.org/pipermail/cip-dev/2017-July/000387.html>.

Network drivers: I recommend disabling USB-attached network drivers
and wireless networking if possible, for the reasons given in
<https://lists.cip-project.org/pipermail/cip-dev/2017-July/000387.html>.

I recommend disabling CONFIG_DEVKMEM and CONFIG_DEVMEM, for the reasons
given in
<https://lists.cip-project.org/pipermail/cip-dev/2017-July/000387.html>.

I recommend enabling the kernel stack protector (either
CONFIG_CC_STACKPROTECTOR_REGULAR or CONFIG_CC_STACKPROTECTOR_STRONG)
and enabling heap address randomisation for user-space by default, by
*disabling* CONFIG_COMPAT_BRK.

I recommend enabling module symbol versioning (CONFIG_MODVERSIONS) in
order to catch mistakes.

Since you have CONFIG_PERF_EVENTS enabled, consider restricting use of
performance events to privileged users. (This requires a patch that
was not accepted upstream, so unfortunately it's not suitable for CIP
kernel branches. It's in the Debian and Android kernel sources.)

I recommend disabling obsolete system calls (CONFIG_SYSFS_SYSCALL,
CONFIG_UID16, and CONFIG_USELIB).

You have user namespaces (CONFIG_USER_NS) enabled. Consider disabling
it or restricting creation of user namespaces to privileged users.
(This also requires a patch that was not accepted upstream. It's in
the Debian kernel sources.)

I recommend enabling linked list debug checks (CONFIG_LIST_DEBUG),
which can make it harder to exploit some bugs.

I recommend disabling timer statistics (CONFIG_TIMER_STATS). This
feature has been removed upstream, so is not maintainable.  Apparently
there are tracepoints that provide similar functionality. 

Ben.

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


Re: Kernel configurations in the CIP project

Ben Hutchings <ben.hutchings@...>
 

On Wed, 2018-10-03 at 08:33 +0900, Daniel Sangorrin wrote:
Hello Lukas,

-----Original Message-----
From: cip-dev-bounces@...
Hi Robert,

If I recall our conversation and follow the discussion on cip-dev correctly, you are still
maintaining the test builds and infrastructure from the CIP project, right?

Could you provide to Markus Kreidl, Nicholas McGuire (see CC) and me the kernel
configurations you use in the test builds for the different CIP members?
Not sure about the configs that Robert uses for testing, but the configurations from CIP members can be found here.
https://gitlab.com/cip-project/cip-kernel/cip-kernel-config
[...]

I think these are the configurations that Lukas needs - they are the
configurations that should be used for determining whether commits are
relevant to CIP.

Ben.

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


[Git][cip-project/cip-testing/board-at-desk-single-dev][master] 2 commits: Use zImage to fix the iwg20m health check failures #186

Agustin Benito Bethencourt
 

Robert Marshall pushed to branch master at cip-project / cip-testing / board-at-desk-single-dev

Commits:

  • 924551c5
    by Robert Marshall at 2018-09-28T09:26:20Z
    Use zImage to fix the iwg20m health check failures #186
    
    LAVA converts the zImage to a uImage using bootm_kernel_addr
    which can cause iwg20m not to boot.
    
  • 333024a2
    by Robert Marshall at 2018-10-04T13:44:50Z
    Merge branch 'iwg20m-usezImage' into 'master'
    
    Use zImage to fix the iwg20m health check failures #186
    
    See merge request cip-project/cip-testing/board-at-desk-single-dev!63

2 changed files:

Changes:

  • device-types/renesas-iwg20m.jinja2
    ... ... @@ -4,11 +4,11 @@
    4 4
     {% set baud_rate = baud_rate|default(115200) %}
    
    5 5
     {% set device_type = "renesas-iwg20m" %}
    
    6 6
     {% set bootloader_prompt = bootloader_prompt|default('iWave-G20M >') %}
    
    7
    -{% set kernel_file = kernel_file | default('uImage') %}
    
    7
    +{% set kernel_file = kernel_file | default('zImage') %}
    
    8 8
     {% set dtb_file = dtb_file | default('r8a7743-iwg20d-q7.dtb') %}
    
    9
    -{% set bootm_kernel_addr = '0x40007fc0' %}
    
    10
    -{% set bootm_ramdisk_addr = '0x41000000' %}
    
    11
    -{% set bootm_dtb_addr = '0x40f00000' %}
    
    9
    +{% set bootz_kernel_addr = '0x40008000' %}
    
    10
    +{% set bootz_ramdisk_addr = '0x41000000' %}
    
    11
    +{% set bootz_dtb_addr = '0x40f00000' %}
    
    12 12
     {% set bootm_low = '0x41e00000' %}
    
    13 13
     {% set bootm_size = '0x100000' %}
    
    14 14
     {% set fdt_addr = '0x40f00000' %}
    

  • tests/iwg20m-test-ramdisk.yaml
    ... ... @@ -47,7 +47,6 @@ actions:
    47 47
           - '\(initramfs\)'
    
    48 48
         method: u-boot
    
    49 49
         commands: ramdisk
    
    50
    -    type: uimage
    
    51 50
         timeout:
    
    52 51
           minutes: 5
    
    53 52
     
    


  • Re: Kernel configurations in the CIP project

    Robert Marshall <robert.marshall@...>
     

    Lukas

    Thanks for your email, comments below.

    Lukas Bulwahn <Lukas.Bulwahn@...> writes:

    Hi Robert,

    If I recall our conversation and follow the discussion on cip-dev
    correctly, you are still maintaining the test builds and
    infrastructure from the CIP project, right?
    That's correct

    Could you provide to Markus Kreidl, Nicholas McGuire (see CC) and me
    the kernel configurations you use in the test builds for the different
    CIP members?
    I'm using the kernel versions with the latest CIP tag, I use exactly
    the procedure described on this page

    https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipsystembuildhowto#building-the-cip-kernel-with-kernel-ci

    building for the beaglebone black and the Renesas iwg20m board.


    Robert

    Background:

    Markus Kreidl has written a tool that determines which patches, which
    hunks of those patches are relevant to a given configuration. We would
    be interested in providing an overview of which patches are especially
    relevant for the given configs of a new CIP kernel patchlevel release,
    and hence, the CIP maintainers (hopefully, it is not just Ben) are
    informed about those and can have a good look at those specific
    patches when they provide a new kernel release version.

    If it useful, we would follow-up how to make that fit nicely into the
    existing review and reporting process. If it not useful, we learned a
    lesson about our tool.

    Best regards,

    Lukas
    
    --
    Robert Marshall, Software Developer Codethink Ltd
    Telephone: +44 7762 840 414 3rd Floor, Dale House, 35 Dale Street
    https://www.codethink.co.uk/ MANCHESTER, M1 2HF. United Kingdom

    8101 - 8120 of 9694