AOSP master do not parse "/proc/cpuinfo" anymore to set ro.hardware and other boot related properties [1].
We can still boot by either adding "androidboot.hardware=XXX" bootarg (where XXX could be juno/hikey/ifc6410 or any other supported hardware platform) Or by embedding this boot information in the platform device tree blob as suggested by this AOSP commit [2].
I was wondering if ARMLT would be interested in keeping this Android boot related information in dts for Juno?
I have never touched anything related to device-trees, but by looking at [2], it seem the device-tree changes for Android won't be much complicated. The following device-tree hack worked for me: -------------------- diff --git a/arch/arm64/boot/dts/juno.dts b/arch/arm64/boot/dts/juno.dts index 9ad05e4..82471db 100644 --- a/arch/arm64/boot/dts/juno.dts +++ b/arch/arm64/boot/dts/juno.dts @@ -26,6 +26,13 @@ stdout-path = &soc_uart0; };
+ firmware { + android { + compatible = "android,firmware"; + hardware = "juno"; + }; + }; + psci { compatible = "arm,psci-0.2"; method = "smc"; --------------------
Regards, Amit Pundir
[1] https://android.googlesource.com/platform/system/core/+/74b34f3cb79aa8f2c5ba... [2] https://android.googlesource.com/platform/system/core.git/+/6a52443d31d4de56...
On Sun, 2015-04-19 at 01:31 +0530, Amit Pundir wrote:
AOSP master do not parse "/proc/cpuinfo" anymore to set ro.hardware and other boot related properties [1].
Hurray :-)
We can still boot by either adding "androidboot.hardware=XXX" bootarg (where XXX could be juno/hikey/ifc6410 or any other supported hardware platform) Or by embedding this boot information in the platform device tree blob as suggested by this AOSP commit [2].
I was wondering if ARMLT would be interested in keeping this Android boot related information in dts for Juno?
I can't find any documentation on the 'firmware' device-tree binding, but I can't help but think that:
a) firmware nodes should describe some property of the firmware b) be set by that firmware
Neither of which are true.
So my feeling would be that the 'correct' thing to do would be to use the kernel commandline argument method instead.
(Well, the most correct method IMO is for Android user-side to use the 'compatible' name from device-tree, and other existing device-tree entries if necessary, rather than invent it's own method of identifying the hardware it's running on).
linaro-android@lists.linaro.org