Skip to contentSkip to conversation

sunxi: Add new Mele_A1000G_quad defconfig

PATCH New Hans de Goede 3 participants 11 messages Jun 1, 2015 – Jun 3, 2015

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 sunxi: Add new Mele_A1000G_quad defconfig

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.

---
 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
arch/arm/dts/Makefile +1 -0
index 267fd17..acbd9b4 100644
@@ -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 \
arch/arm/dts/sun6i-a31-a1000g-quad.dts new file +149 -0

149 lines not on this page · raw message

board/sunxi/MAINTAINERS +1 -0
index 22d560a..0618ec8 100644
@@ -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
configs/Mele_A1000G_quad_defconfig new file +24 -0
new file mode 100644
index 0000000..b93dcf5
@@ -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
configs/Mele_M9_defconfig +10 -0
index 4708133..16881fa 100644
@@ -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
Signature · 1 line
2.4.2
#1 lore raw

PATCH 1/1 sunxi: Add new Mele_A1000G_quad defconfig

Quoted 16 lines · 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.

configs/Mele_A1000G_quad_defconfig new file +0 -0
new file mode 100644
index 0000000..b93dcf5

configs/Mele_A1000G_quad_defconfig line 10

Quoted 10 lines
configs/Mele_A1000G_quad_defconfig new file +10 -0
@@ -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:

Ian.

#2 lore raw

PATCH 1/1 sunxi: Add new Mele_A1000G_quad defconfig

Hi,

Quoted 23 lines · Ian Campbell
Quoted 22 lines · 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.

configs/Mele_A1000G_quad_defconfig new file +6 -0
new file mode 100644
index 0000000..b93dcf5
@@ -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.
Quoted 8 lines

configs/Mele_A1000G_quad_defconfig line 10

Quoted 4 lines
configs/Mele_A1000G_quad_defconfig new file +4 -0
+#
+# 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 ...

Quoted 7 lines

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:

Thanks for the review.

Regards,

Hans

#3 lore raw

PATCH 1/1 sunxi: Add new Mele_A1000G_quad defconfig

Quoted 45 lines · Hans de Goede

Hi,

Quoted 23 lines · Ian Campbell
Quoted 22 lines · 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.

configs/Mele_A1000G_quad_defconfig new file +6 -0
new file mode 100644
index 0000000..b93dcf5
@@ -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.
Quoted 8 lines

configs/Mele_A1000G_quad_defconfig line 10

Quoted 4 lines
configs/Mele_A1000G_quad_defconfig new file +4 -0
+#
+# 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

Quoted 8 lines

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.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150601/e1397635/attachment.sig>
#4 lore raw

PATCH 1/1 sunxi: Add new Mele_A1000G_quad defconfig

Hi,

Quoted 69 lines · Tom Rini
Quoted 45 lines · Hans de Goede

Hi,

Quoted 23 lines · Ian Campbell
Quoted 22 lines · 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.

configs/Mele_A1000G_quad_defconfig new file +6 -0
new file mode 100644
index 0000000..b93dcf5
@@ -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.
Quoted 8 lines

configs/Mele_A1000G_quad_defconfig line 10

Quoted 4 lines
configs/Mele_A1000G_quad_defconfig new file +4 -0
+#
+# 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

Quoted 8 lines

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.

Quoted 3 lines

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

#5 lore raw

PATCH 1/1 sunxi: Add new Mele_A1000G_quad defconfig

Quoted 76 lines · Hans de Goede

Hi,

Quoted 69 lines · Tom Rini
Quoted 45 lines · Hans de Goede

Hi,

Quoted 23 lines · Ian Campbell
Quoted 22 lines · 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.

configs/Mele_A1000G_quad_defconfig new file +6 -0
new file mode 100644
index 0000000..b93dcf5
@@ -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.
Quoted 8 lines

configs/Mele_A1000G_quad_defconfig line 10

Quoted 4 lines
configs/Mele_A1000G_quad_defconfig new file +4 -0
+#
+# 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

Quoted 8 lines

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.

Quoted 3 lines

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.

Quoted 7 lines

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!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150602/f5ce64cc/attachment.sig>
#6 lore raw

PATCH 1/1 sunxi: Add new Mele_A1000G_quad defconfig

In reply to Hans de Goede
Quoted 2 lines · Hans de Goede

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.

#7 lore raw

PATCH 1/1 sunxi: Add new Mele_A1000G_quad defconfig

Hi,

Quoted 8 lines · Ian Campbell
Quoted 2 lines · Hans de Goede

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?

Quoted 5 lines

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

#8 lore raw

PATCH 1/1 sunxi: Add new Mele_A1000G_quad defconfig

In reply to Ian Campbell
Quoted 8 lines · Ian Campbell
Quoted 2 lines · Hans de Goede

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?

Quoted 5 lines

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
...

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150603/3b223fd3/attachment.sig>
#9 lore raw

PATCH 1/1 sunxi: Add new Mele_A1000G_quad defconfig

Hi,

Quoted 17 lines · Tom Rini
Quoted 8 lines · Ian Campbell
Quoted 2 lines · Hans de Goede

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?

Quoted 5 lines

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:

Quoted 8 lines

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

#10 lore raw

PATCH 1/1 sunxi: Add new Mele_A1000G_quad defconfig

Quoted 2 lines · Hans de Goede

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

Agreed.