Re: [linux-sunxi] Re: Allwinner GPL violations: definitive proof.
Hi, On Wed, 25 Feb 2015 14:06:59 +0800 ke...@allwinnertech.com ke...@allwinnertech.com wrote: Hi, Luc, Allwinner is trying to fix the GPL issue taken on Cedarx. That is the right thing, and thank you for this statement. We have release the latest version of cedarx with LGPL. And just close the code of Video Engine hardware, the framework and API is Why is close? Please open the code of Video Engine hardware. If allwinner still isn't aware. The Video Engine hardware was successful reversed engineering more that 1 year already. With the result been the fantastic 100% open source libvdpau-sunxi implementation. http://linux-sunxi.org/VE_Register_guide There isn't anything to hide. Allwinner only has to win by publising more open information about the video engine hardware. By the means of open source code, or any form of hardware documentation. I, as one of the Video Engine hardware reverse engineering developers that wishes to have a proper 100% open source mainlined kernel driver. Ask cooperation from allwinner. Thanks. Manuel Braga opensource. We will review the code again, to fix the GPL issues still existed. We are trying to do better, if you found any GPL issue, please let us know, we will fix it and update it ASAP. About the kernel GPL issue, we are fixing it now, we will update the code to open some drivers. Thanks. Best Regards. ke...@allwinnertech.com From: Luc Verhaegenmailto:l...@skynet.be Date: 2015-02-25 11:55 To: linux-sunxi@googlegroups.commailto:linux-sunxi@googlegroups.com CC: Meng Zhangmailto:ke...@allwinnertech.com; sh...@allwinnertech.commailto:sh...@allwinnertech.com Subject: Allwinner GPL violations: definitive proof. 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. NOTICE: This e-mail and any included attachments are intended only for the sole use of named and intended recipient (s) only. If you are the named and intended recipient, please note that the information contained in this email and its embedded files are confidential and privileged. If you are neither the intended nor named recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. Please reply to the sender and destroy the original message and all your records of this message (whether electronic or otherwise). Furthermore, you should not disclose to any other person, use, copy or disseminate the contents of this e-mail and/or the documents accompanying it. -- -- 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 wanna say big THANKS to Allwinner for this step, please continue to work in this direction. I look forward to see more source code from you guys. One small comment is it will be great if you guys can also use git internally, so we can see the changes along the way. Clement On Feb 25, 2015, at 1:15 PM, Simos Xenitellis simos.li...@googlemail.com wrote: On Wed, Feb 25, 2015 at 5:55 AM, Luc Verhaegen l...@skynet.be wrote: 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. I think it's time for Luc to start playing nice. His toxic behavior does not help. Trying to berate both on list and off list, even new members to this Google group, is unacceptable behavior. It makes me wonder whether his abrasive behavior was actually a factor to the situation that we try to solve here. It's very ironic as well! We see constructive efforts from Allwinner to fix issues and it makes sense for the community to be constructive as well. I do not even see an issue filed at https://github.com/allwinner-zh/media-codec/issues Being constructive and nice takes you a long way, 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. -- 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: Allwinner GPL violations: definitive proof.
On Wed, Feb 25, 2015 at 1:06 AM, ke...@allwinnertech.com ke...@allwinnertech.com wrote: Hi, Luc, Allwinner is trying to fix the GPL issue taken on Cedarx. We have release the latest version of cedarx with LGPL. And just close the code of Video Engine hardware, the framework and API is opensource. We will review the code again, to fix the GPL issues still existed. We are trying to do better, if you found any GPL issue, please let us know, we will fix it and update it ASAP. About the kernel GPL issue, we are fixing it now, we will update the code to open some drivers. Kevin, there are advantages to being open source. For example my company tried using the A20 for a product two years ago. We spent a lot of effort developing it and never could get the video compression working the way we needed it to work. I sent several bugs into Allwinner which got fixed, but the fixes came back about eight months after I had sent the problems in. That was far too late to save our project. Since we couldn't get the A20 version of the product going we finally gave up and switched to a different CPU vendor. All of this messing around probably cost us $250,000. Plus we are paying more for the new CPU. But the new one works correctly, which is the most important point. If I had the source to the compression code I probably could have fixed it myself and sent out a patch. Or maybe I could have inserted debug printouts and narrowed the problem down to a very specific bug report which would have made it easy for you to fix. Instead I was just stuck using a black box which didn't always do the right thing and I had no ability to fix. We finally gave up and switched CPUs. Being open source allows other people to help you improve the code. There are a lot of highly skilled programmers working on Linux. When shipping their products is dependent on getting Allwinner code fixed, they will go in and fix bugs if they have the source code. They will also send you these fixes since they want them incorporated into the official releases. On another topic - kernel drivers. Closed source, out of tree kernel drivers are a security nightmare. Consider what happens when a security bug is found in the Linux kernel. The bug is disclosed and a fix is issued. For vendors on mainline they can quickly incorporate these patches and send our dynamic updates out to their products. But what about closed drivers? It is easy to crack into old kernels. The instructions on how to do it are included in the security vulnerability disclosure. Closed drivers prevent me from applying these security patches and moving onto a newer kernel. Instead I have to wait until Allwinner decides to update their kernels - which may be years. This attack method is used a lot in the wild. It is how the first attack against Sony was done (not the current one). They were running three year old kernels on their servers. Somebody just looked up the vulnerabilities that had been fixed and used one to walk right into their corporate network. This is a not a good thing for someone like Allwinner who is making security camera chips now. Thanks. Best Regards. ke...@allwinnertech.com From: Luc Verhaegen Date: 2015-02-25 11:55 To: linux-sunxi@googlegroups.com CC: Meng Zhang; sh...@allwinnertech.com Subject: Allwinner GPL violations: definitive proof. 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
Re: [linux-sunxi] Allwinner GPL violations: definitive proof.
On Wed, Feb 25, 2015 at 5:55 AM, Luc Verhaegen l...@skynet.be wrote: 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. I think it's time for Luc to start playing nice. His toxic behavior does not help. Trying to berate both on list and off list, even new members to this Google group, is unacceptable behavior. It makes me wonder whether his abrasive behavior was actually a factor to the situation that we try to solve here. It's very ironic as well! We see constructive efforts from Allwinner to fix issues and it makes sense for the community to be constructive as well. I do not even see an issue filed at https://github.com/allwinner-zh/media-codec/issues Being constructive and nice takes you a long way, 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 02/25/15 12:15, Simos Xenitellis wrote: We see constructive efforts from Allwinner to fix issues and it makes sense for the community to be constructive as well. i see *words* saying that they would fix issues. i see no *actions*. and that has been true for a very, very, very long time. -- 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 Wednesday, 25 February 2015 23:15:38 UTC+11, Simos Xenitellis wrote: On Wed, Feb 25, 2015 at 5:55 AM, Luc Verhaegen l...@skynet.be wrote: 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. I think it's time for Luc to start playing nice. His toxic behavior does not help. Trying to berate both on list and off list, even new members to this Google group, is unacceptable behavior. It makes me wonder whether his abrasive behavior was actually a factor to the situation that we try to solve here. It's very ironic as well! We see constructive efforts from Allwinner to fix issues and it makes sense for the community to be constructive as well. I do not even see an issue filed at https://github.com/allwinner-zh/media-codec/issues Being constructive and nice takes you a long way, Simos Wrong! Luc is being overly nice. We write and release code under the *terms* of the GPL, those are the legal terms we wish for *our* work to be used under. Allwinner make huge volumes of money off *our* work. Except us to be filing suite with FSF to ensure these violations are chased up! Allwinner can cut the shit, they have plenty of money and resources to see this is resolved by weeks end! None of this my favor company is my friend, they said nice words, pat pat on the back.. crap.. Luc does not need to be 'nice' to Allwinner, Allwinner needs to comply with the *law* period ! Regards, -- 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 2/4] i2c: sunxi: Add Reduced Serial Bus (RSB) DT bindings documentation
On Tuesday 24 February 2015 22:32:57 Chen-Yu Tsai wrote:
On Tue, Feb 24, 2015 at 10:17 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 24 February 2015 22:01:26 Chen-Yu Tsai wrote:
On Tue, Feb 24, 2015 at 6:37 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 24 February 2015 18:29:02 Chen-Yu Tsai wrote:
+ rsb@01f03400 {
+ compatible = allwinner,sun8i-a23-rsb;
+ reg = 0x01f03400 0x400;
+ interrupts = 0 39 4;
+ clocks = apb0_gates 3;
+ clock-frequency = 300;
+ resets = apb0_rst 3;
+
+ axp223: pmic@2d {
+ compatible = x-powers,axp223,
x-powers,axp221;
+ reg = 0x2d;
+ allwinner,rsb-hw-addr = 0x3e3;
+
+ /* ... */
+ };
+ };
I don't really understand the need for having two addresses (runtime
and hardware). Could the runtime address be configured at runtime?
You can, though the driver doesn't support this. I don't think the
I2C subsystem allows arbitrary device insertion during normal
operation, but maybe i2c-dev? I've tried using different addresses
for devices so they do get changed during the probe phase, just
to be sure that the code works, and it's not just sitting at
the address the bootloader used.
In any case, the distinction is more like burnt-in or hardwired
addresses vs software configurable addresses.
The simplest binding would the probably be to only put the
hardware address into the 'reg' property and always assign the
logical addresses dynamically.
Would that add a lot of complexity or does it have any other
downsides?
The hardware address is 12 bits wide. Any address higher than
0x3ff will be rejected by the I2C core. The AC100 is at 0xe89.
Assigning addresses dynamically means the driver has to keep
a lookup table to map the hardware address to the logical
address to issue the command to.
There's also the issue of dynamically assigned address colliding
with unlisted devices, though I think this would only happen in
the development / bring up phase of the device.
I think the first issue pretty much rules out putting the
hardware address into 'reg'.
Putting the logical address in the 'reg' property allows the
user to poke unlisted devices using i2c-tools, though this
is not so useful to the average user.
Ok, fair enough. Your approach seems reasonable then, but it
might be helpful to add your explanation to the changelog of the
patch that introduces the binding.
Arnd
--
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] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
From: Steven Saunderson essat2...@gmail.com Sent: Wednesday, 25 February 2015, 6:30 Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth I think the host UART driver ( serial8250 ) should be dealing with the handshaking. It is hopefully just a question of getting it configured correctly at start up. This could make things simpler. If you can configure the serial port for a null-modem environment then it might be possible to use the standard program. I had assumed it could be configured and that was the reason for suggesting stty crtscts -F /dev/ttyS2 A patch was posted back in May 2014 that added has-hw-flow-control to the DTS bindings:http://lists.openwall.net/linux-kernel/2014/05/28/673 It doesn't appear to have been applied:https://www.kernel.org/doc/Documentation/devicetree/bindings/serial/of-serial.txt There appears another patch renaming the documentation file from of-serial.txt to 8250.txt:https://lkml.org/lkml/2014/11/25/596That doesn't appear to have been applied. So maybe that is why 3.19 doesn't work as expected. Does anyone know the status of hardware flow control for UART on AllWinner SoCs? Al -- 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] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
Until yesterday I used sun7i-a20-cubietruck.dtb generated from files supplied with the Linux 3.19.0-rc6 kernel. With this .dtb the Bluetooth UART is accessed via /dev/ttyS2. This is different from the 3.4 kernels which provide access via /dev/ttyS1. Now I've generated a new .dtb using the latest files from https://github.com/wens/linux/blob/sunxi-next/arch/arm/boot/dts/ and with this .dtb the relevant UART (uart2) is accessed via /dev/ttyS1. This is a great improvement. It also means that my decisions based on the kernel level are incorrect. I've changed the scripts so they always use ttyS1 and will have to manually altered if required. I've updated my repository at https://github.com/phelum/CT_Bluetooth with these scripts and also the .dts and .dtb I'm using. The .dts generated from the files above didn't contain a clause enabling uart2 so I added such a clause to the end of the .dts before creating the .dtb. On Thursday, February 26, 2015 at 6:31:55 AM UTC+11, Al Thomas wrote: Does anyone know the status of hardware flow control for UART on AllWinner SoCs? Hi Al, I don't know about this and I'm not sure it would help anyway. I added CTS checking to my version of the Broadcom program last year when trying to fix the download problem. The only time I see CTS drop is immediately after a reset (BT_REST toggle) and immediately after sending an HCI_reset command. The standard Broadcom program has a parameter specifying the wait period after sending HCI_reset. So the standard program will probably work if the delay (e.g. --tosleep 5000) is specified in the command. The problem I see with any hardware or serial port flow control is that anything that uses CTS might also drive RTS. In the download case here we need RTS asserted continuously and this might not happen in any CTS-sensitive environment. It seems safer to me for the download program to drive RTS and whether this program reacts to CTS is another matter. This still leaves the issue with RTS and the BT_REST pulse. It should be possible to write a small program that opens the serial port, asserts RTS, applies the BT_REST pulse, and then closes after say 10ms. The standard download program could be run after this preparation step. Does this sound like a better approach ? Cheers, Steven -- 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: Wiki broken
This problem seem to have returned. Could someone help? Username gnyers On Friday, June 27, 2014 at 1:05:15 PM UTC+2, Paul Jones wrote: Hi, If the wiki administrator is lurking here, just an FYI that the wiki is slightly broken: linux-sunxi.org could not send your confirmation mail. Please check your email address for invalid characters. Mailer returned: Unknown error in PHP's mail() function. My wiki username is peejay Thanks, Paul. -- 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, 2015-02-25 at 14:15 +0200, Simos Xenitellis wrote: On Wed, Feb 25, 2015 at 5:55 AM, Luc Verhaegen l...@skynet.be wrote: 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. I think it's time for Luc to start playing nice. His toxic behavior does not help. Trying to berate both on list and off list, even new members to this Google group, is unacceptable behavior. It makes me wonder whether his abrasive behavior was actually a factor to the situation that we try to solve here. It's very ironic as well! We see constructive efforts from Allwinner to fix issues and it makes sense for the community to be constructive as well. I do not even see an issue filed at https://github.com/allwinner-zh/media-codec/issues Being constructive and nice takes you a long way, Simos Being ignorant makes you.. ? https://github.com/allwinner-zh/bootloader/issues Päikest, Priit Laes :) -- 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: Allwinner GPL violations: definitive proof.
On Wed, 25/2/15, ke...@allwinnertech.com ke...@allwinnertech.com wrote: Allwinner is trying to fix the GPL issue taken on Cedarx. [snip] I'm pleased to read that but in that case where are the sources? It is not hard (English meaning: it is easy) to find how you built the various binaries and then release the code. Please - to avoid more reminders and complaints - just get on with releasing the sources. Delay followed by more delay really makes you look bad, which is a pity as people are trying to support your devices. In future, just release the matching sources every time you release binaries. It is s easy! Regards, 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.
Re: [linux-sunxi] Re: Allwinner GPL violations: definitive proof.
On Wed, Feb 25, 2015 at 02:06:59PM +0800, ke...@allwinnertech.com wrote: Hi, Luc, Allwinner is trying to fix the GPL issue taken on Cedarx. It's been 4 years since your violations started. You have been told often enough. At least from 2012 onwards Allwinner has been very aware of the legal status of the software its business fully depends on. You were even given a nice consistent list of issues back in August, and in the 6 months that passed since then you have not fixed a single thing. We have release the latest version of cedarx with LGPL. No, you have not. And just close the code of Video Engine hardware, the framework and API is opensource. This is where you violate at least the ffmpeg LGPL license and breach on2 technologies (now google) copyright with the libVP62 symbols in there. I have been very clear and consistent about this, yet you still either fail to or are unwilling to understand. We will review the code again, to fix the GPL issues still existed. We are trying to do better, if you found any GPL issue, please let us know, we will fix it and update it ASAP. I have been pointing these out since at least august, quite concisely and very understandably. And all allwinner ever does is come with excuses and nonsense code or binary releases which just continue the violations. About the kernel GPL issue, we are fixing it now, we will update the code to open some drivers. Not some. ALL. As required by the GPL. Truly unbelievable and absolutely ludicrous. 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.
