Y2023 (Under review till 2023/2/1)

10 point per person. You can vote point each Task ID.  (ex. IC001 10 point, other  0 point is OK.  IC-001 5 point, IC-002 3 point, IC-003 2point is OK)

Task IDTaskPriority
(for EG task)		Priority
(need contractor)		JIRAConfluence/MaterialTotal PointsIshiiKurokawaYamaguchiNobutaTokitaHarakiAsaba

IC-001OSS assessment2

Architectural criteria of the reusing existing OSS712211



IC-002Change IVI guest from existing demo (MM version) to AGL IVI.


For CES demo?









IC-003Input device support inside a guest. touch, keyboard, vinput, etc.9

https://static.sched.com/hosted_files/ossalsjp21/b1/AGL_ICEG_Activity_ALS2021.pdf

p36,37

2


11



IC-004Implement Container runtime, mangement(resource, lifecycle)
Working by EG members (Not require to contractor)		7

Now develop in (TOODO.URL)3


12



IC-005HW overlay architecture (w/ drm lease, container)  - blue print/white paper












IC-006

OSS reference implementation for the RTOS combinations.

Rpy Pico? - Work by Tokita-san.

Zephyr? FreeRTOS?

RefHW?

Contractor:
??

1


2422343
10

IC-007Yocto multiconfig FAQ


Scott









IC-008Adding board support


The drm-lease-manager will support Rpi4, qemu maybe.  IC integration extend to support these environment.









IC-009

Network sharing




Host/guest routing (ip tables)









IC-010Instrument Cluster (Core system, which is minimal system for QM isolation uses LTS UCB)
Working by EG members (Not require contractor)		10


1



1



IC-011New IC components













IC-012Cross-domain buffer sharing mechanism between IC<→IVI; IVI<→RSE













IC-013Camera Support for AGL via PipeWire5


42

2




IC-014Multiple display configuration management in the Compositor













IC-xxx

Qt new desing and app instead of momi-apps (homescreen, map, music, etc.)  

New cluster design and new refgui app development.

3

AGL common design : Discuss in SAT, SC, AB.

Cluster continue to use Qt? Flutter? other?
    New design : Change to Qt6. (Drop current RefGUI),  IVI side (without momi) depend to SAT, SC, AB judge.

61131




IC-xxxAGL document page for IC profile 













IC-xxxCAN signal demo integration3

  • CAN simulator/steering wheel as CAN input
  • CAN signal linkage between handlers on RTOS and listers on Linux
  • IC/IVI apps interact with CAN events
623

1



IC-xxxCode coverage tool and CIAT report.5

Req to CIAT?4
12
1



IC-xxxFinish audio support7

  • USB audio output from IVI guest
  • Alert sound output from IC guest
321






Y2022 

10 point per person. You can vote point each Task ID.  (ex. IC001 10 point, other  0 point is OK.  IC-001 5 point, IC-002 3 point, IC-003 2point is OK)

Vote deadline:  Before than Mar. 11. 

Task IDTaskPriority
(for EG task)		Priority
(need contractor)		JIRAConfluence/MaterialTotal Points
IC-001OSS assessment1

Architectural criteria of the reusing existing OSS10
IC-002Change IVI guest from existing demo (MM version) to AGL IVI.2

For CES demo?6
IC-003Input device support inside a guest. touch, keyboard, vinput, etc.3

https://static.sched.com/hosted_files/ossalsjp21/b1/AGL_ICEG_Activity_ALS2021.pdf

p36,37

5
IC-004Implement Container runtime, mangement(resource, lifecycle)
Working by EG members (Not require to contractor)		3


5
IC-005HW overlay architecture (w/ drm lease, container)  - blue print/white paper5

4
IC-006OSS reference implementation for the RTOS combinations.5


4
IC-007Yocto multiconfig FAQ7

Scott3
IC-008Adding board support7

The drm-lease-manager will support Rpi4, qemu maybe.  IC integration extend to support these environment.3
IC-009

Network sharing

9

Host/guest routing (ip tables)2
IC-010Instrument Cluster (Core system, which is minimal system for QM isolation uses LTS UCB)
Working by EG members (Not require contractor)		10


1
IC-011New IC components




IC-012Cross-domain buffer sharing mechanism between IC<→IVI; IVI<→RSE




IC-013Camera Support for AGL via PipeWire




IC-014Multiple display configuration management in the Compositor





























































Y2021

Task IDTaskPriority
(for EG task)		Priority
(need contractor)		JIRAConfluence/Material
IC-001Maintain AGL Window Manager, Compositor, and Homescreen1311

IC-002Multi-seat support - Graphics



IC-003Waltham Refinements and improvements



IC-004Camera Support for AGL via PipeWire108

IC-005Instrument Cluster(Compositor and Windowmanager in privileged)
Including the drm lease work		-
--
IC-005.1Implement Container runtime, mangement(resource, lifecycle)
Working by EG members (Not require to contractor)		1_

IC-006Instrument Cluster(Fast boot)
dropped		-
--
IC-007Instrument Cluster(Sound system, sound server and Soundmanager in privileged))
Start at 2020. Now working.		53SPEC-3471
IC-008Instrument Cluster(DRM sharing - Current iGel work)
Maintenance for AGL upstream.
Add DRM lease support to AGL compositor (Ref. SPEC-3838)		21SPEC-3838

IC-008.1Improved integration of DRM lease with AGL Compositor - remove nested Wayland backends86

IC-008.2drm-lease-manager update
e.g.
- configuration (SPEC-3815 )
- multi-display on 1 connector (SPEC-3815 )
- feature update for IC use case : weston with lease-manager foucus on upstream		86

IC-008.3Multiple display configuration management in the Compositor108SPEC-3818
IC-008.4V4L2 overlay support for DRM Lease.
1

IC-009Instrument Cluster (Core system, which is minimal system for QM isolation uses LTS UCB)
Working by EG members (Not require contractor)		3_

IC-010OSS reference implementation for the RTOS combinations.
Develop this task with L.F. mentorship in our plan.
Implement RTOS with real-time function (ex. CAN communication) and inter OS communication using Bosch iccom.
Ref. gsoc_sat.pdf
Rename and upstreaming of Bosch iccom.		42

IC-011AGL IC integration (Qualified IC profile)
Adding board support
IC EG members may realize to the qualified ic profile at only one reference board. When we want to add another board, need to another work.		64

IC-012OSS assessment64
https://confluence.automotivelinux.org/display/IC/Architectural+criteria+of+the+reusing+existing+OSS
IC-013Non volatile RAM disk development.
PRAMFS was stopped maintenance. Need to same solution. In case of IVI PR, that same situations.
Non volatile RAM block device?.		1210
Non volatile RAM disk development.
IC-014New IC components



IC-015

Switch Waltham to use WirePlumber for Audio/Video/Screen streaming
- This means adding a network streaming component to PipeWire to stream beyond another container inside the same OS
- Support streaming to other IVI screens, RSE, and/or IC





IC-016Cross-domain buffer sharing mechanism between IC<→IVI; IVI<→RSE



IC-017Requirment Spec for IC profile









  • No labels

10 Comments

  1. Stephane Desneux

    IC-010: please also consider openAMP in the equation: it seems less proprietary and more widely adopted.

    OpenAMP is backed by ST, NXP, Xilinx, ... and also leverages rpmsg framework which is even more widely adopted. On the other side, ic-com seems less adopted (see: https://github.com/Bosch-SW/linux-iccom) and may only have sense when  MCU is separated from main SoC.

    IMO, openAMP is more fitted for MCU inside the same SoC whereas ic-com may better address cases where MCU is outside the SoC. Note also that we already have a public implementation of openAMP on both linux and zephyr for M3/H3.

    A clear study ic-com versus openAMP should be done to conclude.

    My $0.02...

    1. Naoto YAMAGUCHI

      Thanks Stephane

      Renesas ICCOMM is not mandatory, it's one of the candidate.
      Bosch ICCOMM is require to bidirectional communication method. When this item will accept by SC, we will stat to discus more detail.

  2. Stephane Desneux

    Please let me point this: ICCOMM implementations (Bosch or Renesas) are NOT REQUIRED . ICCOM may be useful in some cases (which ones?) but it's not mandatory at all. Mainline solutions using openAMP and rpmsg should be privileged in an OSS project as AGL, where potential companions like Linux, Yocto, Zephyr are all hosted at LF...  At the end, having an OSS project pushing for proprietary solutions is NOT a good idea IMO.

    1. Naoto YAMAGUCHI

      Bosch ICCOMM and Renesas ICCOMM is completely separate solutions.
      Bosch ICCOMM is a transport layer of the communication method.  Renesas ICCOMM is a less than datalink layer of the communication method.

      Bosch ICCOMM is a required solution of the our architecture.

      Renesas ICCOMM is a one of the candidate solutions, other solution is acceptable. For example MDCOM from TOPPERS project. OpenAMP is as a same.

      1. Stephane Desneux

        Bosch ICCOMM and Renesas ICCOMM is completely separate solutions.

        Even if separate, they're designed to cooperate as I understand. As ICCOM components are a bit hard to find, I'd be interested in public links to source codes. Could you please give us the links for Bosch and Renesas ICCOM layers so we can try to learn from them and build them ?

        Bosch ICCOMM is a required solution of the our architecture.

        Saying "required" is a bit strong: having an architecture depending on a very technical component is never a good idea. What about LTS ? What about adoption ? You could say that you want to have a reference implementation using ICCOM. But forcing any OEM/Tier1 to use ICCOM is rather excessive IMO.

        Also, regarding IPC mechanisms, we currently have an alpha implementation of AGL Appfw IPCs on top of rpmsg/openAMP to let 2 userland services/apps hosted in both worlds communicate through APIs verbs, as presented by Julien recently at AMM (https://sched.co/hdqo).

        1. Naoto YAMAGUCHI

          Iotb'z create other solutions, it's ok. I think good contributions. But we not select it in current architecture.
          We are building I.C. software stack now. Main component selection is completed. This topic is based on this architecture.

          We will start discussion for our next generations architecture in end of year maybe. In this timing, if eg members think to your solution is more better, may will start discussion.

          1. Stephane Desneux

            Thanks for the hint: I was not aware that such architecture decision had been made finally (there are always some parts of mystery and misunderstanding, even in open projects like AGL...)

            Anyway, feel free to ping us on this topic: you know how to reach us. I have no doubt that we'll all make progress on this topic.


            1. Naoto YAMAGUCHI

              Thanks for your comment.

              Your Zephyer contributions is interesting.
              Previously, we plan to use NuttX, it's worked by kusakabe-san. That work using Renesas ICCOM. But that code is losted... These topic talked in last SAT GSoC discussion. Our mentorship plan was give up in this timing.

              After that, we found to Zephyer contributions from yours, it's informed by kurokawa-san.
              That was good information. We can continue this plan.
              I think that thanks for your zephyer contributions.

              1. Richard Elberger

                Could FreeRTOS be considered for a reference implementation?

              2. Stephane Desneux

                FYI, support for Renesas M3 has been added in mainline Zephyr project: https://github.com/zephyrproject-rtos/zephyr/pull/31307

                The support will be part of Zephyr 2.6 due in June 21 (will also be a LTS version).