Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Update Renesas Machine configuration [m3|h3]ulcb

Description

The default configuration of the Renesas machine [m3|h3]ulcb must have the kingfisher board support by default.

I open this ticket to discuss about the Renesas board configuration support.

Last month we had some changes on AGL, about Renesas board configuration support, and many people seem to disagree with those changes.

One request was made to revert this commit:
https://git.automotivelinux.org/AGL/meta-agl/commit/templates/machine?id=0524237a83de69a0877ea4775ebdd061441ade29

As an answer to this request, I created a gerrit review:

But with too few explanations (my fault sorry).

Goal:
We want support and the best integration possible of the Renesas boards (and Kingfisher support) in AGL.

I will try to describe, in the most concise way, the statement of work of the Renesas machine configuration in AGL.
(Not the current state but what we really want at the end).

It's open to discussion and can evolve.

This is what I propose:

1) Mandatory support Machine:

  • m3ulcb (with kingfisher support)

  • m3ulcb-nogfx (with kingfisher support)

  • h3ulcb (with kingfisher support)

  • h3ulcb-nogfx (with kingfisher support)

Note: The kingfisher support comes from layer "meta-rcar" from Cogent.

2) Only [m3|h3]ulcb-nogfx are used in AGL CI.

It means if the kingfisher support is broken, the AGL CI is also broken.
During this time we need to commit a fix to remove the KF support from AGL and revert it after fixing "meta-rcar".

3) Optional support machine:

  • ebisu

  • m3-salvator-x

  • h3-salvator-x

Note: These optional machines do not used the "meta-rcar" from Cogent.

4) None of the optional machine are used in AGL CI.

5) Currently, we use a white list to add recipes from "meta-rcar" (Cogent layer) to AGL.

6) The image and the SDK generated with the Kingfisher support has got a specific file name not to be confused with the one without kingfisher support.

 

These are the questions we need answer:

1.1) Q: Do we want to have kingfisher support for [m3|h3]ulcb-nogfx?

2.1) Q: Do we want to remove the kingfisher support, from AGL, each time it is broken?

2.2) Q: Do we want to have a solution to build [m3|h3]ulcb without kingfisher support?

2.3) Q: If 2.2) == yes: Do we want an AGL feature to disable KF support or an AGL machine config?

5.1) Q: Do we want to use a black list or a white list to manage the kingfisher support?
We don't use all the recipes from the Layer meta-rcar (from Cogent, kingfisher support layer).
Only recipes in cogent-symlinks directory are used in AGL.
The selection can be made in two way:

A black list:

  • We need to add recipes each time something goes wrong.

  • Each time we update the layer "meta-rcar" we must check the recipes black list.

A white list(Current choice):

  • We need to check each time new recipes coming from the layer "meta-rcar".

5.2) Q: if 5.1) == white list: What recipes do we want in the white list?

Note 5):

The white list is defined thanks to layer.conf:

from meta-agl/meta-agl-bsp/meta-rcar-gen3-adas/conf/layer.conf

And recipes are added by symlink in directory:

meta-agl/meta-agl-bsp/meta-rcar-gen3-adas/cogent-symlinks

If you have some other requests, please do not hesitate to express them or any comments.

I will update this description.

Environment

None

is duplicated by

relates to

Activity

Harunobu Kurokawa 
August 27, 2020 at 2:45 PM

,

I understand the situation and conclusion.

Thank you update the documentation site , Stephane 

Stephane Desneux 
August 27, 2020 at 2:01 PM
(edited)

Decision at SAT meeting: stay in the current situation = only h3ulcb-kf builds support for Kingfisher.

It means that Ronan's review must be abandoned.

Also, documentation for master and JJ already reflects this:

Only the name of the folder in the deploy dir must be fixed to match the aglsetup target name instead of MACHINE name.

Stephane Desneux 
August 25, 2020 at 1:15 PM

I can't disagree: both schemas have pros and cons... As soon as we don't mix images and sdk binaries in the same deploy dir without proper naming, I'm fine with any solution.

: can you explain why it'd be important to switch back to the old model?

Jan-Simon Moeller 
August 25, 2020 at 9:33 AM

My opinion is that

  • we can fix the root cause leading to this by fixing our documentations

  • [m/h]3ulcb needs to be the bare board without add-ons.

  • I'm absolutely NOT in favour of -nokf. E.g.:

    • What should the target be once we add the refhw ? It would base on h3 MACHINE, so it does not make sense to have it default to "+kf".

    • lowest common denominator between 'h3+kf' and 'refhw' is 'h3' , so this makes sense to have as 'pure' target.

Stephane Desneux 
August 25, 2020 at 9:04 AM

@Jan-Simon: any opinion on this topic and Ronan's review #25056?

What is done is basically renaming the target names to the previous (old) scheme while still allowing to have a build without KF support. If we merge Ronan's review, we would get the following names (resp. for H3):

  • m3ulcb is the usual image we had before (= with KF support)

  • m3ulcb-nokf means without KF support (can be used in CI for ex., if we don't want to pull Cogent's layer - see below)

  • m3ulcb-nogfx means without KF and without graphics support (no proprietary drivers) : used for publishing AGL images on download.automotivelinux.org

In CI, choosing between m3ulcb and m3ulcb-nokf is a question of maturity of the Cogent's layer. Generally, new BSPs are released first, then Cogent layer is aligned a few weeks later: we can then decide to bump the BSP early (so use m3ulcb-nokf for CI) and later bump Cogent layer and switch CI back to m3ulcb.

Fixed

Details

Assignee

Reporter

Labels

Priority

Created July 28, 2020 at 8:47 PM
Updated December 22, 2020 at 7:05 PM
Resolved October 25, 2020 at 3:50 PM