Add (build+run)time mechanisms to enhance hw detection and platform options
Description
Environment
relates to
Activity
Stephane Desneux October 17, 2019 at 8:51 PM
I managed to finalize a bunch of scripts that will help to solve this issue.
Please take a look at the README here: https://github.com/iotbzh/platform-runtime-tools
Current hw detection is done for intel, renesas and partially for raspberry pi (see: https://github.com/iotbzh/platform-runtime-tools/tree/master/scriptlets/detect/core) . Other boards will have to be added by their respective owners. For integration, the detection scripts should also be packaged separately in meta-agl/meta-agl-bsp instead of having them in platform-runtime-tools.
Firstboot detection is also covered: pr-detect has the ability to run detection scripts only once at firstboot.
Hotplug is not handled yet, but some scripting could be added later to interact with udev and maintain the hw information up to date.
Values are available in two formats, as with build info: a shell-compatible file and a JSON file (reminder: the JSON files are all parsed by AGL service 'platform-info' => all variables hereafter are available to any AGL service or app!)
As a summary, here's the outcome in /etc/platform-info on H3+KF:
We can discuss on which key should be defined for every architecture/vendor/board and the ones which are optional. But I think we can decently use the above set as a beginning for all boards.
Stephane Desneux August 2, 2019 at 9:56 AM
No this shouldn't be closed. As I explained in , we have something working but not for all boards.
Sebastien Douheret August 1, 2019 at 8:17 AM
This task must be kept open, the sub-task is not done.
Walt Miner July 31, 2019 at 5:22 PM
Can this issue be closed?
Tom Rini October 3, 2018 at 12:58 PM
Your overall proposal is fine. Start out with providing "board name". Per Romain's script we can provide N strings from the high-level compatible entry and on x86-64 we will have /sys/devices/virtual/dmi/id/product_name available.
Details
Details
Assignee
Stephane DesneuxReporter
ronan Le MartretLabels
Contract ID
Priority
Major
NOTE: Description rewritten on July 6th 2018
4 steps envisioned:
at build time, add information for static build information, like machine, agl features, layers commit ids (manifest) etc. The SDK should also expose the same information, so that they can be reused when packaging apps to add automatic platform dependencies (ex: an app would require AGL version >= 5.0.3 because SDK has version 5.0.3)
at first boot, add information related to "deep" hardware detection, like detecting hardware features that can't be specified as machne-specific. Scriptlets mode envisioned here = add a way to specify a script fragment at build time that would land in the right folder to be launched at first boot. This is very close to the first boot mechanism to install widgets, propbably occuring earlier in the boot workflow.
at each boot, add information related to "quick" hardware inspection, like: HDMI connectors enabled, USB devices piugged in ... anything that could change from one boot to another (= we're close to hotplug and udev rules). Again, scriptlet mode envisioned here, to let every package ship a script fragment that will try to detect things.
at any time (build, firstboot, later...), a custom vehicle-specific file could be added for custom options not so related to hardware but more to integrator choices
For each step, try to have a commonality:
same utility/method to generate/modify files (kinda very simplistic registry tool), used as native tool during build or on the target from firstboot+boot detection scripts
1 file per step. Proposal:
/etc/platform-build-info: static info from build
/etc/platform-hw-info: firstboot detection, mostly dedicated to static HW config
/etc/platform-runtime-info: every-boot detection
/etc/platform-custom-info: customization, left to integrators
dual format mode for each step
/etc/platform-xxxxx-info with "shell format" (=the same as etc/os-release AKA LSB format): VAR="value" - useful for shell scripts and systemd env sourcing
/etc/platform-xxxxx-info.json with JSON format, mostly useful from bindings which are used to read and parse json easily, but also to put some extra "complex" data structures less accessible in shell format. Typical examples: complex objects like full build manifests (=yocto layers git + commit IDs + branches)
Outcome:
make support easier (customer:"I have an issue on my AGL image bla bla bla"; operator:"please push me your /etc/platform-build-info")
provide a basic framework for runtime detection (usable in 4A for audio HAL adjustments, gfx environment, sensors network detection; network detection ...)
Hope to see many "platform-build-info" attached to Jira issues!
Update 2018-11-20:
let's put all files in /etc/platform-info (instead of /etc)
a binding is being created to abstract the information (see apps/agl-service-platform-info)