[linux-sunxi] Re: [PATCH] sunxi: Machine id hack to prevent loading buggy sunxi-3.4 kernels
On Tue, 03 Mar 2015 08:17:56 + Ian Campbell ijc+ub...@hellion.org.uk wrote: On Mon, 2015-03-02 at 00:07 +0200, Siarhei Siamashka wrote: Just one suggestion. It would be really nice if the Debian installer could present itself on all the available consoles, so that the user can use any of them for providing input to the installer. There is some reason why d-i doesn't do this by default. I think it's to do with bricking or otherwise interfering with devices attached to serial ports e.g I think Braille terminals were mentioned, but I suppose any random device might not like getting random strings of characters. There could be perhaps a fake kernel cmdline option to specify the exact list of consoles to be used by the Debian installer? Otherwise there will be a need to provide separate SD card images for the HDMI console (for the Raspberry Pi wannable competitors), the UART serial console (A10/A20 development boards without HDMI) and the USB OTG serial gadget console (for the tablets without HDMI). Instead of just having only a single SD card image to handle everything automatically. I've backported DT the /chosen/stdout-path support to the kernel a while ago and I thought together with Hans' u-boot patches to populate this field with the right thing then console selection would Just Work(tm). I need to check this new feature myself, especially whether it can do user input handling. At least for HDMI vs. UART since I'm not quite sure how the OTG gadget console is presented to Linux and whether it falls into this stuff correctly. It should be seen as just one more /dev/tty* entry (maybe USB or ACM). My original plan from http://lists.denx.de/pipermail/u-boot/2015-January/202306.html was to make the bootable SD card just drop into the FEL mode in the case if an A13/A23 SoC is detected or if there is no HDMI monitor connected. Then a custom application running on a desktop PC could upload a custom SPL for the only purpose of identifying the DRAM size and bus width. Then present a choice of the possibly matching devices to the user, boot the system via FEL, run hardware reliability tests and move on to preparing the rootfs. But with the Debian installer, this becomes somewhat more difficult. Because we need a way of handling user input during the installation (for the language selection, time zone, and other things). However with the new USB OTG code from Hans hopefully coming into the Linux kernel, we can have everything much easier and more unified :-) Basically, the serial port over USB should work fine even in Windows (at least it works for the Arduino people): http://arduino.cc/en/Guide/Windows And because the BROM is able to use USB OTG for the FEL mode on all sunxi devices, the serial console over USB should also work in a generic image without any special device dependent configuration. Oh, and one more suggestion. The SD card partitioning could be also improved in order to make it more user friendly. Right now the user may be confused by the Debian installer regarding what to do with the existing partition on the SD card (yes, it can be safely erased since the installer is running from RAM and does not rely on the data from that partition anymore). I leave this one to Karsten who looks after the SD card images. I just mean that the Debian installer could be a little bit more aware of the target platform and guide the user appropriately without leading to any surprises. -- Best regards, Siarhei Siamashka -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Allwinner GPL violations: definitive proof.
Am 04.03.2015, 12:57 Uhr, schrieb Luc Verhaegen l...@skynet.be: On Wed, Feb 25, 2015 at 04:55:15AM +0100, Luc Verhaegen wrote: This was just posted on the allwinner github account: https://github.com/allwinner-zh/media-codec This contains: https://github.com/allwinner-zh/media-codec/blob/master/sunxi-cedarx/LIBRARY/CODEC/VIDEO/DECODER/libvdecoder.so This binary contains symbols from both ffmpeg (LGPL, but altered/hacked up) and libVP62 (anti-compiled from java, and taken off the web in 2006). The LGPL forces Allwinner to produce the full and complete source code of these binaries. How they are going to explain libVP62 to On2 Technologies, now google, is beyond me (cfr. http://en.wikipedia.org/wiki/VP6) With all the previous indiscretions, it was always possible to claim that there was some chance that Allwinner was not the source of the many violations. It was always pretty clear that Allwinner was the source, there were just too many coincidences, the violation was too all encompassing, and not a single device maker spilled the goods. The fact that they threw out a kernel tree with most code and all binaries removed, was, despite being a ludicrous and laughable action, another very clear sign that Allwinner was indeed the source of these violations. Now however, the fact that allwinner posted this very clearly shows that Allwinner is the source. It is absolutely unequivocal this time round. To top this off, it is 6 months after the last GPL violation shitstorm. This puts serious doubts behind the claims that Allwinner truly is learning and willing to cooperate. Allwinner, it is very high time to start playing nice. You've been at it for 4 years now and seem utterly incapable of or unwilling to change. Luc Verhaegen. So now there is a LICENSE file stating that the code in https://github.com/allwinner-zh/media-codec is LGPL? So Allwinner believes that by sticking the LGPL on a _binary_ solves all the problems? Just like it seems to believe that removing all binaries from a kernel tree solves all problems with the GPL? Really? This is simply ridiculous. Luc Verhaegen. Luc, of course it is your personal decision to organize a shitstorm when you believe that it results in compliance, but I have many doubts about that. However, I would hope that you organize it without referring to the sunxi project and list, because imho the project would be more harmed than helped! I.Irgendeiner -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Allwinner GPL violations: definitive proof.
On March 4, 2015, at 8:12 AM, Luc Verhaegen l...@skynet.be wrote: On Wed, Mar 04, 2015 at 04:55:57PM +0100, Irgendeiner wrote: Am 04.03.2015, 12:57 Uhr, schrieb Luc Verhaegen l...@skynet.be: So now there is a LICENSE file stating that the code in https://github.com/allwinner-zh/media-codec is LGPL? So Allwinner believes that by sticking the LGPL on a _binary_ solves all the problems? Just like it seems to believe that removing all binaries from a kernel tree solves all problems with the GPL? Really? This is simply ridiculous. Luc Verhaegen. Luc, of course it is your personal decision to organize a shitstorm when you believe that it results in compliance, but I have many doubts about that. However, I would hope that you organize it without referring to the sunxi project and list, because imho the project would be more harmed than helped! This is not a new issue, far from it. This has been going on for years and what you see now is the culmination of years of asking nicely and either being ignored or getting fed bullshit excuses. Where are all these people coming from to defend it? At least one is obviously a shill but man... Anyway, if they ignored us when asking nicely, how much worse can it get? It's kind of an all or nothing thing. You can't go to market with partial compliance. I got burned by this at Pengpod. My touch screen controller went off the market and none of the replacements had source, just binary kernels packed in Android images. It forced me to bet everything on a new oem that seemed to be as compliant as possible. Further, imagine you work for a giant tech company with the potential to buy millions of units year. Could you recommend Allwinner to your bosses? Not with the current state of compliance, legally it's impossible to do business at any real scale this way. Companies figure this out before they even contact AW, it's part of their due diligence. I think this is hurting them more than they know. Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Allwinner GPL violations: definitive proof.
On Wed, Mar 04, 2015 at 04:55:57PM +0100, Irgendeiner wrote: Am 04.03.2015, 12:57 Uhr, schrieb Luc Verhaegen l...@skynet.be: So now there is a LICENSE file stating that the code in https://github.com/allwinner-zh/media-codec is LGPL? So Allwinner believes that by sticking the LGPL on a _binary_ solves all the problems? Just like it seems to believe that removing all binaries from a kernel tree solves all problems with the GPL? Really? This is simply ridiculous. Luc Verhaegen. Luc, of course it is your personal decision to organize a shitstorm when you believe that it results in compliance, but I have many doubts about that. However, I would hope that you organize it without referring to the sunxi project and list, because imho the project would be more harmed than helped! This is not a new issue, far from it. This has been going on for years and what you see now is the culmination of years of asking nicely and either being ignored or getting fed bullshit excuses. Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 2/4] i2c: sunxi: Add Reduced Serial Bus (RSB) DT bindings documentation
On Mon, Mar 02, 2015 at 04:24:44PM +0800, Chen-Yu Tsai wrote: Reduced Serial Bus (RSB) is an SMBus like bus used to communicate with some PMICs (like the AXP223) or other peripherals. The RSB DT bindings are pretty much the same as the one defined for the marvell's mv64xxx controller, with the additional RSB specific allwinner,rsb-hw-addr property for slave device nodes. There are 2 types of addresses for RSB devices, a hardware address and a runtime (software) configurable address. The former is only used when configuring the latter. All read/write accesses use the runtime address. It would seem straightforward to use the hardware address in the DT bindings as the slave's address. However this will not work as the hardware address is 12 bits wide, and at least 1 device, the AC100 audio codec, has the highest bit set. This address would be incompatible with I2C (7 or 10 bit addresses) and likely rejected. Hence this binding uses statically allocated (by the author of the DT) runtime addresses for the slave's reg property. The hardware address is put in a separete named property. When writing a new DT, ^ separate the author must take care to not have multiple slave devices use the same address. It is recommended to follow whatever conventions the hardware vendor uses. While very complete, the three last paragraphs should rather be, or at least duplicated, in the file itself. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] Regarding the sunxi-cedarx support
From many years of experience I got convinced that an aggressive style by itself always results in a less productive situation, eventually even in a deadlock. Someone either has the power and money to convince the other party that it will lose a legal battle in _very near_ future. If you lack power and money you better seek cooperation. If anybody can convince FSF or softwarefreedom.org to contact Allwinner, then there is a chance that they will comply. Trying to organize a boycott of Allwinner products shows lack of understanding how these markets operate. I.Irgendeiner -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Allwinner GPL violations: definitive proof.
Hi, On Wed, 4 Mar 2015 09:46:07 -0300 Rodrigo Pereira rodrigo2kpere...@gmail.com wrote: This is because reverse engeneering is a PITA, I suppose. http://linux-sunxi.org/CedarX/Reverse_Engineering I disagree. Reverse engineering is an enjoyable and fun thing to do. And as can be see in the above url, it only took a space of a few weeks to get successful results, with the majority of the work done by only one person. What is PITA, is to be ignored. After all this work done, we(the people that work by reverse engineering this video engine, so that would be possible to write a proper driver that can be mainlined). What we get? Just indifference that the reverse engineering effort even exists. Look at this maillist, people here begging allwinner for a binary with a correct license (because without a license without issues, nobody that wants to stay lawful can even use the binary). And for what?, this binary will not magical resolve all the things, this binary is a stopper for a proper driver, this binary can't be part of mainline kernel. Don't forget what happened around two years ago, when the developers of an unnamed favorite media player tried to add hardware acceleration. What we get? Endless users asking why it doesn't work, but incapable in recognizing the work that must be done before. In the end, the users expect all from us, but is not enough. You know, if we(the reverse engineering people) had a bit more support, we would be motivated to work a bit harder, so that maybe today we all would be much happier. And this page would have progressed much more. http://linux-sunxi.org/VE_Planning -- Manuel Braga -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 1/4] i2c: sunxi: Add Reduced Serial Bus (RSB) support
On Mon, Mar 02, 2015 at 04:24:43PM +0800, Chen-Yu Tsai wrote: The RSB controller looks like an SMBus controller which only supports byte and word data transfers. It can also do double-word data transfers, but the I2C subsystem does not support this, nor have we seen devices using this. The RSB differs from standard SMBus protocol on several aspects: - it uses addresses set at runtime to address slaves. Runtime addresses are sent to slaves using their 12bit hardware addresses. Up to 15 runtime addresses are available. - it adds a parity bit every 8bits of data and address for read and write accesses; this replaces the ack bit - only one read access is required to read a byte (instead of a write followed by a read access in standard SMBus protocol) - there's no Ack bit after each read access This means this bus cannot be used to interface with standard SMBus devices (known devices supporting this interface are the AXP223, AXP806, AXP809 PMICs and the AC100 codec/RTC). However the RSB protocol is an extension of P2WI, which was close enough to SMBus to be integrated into the I2C subsystem in commit 3e833490fae5 (i2c: sunxi: add P2WI (Push/Pull 2 Wire Interface) controller support). Signed-off-by: Chen-Yu Tsai w...@csie.org I don't have the bandwidth for a full review right now. However, I already wanted to tell you guys that my gut feeling is that this protocol is quite far away from I2C. P2WI was already at the edge. Maybe there is a better place for such custom stuff? I dunno yet. Thanks, Wolfram --- drivers/i2c/busses/Kconfig | 12 + drivers/i2c/busses/Makefile| 1 + drivers/i2c/busses/i2c-sunxi-rsb.c | 458 + 3 files changed, 471 insertions(+) create mode 100644 drivers/i2c/busses/i2c-sunxi-rsb.c diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index 22da9c2ffa22..cf9337877181 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -840,6 +840,18 @@ config I2C_SUN6I_P2WI This interface is used to connect to specific PMIC devices (like the AXP221). +config I2C_SUNXI_RSB + tristate Allwinner Reduced Serial Bus controller + depends on RESET_CONTROLLER + depends on MACH_SUN8I || MACH_SUN9I || COMPILE_TEST + help + If you say yes to this option, support will be included for the + Reduced Serial Bus controller embedded in some sunxi SOCs. + The RSB looks like an SMBus controller (which supports only byte + accesses), but requires setting runtime addresses for slave devices. + This interface is used to connect to specific PMIC devices (like the + AXP223) or peripherals (like the AC100). + config I2C_TEGRA tristate NVIDIA Tegra internal I2C controller depends on ARCH_TEGRA diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile index 3638feb6677e..f95d50315003 100644 --- a/drivers/i2c/busses/Makefile +++ b/drivers/i2c/busses/Makefile @@ -81,6 +81,7 @@ obj-$(CONFIG_I2C_SIRF) += i2c-sirf.o obj-$(CONFIG_I2C_ST) += i2c-st.o obj-$(CONFIG_I2C_STU300) += i2c-stu300.o obj-$(CONFIG_I2C_SUN6I_P2WI) += i2c-sun6i-p2wi.o +obj-$(CONFIG_I2C_SUNXI_RSB) += i2c-sunxi-rsb.o obj-$(CONFIG_I2C_TEGRA) += i2c-tegra.o obj-$(CONFIG_I2C_VERSATILE) += i2c-versatile.o obj-$(CONFIG_I2C_WMT)+= i2c-wmt.o diff --git a/drivers/i2c/busses/i2c-sunxi-rsb.c b/drivers/i2c/busses/i2c-sunxi-rsb.c new file mode 100644 index ..7e9be3e14b8a --- /dev/null +++ b/drivers/i2c/busses/i2c-sunxi-rsb.c @@ -0,0 +1,458 @@ +/* + * RSB (Reduced Serial Bus) driver. + * + * Author: Chen-Yu Tsai w...@csie.org + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed as is without any warranty of any + * kind, whether express or implied. + * + * The RSB controller looks like an SMBus controller which only supports + * byte and word data transfers. But, it differs from standard SMBus + * protocol on several aspects: + * - it uses addresses set at runtime to address slaves. Runtime addresses + * are sent to slaves using their 12bit hardware addresses. Up to 15 + * runtime addresses are available. + * - it adds a parity bit every 8bits of data and address for read and + * write accesses; this replaces the ack bit + * - only one read access is required to read a byte (instead of a write + * followed by a read access in standard SMBus protocol) + * - there's no Ack bit after each read access + * + * This means this bus cannot be used to interface with standard SMBus + * devices. Devices known to support this interface include the AXP223, + * AXP809, and AXP806 PMICs, and the AC100 audio codec, all from X-Powers. + * + * A description of the operation and wire protocol can be found in the + * RSB section of Allwinner's A80
Re: [linux-sunxi] Re: [U-Boot] [PATCH] sunxi: Machine id hack to prevent loading buggy sunxi-3.4 kernels
On 4 March 2015 at 21:15, Karsten Merker mer...@debian.org wrote: [removed u-b...@lists.denx.de from the CC list as my reply would be off-topic there] On Wed, Mar 04, 2015 at 05:17:23PM +0200, Siarhei Siamashka wrote: On Tue, 03 Mar 2015 08:17:56 + Ian Campbell ijc+ub...@hellion.org.uk wrote: Oh, and one more suggestion. The SD card partitioning could be also improved in order to make it more user friendly. Right now the user may be confused by the Debian installer regarding what to do with the existing partition on the SD card (yes, it can be safely erased since the installer is running from RAM and does not rely on the data from that partition anymore). I leave this one to Karsten who looks after the SD card images. I just mean that the Debian installer could be a little bit more aware of the target platform and guide the user appropriately without leading to any surprises. Hello, that is rather difficult - the modules within d-i such as the partitioner try to be platform-agnostic as much as possible and making their behaviour platform-dependent is something that is generally frowned upon. I will try to cover this issue in the Debian installation guide, but there are some other points that I need to take care of first, so that will probably need some time. Installing to the same medium the installer is running from is not platform specific but is typically not advised on platforms that have multiple usable media. Still getting this to work properly may be useful outside sunxi. Thanks Michal -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH] sunxi: Machine id hack to prevent loading buggy sunxi-3.4 kernels
On 4 March 2015 at 16:17, Siarhei Siamashka siarhei.siamas...@gmail.com wrote: On Tue, 03 Mar 2015 08:17:56 + Ian Campbell ijc+ub...@hellion.org.uk wrote: On Mon, 2015-03-02 at 00:07 +0200, Siarhei Siamashka wrote: Just one suggestion. It would be really nice if the Debian installer could present itself on all the available consoles, so that the user can use any of them for providing input to the installer. There is some reason why d-i doesn't do this by default. I think it's to do with bricking or otherwise interfering with devices attached to serial ports e.g I think Braille terminals were mentioned, but I suppose any random device might not like getting random strings of characters. There could be perhaps a fake kernel cmdline option to specify the exact list of consoles to be used by the Debian installer? Otherwise there will be a need to provide separate SD card images for the HDMI console (for the Raspberry Pi wannable competitors), the UART serial console (A10/A20 development boards without HDMI) and the USB OTG serial gadget console (for the tablets without HDMI). Instead of just having only a single SD card image to handle everything automatically. I've backported DT the /chosen/stdout-path support to the kernel a while ago and I thought together with Hans' u-boot patches to populate this field with the right thing then console selection would Just Work(tm). I need to check this new feature myself, especially whether it can do user input handling. At least for HDMI vs. UART since I'm not quite sure how the OTG gadget console is presented to Linux and whether it falls into this stuff correctly. It should be seen as just one more /dev/tty* entry (maybe USB or ACM). My original plan from http://lists.denx.de/pipermail/u-boot/2015-January/202306.html was to make the bootable SD card just drop into the FEL mode in the case if an A13/A23 SoC is detected or if there is no HDMI monitor connected. Then a custom application running on a desktop PC could upload a custom SPL for the only purpose of identifying the DRAM size and bus width. Then present a choice of the possibly matching devices to the user, boot the system via FEL, run hardware reliability tests and move on to preparing the rootfs. But with the Debian installer, this becomes somewhat more difficult. Because we need a way of handling user input during the installation (for the language selection, time zone, and other things). For things selectable from a menu it might be possible to use the volume and power keys as the Android recovery does. Driver for the power key is already in u-boot. It's just not hooked up to provide input. However with the new USB OTG code from Hans hopefully coming into the Linux kernel, we can have everything much easier and more unified :-) Basically, the serial port over USB should work fine even in Windows (at least it works for the Arduino people): http://arduino.cc/en/Guide/Windows And because the BROM is able to use USB OTG for the FEL mode on all sunxi devices, the serial console over USB should also work in a generic image without any special device dependent configuration. I pretty much use only the OTG port when I boot GNU/Linux on a tablet. yes, I can get display output but any input has to come over OTG so I use ethernet gadget and ssh. That also happens to cover downloading stuff in case the WiFi chipset is not supported. I have yet to see an Allwinner tablet with supported touchscreen. Thanks Michal -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 2/2] dt-bindings: Add vendor-prefix for Wexler
This patch adds vendor-prefix for Wexler. WEXLER trademark owned by AVIRSA Electronics, a member of the diversified holding AVIRSA. Signed-off-by: Aleksei Mamlin mamli...@gmail.com --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 389ca13..eb67da4 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -189,6 +189,7 @@ variscite Variscite Ltd. viaVIA Technologies, Inc. virtio Virtual I/O Device Specification, developed by the OASIS consortium voipac Voipac Technologies s.r.o. +wexler AVIRSA Electronics winbond Winbond Electronics corp. wlfWolfson Microelectronics wm Wondermedia Technologies, Inc. -- 2.0.5 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] ARM: dts: sun7i: Add dts file for Wexler TAB7200
On Wed, 4 Mar 2015 21:18:19 +0100 Maxime Ripard maxime.rip...@free-electrons.com wrote: On Wed, Mar 04, 2015 at 11:15:47AM +0300, Aleksei Mamlin wrote: This patch add support for Wexler TAB7200 tablet. The Wexler TAB7200 is a A20 based tablet with 7 inch display(800x480), capacitive touchscreen(5 fingers), 1G RAM, 4G NAND, micro SD card slot, mini HDMI port, 3.5mm audio plug, 1 USB OTG port and 1 USB 2.0 port. Signed-off-by: Aleksei Mamlin mamli...@gmail.com --- .../devicetree/bindings/vendor-prefixes.txt| 1 + arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts | 185 + 3 files changed, 188 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 389ca13..eb67da4 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -189,6 +189,7 @@ variscite Variscite Ltd. viaVIA Technologies, Inc. virtio Virtual I/O Device Specification, developed by the OASIS consortium voipac Voipac Technologies s.r.o. +wexler AVIRSA Electronics Why a different name? WEXLER trademark owned by AVIRSA Electronics, a member of the diversified holding AVIRSA. Also, please make that a separate patch. Ok, I'll do winbond Winbond Electronics corp. wlfWolfson Microelectronics wm Wondermedia Technologies, Inc. diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index beac15f..f6dc2ac 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -550,7 +550,8 @@ dtb-$(CONFIG_MACH_SUN7I) += \ sun7i-a20-olinuxino-lime2.dtb \ sun7i-a20-olinuxino-micro.dtb \ sun7i-a20-pcduino3.dtb \ - sun7i-a20-pcduino3-nano.dtb + sun7i-a20-pcduino3-nano.dtb \ + sun7i-a20-wexler-tab7200.dtb dtb-$(CONFIG_MACH_SUN8I) += \ sun8i-a23-ippo-q8h-v5.dtb \ sun8i-a23-ippo-q8h-v1.2.dtb diff --git a/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts b/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts new file mode 100644 index 000..d50f40b --- /dev/null +++ b/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts @@ -0,0 +1,185 @@ +/* + * Copyright 2015 Aleksei Mamlin + * Aleksei Mamlin mamli...@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 sun7i-a20.dtsi +#include sunxi-common-regulators.dtsi + +#include dt-bindings/gpio/gpio.h +#include dt-bindings/input/input.h +#include
[linux-sunxi] Re: [PATCH] ARM: dts: sun7i: Add dts file for Wexler TAB7200
On Wed, Mar 04, 2015 at 11:15:47AM +0300, Aleksei Mamlin wrote:
This patch add support for Wexler TAB7200 tablet.
The Wexler TAB7200 is a A20 based tablet with 7 inch display(800x480),
capacitive touchscreen(5 fingers), 1G RAM, 4G NAND, micro SD card slot,
mini HDMI port, 3.5mm audio plug, 1 USB OTG port and 1 USB 2.0 port.
Signed-off-by: Aleksei Mamlin mamli...@gmail.com
---
.../devicetree/bindings/vendor-prefixes.txt| 1 +
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts | 185
+
3 files changed, 188 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 389ca13..eb67da4 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -189,6 +189,7 @@ variscite Variscite Ltd.
via VIA Technologies, Inc.
virtio Virtual I/O Device Specification, developed by the OASIS
consortium
voipac Voipac Technologies s.r.o.
+wexler AVIRSA Electronics
Why a different name?
Also, please make that a separate patch.
winbond Winbond Electronics corp.
wlf Wolfson Microelectronics
wm Wondermedia Technologies, Inc.
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index beac15f..f6dc2ac 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -550,7 +550,8 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-olinuxino-lime2.dtb \
sun7i-a20-olinuxino-micro.dtb \
sun7i-a20-pcduino3.dtb \
- sun7i-a20-pcduino3-nano.dtb
+ sun7i-a20-pcduino3-nano.dtb \
+ sun7i-a20-wexler-tab7200.dtb
dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a23-ippo-q8h-v5.dtb \
sun8i-a23-ippo-q8h-v1.2.dtb
diff --git a/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
b/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
new file mode 100644
index 000..d50f40b
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
@@ -0,0 +1,185 @@
+/*
+ * Copyright 2015 Aleksei Mamlin
+ * Aleksei Mamlin mamli...@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 sun7i-a20.dtsi
+#include sunxi-common-regulators.dtsi
+
+#include dt-bindings/gpio/gpio.h
+#include dt-bindings/input/input.h
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/pinctrl/sun4i-a10.h
+
+/ {
+ model = Wexler TAB7200;
+ compatible = wexler,tab7200, allwinner,sun7i-a20;
+};
+
+cpu0 {
+ cpu-supply = reg_dcdc2;
+};
+
+ehci0 {
+ status = okay;
+};
+
+ehci1 {
+ status = okay;
+};
+
[linux-sunxi] Re: [PATCH] ARM: sun7i: dt: Add new MK808C device
On Tue, Mar 03, 2015 at 09:22:32PM +0100, Code Kipper wrote:
+
+/ {
+ model = mk808c;
+ compatible = mk808c, allwinner,sun7i-a20;
the compatible must be of the format vendor,device. Please add the
vendor name.
AhhhI've searched high and low for a vendors name. I listed it as
unknown on the wiki page,
would 'odm' be considered valid?
Not really. Another mk808c device might very well be made by some
other odm.
Don't your device has any brand on the case or the PCB?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
[linux-sunxi] Re: [PATCH] ARM: dts: sun7i: Add dts file for Wexler TAB7200
On Wed, Mar 04, 2015 at 11:26:15PM +0300, Aleksei Mamlin wrote: On Wed, 4 Mar 2015 21:18:19 +0100 Maxime Ripard maxime.rip...@free-electrons.com wrote: On Wed, Mar 04, 2015 at 11:15:47AM +0300, Aleksei Mamlin wrote: This patch add support for Wexler TAB7200 tablet. The Wexler TAB7200 is a A20 based tablet with 7 inch display(800x480), capacitive touchscreen(5 fingers), 1G RAM, 4G NAND, micro SD card slot, mini HDMI port, 3.5mm audio plug, 1 USB OTG port and 1 USB 2.0 port. Signed-off-by: Aleksei Mamlin mamli...@gmail.com --- .../devicetree/bindings/vendor-prefixes.txt| 1 + arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts | 185 + 3 files changed, 188 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 389ca13..eb67da4 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -189,6 +189,7 @@ variscite Variscite Ltd. via VIA Technologies, Inc. virtio Virtual I/O Device Specification, developed by the OASIS consortium voipac Voipac Technologies s.r.o. +wexler AVIRSA Electronics Why a different name? WEXLER trademark owned by AVIRSA Electronics, a member of the diversified holding AVIRSA. It's not really an issue. There's a lot of different vendor owned by the same companies in that file. And the fact that you named it wexler in the first place proves that wexler is more known than avirsa. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] Allwinner GPL violations: definitive proof.
On Thu, Mar 5, 2015 at 9:10 AM, prfl...@gmail.com wrote: My two cents: Stop asking for fixing and start doing the legal stuff (sue for example) They have 4 years to fix, they do nothing. they release non functional patches, and they not release the code correctly. They reply to simpleness and notes in a attempt to avoid or deviate the issue. You have 2 options: 1) start doing legal actions The issue is that a copyright holder must start this action, i.e. someone who's code is affected by their actions. From what I've read, most of the GPL enforcement lawsuits have been of the no source variety and involved busybox as the authors of that software are small in number and are interested in pursuing GPL enforcement. (This is why there's now a competitor called toolbox: companies were sick of being sued over busybox.) I do not believe that anyone has successfully pursued GPL enforcement over Linux itself, however I'd love to be corrected. The fact that the kernel tree is essentially the full source with a couple of blobs will also complicate things: Allwinner is likely to comply by releasing code without the blobs and associated functionality as that's easier. Luc's definitive proof in the original post is a good starting point, however it requires that ffmpeg and On2 / Google sue and is only one file of many. (I've also seen instances like this resolved by the company releasing new blobs that don't have the proof people saw, i.e. all symbols renamed, code minimally obfuscated, etc.) Legal action is likely to end up being an uphill battle regardless of which avenue is pursued. Personally I'm exceptionally disappointed that Linaro has let them anywhere near their table with these GPL violations unresolved. (However Linaro's track record isn't the best.) 2) keep play nice an 'spect they overabusse that to keep another 4 years unpunnished (no pun intended) violating (l)gpl and releasing non functinal code like now. Apart from raising awareness and talking to Allwinner, we don't have a lot of realistic options. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Allwinner GPL violations: definitive proof.
On Wed, Mar 4, 2015 at 3:10 PM, Luc Verhaegen l...@skynet.be wrote: On Wed, Mar 04, 2015 at 02:31:41PM +0200, Simos Xenitellis wrote: On Wed, Mar 4, 2015 at 1:57 PM, Luc Verhaegen l...@skynet.be wrote: On Wed, Feb 25, 2015 at 04:55:15AM +0100, Luc Verhaegen wrote: ... So now there is a LICENSE file stating that the code in https://github.com/allwinner-zh/media-codec is LGPL? So Allwinner believes that by sticking the LGPL on a _binary_ solves all the problems? Just like it seems to believe that removing all binaries from a kernel tree solves all problems with the GPL? Really? This is simply ridiculous. This guy is so toxic. Apparently it's an attitude style to be permanently negative. You give him caviar and he complains that it's black. Or a VIN ROMANEE CONTI 1955 and he complains that it's too old. I do not know whether there will be more commits to that repo. Just in case there are, a typical person would refrain from making such comments. Simos Simos, I am corrosive and bitter, but perhaps i am not the toxic one here. Luc, Hi. You are not a bad person. We first met at XDS2008, so I have somewhat first-hand experience. We even had lunch/dinner at the pub and you behaved as a normal human being to the waiter; I do not think there was trimmed pubic hair in the haggis we all ate. You really try to make good things and help the projects that you are active in. However, in this thing called community building, it's not your cup of tea. You try to insult new contributors into doing NewDevice pages on the Wiki but you end up sending them away. The worst part is that others in the list can see the mess and will not touch the wiki either. Also, edit-war with new contributors? The solution here is to get others to help out and you do *not* get involved. You might want to watch https://www.youtube.com/watch?v=Q52kFL8zVoM which discusses the subtleties of community building. All we ever see you do is trash me. You have written no code, you have not contributed to the wiki, you only now spend some time on irc to try to clean up your image. That's an attempt to divert the discussion to me in person. I am not the story. Unlike what you claim above, I actually contributed. If you really want to go through this avenue: if I prove you wrong, you back off entirely from all this. You started calling for banishing me, while trying to instigate a fork, almost as soon as you got here. And you try to post about every little positive thing that allwinner does (while allwinner ignores its hard legal responsibilities), to try to take credit for them and to try artificially gain any form of standing here. Personally I cannot think of a way to gain something here. Gain reputation among you all? I respect all of you, but no. In your case, you have things to lose from this community. You have invested in this project. You have invested so much that you would be even a suitable recruit for Allwinner. Even having access to internal documents and source in order to produce a proper libvdpau. But sadly, you come off as a loose cannon. It's scary. It does not appear that you have a flexible strategy. In fact it's so inflexible that your only way to win is if Allwinner says: fuck my life, get this ssh account and take everything. Perhaps you and Allwinner do not realize this. But linux-sunxi does not need Allwinner, Allwinner needs linux-sunxi. What linux-sunxi requires from Allwinner is a legal matter, and a pretty open and shut case at that. Allwinner trying to make their mole a part of this community this crudely or artificially, while so badly messing up the basics, that is not only counterproductive, it is quite preposterous. I would love to see all source free and open-source. And most importantly, all the companies behind it, to actually believe in the benefits. Due to v2 in GPL, your stick is not long enough. They can adhere to the license but still be stuck. In addition, an actual strategy to get them all into free and open-source is if you make all sort of efforts/compromises to have one SoC completely and fully free/open-source. Then, promote that SoC as loud as possible, so the others would have to follow on their own volition. This is especially true for the GPU in ARM SoCs. I noticed in your recent blog post that you are starting linux-exynos.org. Simos -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Regarding the sunxi-cedarx support
On Wed, Mar 4, 2015 at 7:14 PM, Irgendeiner irgendei...@gmx.ch wrote: From many years of experience I got convinced that an aggressive style by itself always results in a less productive situation, eventually even in a deadlock. Someone either has the power and money to convince the other party that it will lose a legal battle in _very near_ future. If you lack power and money you better seek cooperation. If anybody can convince FSF or softwarefreedom.org to contact Allwinner, then there is a chance that they will comply. Trying to organize a boycott of Allwinner products shows lack of understanding how these markets operate. I think you capture my thoughts quite well. In terms of strategy, it does not make any sense to have aggression among members of your very own side. It is weird to follow a strategy of attack against your own side because you want to follow a specific direction that aims to benefit anyway that side that you are attacking. It is so sad that if the companies ignore you altogether, then developers do not attack them. You make an effort to get a company to talk, and a s***storm ensues. Simos -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Allwinner GPL violations: definitive proof.
I think we need to bring this back to simple. 1) as FOSS not out to harm allwinnertech all FOSS want is conformance with license. Reality here the two worst laws to break as a hardware vendor is copyright and trademark. Serous-ally. Both you can enforce by customs both can cause product destruction. This is pure nightmare because what would happen if a developer of the work decided to take the customs path a stack of product for one of allwinner customers would get to the board be ruled as contain copyright infringing work then crushed. This has happened to gameconsoles and other items in the past. The buyer is left out of pocket. Its basically a common mistake since FOSS does not act often that it does not have teeth. The reality most FOSS developers know they have the teeth to put a company out of business so try negotiation. https://libav.org/shame.html you will notice all the ones here are fairly much software companies. Developers don't have very effective teeth to go after software companies. Also remember even if the infringement is preformed by a sub-company the fact its on your device can make that device destroyable and you will be expected to get the compensation out the sub company that provided you with the infringing software. The reality is you are better to break patent law than trademark or copyright as hardware company. Something Allwinner take on board is release the source after the fact is an extremely bad idea. If you go to Intel and Amd you will notice they release the open source code before the chip ship. This means the chips cannot be destroyed at customs. You are only able to catch up with the source release after the fact because at this stage the FOSS developers are being kind. Siarhei Siamashka the case of the firmware not using the Linux kernel firmware loader what promises that we will not have that happen again. Is there staff training to make sure this does not happen again. Siarhei Siamashka there are compliance tools. http://www.linuxfoundation.org/programs/legal/compliance/tools Are you using them. If not please start using them. If you are using them please open bug reports for the cases that these issues got missed. http://www.binaryanalysis.org/en/home This tool is built particularly to allow FOSS developers to locate infringement in closed source binaries. Basically FOSS developers have tools to find infringement and they have made the tools for your side to detect infringement before it gets out the door. Please allwinner stop messing with them because when they do decide to hit it is going to hurt. I like your chips don't want to have the case that I have ordered something only to find its been crushed because you were infringing. Basically due to the tools it would have taken Luc Verhaegen bugger all effort to find the issue. Since it takes bugger all effort why did not the allwinner staff locate it. Maybe they are not tooled up correctly and maybe this is the cause of all the on going issues. If you can prove a fault with the FOSS compliance tool that it failed to detect it at least you have workable excuse and evidence that you attempted to be conforming but this still does not help you if developer has chosen to go the customs path to copyright enforcement. The best option is do not infringe and if you do don't just play it down have some decent explanation in a form of an operational failure of something or someone at least then the FOSS developers finding the problems walk way kind of ok and are unlikely to take it further. Peter Dolding -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] BananPro WiFi Module (ap6181) Problems
Hi, On 03-03-15 20:12, Arend van Spriel wrote: On 03/03/15 14:33, Hans de Goede wrote: Hi, On 03-03-15 14:01, peter.c...@lemaker.com wrote: Hello everyone I try to compile with the newest kernel from the website at https://github.com/linux-sunxi/linux-sunxi/tree/sunxi-next . and the kernel can work normally on the BananaPro board. Meanwhile, I use the brcmfmac to driver the ap6181(wifi module as same as ap6210) in the linux-3.19, and the WiFi can work normally, but there is something wrong when i use the scp to copy. The error message as follows: [ 108.934478] sunxi-mmc 1c12000.mmc: smc 1 err, cmd 53, RD SBE !! [ 108.940736] sunxi-mmc 1c12000.mmc: data error, sending stop command [ 108.947833] brcmfmac: brcmf_sdio_readframes: RXHEADER FAILED: -110 [ 108.954330] brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame, send NAK [ 108.966952] brcmfmac: brcmf_sdiod_regrw_helper: failed to write data F1@0x0a040, err: -5 [ 108.975499] brcmfmac: brcmf_sdio_hdparse: seq 79: sequence number error, expect 80 [ 109.336188] sunxi-mmc 1c12000.mmc: smc 1 err, cmd 53, RD DTO !! [ 109.342442] sunxi-mmc 1c12000.mmc: data error, sending stop command [ 109.703557] sunxi-mmc 1c12000.mmc: smc 1 err, cmd 53, RD DTO !! [ 109.709843] sunxi-mmc 1c12000.mmc: data error, sending stop command [ 110.070986] sunxi-mmc 1c12000.mmc: smc 1 err, cmd 53, RD DTO !! [ 110.077273] sunxi-mmc 1c12000.mmc: data error, sending stop command [ 110.083928] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data F1@0x0a020, err: -110 It seems like there is a problem with the brcmfmac or sdio driver in the linux-3.19. Looking forward to you reply. Yes this is a known problem with broadcom sdio wifi on sunxi devices and upstream kernels. Arend van Spriel from broadcom is looking into this. Arend, any luck in reproducing this on your cubietruck? Whether it be coincidence or devils' play, but today I got the cubietruck up and running with fc21 3.18.7 kernel. I tried installing a kernel from our internal tree (3.19-rc?) but did not get it working. So I got back to 3.18.7 fc21 kernel and build our latest brcmfmac against it using a backports package. I started a ping when I left the office and had another look at home seeing the same RD DTO messages. So yes I have reproduced it, but did not capture a log. Good (that you've reproduced it) note that it is much easier to reproduce by scp-ing a bunch of large(ish) files, then it usually triggers within a minute. And any luck in finding a fix for it ? We recently did have an issue where the device indicates busy using data lines and host ignored that and started next cmd53 causing the device to end in a bad state. Not sure if sunxi-mmc has similar issue. Will need to investigate that further. This might very well be a sunxi-mmc bug, but on my cubioetruck if I first boot into the linux which is on the onboard flash, and then insert a sdcard with upstream kernel and reboot so that it boots from the sdcard the problem is gone. And I've done a regdump comparing all settings on the mmc controller side, I might have missed something but atm my first hunch is that the kernel in the nand sets some bits in the wifi module which stick over reboot and fix this. Could actually still be the same thing you're talking about but that the wifi moudle behavior is somehow changed to avoid that. Also note that the very first error is not a cmd 53 error, there first is a single different command which fails (forgot which one sorry) and then from there on a lot of cmd53 errors. The first failing command also does not fail with a response time out, but with a start bit error. Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Reviewing the book Getting Started with Cubieboard (Packt Publishing Ltd)
Hi All, As you may know, there is an introductory book about the A-Series of Allwinner SoCs (specifically A10, A13 and A20), called Getting Started with Cubieboard, written by Olliver Schinagl and published by Packt Publishing Ltd. Read more at https://www.packtpub.com/hardware-and-creative/getting-started-cubieboard Packt is doing some publicity for this book. What they are doing is that they give the e-book version of the book in exchange for an online review. The idea is that by having several online reviews for the book, it helps prospective buyers to decide whether to buy or not. Obviously, you are free to write whatever you want in the review. I offered them my help in finding such reviewers, and they are looking for 3 persons. Here are the details: 1. Have a look at https://www.packtpub.com/hardware-and-creative/getting-started-cubieboard to decide if you are interested to go through this. 2. Write a review on Amazon, Google Books and goodreads. For Amazon, you need to have an account and have bought something in order to be able to post reviews. 3. Write a review on your personal blog or similar social media. If you are interested in taking part, please send me a private email. Please also add a sentence describing why it would be helpful to you to get a copy (to be used in case there are more than 3 replies). I'll collect replies until this Friday. If there are any general questions, reply here. I have no affiliation with Packt Publishing Ltd. Simos -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Allwinner GPL violations: definitive proof.
On Wed, Feb 25, 2015 at 04:55:15AM +0100, Luc Verhaegen wrote: This was just posted on the allwinner github account: https://github.com/allwinner-zh/media-codec This contains: https://github.com/allwinner-zh/media-codec/blob/master/sunxi-cedarx/LIBRARY/CODEC/VIDEO/DECODER/libvdecoder.so This binary contains symbols from both ffmpeg (LGPL, but altered/hacked up) and libVP62 (anti-compiled from java, and taken off the web in 2006). The LGPL forces Allwinner to produce the full and complete source code of these binaries. How they are going to explain libVP62 to On2 Technologies, now google, is beyond me (cfr. http://en.wikipedia.org/wiki/VP6) With all the previous indiscretions, it was always possible to claim that there was some chance that Allwinner was not the source of the many violations. It was always pretty clear that Allwinner was the source, there were just too many coincidences, the violation was too all encompassing, and not a single device maker spilled the goods. The fact that they threw out a kernel tree with most code and all binaries removed, was, despite being a ludicrous and laughable action, another very clear sign that Allwinner was indeed the source of these violations. Now however, the fact that allwinner posted this very clearly shows that Allwinner is the source. It is absolutely unequivocal this time round. To top this off, it is 6 months after the last GPL violation shitstorm. This puts serious doubts behind the claims that Allwinner truly is learning and willing to cooperate. Allwinner, it is very high time to start playing nice. You've been at it for 4 years now and seem utterly incapable of or unwilling to change. Luc Verhaegen. So now there is a LICENSE file stating that the code in https://github.com/allwinner-zh/media-codec is LGPL? So Allwinner believes that by sticking the LGPL on a _binary_ solves all the problems? Just like it seems to believe that removing all binaries from a kernel tree solves all problems with the GPL? Really? This is simply ridiculous. Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Allwinner GPL violations: definitive proof.
2015-03-04 11:19 GMT-03:00 ovidi...@gmail.com: @Roberto asuming allwinner has did copy the hardware (speaking about A80 sun9i) and the reason of violating GPL's and not publishing sources is might be possible to get sued by original silicon vendor ... but the question is which silicon vendor uses big.Little + powerVR gpu? Reading around there is no such silicon vendor who will have big.Little architecture with PowerVR gpu inside. http://www.theinquirer.net/inquirer/news/2285404/mediatek-releases-first-big-little-chip-that-uses-powervr-series-6-gpu -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [U-Boot] Basic A33 support including dram init available in my personal repo
On Mon, 2 Mar 2015 17:21:48 +0530 Vishnu Patekar vishnupatekar0...@gmail.com wrote: Hello Hans, Thank you for the comments. On Mon, Mar 2, 2015 at 3:55 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 01-03-15 19:42, Vishnu Patekar wrote: Allwinner A33 tablets comes with the libdram binary, fortunately I've found the libdram code at https://github.com/realthunder/a33_bootloader/ tree/master/basic_loader/bsp/bsp_for_a67. Ah, that is both good and bad... Now, for me good part is over, now it's just bad. I've integrated it with mainline u-boot, still lot to do to post it to upstream Integrated sounds as if you've copied pieces of code from the bsp code you've found into mainline u-boot. That is a big no no (this the bad part). AFAIK the bsp code does not come with a GPL license header, and Allwinner does not want to release these bits under the GPL for whatever reasons, a lot can be said about this, but in the end currently the bsp code is not GPL licensed, so we cannot use it / copy from it. There can be no discussion on this, when you're submitting this upstream you must not have any literal copied code in the patch you're sending upstream. You can use non copyrightable information from the bsp sources like register names and the initialization algorithm (IANAL), but you must 100% write your own code! I've been working on A33 dram support too, without any source code access, instead I've been tracing what the boot0 machine code does and going from there. What I've sofar is that the code first inits the DRAM PLL / cmu dram registers, it seems that the A33 has 2 dram pll-s and that one of the dram_para fields configures which pll to use and configures some sigma-delta pattern to reduce rf interference, at least on my A33 tablet the code seems to want to pick the new / second dram pll. But I see no reason why the first one should not work, so for now if I were you I would just use the A23 dram pll / cmu setup code modified to set the one or 2 extra reset / enable bits the A33 has, but still using the old / first dram pll, we can always add support for the new one later. Then the boot0 code calculates a load of timing parameters and writes these to registers. I've already written my own C-code reproducing the init algorithm from boot0 for this (attached) this is GPL code and you should be able to use this to replace a chunk of the bsp code. Note that I found 2 code paths based on a tpr13 bit (iirc) one for autoconfig, and one for reading values from the tpr dram_para values, my code supports only autoconfig, you can add a printf to warn if manual config is requested and still keep using autoconfig. The same goes for any other code paths were there is both a manual and an auto option, look at what actual shipped tablets are using, only support that and print a warning for the other case, were possible always use autoconfig. After this boot0 does more stuff, but this is as far as I've gotten and currently I've other priorities. If I were you I would start with the existing dram_sun6i.c from upstream u-boot, as the A33 DRAM controller seems to be closest to the A31 one, then add in the dram_sun8i.c pll init code, and the timing stuff which I've already written, and then see where the initialization algorithm is different for the A33 and modify the dram_sun6i.c code to match what is needed to get the A33 going, if extra code is needed you MUST write NEW code. When you submit support for this upstream you must include a Signed-off-by, and thereby you are declaring that the code is all your own and that you've the right to submit this code under the GPL license, this means that there must be absolutely no copied code in your upstream patch submission! Also see: https://git.kernel.org/cgit/linux/kernel/git/torvalds/ linux.git/tree/Documentation/SubmittingPatches Section 11) Sign your work Basic A33 support including dram init available in my personal repo https://github.com/vishnupatekar/u-boot-sunxi/tree/a33-dram I could able to boot u-boot over fel, and get u-boot command prompt on microSD pins which are multiplexed with UART0. The device page for A33 tablet which I've is here: http://linux-sunxi.org/Softwinner_astar-rda Thanks for your work on this, and sorry if I sound a bit harsh above, but I really need to be strict about not allowing any non GPL code into u-boot. No, You've not been harsh, instead you've been helpful in this case. Thank you for clearing my doubts. I was under impression that if we keep the copyright header, it can be accepted. BTW, libdram as binary and used in u-boot is also GPL violation, right? I'll see how can I re-use the A31 dram init code and get it work for A33. I see that this discussion has unfortunately derailed. Vishnu, please
Re: [linux-sunxi] Allwinner GPL violations: definitive proof.
I'll try to summarize the thread and restart it. Simos please don't +1 I hope to see code from Allwinner to make things better for users. I don't fully agree with Luc's words but he has credit that Allwinner doesn't: real code to be used today helping a lot of people. Thank you for all guys spending time on this. We will not to win anything attacking people here. So let's stop to talk about what will happen and just show the code. This is the best argument that no one can ignore. Cheers, - Roberto - Roberto On Wed, Mar 4, 2015 at 10:11 AM, Simon Kenyon simoncken...@gmail.com wrote: On 03/04/15 12:51, Simos Xenitellis wrote: I'll try to summarize the thread and restart it. Simos please don't -- simon Simon Kenyon e: simoncken...@gmail.com m: +353 86 240 0005 l: http://ie.linkedin.com/pub/simon-kenyon/0/6b2/744/ s: simonckenyon t: @simonckenyon g: google.com/+SimonKenyon -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Allwinner GPL violations: definitive proof.
On Wed, Mar 04, 2015 at 02:31:41PM +0200, Simos Xenitellis wrote: On Wed, Mar 4, 2015 at 1:57 PM, Luc Verhaegen l...@skynet.be wrote: On Wed, Feb 25, 2015 at 04:55:15AM +0100, Luc Verhaegen wrote: ... So now there is a LICENSE file stating that the code in https://github.com/allwinner-zh/media-codec is LGPL? So Allwinner believes that by sticking the LGPL on a _binary_ solves all the problems? Just like it seems to believe that removing all binaries from a kernel tree solves all problems with the GPL? Really? This is simply ridiculous. This guy is so toxic. Apparently it's an attitude style to be permanently negative. You give him caviar and he complains that it's black. Or a VIN ROMANEE CONTI 1955 and he complains that it's too old. I do not know whether there will be more commits to that repo. Just in case there are, a typical person would refrain from making such comments. Simos Simos, I am corrosive and bitter, but perhaps i am not the toxic one here. All we ever see you do is trash me. You have written no code, you have not contributed to the wiki, you only now spend some time on irc to try to clean up your image. You started calling for banishing me, while trying to instigate a fork, almost as soon as you got here. And you try to post about every little positive thing that allwinner does (while allwinner ignores its hard legal responsibilities), to try to take credit for them and to try artificially gain any form of standing here. Perhaps you and Allwinner do not realize this. But linux-sunxi does not need Allwinner, Allwinner needs linux-sunxi. What linux-sunxi requires from Allwinner is a legal matter, and a pretty open and shut case at that. Allwinner trying to make their mole a part of this community this crudely or artificially, while so badly messing up the basics, that is not only counterproductive, it is quite preposterous. Stop trying to hollow out Allwinners hard legal requirements. Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: Allwinner GPL violations: definitive proof.
@Allwinner staff guys where is the A80 vpu / gpu hardware acceleration in linux / ubuntu / kodi? I sugest you to hire Luc Verhaegen if you guys are not able to provide this A80 linux vp/gpu hardware accelerated support. The end users from freaktab forum and tronsmart forum keep waiting to see this happen. Do you really want us the end users to boycott your Allwinner products? -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Allwinner GPL violations: definitive proof.
On Wed, Mar 4, 2015 at 1:57 PM, Luc Verhaegen l...@skynet.be wrote: On Wed, Feb 25, 2015 at 04:55:15AM +0100, Luc Verhaegen wrote: ... So now there is a LICENSE file stating that the code in https://github.com/allwinner-zh/media-codec is LGPL? So Allwinner believes that by sticking the LGPL on a _binary_ solves all the problems? Just like it seems to believe that removing all binaries from a kernel tree solves all problems with the GPL? Really? This is simply ridiculous. This guy is so toxic. Apparently it's an attitude style to be permanently negative. You give him caviar and he complains that it's black. Or a VIN ROMANEE CONTI 1955 and he complains that it's too old. I do not know whether there will be more commits to that repo. Just in case there are, a typical person would refrain from making such comments. Simos -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Allwinner GPL violations: definitive proof.
On 03/04/15 12:51, Simos Xenitellis wrote: I'll try to summarize the thread and restart it. Simos please don't -- simon Simon Kenyon e: simoncken...@gmail.com m: +353 86 240 0005 l: http://ie.linkedin.com/pub/simon-kenyon/0/6b2/744/ s: simonckenyon t: @simonckenyon g: google.com/+SimonKenyon -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Allwinner GPL violations: definitive proof.
On Wed, 4/3/15, Simon Kenyon simoncken...@gmail.com wrote: On 03/04/15 12:51, Simos Xenitellis wrote: I'll try to summarize the thread and restart it. Simos please don't +1 I see Luc as basically in the right. I wouldn't support every little detail or his manner of expressing himself in every case but overall it's time Allwinner behaved properly. It would be fun if someone got embargoes on Allwinner products for USA, EU other places such that because of their legal violations their products were banned from sale. Not fun as in I would like it but so Allwinner would have little choice but to at long last do the right things. No-one made Allwinner use GPL code, they chose to. So, they have to comply with its terms. John -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Regarding the sunxi-cedarx support
Hi All, As some may say, what is important to look at, is our end-game. That is, how should our relationship with Allwinner be, and what steps to take to get there. Allwinner has made mistakes with regards to free/open-source licenses of software. Some of those mistakes could have been avoidable (that is, still not release the source but distribute in a more appropriate way), while others have no way around (i.e. the source must be released) nor excuse. For the part of libvdecoder.so/libvencoder.so, if there are libraries in there that did not come from Allwinner, then there is a workaround for them by splitting the code in separate libraries. It would make them compliant (in future versions) but then the core issue of software support would be bypassed. I do not know whether libvdecoder.so has non-Allwinner code; perhaps David could investigate and deliver a verdict. There is this tradition for semiconductor companies to try to keep closed as much as possible. Being less exposed should mean less potential problems? And more control over the downstream? Well, that tradition is changing and it's not the important the new trend is to attract as many developers as possible. It is so critical to attract developers to your hardware/software, that companies start to make things free and open-source. For me, the important message from the recent discussion on software support in CedarX, is what Jon Smirl and javqui said. That they have been doing projects and the lack of good support is a huge issue. Also, very expensive to their projects. This is something that Allwinner must note down and rectify. Apart from the developers being affected, it is also Allwinner that loses developers and new customers. There are more and more SoCs from others to choose from, including Intel, who are doing a similar open driver (http://www.phoronix.com/scan.php?page=news_itempx=MTg4Mjg). Even the PR manager at ImgTec showed interest to get things more open at http://www.reddit.com/r/linux/comments/2ps5l3/the_state_of_open_source_drivers_for_mobile_and/ I do not like the aggressive/abusive style that is shown in this list. I do not think that it can deliver a working relationship that can last. While we talk about community, it's still free for all to anyone to lead to different directions. I think the end-game should be towards a long-term working relationship. In the case that Allwinner cannot deliver, so be it. Everyone would loses, including Allwinner. However, I see efforts to adapt, including the hiring of David. It's up to Allwinner to adapt quickly in order to keep attracting developers. Simos -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Allwinner GPL violations: definitive proof.
miercuri, 4 martie 2015, 15:44:44 UTC+2, Roberto Alcântara a scris: I'll try to summarize the thread and restart it. Simos please don't +1 I hope to see code from Allwinner to make things better for users. I don't fully agree with Luc's words but he has credit that Allwinner doesn't: real code to be used today helping a lot of people. Thank you for all guys spending time on this. We will not to win anything attacking people here. So let's stop to talk about what will happen and just show the code. This is the best argument that no one can ignore. Cheers, - Roberto - Roberto On Wed, Mar 4, 2015 at 10:11 AM, Simon Kenyon simonc...@gmail.com wrote: On 03/04/15 12:51, Simos Xenitellis wrote: I'll try to summarize the thread and restart it. Simos please don't -- simon Simon Kenyon e: simonc...@gmail.com m: +353 86 240 0005 l: http://ie.linkedin.com/pub/simon-kenyon/0/6b2/744/ s: simonckenyon t: @simonckenyon g: google.com/+SimonKenyon -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. @Roberto asuming allwinner has did copy the hardware (speaking about A80 sun9i) and the reason of violating GPL's and not publishing sources is might be possible to get sued by original silicon vendor ... but the question is which silicon vendor uses big.Little + powerVR gpu? Reading around there is no such silicon vendor who will have big.Little architecture with PowerVR gpu inside. @All others Boycotting Allwinner products is a bad thing but possible and usable after all also very easy to achieve it. Commercial products forums such as AVS , freaktab and a lot more other waiting just a sign to start the media lynching over Allwinner Maybe there is no need for a media lynching and boycotting after all each silicon vendor have to protect his patents and intelectual property. Maybe following the same thin line of Amlogic or Freescale vendors would be the solution i don't know. I saw a lot of buyers who own A80 based boxes awaiting some good signs from Allwinner ... for them patience is not a virtue... -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [U-Boot] Basic A33 support including dram init available in my personal repo
Hi, On 04-03-15 13:33, Siarhei Siamashka wrote: On Mon, 2 Mar 2015 17:21:48 +0530 Vishnu Patekar vishnupatekar0...@gmail.com wrote: Hello Hans, Thank you for the comments. On Mon, Mar 2, 2015 at 3:55 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 01-03-15 19:42, Vishnu Patekar wrote: Allwinner A33 tablets comes with the libdram binary, fortunately I've found the libdram code at https://github.com/realthunder/a33_bootloader/ tree/master/basic_loader/bsp/bsp_for_a67. Ah, that is both good and bad... Now, for me good part is over, now it's just bad. I've integrated it with mainline u-boot, still lot to do to post it to upstream Integrated sounds as if you've copied pieces of code from the bsp code you've found into mainline u-boot. That is a big no no (this the bad part). AFAIK the bsp code does not come with a GPL license header, and Allwinner does not want to release these bits under the GPL for whatever reasons, a lot can be said about this, but in the end currently the bsp code is not GPL licensed, so we cannot use it / copy from it. There can be no discussion on this, when you're submitting this upstream you must not have any literal copied code in the patch you're sending upstream. You can use non copyrightable information from the bsp sources like register names and the initialization algorithm (IANAL), but you must 100% write your own code! I've been working on A33 dram support too, without any source code access, instead I've been tracing what the boot0 machine code does and going from there. What I've sofar is that the code first inits the DRAM PLL / cmu dram registers, it seems that the A33 has 2 dram pll-s and that one of the dram_para fields configures which pll to use and configures some sigma-delta pattern to reduce rf interference, at least on my A33 tablet the code seems to want to pick the new / second dram pll. But I see no reason why the first one should not work, so for now if I were you I would just use the A23 dram pll / cmu setup code modified to set the one or 2 extra reset / enable bits the A33 has, but still using the old / first dram pll, we can always add support for the new one later. Then the boot0 code calculates a load of timing parameters and writes these to registers. I've already written my own C-code reproducing the init algorithm from boot0 for this (attached) this is GPL code and you should be able to use this to replace a chunk of the bsp code. Note that I found 2 code paths based on a tpr13 bit (iirc) one for autoconfig, and one for reading values from the tpr dram_para values, my code supports only autoconfig, you can add a printf to warn if manual config is requested and still keep using autoconfig. The same goes for any other code paths were there is both a manual and an auto option, look at what actual shipped tablets are using, only support that and print a warning for the other case, were possible always use autoconfig. After this boot0 does more stuff, but this is as far as I've gotten and currently I've other priorities. If I were you I would start with the existing dram_sun6i.c from upstream u-boot, as the A33 DRAM controller seems to be closest to the A31 one, then add in the dram_sun8i.c pll init code, and the timing stuff which I've already written, and then see where the initialization algorithm is different for the A33 and modify the dram_sun6i.c code to match what is needed to get the A33 going, if extra code is needed you MUST write NEW code. When you submit support for this upstream you must include a Signed-off-by, and thereby you are declaring that the code is all your own and that you've the right to submit this code under the GPL license, this means that there must be absolutely no copied code in your upstream patch submission! Also see: https://git.kernel.org/cgit/linux/kernel/git/torvalds/ linux.git/tree/Documentation/SubmittingPatches Section 11) Sign your work Basic A33 support including dram init available in my personal repo https://github.com/vishnupatekar/u-boot-sunxi/tree/a33-dram I could able to boot u-boot over fel, and get u-boot command prompt on microSD pins which are multiplexed with UART0. The device page for A33 tablet which I've is here: http://linux-sunxi.org/Softwinner_astar-rda Thanks for your work on this, and sorry if I sound a bit harsh above, but I really need to be strict about not allowing any non GPL code into u-boot. No, You've not been harsh, instead you've been helpful in this case. Thank you for clearing my doubts. I was under impression that if we keep the copyright header, it can be accepted. BTW, libdram as binary and used in u-boot is also GPL violation, right? I'll see how can I re-use the A31 dram init code and get it work for A33. I see that this discussion has unfortunately derailed. Vishnu, please don't take this MUST and NEW code statements from Hans as a strict requirement. We only need Allwinner to re-license these pieces of A33 dram code under
Re: [linux-sunxi] Regarding the sunxi-cedarx support
Here's my top ten list for Allwinner.. 1) I've worked in this industry a very long time and have lived through a bunch of boom and bust cycles. These cycles are not going away. The market for tablets is going to bust sooner or later because something new will come along. To protect yourself from these cycles you must diversify your product line and customer base. This is not optional, if you don't do this your company will die in the bust. I've seen if happen a dozen times. Camera chips is a good start. 2) Your company can be killed by security flaws. These flaws may not kill you directly, but they will kill your OEM manufacturers and then they don't but chips. The best way to keep these flaws under control is to stay on the latest software. That means getting your code upstream and into mainline for the kernel and everything else. It also means that it is critical for your OEMs to support remote firmware updates. 3) ARM64 is not going to save you. Every chip maker on the planet is aimed at the ARM64 server market. The competition is going to be brutal. Margins are likely to be low. There is also a large software component. People buying ARM64 servers are extremely vulnerable to security flaws since their business are the number one target of Internet attacks. These people are not going to buy anything with a three year old vendor kernel on it. Your chip support has to be in mainline. 4) Don't underestimate the Linux community. There are tens of thousands of programmers involved with Linux. Many of these programmers are highly skilled. A lot of them are probably more skilled in their area of expertise than your own employees. These people (for many various reasons) will fix your code for you for free if they are given the chance. The main reason they do this for free is because their own products they are trying to ship depends on your code. 5) Getting your kernel code into mainline will actually reduce the amount of engineering you need to do. That's because when you submit the code it will get inspected by highly skilled people. Those people are going to notice a lot of bugs and tell you to go fix them before accepting the submission. They will also help teach you the Linux way of doing things. It is much less effort to follow the Linux way of doing things than it is to do something different and then keep porting that different solution to dozens of kernels. Once your code is in mainline the rules require that other developers can't break it. You don't have that protection right now as you've discovered when you try and port the code forward for each new kernel. 6) Comply with the GPL. You may think that you have secrets but you really don't. There are twenty vendors doing video encode/decode. They have all figured it out so the knowledge is out there. Obviously the people that wrote these encoding specs know the details. By hiding the code you simply prevent people that know more about these codecs (more than your own engineers) from giving you free help to fix them. Don't worry about patents, you're in China, nothing is going to happen. With the GPL the most dangerous thing is when a competitor anonymously funds a lawyer to attack you over the GPL in the middle of your IPO. 7) Get rid of any notion of selling access to SDKs. Don't charge for support request either. But -- every company knows who their big customers are. Support request from big customers get detailed answers, support request from a small one might be told the page number of the manual to go read. Make these SDKs easily accessible by anyone. The dumbest thing to do is tie this access to your hardware customers. Most of the time the people doing the hardware and not the people doing the software. Most hardware companies are terrible at software. Directly communicate with the people doing the software. Use places like github which are easily accessible. 8) Get your chips into some US and EU distributors. Like Digikey or Farnell. US/EU companies will buy these chips to locally build prototypes. Those prototypes are key to developing new customers. Most of the volume production will be in China. I find it really annoying to have to get Chinese friends to send me chips all of the time. Future Electronics was willing to carry your line a couple of years ago, what happened? 9) Support the early creation of low cost developer boards. You've been doing a pretty good job of this. But there is still no developer board for the A23/A33. Also, what about developer boards for the camera chips? 10) First item was diversify. Here's an idea. Multichip packages like the Hi3518e and the GM813S are really easy to design in. How about versions of your Axx chips with embedded DRAM dies. These chips could be aimed at markets that don't need the LCD interface. Removing the DRAM and LCD interfaces will hugely reduce pin count. 10a) For all of your existing chips.. Increase customer diversity by multiplexing all of the peripherals, GPIOs,etc
