Date   

[PATCH 4.19.y-cip 08/17] drm: Add atomic variants for bridge enable/disable

Biju Das <biju.das.jz@...>
 

From: Sean Paul <seanpaul@chromium.org>

commit 5ade071ba13e3bb24e3a9d5f8d6a3cf145deeb18 upstream.

This patch adds atomic variants for all of
pre_enable/enable/disable/post_disable bridge functions. These will be
called from the appropriate atomic helper functions. If the bridge
driver doesn't implement the atomic version of the function, we will
fall back to the vanilla implementation.

Note that some drivers call drm_bridge_disable directly, and these cases
are not covered. It's up to the driver to decide whether to implement
both atomic_disable and disable, or if it's not necessary.

Changes in v3:
- Added to the patchset
Changes in v4:
- Fix up docbook references (Daniel)
Changes in v5:
- None

Link to v3: https://patchwork.freedesktop.org/patch/msgid/20190502194956.218441-4-sean@poorly.run
Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-4-sean@poorly.run

Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190611160844.257498-4-sean@poorly.run
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
drivers/gpu/drm/drm_atomic_helper.c | 8 +-
drivers/gpu/drm/drm_bridge.c | 110 ++++++++++++++++++++++++++++
include/drm/drm_bridge.h | 106 +++++++++++++++++++++++++++
3 files changed, 220 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index c22062cc9992..84bc8af8fc71 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -951,7 +951,7 @@ disable_outputs(struct drm_device *dev, struct drm_atomic_state *old_state)
* Each encoder has at most one connector (since we always steal
* it away), so we won't call disable hooks twice.
*/
- drm_bridge_disable(encoder->bridge);
+ drm_atomic_bridge_disable(encoder->bridge, old_state);

/* Right function depends upon target state. */
if (funcs) {
@@ -963,7 +963,7 @@ disable_outputs(struct drm_device *dev, struct drm_atomic_state *old_state)
funcs->dpms(encoder, DRM_MODE_DPMS_OFF);
}

- drm_bridge_post_disable(encoder->bridge);
+ drm_atomic_bridge_post_disable(encoder->bridge, old_state);
}

for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) {
@@ -1262,7 +1262,7 @@ void drm_atomic_helper_commit_modeset_enables(struct drm_device *dev,
* Each encoder has at most one connector (since we always steal
* it away), so we won't call enable hooks twice.
*/
- drm_bridge_pre_enable(encoder->bridge);
+ drm_atomic_bridge_pre_enable(encoder->bridge, old_state);

if (funcs) {
if (funcs->enable)
@@ -1271,7 +1271,7 @@ void drm_atomic_helper_commit_modeset_enables(struct drm_device *dev,
funcs->commit(encoder);
}

- drm_bridge_enable(encoder->bridge);
+ drm_atomic_bridge_enable(encoder->bridge, old_state);
}

drm_atomic_helper_commit_writebacks(dev, old_state);
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 1638bfe9627c..190f43380e29 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -348,6 +348,116 @@ void drm_bridge_enable(struct drm_bridge *bridge)
}
EXPORT_SYMBOL(drm_bridge_enable);

+/**
+ * drm_atomic_bridge_disable - disables all bridges in the encoder chain
+ * @bridge: bridge control structure
+ * @state: atomic state being committed
+ *
+ * Calls &drm_bridge_funcs.atomic_disable (falls back on
+ * &drm_bridge_funcs.disable) op for all the bridges in the encoder chain,
+ * starting from the last bridge to the first. These are called before calling
+ * &drm_encoder_helper_funcs.atomic_disable
+ *
+ * Note: the bridge passed should be the one closest to the encoder
+ */
+void drm_atomic_bridge_disable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state)
+{
+ if (!bridge)
+ return;
+
+ drm_atomic_bridge_disable(bridge->next, state);
+
+ if (bridge->funcs->atomic_disable)
+ bridge->funcs->atomic_disable(bridge, state);
+ else if (bridge->funcs->disable)
+ bridge->funcs->disable(bridge);
+}
+EXPORT_SYMBOL(drm_atomic_bridge_disable);
+
+/**
+ * drm_atomic_bridge_post_disable - cleans up after disabling all bridges in the
+ * encoder chain
+ * @bridge: bridge control structure
+ * @state: atomic state being committed
+ *
+ * Calls &drm_bridge_funcs.atomic_post_disable (falls back on
+ * &drm_bridge_funcs.post_disable) op for all the bridges in the encoder chain,
+ * starting from the first bridge to the last. These are called after completing
+ * &drm_encoder_helper_funcs.atomic_disable
+ *
+ * Note: the bridge passed should be the one closest to the encoder
+ */
+void drm_atomic_bridge_post_disable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state)
+{
+ if (!bridge)
+ return;
+
+ if (bridge->funcs->atomic_post_disable)
+ bridge->funcs->atomic_post_disable(bridge, state);
+ else if (bridge->funcs->post_disable)
+ bridge->funcs->post_disable(bridge);
+
+ drm_atomic_bridge_post_disable(bridge->next, state);
+}
+EXPORT_SYMBOL(drm_atomic_bridge_post_disable);
+
+/**
+ * drm_atomic_bridge_pre_enable - prepares for enabling all bridges in the
+ * encoder chain
+ * @bridge: bridge control structure
+ * @state: atomic state being committed
+ *
+ * Calls &drm_bridge_funcs.atomic_pre_enable (falls back on
+ * &drm_bridge_funcs.pre_enable) op for all the bridges in the encoder chain,
+ * starting from the last bridge to the first. These are called before calling
+ * &drm_encoder_helper_funcs.atomic_enable
+ *
+ * Note: the bridge passed should be the one closest to the encoder
+ */
+void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state)
+{
+ if (!bridge)
+ return;
+
+ drm_atomic_bridge_pre_enable(bridge->next, state);
+
+ if (bridge->funcs->atomic_pre_enable)
+ bridge->funcs->atomic_pre_enable(bridge, state);
+ else if (bridge->funcs->pre_enable)
+ bridge->funcs->pre_enable(bridge);
+}
+EXPORT_SYMBOL(drm_atomic_bridge_pre_enable);
+
+/**
+ * drm_atomic_bridge_enable - enables all bridges in the encoder chain
+ * @bridge: bridge control structure
+ * @state: atomic state being committed
+ *
+ * Calls &drm_bridge_funcs.atomic_enable (falls back on
+ * &drm_bridge_funcs.enable) op for all the bridges in the encoder chain,
+ * starting from the first bridge to the last. These are called after completing
+ * &drm_encoder_helper_funcs.atomic_enable
+ *
+ * Note: the bridge passed should be the one closest to the encoder
+ */
+void drm_atomic_bridge_enable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state)
+{
+ if (!bridge)
+ return;
+
+ if (bridge->funcs->atomic_enable)
+ bridge->funcs->atomic_enable(bridge, state);
+ else if (bridge->funcs->enable)
+ bridge->funcs->enable(bridge);
+
+ drm_atomic_bridge_enable(bridge->next, state);
+}
+EXPORT_SYMBOL(drm_atomic_bridge_enable);
+
#ifdef CONFIG_OF
/**
* of_drm_find_bridge - find the bridge corresponding to the device node in
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index d26eaa317fc2..97b17cb9cc51 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -237,6 +237,103 @@ struct drm_bridge_funcs {
* The enable callback is optional.
*/
void (*enable)(struct drm_bridge *bridge);
+
+ /**
+ * @atomic_pre_enable:
+ *
+ * This callback should enable the bridge. It is called right before
+ * the preceding element in the display pipe is enabled. If the
+ * preceding element is a bridge this means it's called before that
+ * bridge's @atomic_pre_enable or @pre_enable function. If the preceding
+ * element is a &drm_encoder it's called right before the encoder's
+ * &drm_encoder_helper_funcs.atomic_enable hook.
+ *
+ * The display pipe (i.e. clocks and timing signals) feeding this bridge
+ * will not yet be running when this callback is called. The bridge must
+ * not enable the display link feeding the next bridge in the chain (if
+ * there is one) when this callback is called.
+ *
+ * Note that this function will only be invoked in the context of an
+ * atomic commit. It will not be invoked from &drm_bridge_pre_enable. It
+ * would be prudent to also provide an implementation of @pre_enable if
+ * you are expecting driver calls into &drm_bridge_pre_enable.
+ *
+ * The @atomic_pre_enable callback is optional.
+ */
+ void (*atomic_pre_enable)(struct drm_bridge *bridge,
+ struct drm_atomic_state *state);
+
+ /**
+ * @atomic_enable:
+ *
+ * This callback should enable the bridge. It is called right after
+ * the preceding element in the display pipe is enabled. If the
+ * preceding element is a bridge this means it's called after that
+ * bridge's @atomic_enable or @enable function. If the preceding element
+ * is a &drm_encoder it's called right after the encoder's
+ * &drm_encoder_helper_funcs.atomic_enable hook.
+ *
+ * The bridge can assume that the display pipe (i.e. clocks and timing
+ * signals) feeding it is running when this callback is called. This
+ * callback must enable the display link feeding the next bridge in the
+ * chain if there is one.
+ *
+ * Note that this function will only be invoked in the context of an
+ * atomic commit. It will not be invoked from &drm_bridge_enable. It
+ * would be prudent to also provide an implementation of @enable if
+ * you are expecting driver calls into &drm_bridge_enable.
+ *
+ * The enable callback is optional.
+ */
+ void (*atomic_enable)(struct drm_bridge *bridge,
+ struct drm_atomic_state *state);
+ /**
+ * @atomic_disable:
+ *
+ * This callback should disable the bridge. It is called right before
+ * the preceding element in the display pipe is disabled. If the
+ * preceding element is a bridge this means it's called before that
+ * bridge's @atomic_disable or @disable vfunc. If the preceding element
+ * is a &drm_encoder it's called right before the
+ * &drm_encoder_helper_funcs.atomic_disable hook.
+ *
+ * The bridge can assume that the display pipe (i.e. clocks and timing
+ * signals) feeding it is still running when this callback is called.
+ *
+ * Note that this function will only be invoked in the context of an
+ * atomic commit. It will not be invoked from &drm_bridge_disable. It
+ * would be prudent to also provide an implementation of @disable if
+ * you are expecting driver calls into &drm_bridge_disable.
+ *
+ * The disable callback is optional.
+ */
+ void (*atomic_disable)(struct drm_bridge *bridge,
+ struct drm_atomic_state *state);
+
+ /**
+ * @atomic_post_disable:
+ *
+ * This callback should disable the bridge. It is called right after the
+ * preceding element in the display pipe is disabled. If the preceding
+ * element is a bridge this means it's called after that bridge's
+ * @atomic_post_disable or @post_disable function. If the preceding
+ * element is a &drm_encoder it's called right after the encoder's
+ * &drm_encoder_helper_funcs.atomic_disable hook.
+ *
+ * The bridge must assume that the display pipe (i.e. clocks and timing
+ * signals) feeding it is no longer running when this callback is
+ * called.
+ *
+ * Note that this function will only be invoked in the context of an
+ * atomic commit. It will not be invoked from &drm_bridge_post_disable.
+ * It would be prudent to also provide an implementation of
+ * @post_disable if you are expecting driver calls into
+ * &drm_bridge_post_disable.
+ *
+ * The post_disable callback is optional.
+ */
+ void (*atomic_post_disable)(struct drm_bridge *bridge,
+ struct drm_atomic_state *state);
};

/**
@@ -323,6 +420,15 @@ void drm_bridge_mode_set(struct drm_bridge *bridge,
void drm_bridge_pre_enable(struct drm_bridge *bridge);
void drm_bridge_enable(struct drm_bridge *bridge);

+void drm_atomic_bridge_disable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state);
+void drm_atomic_bridge_post_disable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state);
+void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state);
+void drm_atomic_bridge_enable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state);
+
#ifdef CONFIG_DRM_PANEL_BRIDGE
struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
u32 connector_type);
--
2.17.1


[PATCH 4.19.y-cip 00/17] Add RZ/G2E Dual LVDS display

Biju Das <biju.das.jz@...>
 

Add RZ/G2E Dual LVDS display support. All patches in this series are
cherry-picked from upstream kernel.

Fabrizio Castro (7):
drm: rcar-du: lvds: Improve identification of panels
drm: of: Add drm_of_lvds_get_dual_link_pixel_order
drm: rcar-du: lvds: Get dual link configuration from DT
drm: rcar-du: lvds: Allow for even and odd pixels swap
arm64: dts: renesas: r8a774c0: Point LVDS0 to its companion LVDS1
dt-bindings: display: Add idk-2121wr binding
arm64: dts: renesas: Add EK874 board with idk-2121wr display support

Geert Uytterhoeven (1):
arm64: dts: renesas: rzg2: Add reset control properties for display

Jacopo Mondi (1):
drm: rcar_lvds: Fix dual link mode operations

Laurent Pinchart (7):
drm: rcar-du: lvds: Remove LVDS double-enable checks
drm: bridge: Add dual_link field to the drm_bridge_timings structure
dt-bindings: display: renesas: lvds: Add renesas,companion property
drm: rcar-du: lvds: Add support for dual-link mode
drm: rcar-du: Skip LVDS1 output on Gen3 when using dual-link LVDS mode
drm: Add drm_atomic_get_(old|new)_connector_for_encoder() helpers
drm: rcar-du: lvds: Get mode from state

Sean Paul (1):
drm: Add atomic variants for bridge enable/disable

.../bindings/display/bridge/renesas,lvds.txt | 18 +-
.../display/panel/advantech,idk-2121wr.yaml | 122 ++++++
arch/arm64/boot/dts/renesas/Makefile | 3 +-
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 5 +-
arch/arm64/boot/dts/renesas/r8a774b1.dtsi | 5 +-
.../dts/renesas/r8a774c0-ek874-idk-2121wr.dts | 116 ++++++
arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 8 +-
drivers/gpu/drm/drm_atomic.c | 113 ++++++
drivers/gpu/drm/drm_atomic_helper.c | 8 +-
drivers/gpu/drm/drm_bridge.c | 110 ++++++
drivers/gpu/drm/drm_of.c | 116 ++++++
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 12 +
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
drivers/gpu/drm/rcar-du/rcar_lvds.c | 348 +++++++++++-------
drivers/gpu/drm/rcar-du/rcar_lvds.h | 5 +
include/drm/drm_atomic.h | 7 +
include/drm/drm_bridge.h | 114 ++++++
include/drm/drm_connector.h | 9 +
include/drm/drm_of.h | 20 +
19 files changed, 996 insertions(+), 145 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
create mode 100644 arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts

--
2.17.1


Re: [isar-cip-core] tests: put all tests into a opt layer

Jan Kiszka
 

On 22.07.20 12:46, Daniel Sangorrin wrote:
Hi Jan

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Jan Kiszka
Sent: Wednesday, July 22, 2020 5:05 PM
To: sangorrin daniel(サンゴリン ダニエル □SWC◯ACT) <daniel.sangorrin@toshiba.co.jp>; cip-dev@lists.cip-project.org; iwamatsu
nobuhiro(岩松 信洋 □SWC◯ACT) <nobuhiro1.iwamatsu@toshiba.co.jp>
Subject: Re: [cip-dev] [isar-cip-core] tests: put all tests into a opt layer

On 22.07.20 09:25, daniel.sangorrin@toshiba.co.jp wrote:
________________________________________
From: Jan Kiszka <jan.kiszka@siemens.com>
Sent: Wednesday, July 22, 2020 3:44 PM
To: cip-dev@lists.cip-project.org; sangorrin daniel(サンゴリン ダニエル
□SWC◯ACT); iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
Subject: Re: [cip-dev] [isar-cip-core] tests: put all tests into a opt
layer

On 21.07.20 14:42, Daniel Sangorrin wrote:
having an opt-tests layer makes it easier to see what tests are
installed, and allows creating images without them as well
JAN:
"Having ... as well."

Does this obsolete
https://gitlab.com/cip-project/cip-core/isar-cip-core/-/merge_requests
/7,
where I just commented on?

DANIEL: Maybe you can apply Iwamatsu-san merge request first, and I will prepare a new patch on top of that to avoid confusion.
That would confuse me now: What creating a separate test image first, just to remove it again?
Sorry for the confusion.
If you apply MR7, I will move the rt-tests and stress-ng packages from the customization "package" to the test image.
If you instead apply MR5, I will move them to opt-testtools.yml
Or is there any special reason for rt-tests and stress-ng to be in the customization package?
Nobuhiro, is something missing from your perspective in Daniels approach? If not, I'd like to have one patch that takes us to that level.

By now, I think an opt-testtools.yml is better (an "option", not a "layer") than a separate image. That allows to test the security image eventually as well.

Jan

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


Re: [isar-cip-core] tests: put all tests into a opt layer

Daniel Sangorrin
 

Hi Jan

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Jan Kiszka
Sent: Wednesday, July 22, 2020 5:05 PM
To: sangorrin daniel(サンゴリン ダニエル □SWC◯ACT) <daniel.sangorrin@toshiba.co.jp>; cip-dev@lists.cip-project.org; iwamatsu
nobuhiro(岩松 信洋 □SWC◯ACT) <nobuhiro1.iwamatsu@toshiba.co.jp>
Subject: Re: [cip-dev] [isar-cip-core] tests: put all tests into a opt layer

On 22.07.20 09:25, daniel.sangorrin@toshiba.co.jp wrote:
________________________________________
From: Jan Kiszka <jan.kiszka@siemens.com>
Sent: Wednesday, July 22, 2020 3:44 PM
To: cip-dev@lists.cip-project.org; sangorrin daniel(サンゴリン ダニエル
□SWC◯ACT); iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
Subject: Re: [cip-dev] [isar-cip-core] tests: put all tests into a opt
layer

On 21.07.20 14:42, Daniel Sangorrin wrote:
having an opt-tests layer makes it easier to see what tests are
installed, and allows creating images without them as well
JAN:
"Having ... as well."

Does this obsolete
https://gitlab.com/cip-project/cip-core/isar-cip-core/-/merge_requests
/7,
where I just commented on?

DANIEL: Maybe you can apply Iwamatsu-san merge request first, and I will prepare a new patch on top of that to avoid confusion.
That would confuse me now: What creating a separate test image first, just to remove it again?
Sorry for the confusion.

If you apply MR7, I will move the rt-tests and stress-ng packages from the customization "package" to the test image.
If you instead apply MR5, I will move them to opt-testtools.yml

Or is there any special reason for rt-tests and stress-ng to be in the customization package?

Thanks,
Daniel


Jan

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


Re: [isar-cip-core] tests: put all tests into a opt layer

Jan Kiszka
 

On 22.07.20 09:25, daniel.sangorrin@toshiba.co.jp wrote:
________________________________________
From: Jan Kiszka <jan.kiszka@siemens.com>
Sent: Wednesday, July 22, 2020 3:44 PM
To: cip-dev@lists.cip-project.org; sangorrin daniel(サンゴリン ダニエル □SWC◯ACT); iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
Subject: Re: [cip-dev] [isar-cip-core] tests: put all tests into a opt layer
On 21.07.20 14:42, Daniel Sangorrin wrote:
having an opt-tests layer makes it easier to see what
tests are installed, and allows creating images without
them as well
JAN:
"Having ... as well."
Does this obsolete
https://gitlab.com/cip-project/cip-core/isar-cip-core/-/merge_requests/7,
where I just commented on?
DANIEL: Maybe you can apply Iwamatsu-san merge request first, and I will prepare a new patch on top of that to avoid confusion.
That would confuse me now: What creating a separate test image first, just to remove it again?

Jan

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


Re: [isar-cip-core] tests: put all tests into a opt layer

Daniel Sangorrin
 

________________________________________
From: Jan Kiszka <jan.kiszka@siemens.com>
Sent: Wednesday, July 22, 2020 3:44 PM
To: cip-dev@lists.cip-project.org; sangorrin daniel(サンゴリン ダニエル □SWC◯ACT); iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
Subject: Re: [cip-dev] [isar-cip-core] tests: put all tests into a opt layer

On 21.07.20 14:42, Daniel Sangorrin wrote:
having an opt-tests layer makes it easier to see what
tests are installed, and allows creating images without
them as well
JAN:
"Having ... as well."

Does this obsolete
https://gitlab.com/cip-project/cip-core/isar-cip-core/-/merge_requests/7,
where I just commented on?

DANIEL: Maybe you can apply Iwamatsu-san merge request first, and I will prepare a new patch on top of that to avoid confusion.

Thanks,
Daniel


Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
---
.gitlab-ci.yml | 8 ++++----
README.md | 4 ++++
opt-tests.yml | 19 +++++++++++++++++++
recipes-core/customizations/customizations.bb | 5 ++---
recipes-core/images/cip-core-image.bb | 3 +--
5 files changed, 30 insertions(+), 9 deletions(-)
create mode 100644 opt-tests.yml

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 6f1dc91..90eec1f 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -13,17 +13,17 @@ all:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY

- - kas build kas.yml:board-simatic-ipc227e.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-simatic-ipc227e.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster simatic-ipc227e

- sudo rm -rf build/tmp
- - kas build kas.yml:board-bbb.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-bbb.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster bbb am335x-boneblack.dtb

- sudo rm -rf build/tmp
- - kas build kas.yml:board-iwg20m.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-iwg20m.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster iwg20m r8a7743-iwg20d-q7-dbcm-ca.dtb

- sudo rm -rf build/tmp
- - kas build kas.yml:board-rzg2m.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-rzg2m.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster hihope-rzg2m renesas/r8a774a1-hihope-rzg2m-ex.dtb
diff --git a/README.md b/README.md
index bbad1a0..7339396 100644
--- a/README.md
+++ b/README.md
@@ -25,6 +25,10 @@ this:

This image can be run using `start-qemu.sh x86`.

+If you want to include the testing layer add ':opt-tests.yml' like this
Wording: It's not a testing layer, it's "test packages", no?

+
+ ./kas-docker --isar build kas.yml:board-qemu-amd64.yml:opt-tests.yml
+
The BeagleBone Black target is selected by `... kas.yml:board-bbb.yml`. In
order to build the image with the PREEMPT-RT kernel, append `:opt-rt.yml` to
the above. Append ':opt-4.4.yml' to use the kernel version 4.4 instead of 4.19.
diff --git a/opt-tests.yml b/opt-tests.yml
new file mode 100644
index 0000000..a1f431d
--- /dev/null
+++ b/opt-tests.yml
@@ -0,0 +1,19 @@
+#
+# CIP Core, generic profile
+#
+# Copyright (c) Toshiba corp., 2020
+#
+# Authors:
+# Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
+#
+# SPDX-License-Identifier: MIT
+#
+
+header:
+ version: 8
+
+local_conf_header:
+ tests: |
+ IMAGE_INSTALL += "ltp-full"
+ IMAGE_PREINSTALL += "rt-tests stress-ng"
This, in fact, has some benefit over a separate image in that it would
also allow to make the security image testable by appending the snippet

+
No extra line at EOF, please.

diff --git a/recipes-core/customizations/customizations.bb b/recipes-core/customizations/customizations.bb
index 38881fb..cbd6daf 100644
--- a/recipes-core/customizations/customizations.bb
+++ b/recipes-core/customizations/customizations.bb
@@ -11,7 +11,7 @@

inherit dpkg-raw

-DESCRIPTION = "CIP Core image demo & test customizations"
+DESCRIPTION = "CIP Core image demo customizations"
Maybe "reference customizations" - typically, you will replace this
package for a real product with a, well, product specific customization.


SRC_URI = " \
file://postinst \
@@ -21,8 +21,7 @@ SRC_URI = " \
DEPENDS += "sshd-regen-keys"

DEBIAN_DEPENDS = " \
- ifupdown, isc-dhcp-client, net-tools, iputils-ping, ssh, sshd-regen-keys, \
- rt-tests, stress-ng"
+ ifupdown, isc-dhcp-client, net-tools, iputils-ping, ssh, sshd-regen-keys"

do_install() {
install -v -d ${D}/etc/network/interfaces.d
diff --git a/recipes-core/images/cip-core-image.bb b/recipes-core/images/cip-core-image.bb
index 9ee4b25..188c714 100644
--- a/recipes-core/images/cip-core-image.bb
+++ b/recipes-core/images/cip-core-image.bb
@@ -15,5 +15,4 @@ ISAR_RELEASE_CMD = "git -C ${LAYERDIR_cip-core} describe --tags --dirty --always
DESCRIPTION = "CIP Core image"

IMAGE_INSTALL += "customizations"
-# for cip-testing
-IMAGE_INSTALL += "ltp-full"
+
No extra line at EOF, please.

Jan

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


Re: [isar-cip-core] tests: put all tests into a opt layer

Jan Kiszka
 

On 21.07.20 14:42, Daniel Sangorrin wrote:
having an opt-tests layer makes it easier to see what
tests are installed, and allows creating images without
them as well
"Having ... as well."

Does this obsolete https://gitlab.com/cip-project/cip-core/isar-cip-core/-/merge_requests/7, where I just commented on?

Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
---
.gitlab-ci.yml | 8 ++++----
README.md | 4 ++++
opt-tests.yml | 19 +++++++++++++++++++
recipes-core/customizations/customizations.bb | 5 ++---
recipes-core/images/cip-core-image.bb | 3 +--
5 files changed, 30 insertions(+), 9 deletions(-)
create mode 100644 opt-tests.yml
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 6f1dc91..90eec1f 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -13,17 +13,17 @@ all:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
- - kas build kas.yml:board-simatic-ipc227e.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-simatic-ipc227e.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster simatic-ipc227e
- sudo rm -rf build/tmp
- - kas build kas.yml:board-bbb.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-bbb.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster bbb am335x-boneblack.dtb
- sudo rm -rf build/tmp
- - kas build kas.yml:board-iwg20m.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-iwg20m.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster iwg20m r8a7743-iwg20d-q7-dbcm-ca.dtb
- sudo rm -rf build/tmp
- - kas build kas.yml:board-rzg2m.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-rzg2m.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster hihope-rzg2m renesas/r8a774a1-hihope-rzg2m-ex.dtb
diff --git a/README.md b/README.md
index bbad1a0..7339396 100644
--- a/README.md
+++ b/README.md
@@ -25,6 +25,10 @@ this:
This image can be run using `start-qemu.sh x86`.
+If you want to include the testing layer add ':opt-tests.yml' like this
Wording: It's not a testing layer, it's "test packages", no?

+
+ ./kas-docker --isar build kas.yml:board-qemu-amd64.yml:opt-tests.yml
+
The BeagleBone Black target is selected by `... kas.yml:board-bbb.yml`. In
order to build the image with the PREEMPT-RT kernel, append `:opt-rt.yml` to
the above. Append ':opt-4.4.yml' to use the kernel version 4.4 instead of 4.19.
diff --git a/opt-tests.yml b/opt-tests.yml
new file mode 100644
index 0000000..a1f431d
--- /dev/null
+++ b/opt-tests.yml
@@ -0,0 +1,19 @@
+#
+# CIP Core, generic profile
+#
+# Copyright (c) Toshiba corp., 2020
+#
+# Authors:
+# Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
+#
+# SPDX-License-Identifier: MIT
+#
+
+header:
+ version: 8
+
+local_conf_header:
+ tests: |
+ IMAGE_INSTALL += "ltp-full"
+ IMAGE_PREINSTALL += "rt-tests stress-ng"
This, in fact, has some benefit over a separate image in that it would also allow to make the security image testable by appending the snippet

+
No extra line at EOF, please.

diff --git a/recipes-core/customizations/customizations.bb b/recipes-core/customizations/customizations.bb
index 38881fb..cbd6daf 100644
--- a/recipes-core/customizations/customizations.bb
+++ b/recipes-core/customizations/customizations.bb
@@ -11,7 +11,7 @@
inherit dpkg-raw
-DESCRIPTION = "CIP Core image demo & test customizations"
+DESCRIPTION = "CIP Core image demo customizations"
Maybe "reference customizations" - typically, you will replace this package for a real product with a, well, product specific customization.

SRC_URI = " \
file://postinst \
@@ -21,8 +21,7 @@ SRC_URI = " \
DEPENDS += "sshd-regen-keys"
DEBIAN_DEPENDS = " \
- ifupdown, isc-dhcp-client, net-tools, iputils-ping, ssh, sshd-regen-keys, \
- rt-tests, stress-ng"
+ ifupdown, isc-dhcp-client, net-tools, iputils-ping, ssh, sshd-regen-keys"
do_install() {
install -v -d ${D}/etc/network/interfaces.d
diff --git a/recipes-core/images/cip-core-image.bb b/recipes-core/images/cip-core-image.bb
index 9ee4b25..188c714 100644
--- a/recipes-core/images/cip-core-image.bb
+++ b/recipes-core/images/cip-core-image.bb
@@ -15,5 +15,4 @@ ISAR_RELEASE_CMD = "git -C ${LAYERDIR_cip-core} describe --tags --dirty --always
DESCRIPTION = "CIP Core image"
IMAGE_INSTALL += "customizations"
-# for cip-testing
-IMAGE_INSTALL += "ltp-full"
+
No extra line at EOF, please.

Jan

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


Re: Kindly review for kernel config changes

Daniel Sangorrin
 

Hi Kent,

Let me check if we can use the cip-kernel-config version on ISAR and remove the one in isar-cip-core.

I will also add nftables as a fragment to isar-cip-core until you tell me that it needs long-term support. If it needs long-term support we will have to move it to cip-kernel-config.

Thanks,
Daniel

________________________________________
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> on behalf of Kento Yoshida <kento.yoshida.wz@renesas.com>
Sent: Tuesday, July 21, 2020 5:40 PM
To: cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] Kindly review for kernel config changes

isar-cip-core and deby share cip-kernel-config configuration files.
*isar-cip-core still has the configuration files there but conf/machine files with
USE_CIP_KERNEL_CONFIG = "1" do not use them anymore.
I see. Thank you, Daniel.
But, I'm wondering why conf/machine/qemu-amd64.conf doesn't define USE_CIP_KERNEL_CONFIG = "1".

Do you have any information for this, Dinesh or Venkata?
I think we should reconfirm to add these configs to https://gitlab.com/cip-project/cip-kernel/cip-kernel-config/-/blob/master/4.19.y-cip/x86/cip_qemu_defconfig.
Or, have you already confirmed to build the image using this?

BR, Kent

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of
Daniel Sangorrin via lists.cip-project.org
Sent: Tuesday, July 21, 2020 4:57 PM
To: cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] Kindly review for kernel config changes

Hi Kent,

The configuration should go to
https://gitlab.com/cip-project/cip-kernel/cip-kernel-config not isar-cip-core.

isar-cip-core and deby share cip-kernel-config configuration files.
*isar-cip-core still has the configuration files there but conf/machine files with
USE_CIP_KERNEL_CONFIG = "1" do not use them anymore.

Actually that is a nother AI.

Thanks,
Daniel

________________________________________
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> on behalf of
Kento Yoshida <kento.yoshida.wz@renesas.com>
Sent: Tuesday, July 21, 2020 4:12 PM
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] Kindly review for kernel config changes

Hi,

The security working group need to use "nftables", and it requires to add the
below kernel configs to work.
Before merging to the master branch of "isar-cip-core", would you kindly review to
add the below configs by this Friday, everyone?

--- a/recipes-kernel/linux/files/qemu-amd64_defconfig
+++ b/recipes-kernel/linux/files/qemu-amd64_defconfig
@@ -351,3 +351,34 @@ CONFIG_CRYPTO_DEV_CCP=y # CONFIG_XZ_DEC_ARM
is not set # CONFIG_XZ_DEC_ARMTHUMB is not set # CONFIG_XZ_DEC_SPARC is
not set
+CONFIG_NF_TABLES=y
+CONFIG_NF_TABLES_INET=y
+CONFIG_NF_TABLES_NETDEV=y
+CONFIG_NFT_EXTHDR=y
+CONFIG_NFT_META=y
+CONFIG_NFT_CT=y
+CONFIG_NFT_RBTREE=y
+CONFIG_NFT_HASH=y
+CONFIG_NFT_COUNTER=y
+CONFIG_NFT_LOG=y
+CONFIG_NFT_LIMIT=y
+CONFIG_NFT_MASQ=y
+CONFIG_NFT_REDIR=y
+CONFIG_NFT_NAT=y
+CONFIG_NFT_QUEUE=y
+CONFIG_NFT_REJECT=y
+CONFIG_NFT_REJECT_INET=y
+CONFIG_NFT_COMPAT=y
+CONFIG_NFT_CHAIN_ROUTE_IPV4=y
+CONFIG_NFT_REJECT_IPV4=y
+CONFIG_NFT_CHAIN_NAT_IPV4=y
+CONFIG_NFT_MASQ_IPV4=y
+# CONFIG_NFT_REDIR_IPV4 is not set
+CONFIG_NFT_CHAIN_ROUTE_IPV6=y
+CONFIG_NFT_REJECT_IPV6=y
+CONFIG_NFT_CHAIN_NAT_IPV6=y
+CONFIG_NFT_MASQ_IPV6=y
+# CONFIG_NFT_REDIR_IPV6 is not set
+CONFIG_NFT_BRIDGE_META=y
+CONFIG_NFT_BRIDGE_REJECT=y
+CONFIG_NF_LOG_BRIDGE=y

BR, Kent


Fw: [isar-cip-core] tests: put all tests into a opt layer

Daniel Sangorrin
 

Hi Jan,

Sorry, I failed to put you in the Cc when I sent this patch.
There are also 3 patches from Venkata-san on the cip-dev mailing list (sent yesterday)
Apart from that there are some merge requests on gitlab.

Thanks,
Daniel


________________________________________
From: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
Sent: Tuesday, July 21, 2020 7:59 PM
To: sangorrin daniel(サンゴリン ダニエル □SWC◯ACT)
Subject: [isar-cip-core] tests: put all tests into a opt layer

having an opt-tests layer makes it easier to see what
tests are installed, and allows creating images without
them as well

Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
---
.gitlab-ci.yml | 8 ++++----
README.md | 4 ++++
opt-tests.yml | 19 +++++++++++++++++++
recipes-core/customizations/customizations.bb | 5 ++---
recipes-core/images/cip-core-image.bb | 3 +--
5 files changed, 30 insertions(+), 9 deletions(-)
create mode 100644 opt-tests.yml

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 6f1dc91..90eec1f 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -13,17 +13,17 @@ all:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY

- - kas build kas.yml:board-simatic-ipc227e.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-simatic-ipc227e.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster simatic-ipc227e

- sudo rm -rf build/tmp
- - kas build kas.yml:board-bbb.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-bbb.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster bbb am335x-boneblack.dtb

- sudo rm -rf build/tmp
- - kas build kas.yml:board-iwg20m.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-iwg20m.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster iwg20m r8a7743-iwg20d-q7-dbcm-ca.dtb

- sudo rm -rf build/tmp
- - kas build kas.yml:board-rzg2m.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-rzg2m.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster hihope-rzg2m renesas/r8a774a1-hihope-rzg2m-ex.dtb
diff --git a/README.md b/README.md
index bbad1a0..7339396 100644
--- a/README.md
+++ b/README.md
@@ -25,6 +25,10 @@ this:

This image can be run using `start-qemu.sh x86`.

+If you want to include the testing layer add ':opt-tests.yml' like this
+
+ ./kas-docker --isar build kas.yml:board-qemu-amd64.yml:opt-tests.yml
+
The BeagleBone Black target is selected by `... kas.yml:board-bbb.yml`. In
order to build the image with the PREEMPT-RT kernel, append `:opt-rt.yml` to
the above. Append ':opt-4.4.yml' to use the kernel version 4.4 instead of 4.19.
diff --git a/opt-tests.yml b/opt-tests.yml
new file mode 100644
index 0000000..a1f431d
--- /dev/null
+++ b/opt-tests.yml
@@ -0,0 +1,19 @@
+#
+# CIP Core, generic profile
+#
+# Copyright (c) Toshiba corp., 2020
+#
+# Authors:
+# Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
+#
+# SPDX-License-Identifier: MIT
+#
+
+header:
+ version: 8
+
+local_conf_header:
+ tests: |
+ IMAGE_INSTALL += "ltp-full"
+ IMAGE_PREINSTALL += "rt-tests stress-ng"
+
diff --git a/recipes-core/customizations/customizations.bb b/recipes-core/customizations/customizations.bb
index 38881fb..cbd6daf 100644
--- a/recipes-core/customizations/customizations.bb
+++ b/recipes-core/customizations/customizations.bb
@@ -11,7 +11,7 @@

inherit dpkg-raw

-DESCRIPTION = "CIP Core image demo & test customizations"
+DESCRIPTION = "CIP Core image demo customizations"

SRC_URI = " \
file://postinst \
@@ -21,8 +21,7 @@ SRC_URI = " \
DEPENDS += "sshd-regen-keys"

DEBIAN_DEPENDS = " \
- ifupdown, isc-dhcp-client, net-tools, iputils-ping, ssh, sshd-regen-keys, \
- rt-tests, stress-ng"
+ ifupdown, isc-dhcp-client, net-tools, iputils-ping, ssh, sshd-regen-keys"

do_install() {
install -v -d ${D}/etc/network/interfaces.d
diff --git a/recipes-core/images/cip-core-image.bb b/recipes-core/images/cip-core-image.bb
index 9ee4b25..188c714 100644
--- a/recipes-core/images/cip-core-image.bb
+++ b/recipes-core/images/cip-core-image.bb
@@ -15,5 +15,4 @@ ISAR_RELEASE_CMD = "git -C ${LAYERDIR_cip-core} describe --tags --dirty --always
DESCRIPTION = "CIP Core image"

IMAGE_INSTALL += "customizations"
-# for cip-testing
-IMAGE_INSTALL += "ltp-full"
+
--
2.25.1


Re: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additional support for Renesas platforms

Biju Das <biju.das.jz@...>
 

Hi Pavel,

Thanks for the feedback.

Subject: Re: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additional
support for Renesas platforms

Hi!

On Mon 2020-07-20 18:52:23, Biju Das wrote:
From: Geert Uytterhoeven <geert+renesas@glider.be>

commit bf9e333ec0d54f7428d9192ad403c3cb523584c7 upstream

Increase build and test coverage by enabling support for more
hardware present on Renesas SoCs and boards:
- R-Car CAN and CAN-FD controllers,
Ok, I can apply this if there are no comments.
Both patches seem to be okay to me.
I will push to repository if there is no problem in our test.
I see it is already pushed, thank you!

Biju, the first patch seems like a bugfix suitable for -stable. Can you send it to
Greg (etc) for inclusion?
Yes, Will do.

Regards,
Biju


Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647


Re: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additional support for Renesas platforms

Pavel Machek
 

Hi!

On Mon 2020-07-20 18:52:23, Biju Das wrote:
From: Geert Uytterhoeven <geert+renesas@glider.be>

commit bf9e333ec0d54f7428d9192ad403c3cb523584c7 upstream

Increase build and test coverage by enabling support for more hardware
present on Renesas SoCs and boards:
- R-Car CAN and CAN-FD controllers,
Ok, I can apply this if there are no comments.
Both patches seem to be okay to me.
I will push to repository if there is no problem in our test.
I see it is already pushed, thank you!

Biju, the first patch seems like a bugfix suitable for -stable. Can
you send it to Greg (etc) for inclusion?

Best regards,
Pavel

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


[isar-cip-core] tests: put all tests into a opt layer

Daniel Sangorrin
 

having an opt-tests layer makes it easier to see what
tests are installed, and allows creating images without
them as well

Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
---
.gitlab-ci.yml | 8 ++++----
README.md | 4 ++++
opt-tests.yml | 19 +++++++++++++++++++
recipes-core/customizations/customizations.bb | 5 ++---
recipes-core/images/cip-core-image.bb | 3 +--
5 files changed, 30 insertions(+), 9 deletions(-)
create mode 100644 opt-tests.yml

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 6f1dc91..90eec1f 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -13,17 +13,17 @@ all:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY

- - kas build kas.yml:board-simatic-ipc227e.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-simatic-ipc227e.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster simatic-ipc227e

- sudo rm -rf build/tmp
- - kas build kas.yml:board-bbb.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-bbb.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster bbb am335x-boneblack.dtb

- sudo rm -rf build/tmp
- - kas build kas.yml:board-iwg20m.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-iwg20m.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster iwg20m r8a7743-iwg20d-q7-dbcm-ca.dtb

- sudo rm -rf build/tmp
- - kas build kas.yml:board-rzg2m.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-rzg2m.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster hihope-rzg2m renesas/r8a774a1-hihope-rzg2m-ex.dtb
diff --git a/README.md b/README.md
index bbad1a0..7339396 100644
--- a/README.md
+++ b/README.md
@@ -25,6 +25,10 @@ this:

This image can be run using `start-qemu.sh x86`.

+If you want to include the testing layer add ':opt-tests.yml' like this
+
+ ./kas-docker --isar build kas.yml:board-qemu-amd64.yml:opt-tests.yml
+
The BeagleBone Black target is selected by `... kas.yml:board-bbb.yml`. In
order to build the image with the PREEMPT-RT kernel, append `:opt-rt.yml` to
the above. Append ':opt-4.4.yml' to use the kernel version 4.4 instead of 4.19.
diff --git a/opt-tests.yml b/opt-tests.yml
new file mode 100644
index 0000000..a1f431d
--- /dev/null
+++ b/opt-tests.yml
@@ -0,0 +1,19 @@
+#
+# CIP Core, generic profile
+#
+# Copyright (c) Toshiba corp., 2020
+#
+# Authors:
+# Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
+#
+# SPDX-License-Identifier: MIT
+#
+
+header:
+ version: 8
+
+local_conf_header:
+ tests: |
+ IMAGE_INSTALL += "ltp-full"
+ IMAGE_PREINSTALL += "rt-tests stress-ng"
+
diff --git a/recipes-core/customizations/customizations.bb b/recipes-core/customizations/customizations.bb
index 38881fb..cbd6daf 100644
--- a/recipes-core/customizations/customizations.bb
+++ b/recipes-core/customizations/customizations.bb
@@ -11,7 +11,7 @@

inherit dpkg-raw

-DESCRIPTION = "CIP Core image demo & test customizations"
+DESCRIPTION = "CIP Core image demo customizations"

SRC_URI = " \
file://postinst \
@@ -21,8 +21,7 @@ SRC_URI = " \
DEPENDS += "sshd-regen-keys"

DEBIAN_DEPENDS = " \
- ifupdown, isc-dhcp-client, net-tools, iputils-ping, ssh, sshd-regen-keys, \
- rt-tests, stress-ng"
+ ifupdown, isc-dhcp-client, net-tools, iputils-ping, ssh, sshd-regen-keys"

do_install() {
install -v -d ${D}/etc/network/interfaces.d
diff --git a/recipes-core/images/cip-core-image.bb b/recipes-core/images/cip-core-image.bb
index 9ee4b25..188c714 100644
--- a/recipes-core/images/cip-core-image.bb
+++ b/recipes-core/images/cip-core-image.bb
@@ -15,5 +15,4 @@ ISAR_RELEASE_CMD = "git -C ${LAYERDIR_cip-core} describe --tags --dirty --always
DESCRIPTION = "CIP Core image"

IMAGE_INSTALL += "customizations"
-# for cip-testing
-IMAGE_INSTALL += "ltp-full"
+
--
2.25.1


Re: Kindly review for kernel config changes

Kento Yoshida
 

isar-cip-core and deby share cip-kernel-config configuration files.
*isar-cip-core still has the configuration files there but conf/machine files with
USE_CIP_KERNEL_CONFIG = "1" do not use them anymore.
I see. Thank you, Daniel.
But, I'm wondering why conf/machine/qemu-amd64.conf doesn't define USE_CIP_KERNEL_CONFIG = "1".

Do you have any information for this, Dinesh or Venkata?
I think we should reconfirm to add these configs to https://gitlab.com/cip-project/cip-kernel/cip-kernel-config/-/blob/master/4.19.y-cip/x86/cip_qemu_defconfig.
Or, have you already confirmed to build the image using this?

BR, Kent

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of
Daniel Sangorrin via lists.cip-project.org
Sent: Tuesday, July 21, 2020 4:57 PM
To: cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] Kindly review for kernel config changes

Hi Kent,

The configuration should go to
https://gitlab.com/cip-project/cip-kernel/cip-kernel-config not isar-cip-core.

isar-cip-core and deby share cip-kernel-config configuration files.
*isar-cip-core still has the configuration files there but conf/machine files with
USE_CIP_KERNEL_CONFIG = "1" do not use them anymore.

Actually that is a nother AI.

Thanks,
Daniel

________________________________________
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> on behalf of
Kento Yoshida <kento.yoshida.wz@renesas.com>
Sent: Tuesday, July 21, 2020 4:12 PM
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] Kindly review for kernel config changes

Hi,

The security working group need to use "nftables", and it requires to add the
below kernel configs to work.
Before merging to the master branch of "isar-cip-core", would you kindly review to
add the below configs by this Friday, everyone?

--- a/recipes-kernel/linux/files/qemu-amd64_defconfig
+++ b/recipes-kernel/linux/files/qemu-amd64_defconfig
@@ -351,3 +351,34 @@ CONFIG_CRYPTO_DEV_CCP=y # CONFIG_XZ_DEC_ARM
is not set # CONFIG_XZ_DEC_ARMTHUMB is not set # CONFIG_XZ_DEC_SPARC is
not set
+CONFIG_NF_TABLES=y
+CONFIG_NF_TABLES_INET=y
+CONFIG_NF_TABLES_NETDEV=y
+CONFIG_NFT_EXTHDR=y
+CONFIG_NFT_META=y
+CONFIG_NFT_CT=y
+CONFIG_NFT_RBTREE=y
+CONFIG_NFT_HASH=y
+CONFIG_NFT_COUNTER=y
+CONFIG_NFT_LOG=y
+CONFIG_NFT_LIMIT=y
+CONFIG_NFT_MASQ=y
+CONFIG_NFT_REDIR=y
+CONFIG_NFT_NAT=y
+CONFIG_NFT_QUEUE=y
+CONFIG_NFT_REJECT=y
+CONFIG_NFT_REJECT_INET=y
+CONFIG_NFT_COMPAT=y
+CONFIG_NFT_CHAIN_ROUTE_IPV4=y
+CONFIG_NFT_REJECT_IPV4=y
+CONFIG_NFT_CHAIN_NAT_IPV4=y
+CONFIG_NFT_MASQ_IPV4=y
+# CONFIG_NFT_REDIR_IPV4 is not set
+CONFIG_NFT_CHAIN_ROUTE_IPV6=y
+CONFIG_NFT_REJECT_IPV6=y
+CONFIG_NFT_CHAIN_NAT_IPV6=y
+CONFIG_NFT_MASQ_IPV6=y
+# CONFIG_NFT_REDIR_IPV6 is not set
+CONFIG_NFT_BRIDGE_META=y
+CONFIG_NFT_BRIDGE_REJECT=y
+CONFIG_NF_LOG_BRIDGE=y

BR, Kent


[PATCH 3/3] README: Add steps to build cip-security image

Venkata Pyla
 

From: venkata <venkata.pyla@toshiba-tsip.com>

Signed-off-by: venkata <venkata.pyla@toshiba-tsip.com>
---
README.md | 10 ++++++++++
1 file changed, 10 insertions(+)

diff --git a/README.md b/README.md
index bbad1a0..b2c4166 100644
--- a/README.md
+++ b/README.md
@@ -36,6 +36,16 @@ card, run
dd if=build/tmp/deploy/images/bbb/cip-core-image-cip-core-buster-bbb.wic.img \
of=/dev/<medium-device> bs=1M status=progress

+## Building Security target images
+Building images for QEMU x86-64bit machine
+
+ ./kas-docker --isar build --target cip-core-image-security kas.yml:board-qemu-amd64.yml
+
+Run the generated securiy images on QEMU (x86-64bit)
+
+ TARGET_IMAGE=cip-core-image-security ./start-qemu.sh amd64
+
+
## Community Resources

TBD
--
2.27.0.windows.1

The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the
recipient and may contain privileged information.
If you are not the intended recipient, please notify the
sender and delete the message along with any
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail
are those of the individual sender except where the sender
specifically states them to be the views of
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.


[PATCH 2/3] start-qemu.sh: use TARGET_IMAGE to pick respective image file

Venkata Pyla
 

From: venkata <venkata.pyla@toshiba-tsip.com>

if 'TARGET_IMAGE' variable is not set then it pick "cip-core-image",
to pick different target image set the 'TARGET_IMAGE' variable as below
e.g: $TARGET_IMAGE=cip-core-image-security ./start-qemu.sh amd64

Signed-off-by: venkata <venkata.pyla@toshiba-tsip.com>
---
start-qemu.sh | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/start-qemu.sh b/start-qemu.sh
index 49f0266..5c17d74 100755
--- a/start-qemu.sh
+++ b/start-qemu.sh
@@ -75,7 +75,11 @@ if [ -z "${DISTRO_RELEASE}" ]; then
DISTRO_RELEASE="buster"
fi

-IMAGE_PREFIX="$(dirname $0)/build/tmp/deploy/images/qemu-${DISTRO_ARCH}/cip-core-image-cip-core-${DISTRO_RELEASE}-qemu-${DISTRO_ARCH}"
+if [ -z "${TARGET_IMAGE}" ]; then
+ TARGET_IMAGE="cip-core-image"
+fi
+
+IMAGE_PREFIX="$(dirname $0)/build/tmp/deploy/images/qemu-${DISTRO_ARCH}/${TARGET_IMAGE}-cip-core-${DISTRO_RELEASE}-qemu-${DISTRO_ARCH}"
IMAGE_FILE=$(ls ${IMAGE_PREFIX}.ext4.img)

if [ -z "${DISPLAY}" ]; then
--
2.27.0.windows.1

The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the
recipient and may contain privileged information.
If you are not the intended recipient, please notify the
sender and delete the message along with any
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail
are those of the individual sender except where the sender
specifically states them to be the views of
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.


[PATCH 1/3] cip-security: Add packages for IEC-62443-4-2 Evaluation.

Venkata Pyla
 

From: Kazuhiro Hayashi <kazuhiro3.hayashi@toshiba.co.jp>

Identified security packages are added to the target image
and that will be used for IEC-62443-4-2 evaluation

Signed-off-by: Kazuhiro Hayashi <kazuhiro3.hayashi@toshiba.co.jp>
Signed-off-by: pvenkata2 <venkata.pyla@toshiba-tsip.com>
---
.../images/cip-core-image-security.bb | 37 +++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 recipes-core/images/cip-core-image-security.bb

diff --git a/recipes-core/images/cip-core-image-security.bb b/recipes-core/images/cip-core-image-security.bb
new file mode 100644
index 0000000..8253952
--- /dev/null
+++ b/recipes-core/images/cip-core-image-security.bb
@@ -0,0 +1,37 @@
+#
+# A reference image which includes security packages
+#
+# Copyright (c) Toshiba Corporation, 2020
+#
+# Authors:
+# Kazuhiro Hayashi <kazuhiro3.hayashi@toshiba.co.jp>
+#
+# SPDX-License-Identifier: MIT
+#
+
+inherit image
+
+DESCRIPTION = "CIP Core image including security packages"
+
+# Use the same customizations as cip-core-image
+IMAGE_INSTALL += "customizations"
+
+# Debian packages that provide security features
+IMAGE_PREINSTALL += " \
+ openssl libssl1.1 \
+ fail2ban \
+ openssh-server openssh-sftp-server openssh-client \
+ syslog-ng-core syslog-ng-mod-journal \
+ aide aide-common \
+ libnftables0 nftables \
+ libpam-pkcs11 \
+ chrony \
+ tpm2-tools \
+ tpm2-abrmd \
+ libtss2-esys0 libtss2-udev \
+ libpam-cracklib \
+ acl \
+ libauparse0 audispd-plugins auditd \
+ uuid-runtime \
+ sudo \
+"
--
2.27.0.windows.1

The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the
recipient and may contain privileged information.
If you are not the intended recipient, please notify the
sender and delete the message along with any
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail
are those of the individual sender except where the sender
specifically states them to be the views of
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.


Re: Kindly review for kernel config changes

Daniel Sangorrin
 

Hi Kent,

The configuration should go to https://gitlab.com/cip-project/cip-kernel/cip-kernel-config not isar-cip-core.

isar-cip-core and deby share cip-kernel-config configuration files.
*isar-cip-core still has the configuration files there but conf/machine files with USE_CIP_KERNEL_CONFIG = "1" do not use them anymore.

Actually that is a nother AI.

Thanks,
Daniel

________________________________________
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> on behalf of Kento Yoshida <kento.yoshida.wz@renesas.com>
Sent: Tuesday, July 21, 2020 4:12 PM
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] Kindly review for kernel config changes

Hi,

The security working group need to use "nftables", and it requires to add the below kernel configs to work.
Before merging to the master branch of "isar-cip-core", would you kindly review to add the below configs by this Friday, everyone?

--- a/recipes-kernel/linux/files/qemu-amd64_defconfig
+++ b/recipes-kernel/linux/files/qemu-amd64_defconfig
@@ -351,3 +351,34 @@ CONFIG_CRYPTO_DEV_CCP=y
# CONFIG_XZ_DEC_ARM is not set
# CONFIG_XZ_DEC_ARMTHUMB is not set
# CONFIG_XZ_DEC_SPARC is not set
+CONFIG_NF_TABLES=y
+CONFIG_NF_TABLES_INET=y
+CONFIG_NF_TABLES_NETDEV=y
+CONFIG_NFT_EXTHDR=y
+CONFIG_NFT_META=y
+CONFIG_NFT_CT=y
+CONFIG_NFT_RBTREE=y
+CONFIG_NFT_HASH=y
+CONFIG_NFT_COUNTER=y
+CONFIG_NFT_LOG=y
+CONFIG_NFT_LIMIT=y
+CONFIG_NFT_MASQ=y
+CONFIG_NFT_REDIR=y
+CONFIG_NFT_NAT=y
+CONFIG_NFT_QUEUE=y
+CONFIG_NFT_REJECT=y
+CONFIG_NFT_REJECT_INET=y
+CONFIG_NFT_COMPAT=y
+CONFIG_NFT_CHAIN_ROUTE_IPV4=y
+CONFIG_NFT_REJECT_IPV4=y
+CONFIG_NFT_CHAIN_NAT_IPV4=y
+CONFIG_NFT_MASQ_IPV4=y
+# CONFIG_NFT_REDIR_IPV4 is not set
+CONFIG_NFT_CHAIN_ROUTE_IPV6=y
+CONFIG_NFT_REJECT_IPV6=y
+CONFIG_NFT_CHAIN_NAT_IPV6=y
+CONFIG_NFT_MASQ_IPV6=y
+# CONFIG_NFT_REDIR_IPV6 is not set
+CONFIG_NFT_BRIDGE_META=y
+CONFIG_NFT_BRIDGE_REJECT=y
+CONFIG_NF_LOG_BRIDGE=y

BR, Kent


Re: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additional support for Renesas platforms

Biju Das <biju.das.jz@...>
 

Hi Pavel and Nobuhiro,

Thanks for the feedback.

-----Original Message-----
From: nobuhiro1.iwamatsu@toshiba.co.jp
<nobuhiro1.iwamatsu@toshiba.co.jp>
Sent: 21 July 2020 01:43
To: pavel@denx.de; Biju Das <biju.das.jz@bp.renesas.com>
Cc: cip-dev@lists.cip-project.org; Chris Paterson
<Chris.Paterson2@renesas.com>; Prabhakar Mahadev Lad
<prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: RE: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additional
support for Renesas platforms

Hi, all

-----Original Message-----
From: Pavel Machek [mailto:pavel@denx.de]
Sent: Tuesday, July 21, 2020 6:00 AM
To: Biju Das <biju.das.jz@bp.renesas.com>
Cc: cip-dev@lists.cip-project.org; iwamatsu nobuhiro(岩松 信洋 □SWC
◯ACT)
<nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel Machek <pavel@denx.de>;
Chris Paterson <chris.paterson2@renesas.com>; Prabhakar Mahadev Lad
<prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: Re: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable
additional support for Renesas platforms

On Mon 2020-07-20 18:52:23, Biju Das wrote:
From: Geert Uytterhoeven <geert+renesas@glider.be>

commit bf9e333ec0d54f7428d9192ad403c3cb523584c7 upstream

Increase build and test coverage by enabling support for more
hardware present on Renesas SoCs and boards:
- R-Car CAN and CAN-FD controllers,
Ok, I can apply this if there are no comments.
Both patches seem to be okay to me.
I will push to repository if there is no problem in our test.


Should we have some updates for cip-kernel-config?
+1.
It should be updated as well.
Yes Will do.

Regards,
Biju


Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647


Kindly review for kernel config changes

Kento Yoshida
 

Hi,

 

The security working group need to use "nftables", and it requires to add the below kernel configs to work.

Before merging to the master branch of "isar-cip-core", would you kindly review to add the below configs by this Friday, everyone?

 

--- a/recipes-kernel/linux/files/qemu-amd64_defconfig

+++ b/recipes-kernel/linux/files/qemu-amd64_defconfig

@@ -351,3 +351,34 @@ CONFIG_CRYPTO_DEV_CCP=y

# CONFIG_XZ_DEC_ARM is not set

# CONFIG_XZ_DEC_ARMTHUMB is not set

# CONFIG_XZ_DEC_SPARC is not set

+CONFIG_NF_TABLES=y

+CONFIG_NF_TABLES_INET=y

+CONFIG_NF_TABLES_NETDEV=y

+CONFIG_NFT_EXTHDR=y

+CONFIG_NFT_META=y

+CONFIG_NFT_CT=y

+CONFIG_NFT_RBTREE=y

+CONFIG_NFT_HASH=y

+CONFIG_NFT_COUNTER=y

+CONFIG_NFT_LOG=y

+CONFIG_NFT_LIMIT=y

+CONFIG_NFT_MASQ=y

+CONFIG_NFT_REDIR=y

+CONFIG_NFT_NAT=y

+CONFIG_NFT_QUEUE=y

+CONFIG_NFT_REJECT=y

+CONFIG_NFT_REJECT_INET=y

+CONFIG_NFT_COMPAT=y

+CONFIG_NFT_CHAIN_ROUTE_IPV4=y

+CONFIG_NFT_REJECT_IPV4=y

+CONFIG_NFT_CHAIN_NAT_IPV4=y

+CONFIG_NFT_MASQ_IPV4=y

+# CONFIG_NFT_REDIR_IPV4 is not set

+CONFIG_NFT_CHAIN_ROUTE_IPV6=y

+CONFIG_NFT_REJECT_IPV6=y

+CONFIG_NFT_CHAIN_NAT_IPV6=y

+CONFIG_NFT_MASQ_IPV6=y

+# CONFIG_NFT_REDIR_IPV6 is not set

+CONFIG_NFT_BRIDGE_META=y

+CONFIG_NFT_BRIDGE_REJECT=y

+CONFIG_NF_LOG_BRIDGE=y

 

BR, Kent


Re: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additional support for Renesas platforms

Nobuhiro Iwamatsu
 

Hi, all

-----Original Message-----
From: Pavel Machek [mailto:pavel@denx.de]
Sent: Tuesday, July 21, 2020 6:00 AM
To: Biju Das <biju.das.jz@bp.renesas.com>
Cc: cip-dev@lists.cip-project.org; iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
<nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel Machek <pavel@denx.de>; Chris Paterson <chris.paterson2@renesas.com>;
Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: Re: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additional support for Renesas platforms

On Mon 2020-07-20 18:52:23, Biju Das wrote:
From: Geert Uytterhoeven <geert+renesas@glider.be>

commit bf9e333ec0d54f7428d9192ad403c3cb523584c7 upstream

Increase build and test coverage by enabling support for more hardware
present on Renesas SoCs and boards:
- R-Car CAN and CAN-FD controllers,
Ok, I can apply this if there are no comments.
Both patches seem to be okay to me.
I will push to repository if there is no problem in our test.


Should we have some updates for cip-kernel-config?
+1.
It should be updated as well.

Best regards,
Nobuhiro

2101 - 2120 of 7061