[agl-discussions] Proposal to handle AGL metadata
sebastien.douheret at iot.bzh
Thu Mar 22 21:51:32 UTC 2018
here is a quick proposal to address the problematic that Loïc
encountered and that was discussed during last dev meeting.
_Typical issues that need to be addressed :_
1. When building an application from the SDK, some build options may
depend on the machine/platform (MACHINE variable in bitbake). By
default this information is not available in Yocto SDK.
2. At first boot, we may complete the runtime configuration by
auto-detecting some hardware components: examples: MOST module on
Kingfisher, GPS, accelerometer, ....
3. At runtime it may also be useful to identify the particular hardware
options of the platform. As an example, we may want to adjust
weston.ini settings depending on the video output setup that may
change from one boot to another.
4. There are also production metadata that may change the behavior of
some services (example: car model impacting CAN signals definition
or audio system setup)
_Proposal to address these issues:_
A common solution could be to create /etc/agl-XXX files, similar to
/etc/os-release file but specific to AGL that can be sourced by any shell.
To address the above issues, we could typically defined:
1. /etc/agl-release :
Contain build information like MACHINE, AGL version, AGL features,
Yocto layer manifests, image information, ...
This file could be available both in target image and in SDK
sysroots / environment to ensure applications and platform consistency
2. /etc/agl-hardware-config :
Contain hardware setup that cannot be auto-detected.
This file may be generated / updated from different locations :
build time, manually by an operator, first boot...
For example: if a MOST module is available on the Kingfisher, we can
add a known variable into /etc/agl-hardware-config.
3. /etc/agl-runtime-config :
This file could be generated at each boot through udev rule or any
Typical usage: detect how many screens are plugged on the board.
4. /etc/agl-vehicle-config :
Contain car maker metadata. For example: car model, options, VIN...
As /etc files may be read-only, the runtime files could be
copy/generated into /run directory.
Specifically for SDK, Yocto offers an existing mechanism to extend the
SDK environment setup based on script fragments located in sysroot (for
example $OECORE_TARGET_SYSROOT/environment-setup.d/agl-setup.sh ).
It's easy to generate an extra script that will source the corresponding
To handle those operations, we propose to add a new AGL package named
for example agl-info.
Any feedback comments will be appreciated.
sebastien.douheret at iot.bzh - www.iot.bzh
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the automotive-discussions