| Message ID | 1425131285-8640-1-git-send-email-codekipper@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sat, Feb 28, 2015 at 02:48:05PM +0100, codekipper@gmail.com wrote: > From: Marcus Cooper <codekipper@gmail.com> > > The Mele I7 is a Allwinner A31 based Android TV box, with 1G RAM, > 8GB NAND flash, a RTL8188etv wifi chip, 3 USB Host ports using > USB-A receptacles, a micro USB-B receptacle for USB OTG, HDMI out, > a TRS connector for A/V, SPDIF and IrDA. > > This patch adds basic support for the device, more information can > be found here (http://linux-sunxi.org/Mele_I7). > > Signed-off-by: Marcus Cooper <codekipper@gmail.com> > --- > arch/arm/boot/dts/Makefile | 1 + > arch/arm/boot/dts/sun6i-a31-i7.dts | 150 +++++++++++++++++++++++++++++++++++++ > 2 files changed, 151 insertions(+) > create mode 100644 arch/arm/boot/dts/sun6i-a31-i7.dts > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index eae7706..8d9d5ea 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -532,6 +532,7 @@ dtb-$(CONFIG_MACH_SUN6I) += \ > sun6i-a31-app4-evb1.dtb \ > sun6i-a31-colombus.dtb \ > sun6i-a31-hummingbird.dtb \ > + sun6i-a31-i7.dtb \ > sun6i-a31-m9.dtb \ > sun6i-a31s-cs908.dtb > dtb-$(CONFIG_MACH_SUN7I) += \ > diff --git a/arch/arm/boot/dts/sun6i-a31-i7.dts b/arch/arm/boot/dts/sun6i-a31-i7.dts > new file mode 100644 > index 0000000..43fdcd5 > --- /dev/null > +++ b/arch/arm/boot/dts/sun6i-a31-i7.dts > @@ -0,0 +1,150 @@ > +/* > + * Copyright 2015 Marcus Cooper <codekipper@gmail.com> > + * > + * This file is dual-licensed: you can use it either under the terms > + * of the GPL or the X11 license, at your option. Note that this dual > + * licensing only applies to this file, and not this project as a > + * whole. > + * > + * a) This file is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation; either version 2 of the > + * License, or (at your option) any later version. > + * > + * This file 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. > + * > + * You should have received a copy of the GNU General Public > + * License along with this file; if not, write to the Free > + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, > + * MA 02110-1301 USA > + * > + * Or, alternatively, > + * > + * b) Permission is hereby granted, free of charge, to any person > + * obtaining a copy of this software and associated documentation > + * files (the "Software"), to deal in the Software without > + * restriction, including without limitation the rights to use, > + * copy, modify, merge, publish, distribute, sublicense, and/or > + * sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following > + * conditions: > + * > + * The above copyright notice and this permission notice shall be > + * included in all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > + * OTHER DEALINGS IN THE SOFTWARE. > + */ > + > +/dts-v1/; > +#include "sun6i-a31.dtsi" > +#include "sunxi-common-regulators.dtsi" > + > +#include <dt-bindings/gpio/gpio.h> > +#include <dt-bindings/pinctrl/sun4i-a10.h> > + > +/ { > + model = "Mele I7 Quad top set box"; > + compatible = "mele,i7", "allwinner,sun6i-a31"; > + > + chosen { > + bootargs = "earlyprintk console=ttyS0,115200"; Using earlyprintk by default is a bad idea if the kernel is configured with DEBUG_LL support for another SoC. I removed it and applied the patche. Thanks! Maxime
Hi, On 03-03-15 08:16, Maxime Ripard wrote: > On Sat, Feb 28, 2015 at 02:48:05PM +0100, codekipper@gmail.com wrote: >> From: Marcus Cooper <codekipper@gmail.com> >> >> The Mele I7 is a Allwinner A31 based Android TV box, with 1G RAM, >> 8GB NAND flash, a RTL8188etv wifi chip, 3 USB Host ports using >> USB-A receptacles, a micro USB-B receptacle for USB OTG, HDMI out, >> a TRS connector for A/V, SPDIF and IrDA. >> >> This patch adds basic support for the device, more information can >> be found here (http://linux-sunxi.org/Mele_I7). >> >> Signed-off-by: Marcus Cooper <codekipper@gmail.com> >> --- >> arch/arm/boot/dts/Makefile | 1 + >> arch/arm/boot/dts/sun6i-a31-i7.dts | 150 +++++++++++++++++++++++++++++++++++++ >> 2 files changed, 151 insertions(+) >> create mode 100644 arch/arm/boot/dts/sun6i-a31-i7.dts >> >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile >> index eae7706..8d9d5ea 100644 >> --- a/arch/arm/boot/dts/Makefile >> +++ b/arch/arm/boot/dts/Makefile >> @@ -532,6 +532,7 @@ dtb-$(CONFIG_MACH_SUN6I) += \ >> sun6i-a31-app4-evb1.dtb \ >> sun6i-a31-colombus.dtb \ >> sun6i-a31-hummingbird.dtb \ >> + sun6i-a31-i7.dtb \ >> sun6i-a31-m9.dtb \ >> sun6i-a31s-cs908.dtb >> dtb-$(CONFIG_MACH_SUN7I) += \ >> diff --git a/arch/arm/boot/dts/sun6i-a31-i7.dts b/arch/arm/boot/dts/sun6i-a31-i7.dts >> new file mode 100644 >> index 0000000..43fdcd5 >> --- /dev/null >> +++ b/arch/arm/boot/dts/sun6i-a31-i7.dts >> @@ -0,0 +1,150 @@ >> +/* >> + * Copyright 2015 Marcus Cooper <codekipper@gmail.com> >> + * >> + * This file is dual-licensed: you can use it either under the terms >> + * of the GPL or the X11 license, at your option. Note that this dual >> + * licensing only applies to this file, and not this project as a >> + * whole. >> + * >> + * a) This file is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU General Public License as >> + * published by the Free Software Foundation; either version 2 of the >> + * License, or (at your option) any later version. >> + * >> + * This file 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. >> + * >> + * You should have received a copy of the GNU General Public >> + * License along with this file; if not, write to the Free >> + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, >> + * MA 02110-1301 USA >> + * >> + * Or, alternatively, >> + * >> + * b) Permission is hereby granted, free of charge, to any person >> + * obtaining a copy of this software and associated documentation >> + * files (the "Software"), to deal in the Software without >> + * restriction, including without limitation the rights to use, >> + * copy, modify, merge, publish, distribute, sublicense, and/or >> + * sell copies of the Software, and to permit persons to whom the >> + * Software is furnished to do so, subject to the following >> + * conditions: >> + * >> + * The above copyright notice and this permission notice shall be >> + * included in all copies or substantial portions of the Software. >> + * >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, >> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES >> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND >> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT >> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, >> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR >> + * OTHER DEALINGS IN THE SOFTWARE. >> + */ >> + >> +/dts-v1/; >> +#include "sun6i-a31.dtsi" >> +#include "sunxi-common-regulators.dtsi" >> + >> +#include <dt-bindings/gpio/gpio.h> >> +#include <dt-bindings/pinctrl/sun4i-a10.h> >> + >> +/ { >> + model = "Mele I7 Quad top set box"; >> + compatible = "mele,i7", "allwinner,sun6i-a31"; >> + >> + chosen { >> + bootargs = "earlyprintk console=ttyS0,115200"; > > Using earlyprintk by default is a bad idea if the kernel is configured > with DEBUG_LL support for another SoC. While on this subject, u-boot now sets the chosen/stdout-path property up by default, which means that the kernel will do the right thing by default. So we we really do not need any bootargs= in our dts files. Currently we've a random mix where we do have bootargs in some, but not in most sunxi dts files. I believe we should simply remove it everywhere... Regards, Hans
On Tue, Mar 03, 2015 at 08:55:36AM +0100, Hans de Goede wrote: > >>+/ { > >>+ model = "Mele I7 Quad top set box"; > >>+ compatible = "mele,i7", "allwinner,sun6i-a31"; > >>+ > >>+ chosen { > >>+ bootargs = "earlyprintk console=ttyS0,115200"; > > > >Using earlyprintk by default is a bad idea if the kernel is configured > >with DEBUG_LL support for another SoC. > > While on this subject, u-boot now sets the chosen/stdout-path property > up by default, which means that the kernel will do the right thing by > default. So we we really do not need any bootargs= in our dts files. I just tested that this weekend, and it turned out that the kernel couldn't use it so far (ie, no output until init takes over and setup a TTY on ttyS0). Was it working for you? > Currently we've a random mix where we do have bootargs in some, but > not in most sunxi dts files. I believe we should simply remove it > everywhere... We used to set them in SoCs that are not supported by U-boot yet, and where the bootloader won't come and patch the DT (A31, A23, A80). Maxime
Hi, On 03-03-15 09:22, Maxime Ripard wrote: > On Tue, Mar 03, 2015 at 08:55:36AM +0100, Hans de Goede wrote: >>>> +/ { >>>> + model = "Mele I7 Quad top set box"; >>>> + compatible = "mele,i7", "allwinner,sun6i-a31"; >>>> + >>>> + chosen { >>>> + bootargs = "earlyprintk console=ttyS0,115200"; >>> >>> Using earlyprintk by default is a bad idea if the kernel is configured >>> with DEBUG_LL support for another SoC. >> >> While on this subject, u-boot now sets the chosen/stdout-path property >> up by default, which means that the kernel will do the right thing by >> default. So we we really do not need any bootargs= in our dts files. > > I just tested that this weekend, and it turned out that the kernel > couldn't use it so far (ie, no output until init takes over and setup > a TTY on ttyS0). > > Was it working for you? Yes, note that the kernel only honors the stdout-path property if there is no console= argument present if there is a console= argument present on the kernel cmdline then that will overrule the stdout-path property. Which board did you test with, and what u-boot and kernel version ? >> Currently we've a random mix where we do have bootargs in some, but >> not in most sunxi dts files. I believe we should simply remove it >> everywhere... > > We used to set them in SoCs that are not supported by U-boot yet, and > where the bootloader won't come and patch the DT (A31, A23, A80). Ah, so that is (was) the logic, following that logic we should probably remove bootargs= from at least the a23 and a31 boards (basically from all boards but a80). Regards, Hans
On Tue, Mar 03, 2015 at 02:20:31PM +0100, Hans de Goede wrote: > Hi, > > On 03-03-15 09:22, Maxime Ripard wrote: > >On Tue, Mar 03, 2015 at 08:55:36AM +0100, Hans de Goede wrote: > >>>>+/ { > >>>>+ model = "Mele I7 Quad top set box"; > >>>>+ compatible = "mele,i7", "allwinner,sun6i-a31"; > >>>>+ > >>>>+ chosen { > >>>>+ bootargs = "earlyprintk console=ttyS0,115200"; > >>> > >>>Using earlyprintk by default is a bad idea if the kernel is configured > >>>with DEBUG_LL support for another SoC. > >> > >>While on this subject, u-boot now sets the chosen/stdout-path property > >>up by default, which means that the kernel will do the right thing by > >>default. So we we really do not need any bootargs= in our dts files. > > > >I just tested that this weekend, and it turned out that the kernel > >couldn't use it so far (ie, no output until init takes over and setup > >a TTY on ttyS0). > > > >Was it working for you? > > Yes, note that the kernel only honors the stdout-path property if > there is no console= argument present if there is a console= argument > present on the kernel cmdline then that will overrule the stdout-path > property Yeah, I removed the bootargs entirely. > Which board did you test with, and what u-boot and kernel version ? I tested it on my A31 hummingbird, with allwinner's u-boot, but with /chosen/stdout-path hardcoded to "serial0:115200n8", with a 4.0-rc1 kernel. But it might very well just be me. We just tested it on a Marvell board (that uses the same serial driver) this morning and it was fine, so I don't think it's really worth worrying about this :) > >>Currently we've a random mix where we do have bootargs in some, but > >>not in most sunxi dts files. I believe we should simply remove it > >>everywhere... > > > >We used to set them in SoCs that are not supported by U-boot yet, and > >where the bootloader won't come and patch the DT (A31, A23, A80). > > Ah, so that is (was) the logic, following that logic we should probably > remove bootargs= from at least the a23 and a31 boards (basically > from all boards but a80). I'm not so sure about the A31, since most boards won't even boot by default on the SD card, and we have no way to replace U-Boot in NAND so far (afaik). But replacing them by stdout-path is a very good solution too. Maxime
Hi, On 03-03-15 14:58, Maxime Ripard wrote: > On Tue, Mar 03, 2015 at 02:20:31PM +0100, Hans de Goede wrote: >> Hi, >> >> On 03-03-15 09:22, Maxime Ripard wrote: >>> On Tue, Mar 03, 2015 at 08:55:36AM +0100, Hans de Goede wrote: >>>>>> +/ { >>>>>> + model = "Mele I7 Quad top set box"; >>>>>> + compatible = "mele,i7", "allwinner,sun6i-a31"; >>>>>> + >>>>>> + chosen { >>>>>> + bootargs = "earlyprintk console=ttyS0,115200"; >>>>> >>>>> Using earlyprintk by default is a bad idea if the kernel is configured >>>>> with DEBUG_LL support for another SoC. >>>> >>>> While on this subject, u-boot now sets the chosen/stdout-path property >>>> up by default, which means that the kernel will do the right thing by >>>> default. So we we really do not need any bootargs= in our dts files. >>> >>> I just tested that this weekend, and it turned out that the kernel >>> couldn't use it so far (ie, no output until init takes over and setup >>> a TTY on ttyS0). >>> >>> Was it working for you? >> >> Yes, note that the kernel only honors the stdout-path property if >> there is no console= argument present if there is a console= argument >> present on the kernel cmdline then that will overrule the stdout-path >> property > > Yeah, I removed the bootargs entirely. > >> Which board did you test with, and what u-boot and kernel version ? > > I tested it on my A31 hummingbird, with allwinner's u-boot, but with > /chosen/stdout-path hardcoded to "serial0:115200n8", with a 4.0-rc1 > kernel. I'm not sure if stdout-path supports aliases this is what u-boot is using, and which works fine (with 4.0-rc1 kernel): "/soc@01c00000/serial@01c28000:115200" > But it might very well just be me. We just tested it on a Marvell > board (that uses the same serial driver) this morning and it was fine, > so I don't think it's really worth worrying about this :) > >>>> Currently we've a random mix where we do have bootargs in some, but >>>> not in most sunxi dts files. I believe we should simply remove it >>>> everywhere... >>> >>> We used to set them in SoCs that are not supported by U-boot yet, and >>> where the bootloader won't come and patch the DT (A31, A23, A80). >> >> Ah, so that is (was) the logic, following that logic we should probably >> remove bootargs= from at least the a23 and a31 boards (basically >> from all boards but a80). > > I'm not so sure about the A31, since most boards won't even boot by > default on the SD card True. > and we have no way to replace U-Boot in NAND > so far (afaik). But replacing them by stdout-path is a very good > solution too. You mean putting stdout-path in the dts, I'm not sure if I like that, to me both bootargs and stdout-path are something which should be left to the bootloader to set. But I understand that when not using upstream u-boot that may be an issue. Regards, Hans
On Tue, 2015-03-10 at 12:16 +0100, Hans de Goede wrote:
> I'm not sure if stdout-path supports aliases
I thought it did but ePAPR section 3.5 says "A string that specifies the
full path to the node" which suggests not, and AFAICT the code doesn't
try to handle alias.
Ian.
On Tue, Mar 10, 2015 at 12:16:07PM +0100, Hans de Goede wrote: > Hi, > > On 03-03-15 14:58, Maxime Ripard wrote: > >On Tue, Mar 03, 2015 at 02:20:31PM +0100, Hans de Goede wrote: > >>Hi, > >> > >>On 03-03-15 09:22, Maxime Ripard wrote: > >>>On Tue, Mar 03, 2015 at 08:55:36AM +0100, Hans de Goede wrote: > >>>>>>+/ { > >>>>>>+ model = "Mele I7 Quad top set box"; > >>>>>>+ compatible = "mele,i7", "allwinner,sun6i-a31"; > >>>>>>+ > >>>>>>+ chosen { > >>>>>>+ bootargs = "earlyprintk console=ttyS0,115200"; > >>>>> > >>>>>Using earlyprintk by default is a bad idea if the kernel is configured > >>>>>with DEBUG_LL support for another SoC. > >>>> > >>>>While on this subject, u-boot now sets the chosen/stdout-path property > >>>>up by default, which means that the kernel will do the right thing by > >>>>default. So we we really do not need any bootargs= in our dts files. > >>> > >>>I just tested that this weekend, and it turned out that the kernel > >>>couldn't use it so far (ie, no output until init takes over and setup > >>>a TTY on ttyS0). > >>> > >>>Was it working for you? > >> > >>Yes, note that the kernel only honors the stdout-path property if > >>there is no console= argument present if there is a console= argument > >>present on the kernel cmdline then that will overrule the stdout-path > >>property > > > >Yeah, I removed the bootargs entirely. > > > >>Which board did you test with, and what u-boot and kernel version ? > > > >I tested it on my A31 hummingbird, with allwinner's u-boot, but with > >/chosen/stdout-path hardcoded to "serial0:115200n8", with a 4.0-rc1 > >kernel. > > I'm not sure if stdout-path supports aliases this is what u-boot is using, > and which works fine (with 4.0-rc1 kernel): "/soc@01c00000/serial@01c28000:115200" I gave that another try, and it worked like a charm, so it really looks like an instance of PEBKAC. > >But it might very well just be me. We just tested it on a Marvell > >board (that uses the same serial driver) this morning and it was fine, > >so I don't think it's really worth worrying about this :) > > > >>>>Currently we've a random mix where we do have bootargs in some, but > >>>>not in most sunxi dts files. I believe we should simply remove it > >>>>everywhere... > >>> > >>>We used to set them in SoCs that are not supported by U-boot yet, and > >>>where the bootloader won't come and patch the DT (A31, A23, A80). > >> > >>Ah, so that is (was) the logic, following that logic we should probably > >>remove bootargs= from at least the a23 and a31 boards (basically > >>from all boards but a80). > > > >I'm not so sure about the A31, since most boards won't even boot by > >default on the SD card > > True. > > > and we have no way to replace U-Boot in NAND > >so far (afaik). But replacing them by stdout-path is a very good > >solution too. > > You mean putting stdout-path in the dts, I'm not sure if I like that, > to me both bootargs and stdout-path are something which should be > left to the bootloader to set. But I understand that when not > using upstream u-boot that may be an issue. I know that some other platforms ask for stdout-path when they review it, because iirc, barebox uses it to know on which console to output its log and export its shell, which is also a valid interpretation of that property, and, contrary to bootargs, doesn't really imply that the bootloader should update it. Maxime
Hi, On 03/10/2015 07:44 PM, Maxime Ripard wrote: > On Tue, Mar 10, 2015 at 12:16:07PM +0100, Hans de Goede wrote: >> Hi, >> >> On 03-03-15 14:58, Maxime Ripard wrote: >>> On Tue, Mar 03, 2015 at 02:20:31PM +0100, Hans de Goede wrote: >>>> Hi, >>>> >>>> On 03-03-15 09:22, Maxime Ripard wrote: >>>>> On Tue, Mar 03, 2015 at 08:55:36AM +0100, Hans de Goede wrote: >>>>>>>> +/ { >>>>>>>> + model = "Mele I7 Quad top set box"; >>>>>>>> + compatible = "mele,i7", "allwinner,sun6i-a31"; >>>>>>>> + >>>>>>>> + chosen { >>>>>>>> + bootargs = "earlyprintk console=ttyS0,115200"; >>>>>>> >>>>>>> Using earlyprintk by default is a bad idea if the kernel is configured >>>>>>> with DEBUG_LL support for another SoC. >>>>>> >>>>>> While on this subject, u-boot now sets the chosen/stdout-path property >>>>>> up by default, which means that the kernel will do the right thing by >>>>>> default. So we we really do not need any bootargs= in our dts files. >>>>> >>>>> I just tested that this weekend, and it turned out that the kernel >>>>> couldn't use it so far (ie, no output until init takes over and setup >>>>> a TTY on ttyS0). >>>>> >>>>> Was it working for you? >>>> >>>> Yes, note that the kernel only honors the stdout-path property if >>>> there is no console= argument present if there is a console= argument >>>> present on the kernel cmdline then that will overrule the stdout-path >>>> property >>> >>> Yeah, I removed the bootargs entirely. >>> >>>> Which board did you test with, and what u-boot and kernel version ? >>> >>> I tested it on my A31 hummingbird, with allwinner's u-boot, but with >>> /chosen/stdout-path hardcoded to "serial0:115200n8", with a 4.0-rc1 >>> kernel. >> >> I'm not sure if stdout-path supports aliases this is what u-boot is using, >> and which works fine (with 4.0-rc1 kernel): "/soc@01c00000/serial@01c28000:115200" > > I gave that another try, and it worked like a charm, so it really > looks like an instance of PEBKAC. > >>> But it might very well just be me. We just tested it on a Marvell >>> board (that uses the same serial driver) this morning and it was fine, >>> so I don't think it's really worth worrying about this :) >>> >>>>>> Currently we've a random mix where we do have bootargs in some, but >>>>>> not in most sunxi dts files. I believe we should simply remove it >>>>>> everywhere... >>>>> >>>>> We used to set them in SoCs that are not supported by U-boot yet, and >>>>> where the bootloader won't come and patch the DT (A31, A23, A80). >>>> >>>> Ah, so that is (was) the logic, following that logic we should probably >>>> remove bootargs= from at least the a23 and a31 boards (basically >>> >from all boards but a80). >>> >>> I'm not so sure about the A31, since most boards won't even boot by >>> default on the SD card >> >> True. >> >>> and we have no way to replace U-Boot in NAND >>> so far (afaik). But replacing them by stdout-path is a very good >>> solution too. >> >> You mean putting stdout-path in the dts, I'm not sure if I like that, >> to me both bootargs and stdout-path are something which should be >> left to the bootloader to set. But I understand that when not >> using upstream u-boot that may be an issue. > > I know that some other platforms ask for stdout-path when they review > it, because iirc, barebox uses it to know on which console to output > its log and export its shell, which is also a valid interpretation of > that property, and, contrary to bootargs, doesn't really imply that > the bootloader should update it. Hmm, that is interesting we should probably start doing the same in all the sunxi dts files, as eventually I would like to move all u-boot board config to devicetree, so that we only need to maintain dts files and not both dts files and u-boot board configs. Regards, Hans
On Tue, Mar 10, 2015 at 11:33:51PM +0100, Hans de Goede wrote: > >>>and we have no way to replace U-Boot in NAND > >>>so far (afaik). But replacing them by stdout-path is a very good > >>>solution too. > >> > >>You mean putting stdout-path in the dts, I'm not sure if I like that, > >>to me both bootargs and stdout-path are something which should be > >>left to the bootloader to set. But I understand that when not > >>using upstream u-boot that may be an issue. > > > >I know that some other platforms ask for stdout-path when they review > >it, because iirc, barebox uses it to know on which console to output > >its log and export its shell, which is also a valid interpretation of > >that property, and, contrary to bootargs, doesn't really imply that > >the bootloader should update it. > > Hmm, that is interesting we should probably start doing the same in > all the sunxi dts files, as eventually I would like to move all u-boot > board config to devicetree, so that we only need to maintain dts files > and not both dts files and u-boot board configs. I had the plan to remove all earlyprintk in the bootargs of the DTS, I can do it to convert all DTS to use stdout-path as well. Maxime
Hi, On 11-03-15 14:41, Maxime Ripard wrote: > On Tue, Mar 10, 2015 at 11:33:51PM +0100, Hans de Goede wrote: >>>>> and we have no way to replace U-Boot in NAND >>>>> so far (afaik). But replacing them by stdout-path is a very good >>>>> solution too. >>>> >>>> You mean putting stdout-path in the dts, I'm not sure if I like that, >>>> to me both bootargs and stdout-path are something which should be >>>> left to the bootloader to set. But I understand that when not >>>> using upstream u-boot that may be an issue. >>> >>> I know that some other platforms ask for stdout-path when they review >>> it, because iirc, barebox uses it to know on which console to output >>> its log and export its shell, which is also a valid interpretation of >>> that property, and, contrary to bootargs, doesn't really imply that >>> the bootloader should update it. >> >> Hmm, that is interesting we should probably start doing the same in >> all the sunxi dts files, as eventually I would like to move all u-boot >> board config to devicetree, so that we only need to maintain dts files >> and not both dts files and u-boot board configs. > > I had the plan to remove all earlyprintk in the bootargs of the DTS, I > can do it to convert all DTS to use stdout-path as well. Sounds good, please do. Regards, Hans
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index eae7706..8d9d5ea 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -532,6 +532,7 @@ dtb-$(CONFIG_MACH_SUN6I) += \ sun6i-a31-app4-evb1.dtb \ sun6i-a31-colombus.dtb \ sun6i-a31-hummingbird.dtb \ + sun6i-a31-i7.dtb \ sun6i-a31-m9.dtb \ sun6i-a31s-cs908.dtb dtb-$(CONFIG_MACH_SUN7I) += \ diff --git a/arch/arm/boot/dts/sun6i-a31-i7.dts b/arch/arm/boot/dts/sun6i-a31-i7.dts new file mode 100644 index 0000000..43fdcd5 --- /dev/null +++ b/arch/arm/boot/dts/sun6i-a31-i7.dts @@ -0,0 +1,150 @@ +/* + * Copyright 2015 Marcus Cooper <codekipper@gmail.com> + * + * This file is dual-licensed: you can use it either under the terms + * of the GPL or the X11 license, at your option. Note that this dual + * licensing only applies to this file, and not this project as a + * whole. + * + * a) This file is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of the + * License, or (at your option) any later version. + * + * This file 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. + * + * You should have received a copy of the GNU General Public + * License along with this file; if not, write to the Free + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, + * MA 02110-1301 USA + * + * Or, alternatively, + * + * b) Permission is hereby granted, free of charge, to any person + * obtaining a copy of this software and associated documentation + * files (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use, + * copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following + * conditions: + * + * The above copyright notice and this permission notice shall be + * included in all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + */ + +/dts-v1/; +#include "sun6i-a31.dtsi" +#include "sunxi-common-regulators.dtsi" + +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/pinctrl/sun4i-a10.h> + +/ { + model = "Mele I7 Quad top set box"; + compatible = "mele,i7", "allwinner,sun6i-a31"; + + chosen { + bootargs = "earlyprintk console=ttyS0,115200"; + }; + + leds { + compatible = "gpio-leds"; + pinctrl-names = "default"; + pinctrl-0 = <&led_pins_i7>; + + blue { + label = "i7:blue:usr"; + gpios = <&pio 7 13 GPIO_ACTIVE_HIGH>; + }; + }; +}; + +&ehci0 { + status = "okay"; +}; + +&ehci1 { + status = "okay"; +}; + +&gmac { + pinctrl-names = "default"; + pinctrl-0 = <&gmac_pins_mii_a>; + phy = <&phy1>; + phy-mode = "mii"; + status = "okay"; + + phy1: ethernet-phy@1 { + reg = <1>; + }; +}; + +&ir { + pinctrl-names = "default"; + pinctrl-0 = <&ir_pins_a>; + status = "okay"; +}; + +&mmc0 { + pinctrl-names = "default"; + pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_i7>; + vmmc-supply = <®_vcc3v3>; + bus-width = <4>; + cd-gpios = <&pio 7 22 GPIO_ACTIVE_HIGH>; /* PH22 */ + cd-inverted; + status = "okay"; +}; + +&pio { + led_pins_i7: led_pins@0 { + allwinner,pins = "PH13"; + allwinner,function = "gpio_out"; + allwinner,drive = <SUN4I_PINCTRL_10_MA>; + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>; + }; + + mmc0_cd_pin_i7: mmc0_cd_pin@0 { + allwinner,pins = "PH22"; + allwinner,function = "gpio_in"; + allwinner,drive = <SUN4I_PINCTRL_10_MA>; + allwinner,pull = <SUN4I_PINCTRL_PULL_UP>; + }; + + usb1_vbus_pin_i7: usb1_vbus_pin@0 { + allwinner,pins = "PC27"; + allwinner,function = "gpio_out"; + allwinner,drive = <SUN4I_PINCTRL_10_MA>; + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>; + }; +}; + +®_usb1_vbus { + pinctrl-names = "default"; + pinctrl-0 = <&usb1_vbus_pin_i7>; + gpio = <&pio 2 27 GPIO_ACTIVE_HIGH>; + status = "okay"; +}; + +&uart0 { + pinctrl-names = "default"; + pinctrl-0 = <&uart0_pins_a>; + status = "okay"; +}; + +&usbphy { + usb1_vbus-supply = <®_usb1_vbus>; + status = "okay"; +};