Re: [U-Boot] [PATCH] sunxi: Add new Mele_A1000G_quad defconfig

2015-06-03 Thread Ian Campbell
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.



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] sunxi: Add new Mele_A1000G_quad defconfig

2015-06-03 Thread Hans de Goede

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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] sunxi: Add new Mele_A1000G_quad defconfig

2015-06-03 Thread Ian Campbell
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.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] sunxi: Add new Mele_A1000G_quad defconfig

2015-06-03 Thread Hans de Goede

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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] sunxi: Add new Mele_A1000G_quad defconfig

2015-06-03 Thread Tom Rini
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
...

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] sunxi: Add new Mele_A1000G_quad defconfig

2015-06-02 Thread Hans de Goede

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 hdego...@redhat.com
diff --git a/configs/Mele_A1000G_quad_defconfig 
b/configs/Mele_A1000G_quad_defconfig
new file mode 100644
index 000..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


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] sunxi: Add new Mele_A1000G_quad defconfig

2015-06-02 Thread Tom Rini
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 hdego...@redhat.com
 diff --git a/configs/Mele_A1000G_quad_defconfig 
 b/configs/Mele_A1000G_quad_defconfig
 new file mode 100644
 index 000..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!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] sunxi: Add new Mele_A1000G_quad defconfig

2015-06-01 Thread Hans de Goede
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 hdego...@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

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 000..4404f37
--- /dev/null
+++ b/arch/arm/dts/sun6i-a31-a1000g-quad.dts
@@ -0,0 +1,149 @@
+/*
+ * Copyright 2014 Hans de Goede hdego...@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 {
+   

Re: [U-Boot] [PATCH] sunxi: Add new Mele_A1000G_quad defconfig

2015-06-01 Thread Ian Campbell
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 hdego...@redhat.com
 diff --git a/configs/Mele_A1000G_quad_defconfig 
 b/configs/Mele_A1000G_quad_defconfig
 new file mode 100644
 index 000..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 i...@hellion.org.uk

Ian.


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] sunxi: Add new Mele_A1000G_quad defconfig

2015-06-01 Thread Hans de Goede

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 hdego...@redhat.com
diff --git a/configs/Mele_A1000G_quad_defconfig 
b/configs/Mele_A1000G_quad_defconfig
new file mode 100644
index 000..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 i...@hellion.org.uk


Thanks for the review.

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] sunxi: Add new Mele_A1000G_quad defconfig

2015-06-01 Thread Tom Rini
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 hdego...@redhat.com
 diff --git a/configs/Mele_A1000G_quad_defconfig 
 b/configs/Mele_A1000G_quad_defconfig
 new file mode 100644
 index 000..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.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot