| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 11 Mar 2015 08:33:04 -0700 From: Bjorn Andersson <bjorn@...o.se> To: Kumar Gala <galak@...eaurora.org> Cc: Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>, Kevin Hilman <khilman@...nel.org>, linux-arm-msm <linux-arm-msm@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "arm@...nel.org" <arm@...nel.org>, "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, Heiko Stübner <heiko@...ech.de> Subject: Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id On Tue, Mar 10, 2015 at 12:57 PM, Kumar Gala <galak@...eaurora.org> wrote: > > On Mar 10, 2015, at 2:52 PM, Arnd Bergmann <arnd@...db.de> wrote: > >> On Tuesday 10 March 2015 13:10:08 Kumar Gala wrote: >>>>>>>>>>>> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders >>>>>>>>>>>>> on Qualcomm MSM platforms to determine which device tree should be >>>>>>>>>>>>> utilized and passed to the kernel. >>>>>>>>>>>>> >>>>>>>>>>>>> Cc: <devicetree@...r.kernel.org> >>>>>>>>>>>>> Signed-off-by: Kumar Gala <galak@...eaurora.org> >>>>>>>>>>>> >>>>>>>>>>>> Is this the special magic that allows qcom bootloaders to take a kernel >>>>>>>>>>>> plus multiple DTBs and figure out which DTB to pass? >>>>>>>>>>>> >>>>>>>>>>>> Kevin >>>>>>>>>>> >>>>>>>>>>> yes >>>>>>>>>> >>>>>>>>>> That's a bummer. >>>>>>>>>> >>>>>>>>>> Luckily, the solution for upstream is still quite simple: Provide only >>>>>>>>>> one devicetree, and it'll be used, right? >>>>>>>>> >>>>>>>>> We can provide only one, we still need the IDs in the DT. >>>>>>>> >>>>>>>> How are the DTS provided? Concatenated with the kernel, or in a >>>>>>>> wrapped data format? Or in a separate partition from the kernel? >>>>>>> >>>>>>> Its a wrapped data format that is than concatenated with the kernel if I remember correctly. >>>>>> >>>>>> Then you should be able to create a tool that can write this concatenated >>>>>> format and insert these properties from a table that matches the boot >>>>>> loader, right? >>>>>> >>>>>> Arnd >>>>> >>>>> Are you suggesting the tool insert the properties in the DT? I’m not sure I understand what the point of doing that would be. >>>> >>>> To insert platform-local properties that mean nothing outside of the >>>> firmware packaging of the device trees, which is the case here? >>>> >>>> I think the idea of having the installer script inserting them is >>>> quite reasonable in this case. >>>> >>>> >>>> -Olof >>> >>> These values are static, so not sure what the point of having the installer script do that? >>> >> >> It combines two hacks to work around a nonstandard boot loader. >> Once the bootloader is fixed, you can stop using that script. >> >> Arnd > > I feel as if I’m missing something here. If we just have the properties in the .dts files I don’t need to change anything ever, no script, no worries about working with old or new boot loaders, etc. > But are these values actually used by the boot loader? As far as I could see in 8974 the dtbTool provided by Qualcomm extracts the values from the list of dtbs and use them to create the table-of-content in the QCDT blob. The boot loader then looks in this TOC to pick the right dtb to use. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists