Since at least 2014 coreboot exports board specific variant ids for
board-revision, used ram-modules and component variants on the same board
into the loaded devicetree.
These are set on all devicetree-based Chromebooks since then, so at
least we can make the effort to document these long-used properties.
A case where these are used is for example to determine the touchscreen
type that is only identifyable via the sku-id when updating its firmware
on the Scarlet tablet from the Gru ChromeOS family.
Signed-off-by: Heiko Stuebner <heiko@xxxxxxxxx>
---
Documentation/devicetree/bindings/firmware/coreboot.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/firmware/coreboot.txt b/Documentation/devicetree/bindings/firmware/coreboot.txt
index 4c955703cea8..cfc7623e2577 100644
--- a/Documentation/devicetree/bindings/firmware/coreboot.txt
+++ b/Documentation/devicetree/bindings/firmware/coreboot.txt
@@ -21,6 +21,12 @@ Required properties:
0xc0389481 that resides in the topmost 8 bytes of the area.
See coreboot's src/include/imd.h for details.
+Board variant properties determined via strapping measures (like gpios):
+ - board-id: board-specific id indicating the board-revision
+ - ram-code: board-specific id identifying the used ram-module
+ - sku-id: board-specific id indicating a variant (using different
+ display panels for example)
+
Example:
firmware {
ranges;
--
2.17.0
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-rockchip
