| Message ID | 1425503602-24916-1-git-send-email-galak@codeaurora.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wednesday 04 March 2015 15:13:20 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@vger.kernel.org> > Signed-off-by: Kumar Gala <galak@codeaurora.org> This seems to duplicate the root-node compatible strings for no particular reason, with a less flexible format. I think it would be better to fix the boot loader. Arnd
On Mar 4, 2015, at 3:19 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Wednesday 04 March 2015 15:13:20 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@vger.kernel.org> >> Signed-off-by: Kumar Gala <galak@codeaurora.org> > > This seems to duplicate the root-node compatible strings for no particular > reason, with a less flexible format. I think it would be better to fix > the boot loader. While I wish that was an option, this is a solution that has been shipping on MSM platforms and phones for some time. - k
Kumar Gala <galak@codeaurora.org> writes: > 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@vger.kernel.org> > Signed-off-by: Kumar Gala <galak@codeaurora.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
On Mar 5, 2015, at 1:42 PM, Kevin Hilman <khilman@kernel.org> wrote: > Kumar Gala <galak@codeaurora.org> writes: > >> 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@vger.kernel.org> >> Signed-off-by: Kumar Gala <galak@codeaurora.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 - k
On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala <galak@codeaurora.org> wrote: > > On Mar 5, 2015, at 1:42 PM, Kevin Hilman <khilman@kernel.org> wrote: > >> Kumar Gala <galak@codeaurora.org> writes: >> >>> 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@vger.kernel.org> >>> Signed-off-by: Kumar Gala <galak@codeaurora.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? -Olof
On Thu, Mar 5, 2015 at 8:59 PM, Olof Johansson <olof@lixom.net> wrote: > On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala <galak@codeaurora.org> wrote: >> >> On Mar 5, 2015, at 1:42 PM, Kevin Hilman <khilman@kernel.org> wrote: >> >>> Kumar Gala <galak@codeaurora.org> writes: >>> >>>> 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@vger.kernel.org> >>>> Signed-off-by: Kumar Gala <galak@codeaurora.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? > I never managed to figure out how to get that to work (at least on my apq8074 dragonboard.. fortunately ifc6540 seems to work w/ appended dtb).. kind of a pita because it is a bit of a non-standard boot.img format too.. Otoh getting an upstream (or even different kernel) kernel working can be hard enough as-is on random different tablet/phone/etc. Why not make whoever tries' life a bit easier by allowing some nonsense node into the qcom dtbs which makes it compatible w/ bootloaders already out there in the field ;-) BR, -R > > -Olof > -- > To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/05/2015 09:28 PM, Rob Clark wrote: > On Thu, Mar 5, 2015 at 8:59 PM, Olof Johansson <olof@lixom.net> wrote: >> On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala <galak@codeaurora.org> wrote: >>> >>> On Mar 5, 2015, at 1:42 PM, Kevin Hilman <khilman@kernel.org> wrote: >>> >>>> Kumar Gala <galak@codeaurora.org> writes: >>>> >>>>> 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@vger.kernel.org> >>>>> Signed-off-by: Kumar Gala <galak@codeaurora.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? >> > > I never managed to figure out how to get that to work (at least on my > apq8074 dragonboard.. fortunately ifc6540 seems to work w/ appended > dtb).. kind of a pita because it is a bit of a non-standard boot.img > format too.. I think you're talking about the boot flow from plain poweron which I wish I knew more about, but in case it's any help, here are some fastboot boot steps what worked for me a while back. http://elinux.org/Dragonboard/APQ8074 Chris
On Mar 5, 2015, at 7:59 PM, Olof Johansson <olof@lixom.net> wrote: > On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala <galak@codeaurora.org> wrote: >> >> On Mar 5, 2015, at 1:42 PM, Kevin Hilman <khilman@kernel.org> wrote: >> >>> Kumar Gala <galak@codeaurora.org> writes: >>> >>>> 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@vger.kernel.org> >>>> Signed-off-by: Kumar Gala <galak@codeaurora.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. - k
On Fri, Mar 6, 2015 at 8:08 AM, Kumar Gala <galak@codeaurora.org> wrote: > > On Mar 5, 2015, at 7:59 PM, Olof Johansson <olof@lixom.net> wrote: > >> On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala <galak@codeaurora.org> wrote: >>> >>> On Mar 5, 2015, at 1:42 PM, Kevin Hilman <khilman@kernel.org> wrote: >>> >>>> Kumar Gala <galak@codeaurora.org> writes: >>>> >>>>> 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@vger.kernel.org> >>>>> Signed-off-by: Kumar Gala <galak@codeaurora.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? -Olof
On Mar 6, 2015, at 1:15 PM, Olof Johansson <olof@lixom.net> wrote: > On Fri, Mar 6, 2015 at 8:08 AM, Kumar Gala <galak@codeaurora.org> wrote: >> >> On Mar 5, 2015, at 7:59 PM, Olof Johansson <olof@lixom.net> wrote: >> >>> On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala <galak@codeaurora.org> wrote: >>>> >>>> On Mar 5, 2015, at 1:42 PM, Kevin Hilman <khilman@kernel.org> wrote: >>>> >>>>> Kumar Gala <galak@codeaurora.org> writes: >>>>> >>>>>> 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@vger.kernel.org> >>>>>> Signed-off-by: Kumar Gala <galak@codeaurora.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. - k
On Friday 06 March 2015 14:37:52 Kumar Gala wrote: > On Mar 6, 2015, at 1:15 PM, Olof Johansson <olof@lixom.net> wrote: > > > On Fri, Mar 6, 2015 at 8:08 AM, Kumar Gala <galak@codeaurora.org> wrote: > >> > >> On Mar 5, 2015, at 7:59 PM, Olof Johansson <olof@lixom.net> wrote: > >> > >>> On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala <galak@codeaurora.org> wrote: > >>>> > >>>> On Mar 5, 2015, at 1:42 PM, Kevin Hilman <khilman@kernel.org> wrote: > >>>> > >>>>> Kumar Gala <galak@codeaurora.org> writes: > >>>>> > >>>>>> 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@vger.kernel.org> > >>>>>> Signed-off-by: Kumar Gala <galak@codeaurora.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
On Mar 9, 2015, at 7:11 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Friday 06 March 2015 14:37:52 Kumar Gala wrote: >> On Mar 6, 2015, at 1:15 PM, Olof Johansson <olof@lixom.net> wrote: >> >>> On Fri, Mar 6, 2015 at 8:08 AM, Kumar Gala <galak@codeaurora.org> wrote: >>>> >>>> On Mar 5, 2015, at 7:59 PM, Olof Johansson <olof@lixom.net> wrote: >>>> >>>>> On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala <galak@codeaurora.org> wrote: >>>>>> >>>>>> On Mar 5, 2015, at 1:42 PM, Kevin Hilman <khilman@kernel.org> wrote: >>>>>> >>>>>>> Kumar Gala <galak@codeaurora.org> writes: >>>>>>> >>>>>>>> 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@vger.kernel.org> >>>>>>>> Signed-off-by: Kumar Gala <galak@codeaurora.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. - k
On Tue, Mar 10, 2015 at 10:13 AM, Kumar Gala <galak@codeaurora.org> wrote: > > On Mar 9, 2015, at 7:11 AM, Arnd Bergmann <arnd@arndb.de> wrote: > >> On Friday 06 March 2015 14:37:52 Kumar Gala wrote: >>> On Mar 6, 2015, at 1:15 PM, Olof Johansson <olof@lixom.net> wrote: >>> >>>> On Fri, Mar 6, 2015 at 8:08 AM, Kumar Gala <galak@codeaurora.org> wrote: >>>>> >>>>> On Mar 5, 2015, at 7:59 PM, Olof Johansson <olof@lixom.net> wrote: >>>>> >>>>>> On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala <galak@codeaurora.org> wrote: >>>>>>> >>>>>>> On Mar 5, 2015, at 1:42 PM, Kevin Hilman <khilman@kernel.org> wrote: >>>>>>> >>>>>>>> Kumar Gala <galak@codeaurora.org> writes: >>>>>>>> >>>>>>>>> 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@vger.kernel.org> >>>>>>>>> Signed-off-by: Kumar Gala <galak@codeaurora.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
>>>>>>>>> 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@vger.kernel.org> >>>>>>>>>> Signed-off-by: Kumar Gala <galak@codeaurora.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? - k
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@vger.kernel.org> > >>>>>>>>>> Signed-off-by: Kumar Gala <galak@codeaurora.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
On Mar 10, 2015, at 2:52 PM, Arnd Bergmann <arnd@arndb.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@vger.kernel.org> >>>>>>>>>>>> Signed-off-by: Kumar Gala <galak@codeaurora.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. - k
On Tue, Mar 10, 2015 at 3:52 PM, Arnd Bergmann <arnd@arndb.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@vger.kernel.org> >> >>>>>>>>>> Signed-off-by: Kumar Gala <galak@codeaurora.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. > still sounds like an extra hurdle for distro's.. can't you just add the extra entry in the dts files w/ a comment about workaround for bootloader (and then possibly *not* document the property)? BR, -R > Arnd > -- > To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Mar 10, 2015 at 12:57 PM, Kumar Gala <galak@codeaurora.org> wrote: > > On Mar 10, 2015, at 2:52 PM, Arnd Bergmann <arnd@arndb.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@vger.kernel.org> >>>>>>>>>>>>> Signed-off-by: Kumar Gala <galak@codeaurora.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
On Mar 11, 2015, at 10:33 AM, Bjorn Andersson <bjorn@kryo.se> wrote: > On Tue, Mar 10, 2015 at 12:57 PM, Kumar Gala <galak@codeaurora.org> wrote: >> >> On Mar 10, 2015, at 2:52 PM, Arnd Bergmann <arnd@arndb.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@vger.kernel.org> >>>>>>>>>>>>>> Signed-off-by: Kumar Gala <galak@codeaurora.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. Are you asking do we utilize the values out of the DT directly? If so, no. You are correct that the tool pulls them out. This is all about where we keep the information that associates a given DTB with its MSM-ID/BOARD-ID values. While we can move that info into a tool, it just means updating the tool constantly to map an compatible string to those values. The other means is keeping the values with the DTB as properties as this binding suggests. - k
On Wednesday 11 March 2015 08:33:04 Bjorn Andersson wrote: > > 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. > I guess if I understand this right, we just need to fix that dtbTool then to look at the top-level compatible property and/or machine name instead? Arnd
On Mar 11, 2015, at 3:20 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Wednesday 11 March 2015 08:33:04 Bjorn Andersson wrote: >> >> 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. >> > > I guess if I understand this right, we just need to fix that dtbTool > then to look at the top-level compatible property and/or machine > name instead? > > Arnd Correct, and it means updating the tool for every board/dts that gets created in the future. Thus, the feeling was that having the ids kept with the dtb made maintenance far easier. - k
On Wednesday 11 March 2015 15:35:22 Kumar Gala wrote: > On Mar 11, 2015, at 3:20 PM, Arnd Bergmann <arnd@arndb.de> wrote: > > > On Wednesday 11 March 2015 08:33:04 Bjorn Andersson wrote: > >> > >> 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. > >> > > > > I guess if I understand this right, we just need to fix that dtbTool > > then to look at the top-level compatible property and/or machine > > name instead? > > > > Arnd > > Correct, and it means updating the tool for every board/dts that gets created in the future. > > Thus, the feeling was that having the ids kept with the dtb made maintenance far easier. > Part of my objection was to having nonstandard properties that are not even used anywhere in the kernel. If you could just encode them in the root compatible property as a string, that would be a lot nicer. Arnd
diff --git a/Documentation/devicetree/bindings/arm/msm/ids.txt b/Documentation/devicetree/bindings/arm/msm/ids.txt new file mode 100644 index 0000000..9ee8428 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/ids.txt @@ -0,0 +1,65 @@ +* MSM-ID + +The qcom,msm-id entry specifies the MSM chipset and hardware revision. It can +optionally be an array of these to indicate multiple hardware that use the same +device tree. It is expected that the bootloader will use this information at +boot-up to decide which device tree to use when given multiple device trees, +some of which may not be compatible with the actual hardware. It is the +bootloader's responsibility to pass the correct device tree to the kernel. + +PROPERTIES + +- qcom,msm-id: + Usage: required + Value type: <prop-encoded-array> (<chipset_id, rev_id> [, <c2, r2> ..]) + Definition: + The "chipset_id" consists of three fields as below: + + bits 0-15 = The unique MSM chipset id. + bits 16-31 = Reserved. Should be 0 + + chipset_id is an exact match value + + The "rev_id" is a chipset specific 32-bit id that represents + the version of the chipset. + + The rev_id is a best match id. The bootloader will look for + the closest possible patch. + +* BOARD-ID + +The qcom,board-id entry specifies the board type and revision information. It +can optionally be an array of these to indicate multiple boards that use the +same device tree. It is expected that the bootloader will use this information +at boot-up to decide which device tree to use when given multiple device trees, +some of which may not be compatible with the actual hardware. It is the +bootloader's responsibility to pass the correct device tree to the kernel. + +PROPERTIES + +- qcom,board-id: + Usage: required + Value type: <prop-encoded-array> (<board_id, subtype_id> [, <b2, s2> ..]) + Definition: + The "board_id" consists of three fields as below: + + bits 31-24 = Unusued. + bits 23-16 = Platform Version Major + bits 15-8 = Platfrom Version Minor + bits 7-0 = Platform Type + + Platform Type field is an exact match value. The Platform + Major/Minor field is a best match. The bootloader will look + for the closest possible match. + + The "subtype_id" is unique to a Platform Type/Chipset ID. For + a given Platform Type, there will typically only be a single + board and the subtype_id will be 0. However in some cases board + variants may need to be distinquished by different subtype_id + values. + + subtype_id is an exact match value. + +EXAMPLE: + qcom,board-id = <15 2>; + qcom,msm-id = <0x1007e 0>; diff --git a/include/dt-bindings/arm/qcom-ids.h b/include/dt-bindings/arm/qcom-ids.h new file mode 100644 index 0000000..a18f34e --- /dev/null +++ b/include/dt-bindings/arm/qcom-ids.h @@ -0,0 +1,33 @@ +/* Copyright (c) 2015, The Linux Foundation. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 and + * only version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ +#ifndef __DT_BINDINGS_QCOM_IDS_H +#define __DT_BINDINGS_QCOM_IDS_H + +/* qcom,msm-id */ +#define QCOM_ID_MSM8916 206 +#define QCOM_ID_APQ8016 247 +#define QCOM_ID_MSM8216 248 +#define QCOM_ID_MSM8116 249 +#define QCOM_ID_MSM8616 250 + +/* qcom,board-id */ +#define QCOM_BRD_ID(a, major, minor) \ + (((major & 0xff) << 16) | ((minor & 0xff) << 8) | QCOM_BRD_ID_##a) + +#define QCOM_BRD_ID_MTP 8 +#define QCOM_BRD_ID_DRAGONBRD 10 +#define QCOM_BRD_ID_SBC 24 + +#define QCOM_BRD_SUBTYPE_DEFAULT 0 +#define QCOM_BRD_SUBTYPE_MTP8916_SMB1360 1 + +#endif
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@vger.kernel.org> Signed-off-by: Kumar Gala <galak@codeaurora.org> --- Documentation/devicetree/bindings/arm/msm/ids.txt | 65 +++++++++++++++++++++++ include/dt-bindings/arm/qcom-ids.h | 33 ++++++++++++ 2 files changed, 98 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/msm/ids.txt create mode 100644 include/dt-bindings/arm/qcom-ids.h