Add (build+run)time mechanisms to enhance hw detection and platform options
Description
Environment
Work | Priority | Story Points | Assignee | Status |
|---|---|---|---|---|
 Major |  Stephane Desneux | |||
| Major | Stephane Desneux | |||
| Major | Stephane Desneux |
relates to
Activity
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:
[10:49:02] root@h3ulcb:~# cd /etc/platform-info/
[10:49:06] root@h3ulcb:/etc/platform-info# ls -l
total 24
-rw-r--r-- 1 root root 2218 Oct 10 08:40 build
-rw-r--r-- 1 root root 2510 Oct 10 08:40 build.json
-rw-r--r-- 1 root root 341 Oct 10 08:37 core
-rw-r--r-- 1 root root 329 Oct 10 08:37 core.json
-rw-r--r-- 1 root root 118 Oct 10 08:37 devices
-rw-r--r-- 1 root root 115 Oct 10 08:37 devices.json
[10:49:08] root@h3ulcb:/etc/platform-info# cat core
HW_CPU_COUNT=8
HW_MEMORY_TOTAL_MB=3776
HW_SOC_FAMILY="R-Car Gen3"
HW_CPU_ARCH="aarch64"
HW_SOC_NAME="H3"
HW_CPU_FREQ_MHZ=1500
HW_SOC_ID="r8a7795"
HW_CPU_COMPATIBILITY="cortex-a57 armv8"
HW_GPU_NAME="IMG PowerVR Series6XT GX6650"
HW_CPU_CACHE_KB=3044
HW_SOC_REVISION="ES2.0"
HW_BOARD_MODEL="kingfisher-h3ulcb-r8a7795"
HW_SOC_VENDOR="renesas"
[10:49:13] root@h3ulcb:/etc/platform-info# cat devices
HW_BLUETOOTH_DEVICES="hci0"
HW_ETHERNET_DEVICES="eth0"
HW_CAN_DEVICES="can0 can1"
HW_WIFI_DEVICES="wlan0"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.
No this shouldn't be closed. As I explained in https://lf-automotivelinux.atlassian.net/browse/SPEC-1746#icft=SPEC-1746, we have something working but not for all boards.
This task must be kept open, the sub-task https://lf-automotivelinux.atlassian.net/browse/SPEC-2150#icft=SPEC-2150 is not done.
Can this issue be closed?
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
Reporter
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 ...)
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)