| Message ID | 1458762442-9492-1-git-send-email-srinivas.kandagatla@linaro.org |
|---|---|
| State | New |
| Headers | show |
On 03/23/2016 12:47 PM, Srinivas Kandagatla wrote: > diff --git a/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts b/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts > new file mode 100644 > index 0000000..e96aab6 > --- /dev/null > +++ b/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts > @@ -0,0 +1,36 @@ > +#include "qcom-apq8064-v2.0.dtsi" > + > +/ { > + model = "Qualcomm Technologies, Inc. APQ8064 DragonBoard600c"; > + compatible = "qcom,apq8064-dragonboard600c", "qcom,apq8064"; Does the bootloader look at this string at all or is it using appended DTB design? I'm mostly worried about having that qcom,apq8064-dragonboard600c part. It should probably be qcom,apq8064-sbc or something like that instead. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Mar 23, 2016 at 1:30 PM, Srinivas Kandagatla <srinivas.kandagatla@linaro.org> wrote: > > > On 23/03/16 20:07, Stephen Boyd wrote: >> >> On 03/23/2016 12:47 PM, Srinivas Kandagatla wrote: >>> >>> diff --git a/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts >>> b/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts >>> new file mode 100644 >>> index 0000000..e96aab6 >>> --- /dev/null >>> +++ b/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts >>> @@ -0,0 +1,36 @@ >>> +#include "qcom-apq8064-v2.0.dtsi" >>> + >>> +/ { >>> + model = "Qualcomm Technologies, Inc. APQ8064 DragonBoard600c"; >>> + compatible = "qcom,apq8064-dragonboard600c", "qcom,apq8064"; >> >> >> Does the bootloader look at this string at all or is it using appended >> DTB design? I'm mostly worried about having that > > Not at least on APQ8064 bootloaders, as they are still missing DT support. > Currently we append dtb to the kernel. >> >> qcom,apq8064-dragonboard600c part. It should probably be >> qcom,apq8064-sbc or something like that instead. > > Will do that in next version. > This "sbc" isn't that just the abbreviation for "single board computer"? I find it hard to believe this is _the_ 8064 sbc or the only 8064 sbc. Also, if I make a product based of this board, with some minor changes, is that still the sbc? I think the compatible should be "qcom,apq8064-db600c", "qcom,apq8064-sbc", "qcom,apq8064" Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/23/2016 06:04 PM, Bjorn Andersson wrote: > On Wed, Mar 23, 2016 at 1:30 PM, Srinivas Kandagatla > <srinivas.kandagatla@linaro.org> wrote: >> >> On 23/03/16 20:07, Stephen Boyd wrote: >>> On 03/23/2016 12:47 PM, Srinivas Kandagatla wrote: >>>> diff --git a/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts >>>> b/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts >>>> new file mode 100644 >>>> index 0000000..e96aab6 >>>> --- /dev/null >>>> +++ b/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts >>>> @@ -0,0 +1,36 @@ >>>> +#include "qcom-apq8064-v2.0.dtsi" >>>> + >>>> +/ { >>>> + model = "Qualcomm Technologies, Inc. APQ8064 DragonBoard600c"; >>>> + compatible = "qcom,apq8064-dragonboard600c", "qcom,apq8064"; >>> >>> Does the bootloader look at this string at all or is it using appended >>> DTB design? I'm mostly worried about having that >> Not at least on APQ8064 bootloaders, as they are still missing DT support. >> Currently we append dtb to the kernel. >>> qcom,apq8064-dragonboard600c part. It should probably be >>> qcom,apq8064-sbc or something like that instead. >> Will do that in next version. >> > This "sbc" isn't that just the abbreviation for "single board > computer"? I find it hard to believe this is _the_ 8064 sbc or the > only 8064 sbc. I don't make up the names, but for other qcom sbc products the bootloader is looking for sbc there to make sure it picks the right dtb blob. So I guess this is _the_ qcom 8064 sbc? Definitely not _the_ 8064 sbc though. If this device won't get those bootloaders that look for this then it doesn't really matter and I don't care what this is named. Please take a look at Documentation/devicetree/bindings/arm/qcom.txt for what I'm talking about though. > > Also, if I make a product based of this board, with some minor > changes, is that still the sbc? > > I think the compatible should be "qcom,apq8064-db600c", > "qcom,apq8064-sbc", "qcom,apq8064" > > I really hope that people don't keep using the qcom bootloader dtb picking design if they make a new product based off qcom boards with a slight variation. They should replace the vendor part of the compatible anyway with their own vendor prefix, and then the bootloader would need to be updated to look for that string or something else. I really don't want to get in the business of updating dtbTool for all the non-qcom designs that pop up because they keep using the qcom dtb identification scheme. It almost doesn't scale right now and that's just qcom designs. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 23 March 2016 18:48:46 Stephen Boyd wrote: > >> > > This "sbc" isn't that just the abbreviation for "single board > > computer"? I find it hard to believe this is _the_ 8064 sbc or the > > only 8064 sbc. > > I don't make up the names, but for other qcom sbc products the > bootloader is looking for sbc there to make sure it picks the right dtb > blob. So I guess this is _the_ qcom 8064 sbc? Definitely not _the_ 8064 > sbc though. > Is it even made by Qualcomm? IIRC the 410c is made by Arrow, not Qualcomm. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 24, 2016 at 2:48 AM, Stephen Boyd <sboyd@codeaurora.org> wrote: > I don't make up the names, but for other qcom sbc products the > bootloader is looking for sbc there to make sure it picks the right dtb > blob. So I guess this is _the_ qcom 8064 sbc? Definitely not _the_ 8064 > sbc though. > > If this device won't get those bootloaders that look for this then it > doesn't really matter and I don't care what this is named. Please take a > look at Documentation/devicetree/bindings/arm/qcom.txt for what I'm > talking about though. I would really want to get rid of the 'i need to append the DTB' on this board. the DT support in the bootloader have been backported , I am really hoping we can use this DT aware LK, and thus rely on the compatible string, like we do on db410c. So this is important to get the name/property right, since we will get there. In fact, I am even hoping that once we publish this DT aware LK along with this board, the other myriad of 8064 based 'SBC' from various vendors will upgrade their bootloader, so that we can have a single 'boot' image (generated with the help of dtbTool) that works across all devices. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed 23 Mar 18:48 PDT 2016, Stephen Boyd wrote: > On 03/23/2016 06:04 PM, Bjorn Andersson wrote: > > On Wed, Mar 23, 2016 at 1:30 PM, Srinivas Kandagatla > > <srinivas.kandagatla@linaro.org> wrote: > >> > >> On 23/03/16 20:07, Stephen Boyd wrote: [..] > > > > Also, if I make a product based of this board, with some minor > > changes, is that still the sbc? > > > > I think the compatible should be "qcom,apq8064-db600c", > > "qcom,apq8064-sbc", "qcom,apq8064" > > > > > > I really hope that people don't keep using the qcom bootloader dtb > picking design if they make a new product based off qcom boards with a > slight variation. They should replace the vendor part of the compatible > anyway with their own vendor prefix, and then the bootloader would need > to be updated to look for that string or something else. I really don't > want to get in the business of updating dtbTool for all the non-qcom > designs that pop up because they keep using the qcom dtb identification > scheme. It almost doesn't scale right now and that's just qcom designs. At that other company the various dtb's that was to be picked for a given product was always to support the various SoC versions; so those devices always shipped with the mtp board-id and msm-id. As far as I've seen this is how Qualcomm's Android customers does it. But as things progress further I do see a need for being able to also pick the right product and at that point you're right that the vendor must change their boot loader. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/24, Nicolas Dechesne wrote: > On Thu, Mar 24, 2016 at 2:48 AM, Stephen Boyd <sboyd@codeaurora.org> wrote: > > I don't make up the names, but for other qcom sbc products the > > bootloader is looking for sbc there to make sure it picks the right dtb > > blob. So I guess this is _the_ qcom 8064 sbc? Definitely not _the_ 8064 > > sbc though. > > > > If this device won't get those bootloaders that look for this then it > > doesn't really matter and I don't care what this is named. Please take a > > look at Documentation/devicetree/bindings/arm/qcom.txt for what I'm > > talking about though. > > > I would really want to get rid of the 'i need to append the DTB' on > this board. the DT support in the bootloader have been backported , I > am really hoping we can use this DT aware LK, and thus rely on the > compatible string, like we do on db410c. So this is important to get > the name/property right, since we will get there. In fact, I am even > hoping that once we publish this DT aware LK along with this board, > the other myriad of 8064 based 'SBC' from various vendors will upgrade > their bootloader, so that we can have a single 'boot' image (generated > with the help of dtbTool) that works across all devices. Ok, I'm not sure how that's going to work though. If all these 'SBC' devices are using the same bootloader and that bootloader is looking into SMEM for the different device identifying attributes (called socinfo in the downstream kernel) we're going to need to make sure that the devices identify uniquely. There is the 'subtype' attribute, which is just a number to identify different variations of a similar board. I hope that all the 'SBC' boards are using different subtypes or things are going to start getting messy. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 52b34a0..265941a4 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -532,6 +532,7 @@ dtb-$(CONFIG_ARCH_PRIMA2) += \ prima2-evb.dtb dtb-$(CONFIG_ARCH_QCOM) += \ qcom-apq8064-cm-qs600.dtb \ + qcom-apq8064-dragonboard-600c.dtb \ qcom-apq8064-ifc6410.dtb \ qcom-apq8064-sony-xperia-yuga.dtb \ qcom-apq8064-asus-nexus7-flo.dtb \ diff --git a/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts b/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts new file mode 100644 index 0000000..e96aab6 --- /dev/null +++ b/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts @@ -0,0 +1,36 @@ +#include "qcom-apq8064-v2.0.dtsi" + +/ { + model = "Qualcomm Technologies, Inc. APQ8064 DragonBoard600c"; + compatible = "qcom,apq8064-dragonboard600c", "qcom,apq8064"; + + aliases { + serial0 = &gsbi7_serial; + serial1 = &gsbi1_serial; + }; + + soc { + gsbi@12440000 { + status = "okay"; + qcom,mode = <GSBI_PROT_UART_W_FC>; + serial@12450000 { + label = "LS-UART1"; + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&gsbi1_uart_4pins>; + }; + }; + + /* DEBUG UART */ + gsbi@16600000 { + status = "okay"; + qcom,mode = <GSBI_PROT_I2C_UART>; + serial@16640000 { + label = "LS-UART0"; + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&gsbi7_uart_2pins>; + }; + }; + }; +};
This patch adds support to DragonBoard600 with basic serial ports. DragonBoard600 is based on APQ8064. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> --- arch/arm/boot/dts/Makefile | 1 + .../arm/boot/dts/qcom-apq8064-dragonboard-600c.dts | 36 ++++++++++++++++++++++ 2 files changed, 37 insertions(+) create mode 100644 arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html