diff mbox

[U-Boot] sunxi: Add new Mele_A1000G_quad defconfig

Message ID 1433170917-13601-1-git-send-email-hdegoede@redhat.com
State Accepted
Delegated to: Hans de Goede
Headers show

Commit Message

Hans de Goede June 1, 2015, 3:01 p.m. UTC
The Mele A1000G-quad and the Mele M9 have the same PCB, sofar we've been
using the same defconfig (and dts on the kernel side) for both models.
Unfortunately this does not work for the otg controller, on the M9 this
is routed to a micro-usb connector on the outside, while as on the
A1000G-quad it is connected to an usb to sata bridge.

This commit adds a new defconfig for the Mele-A1000G-quad to allow using
different otg controller settings on the 2 boards.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 arch/arm/dts/Makefile                  |   1 +
 arch/arm/dts/sun6i-a31-a1000g-quad.dts | 149 +++++++++++++++++++++++++++++++++
 board/sunxi/MAINTAINERS                |   1 +
 configs/Mele_A1000G_quad_defconfig     |  24 ++++++
 configs/Mele_M9_defconfig              |  10 +++
 5 files changed, 185 insertions(+)
 create mode 100644 arch/arm/dts/sun6i-a31-a1000g-quad.dts
 create mode 100644 configs/Mele_A1000G_quad_defconfig

Comments

Ian Campbell June 1, 2015, 6:12 p.m. UTC | #1
On Mon, 2015-06-01 at 17:01 +0200, Hans de Goede wrote:
> The Mele A1000G-quad and the Mele M9 have the same PCB, sofar we've been
> using the same defconfig (and dts on the kernel side) for both models.
> Unfortunately this does not work for the otg controller, on the M9 this
> is routed to a micro-usb connector on the outside, while as on the
> A1000G-quad it is connected to an usb to sata bridge.
> 
> This commit adds a new defconfig for the Mele-A1000G-quad to allow using
> different otg controller settings on the 2 boards.
> 
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> diff --git a/configs/Mele_A1000G_quad_defconfig b/configs/Mele_A1000G_quad_defconfig
> new file mode 100644
> index 0000000..b93dcf5
> --- /dev/null
> +++ b/configs/Mele_A1000G_quad_defconfig
> @@ -0,0 +1,24 @@
> +# The Mele A1000G quad is yet another Allwinnner based Android top set box
> +# from Mele.
> +#
> +# It uses the same case as the original Mele A1000 and the same PCB as the M9,
> +# the  USM sata storage slot is connected via anusb to sata bridge connected to
> +# the otg controller, this renders the micro USB B receptacle non functional.
> +#
> +# It features an A31 SoC, 2G RAM, 16G Nand, 100Mbit ethernet, HDMI out,
> +# 3 USB A receptacles, 3.5 mm jack for analog audio out, optical spdif,
> +# RTL R8188EU (USB) wifi and a full size sdcard slot

Have you seen the thread "Clean all defconfigs with savedefconfig" which
we were copied on today? It seems that these comments are subject to
automated cleansing :-/

So we should put them somewhere else. Tom says there "in a README
somewhere".

Apart from that and assuming this matches the Linux patch you copied me
on and _that_ gets accepted:

        Acked-by: Ian Campbell <ijc@hellion.org.uk>

Ian.
Hans de Goede June 1, 2015, 6:19 p.m. UTC | #2
Hi,

On 01-06-15 20:12, Ian Campbell wrote:
> On Mon, 2015-06-01 at 17:01 +0200, Hans de Goede wrote:
>> The Mele A1000G-quad and the Mele M9 have the same PCB, sofar we've been
>> using the same defconfig (and dts on the kernel side) for both models.
>> Unfortunately this does not work for the otg controller, on the M9 this
>> is routed to a micro-usb connector on the outside, while as on the
>> A1000G-quad it is connected to an usb to sata bridge.
>>
>> This commit adds a new defconfig for the Mele-A1000G-quad to allow using
>> different otg controller settings on the 2 boards.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> diff --git a/configs/Mele_A1000G_quad_defconfig b/configs/Mele_A1000G_quad_defconfig
>> new file mode 100644
>> index 0000000..b93dcf5
>> --- /dev/null
>> +++ b/configs/Mele_A1000G_quad_defconfig
>> @@ -0,0 +1,24 @@
>> +# The Mele A1000G quad is yet another Allwinnner based Android top set box
>> +# from Mele.
>> +#
>> +# It uses the same case as the original Mele A1000 and the same PCB as the M9,
>> +# the  USM sata storage slot is connected via anusb to sata bridge connected to
>> +# the otg controller, this renders the micro USB B receptacle non functional.
>> +#
>> +# It features an A31 SoC, 2G RAM, 16G Nand, 100Mbit ethernet, HDMI out,
>> +# 3 USB A receptacles, 3.5 mm jack for analog audio out, optical spdif,
>> +# RTL R8188EU (USB) wifi and a full size sdcard slot
>
> Have you seen the thread "Clean all defconfigs with savedefconfig" which
> we were copied on today? It seems that these comments are subject to
> automated cleansing :-/

<Explictly adding Tom to the list of recipients>

Tom, do we really want some autofoobar tool to mangle our defconfigs? Is there
a way we can opt out of this ?

Reasons to opt out:

1) Having comments like the one above on top of the defconfig files makes
it much easier for people to check if they are selecting the right defconfig

2) We deliberately duplicate some settings in defconfig files even though
they are the default since new users submitting new boards tend to copy and
paste an existing defconfig of a similar board and this way they have a short
list of settings to check against the actual board, because their board may
not be using the reference design pins which we use as defaults ...

So personally as sunxi maintainer I would like to opt out of this automatic
destruction of useful info in our defconfigs ...

> So we should put them somewhere else. Tom says there "in a README
> somewhere".
>
> Apart from that and assuming this matches the Linux patch you copied me
> on and _that_ gets accepted:
>
>          Acked-by: Ian Campbell <ijc@hellion.org.uk>

Thanks for the review.

Regards,

Hans
Tom Rini June 1, 2015, 8:46 p.m. UTC | #3
On Mon, Jun 01, 2015 at 08:19:23PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 01-06-15 20:12, Ian Campbell wrote:
> >On Mon, 2015-06-01 at 17:01 +0200, Hans de Goede wrote:
> >>The Mele A1000G-quad and the Mele M9 have the same PCB, sofar we've been
> >>using the same defconfig (and dts on the kernel side) for both models.
> >>Unfortunately this does not work for the otg controller, on the M9 this
> >>is routed to a micro-usb connector on the outside, while as on the
> >>A1000G-quad it is connected to an usb to sata bridge.
> >>
> >>This commit adds a new defconfig for the Mele-A1000G-quad to allow using
> >>different otg controller settings on the 2 boards.
> >>
> >>Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >>diff --git a/configs/Mele_A1000G_quad_defconfig b/configs/Mele_A1000G_quad_defconfig
> >>new file mode 100644
> >>index 0000000..b93dcf5
> >>--- /dev/null
> >>+++ b/configs/Mele_A1000G_quad_defconfig
> >>@@ -0,0 +1,24 @@
> >>+# The Mele A1000G quad is yet another Allwinnner based Android top set box
> >>+# from Mele.
> >>+#
> >>+# It uses the same case as the original Mele A1000 and the same PCB as the M9,
> >>+# the  USM sata storage slot is connected via anusb to sata bridge connected to
> >>+# the otg controller, this renders the micro USB B receptacle non functional.
> >>+#
> >>+# It features an A31 SoC, 2G RAM, 16G Nand, 100Mbit ethernet, HDMI out,
> >>+# 3 USB A receptacles, 3.5 mm jack for analog audio out, optical spdif,
> >>+# RTL R8188EU (USB) wifi and a full size sdcard slot
> >
> >Have you seen the thread "Clean all defconfigs with savedefconfig" which
> >we were copied on today? It seems that these comments are subject to
> >automated cleansing :-/
> 
> <Explictly adding Tom to the list of recipients>
> 
> Tom, do we really want some autofoobar tool to mangle our defconfigs? Is there
> a way we can opt out of this ?
> 
> Reasons to opt out:
> 
> 1) Having comments like the one above on top of the defconfig files makes
> it much easier for people to check if they are selecting the right defconfig
> 
> 2) We deliberately duplicate some settings in defconfig files even though
> they are the default since new users submitting new boards tend to copy and
> paste an existing defconfig of a similar board and this way they have a short
> list of settings to check against the actual board, because their board may
> not be using the reference design pins which we use as defaults ...
> 
> So personally as sunxi maintainer I would like to opt out of this automatic
> destruction of useful info in our defconfigs ...

So, historically people have put a lot of odds and ends info into either
include/configs/board.h or boards/vendor/board/board.c.  With Kconfig
we're moving away from the former and with things like sunxi where we
just slightly tweak some parameters to run on many boards we don't have
the latter the question is where to place otherwise generally useful
info.

The problem, to expand on what I said in the other thread, is that
*_defconfig is treated as an auto-generated file in Kbuild projects (I
know the kernel and I'm pretty sure elsewhere too).  This is only going
to get more noticable as we convert things over to real Kconfig choices,
meaning that if we opt-out of changing sunxi configs they're going to
get broken or make the conversion harder for everyone else.

We should be able to add say board/sunxi/README.txt and keep it
formatted such that new entries go on the bottom and have a predefined
separator at the end so that adding more boards doesn't conflict.
Hans de Goede June 2, 2015, 7:07 a.m. UTC | #4
Hi,

On 01-06-15 22:46, Tom Rini wrote:
> On Mon, Jun 01, 2015 at 08:19:23PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 01-06-15 20:12, Ian Campbell wrote:
>>> On Mon, 2015-06-01 at 17:01 +0200, Hans de Goede wrote:
>>>> The Mele A1000G-quad and the Mele M9 have the same PCB, sofar we've been
>>>> using the same defconfig (and dts on the kernel side) for both models.
>>>> Unfortunately this does not work for the otg controller, on the M9 this
>>>> is routed to a micro-usb connector on the outside, while as on the
>>>> A1000G-quad it is connected to an usb to sata bridge.
>>>>
>>>> This commit adds a new defconfig for the Mele-A1000G-quad to allow using
>>>> different otg controller settings on the 2 boards.
>>>>
>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>>> diff --git a/configs/Mele_A1000G_quad_defconfig b/configs/Mele_A1000G_quad_defconfig
>>>> new file mode 100644
>>>> index 0000000..b93dcf5
>>>> --- /dev/null
>>>> +++ b/configs/Mele_A1000G_quad_defconfig
>>>> @@ -0,0 +1,24 @@
>>>> +# The Mele A1000G quad is yet another Allwinnner based Android top set box
>>>> +# from Mele.
>>>> +#
>>>> +# It uses the same case as the original Mele A1000 and the same PCB as the M9,
>>>> +# the  USM sata storage slot is connected via anusb to sata bridge connected to
>>>> +# the otg controller, this renders the micro USB B receptacle non functional.
>>>> +#
>>>> +# It features an A31 SoC, 2G RAM, 16G Nand, 100Mbit ethernet, HDMI out,
>>>> +# 3 USB A receptacles, 3.5 mm jack for analog audio out, optical spdif,
>>>> +# RTL R8188EU (USB) wifi and a full size sdcard slot
>>>
>>> Have you seen the thread "Clean all defconfigs with savedefconfig" which
>>> we were copied on today? It seems that these comments are subject to
>>> automated cleansing :-/
>>
>> <Explictly adding Tom to the list of recipients>
>>
>> Tom, do we really want some autofoobar tool to mangle our defconfigs? Is there
>> a way we can opt out of this ?
>>
>> Reasons to opt out:
>>
>> 1) Having comments like the one above on top of the defconfig files makes
>> it much easier for people to check if they are selecting the right defconfig
>>
>> 2) We deliberately duplicate some settings in defconfig files even though
>> they are the default since new users submitting new boards tend to copy and
>> paste an existing defconfig of a similar board and this way they have a short
>> list of settings to check against the actual board, because their board may
>> not be using the reference design pins which we use as defaults ...
>>
>> So personally as sunxi maintainer I would like to opt out of this automatic
>> destruction of useful info in our defconfigs ...
>
> So, historically people have put a lot of odds and ends info into either
> include/configs/board.h or boards/vendor/board/board.c.  With Kconfig
> we're moving away from the former and with things like sunxi where we
> just slightly tweak some parameters to run on many boards we don't have
> the latter the question is where to place otherwise generally useful
> info.
>
> The problem, to expand on what I said in the other thread, is that
> *_defconfig is treated as an auto-generated file in Kbuild projects (I
> know the kernel and I'm pretty sure elsewhere too).  This is only going
> to get more noticable as we convert things over to real Kconfig choices,
> meaning that if we opt-out of changing sunxi configs they're going to
> get broken or make the conversion harder for everyone else.
>
> We should be able to add say board/sunxi/README.txt and keep it
> formatted such that new entries go on the bottom and have a predefined
> separator at the end so that adding more boards doesn't conflict.

If we stuff everything in one file people need to match which board
description belongs to which defconfig manually at which point
we might just as well point them to the linux-sunxi.org wiki
which has all this info + actual pictures of the devices.

So if there is no way to store this info in the defconfigs lets
just leave it out and will point people to the wiki.

Regards,

Hans
Tom Rini June 2, 2015, 1:35 p.m. UTC | #5
On Tue, Jun 02, 2015 at 09:07:53AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 01-06-15 22:46, Tom Rini wrote:
> >On Mon, Jun 01, 2015 at 08:19:23PM +0200, Hans de Goede wrote:
> >>Hi,
> >>
> >>On 01-06-15 20:12, Ian Campbell wrote:
> >>>On Mon, 2015-06-01 at 17:01 +0200, Hans de Goede wrote:
> >>>>The Mele A1000G-quad and the Mele M9 have the same PCB, sofar we've been
> >>>>using the same defconfig (and dts on the kernel side) for both models.
> >>>>Unfortunately this does not work for the otg controller, on the M9 this
> >>>>is routed to a micro-usb connector on the outside, while as on the
> >>>>A1000G-quad it is connected to an usb to sata bridge.
> >>>>
> >>>>This commit adds a new defconfig for the Mele-A1000G-quad to allow using
> >>>>different otg controller settings on the 2 boards.
> >>>>
> >>>>Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >>>>diff --git a/configs/Mele_A1000G_quad_defconfig b/configs/Mele_A1000G_quad_defconfig
> >>>>new file mode 100644
> >>>>index 0000000..b93dcf5
> >>>>--- /dev/null
> >>>>+++ b/configs/Mele_A1000G_quad_defconfig
> >>>>@@ -0,0 +1,24 @@
> >>>>+# The Mele A1000G quad is yet another Allwinnner based Android top set box
> >>>>+# from Mele.
> >>>>+#
> >>>>+# It uses the same case as the original Mele A1000 and the same PCB as the M9,
> >>>>+# the  USM sata storage slot is connected via anusb to sata bridge connected to
> >>>>+# the otg controller, this renders the micro USB B receptacle non functional.
> >>>>+#
> >>>>+# It features an A31 SoC, 2G RAM, 16G Nand, 100Mbit ethernet, HDMI out,
> >>>>+# 3 USB A receptacles, 3.5 mm jack for analog audio out, optical spdif,
> >>>>+# RTL R8188EU (USB) wifi and a full size sdcard slot
> >>>
> >>>Have you seen the thread "Clean all defconfigs with savedefconfig" which
> >>>we were copied on today? It seems that these comments are subject to
> >>>automated cleansing :-/
> >>
> >><Explictly adding Tom to the list of recipients>
> >>
> >>Tom, do we really want some autofoobar tool to mangle our defconfigs? Is there
> >>a way we can opt out of this ?
> >>
> >>Reasons to opt out:
> >>
> >>1) Having comments like the one above on top of the defconfig files makes
> >>it much easier for people to check if they are selecting the right defconfig
> >>
> >>2) We deliberately duplicate some settings in defconfig files even though
> >>they are the default since new users submitting new boards tend to copy and
> >>paste an existing defconfig of a similar board and this way they have a short
> >>list of settings to check against the actual board, because their board may
> >>not be using the reference design pins which we use as defaults ...
> >>
> >>So personally as sunxi maintainer I would like to opt out of this automatic
> >>destruction of useful info in our defconfigs ...
> >
> >So, historically people have put a lot of odds and ends info into either
> >include/configs/board.h or boards/vendor/board/board.c.  With Kconfig
> >we're moving away from the former and with things like sunxi where we
> >just slightly tweak some parameters to run on many boards we don't have
> >the latter the question is where to place otherwise generally useful
> >info.
> >
> >The problem, to expand on what I said in the other thread, is that
> >*_defconfig is treated as an auto-generated file in Kbuild projects (I
> >know the kernel and I'm pretty sure elsewhere too).  This is only going
> >to get more noticable as we convert things over to real Kconfig choices,
> >meaning that if we opt-out of changing sunxi configs they're going to
> >get broken or make the conversion harder for everyone else.
> >
> >We should be able to add say board/sunxi/README.txt and keep it
> >formatted such that new entries go on the bottom and have a predefined
> >separator at the end so that adding more boards doesn't conflict.
> 
> If we stuff everything in one file people need to match which board
> description belongs to which defconfig manually at which point
> we might just as well point them to the linux-sunxi.org wiki
> which has all this info + actual pictures of the devices.
> 
> So if there is no way to store this info in the defconfigs lets
> just leave it out and will point people to the wiki.

Yes, wiki it is then, thanks!
Ian Campbell June 3, 2015, 7:49 a.m. UTC | #6
On Tue, 2015-06-02 at 09:07 +0200, Hans de Goede wrote:
> So if there is no way to store this info in the defconfigs lets
> just leave it out and will point people to the wiki.

Would it be totally mad to have a string CONFIG_BOARD_URL containing a
URL (e.g. to the relevant wiki page) which was printed on boot i.e. in a
"Board Info: http://...." type thing and/or in the help output?

This started off as a thought on abusing Kconfig to somehow allow some
of this info to remain, but just that would be a step too far IMHO, but
if it also serves a (somewhat) practical purpose, then, maybe?

(I'm not convinced myself, but thought I'd mention it).

Ian.
Hans de Goede June 3, 2015, 8:15 a.m. UTC | #7
Hi,

On 03-06-15 09:49, Ian Campbell wrote:
> On Tue, 2015-06-02 at 09:07 +0200, Hans de Goede wrote:
>> So if there is no way to store this info in the defconfigs lets
>> just leave it out and will point people to the wiki.
>
> Would it be totally mad to have a string CONFIG_BOARD_URL containing a
> URL (e.g. to the relevant wiki page) which was printed on boot i.e. in a
> "Board Info: http://...." type thing and/or in the help output?
>
> This started off as a thought on abusing Kconfig to somehow allow some
> of this info to remain, but just that would be a step too far IMHO, but
> if it also serves a (somewhat) practical purpose, then, maybe?
>
> (I'm not convinced myself, but thought I'd mention it).

Interesting idea, I would not be against this, either at a global or
at a sunxi level, Tom ?

Regards,

Hans
Tom Rini June 3, 2015, 12:52 p.m. UTC | #8
On Wed, Jun 03, 2015 at 08:49:04AM +0100, Ian Campbell wrote:
> On Tue, 2015-06-02 at 09:07 +0200, Hans de Goede wrote:
> > So if there is no way to store this info in the defconfigs lets
> > just leave it out and will point people to the wiki.
> 
> Would it be totally mad to have a string CONFIG_BOARD_URL containing a
> URL (e.g. to the relevant wiki page) which was printed on boot i.e. in a
> "Board Info: http://...." type thing and/or in the help output?
> 
> This started off as a thought on abusing Kconfig to somehow allow some
> of this info to remain, but just that would be a step too far IMHO, but
> if it also serves a (somewhat) practical purpose, then, maybe?
> 
> (I'm not convinced myself, but thought I'd mention it).

Ah, MAINTAINERS can help here.  Checking out the kernel's copy:

Descriptions of section entries:

        P: Person (obsolete)
        M: Mail patches to: FullName <address@domain>
        L: Mailing list that is relevant to this area
        W: Web-page with status/info
...
Hans de Goede June 3, 2015, 2:09 p.m. UTC | #9
Hi,

On 03-06-15 14:52, Tom Rini wrote:
> On Wed, Jun 03, 2015 at 08:49:04AM +0100, Ian Campbell wrote:
>> On Tue, 2015-06-02 at 09:07 +0200, Hans de Goede wrote:
>>> So if there is no way to store this info in the defconfigs lets
>>> just leave it out and will point people to the wiki.
>>
>> Would it be totally mad to have a string CONFIG_BOARD_URL containing a
>> URL (e.g. to the relevant wiki page) which was printed on boot i.e. in a
>> "Board Info: http://...." type thing and/or in the help output?
>>
>> This started off as a thought on abusing Kconfig to somehow allow some
>> of this info to remain, but just that would be a step too far IMHO, but
>> if it also serves a (somewhat) practical purpose, then, maybe?
>>
>> (I'm not convinced myself, but thought I'd mention it).
>
> Ah, MAINTAINERS can help here.  Checking out the kernel's copy:
>
> Descriptions of section entries:
>
>          P: Person (obsolete)
>          M: Mail patches to: FullName <address@domain>
>          L: Mailing list that is relevant to this area
>          W: Web-page with status/info
> ...
>

Ah yes the W: option in MAINTAINERS is indeed the best place to
stick URL-s, thanks for your input.

Regards,

Hans
Ian Campbell June 3, 2015, 7:08 p.m. UTC | #10
On Wed, 2015-06-03 at 16:09 +0200, Hans de Goede wrote:
> Ah yes the W: option in MAINTAINERS is indeed the best place to
> stick URL-s, thanks for your input.

Agreed.
diff mbox

Patch

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 267fd17..acbd9b4 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -90,6 +90,7 @@  dtb-$(CONFIG_MACH_SUN5I) += \
 	sun5i-a13-tzx-q8-713b7.dtb \
 	sun5i-a13-utoo-p66.dtb
 dtb-$(CONFIG_MACH_SUN6I) += \
+	sun6i-a31-a1000g-quad.dtb \
 	sun6i-a31-app4-evb1.dtb \
 	sun6i-a31-colombus.dtb \
 	sun6i-a31-hummingbird.dtb \
diff --git a/arch/arm/dts/sun6i-a31-a1000g-quad.dts b/arch/arm/dts/sun6i-a31-a1000g-quad.dts
new file mode 100644
index 0000000..4404f37
--- /dev/null
+++ b/arch/arm/dts/sun6i-a31-a1000g-quad.dts
@@ -0,0 +1,149 @@ 
+/*
+ * Copyright 2014 Hans de Goede <hdegoede@redhat.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.
+ *
+ * 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 A1000G Quad top set box";
+	compatible = "mele,a1000g-quad", "allwinner,sun6i-a31";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&led_pins_m9>;
+
+		blue {
+			label = "m9: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_m9>;
+	vmmc-supply = <&reg_vcc3v3>;
+	bus-width = <4>;
+	cd-gpios = <&pio 7 22 GPIO_ACTIVE_HIGH>; /* PH22 */
+	cd-inverted;
+	status = "okay";
+};
+
+&pio {
+	led_pins_m9: 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_m9: 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_m9: usb1_vbus_pin@0 {
+		allwinner,pins = "PC27";
+		allwinner,function = "gpio_out";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+	};
+};
+
+&reg_usb1_vbus {
+	pinctrl-names = "default";
+	pinctrl-0 = <&usb1_vbus_pin_m9>;
+	gpio = <&pio 2 27 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_pins_a>;
+	status = "okay";
+};
+
+&usbphy {
+	usb1_vbus-supply = <&reg_usb1_vbus>;
+	status = "okay";
+};
diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 22d560a..0618ec8 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -10,6 +10,7 @@  F:	configs/Cubieboard_defconfig
 F:	configs/Hyundai_A7HD_defconfig
 F:	configs/jesurun_q5_defconfig
 F:	configs/Mele_A1000_defconfig
+F:	configs/Mele_A1000G_quad_defconfig
 F:	configs/Mele_M3_defconfig
 F:	configs/Mini-X_defconfig
 F:	configs/mk802_defconfig
diff --git a/configs/Mele_A1000G_quad_defconfig b/configs/Mele_A1000G_quad_defconfig
new file mode 100644
index 0000000..b93dcf5
--- /dev/null
+++ b/configs/Mele_A1000G_quad_defconfig
@@ -0,0 +1,24 @@ 
+# The Mele A1000G quad is yet another Allwinnner based Android top set box
+# from Mele.
+#
+# It uses the same case as the original Mele A1000 and the same PCB as the M9,
+# the  USM sata storage slot is connected via anusb to sata bridge connected to
+# the otg controller, this renders the micro USB B receptacle non functional.
+#
+# It features an A31 SoC, 2G RAM, 16G Nand, 100Mbit ethernet, HDMI out,
+# 3 USB A receptacles, 3.5 mm jack for analog audio out, optical spdif,
+# RTL R8188EU (USB) wifi and a full size sdcard slot
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_MACH_SUN6I=y
+CONFIG_DRAM_ZQ=120
+CONFIG_USB1_VBUS_PIN="PC27"
+CONFIG_USB2_VBUS_PIN=""
+CONFIG_DEFAULT_DEVICE_TREE="sun6i-a31-a1000g-quad"
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS="USB_EHCI,SUNXI_GMAC"
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_AXP221_DCDC1_VOLT=3300
+CONFIG_AXP221_DLDO1_VOLT=3300
+CONFIG_AXP221_DLDO4_VOLT=3300
+CONFIG_AXP221_ALDO1_VOLT=3300
diff --git a/configs/Mele_M9_defconfig b/configs/Mele_M9_defconfig
index 4708133..16881fa 100644
--- a/configs/Mele_M9_defconfig
+++ b/configs/Mele_M9_defconfig
@@ -1,3 +1,13 @@ 
+# The Mele M9 is yet another Allwinnner based Android top set box from Mele.
+#
+# It uses the same PCB as the A1000G quad, but in a new case without a
+# USM sata storage slot, and the space on the PCB for the usb to sata
+# bridge connected to the otg controller is not populated, possible
+# making the micro usb otg connector functional (untested)
+#
+# It features an A31 SoC, 2G RAM, 16G Nand, 100Mbit ethernet, HDMI out,
+# 3 USB A receptacles, 3.5 mm jack for analog audio out, optical spdif,
+# micro USB B receptacle, RTL R8188EU (USB) and a full size sdcard slot
 CONFIG_ARM=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_MACH_SUN6I=y