Re: [linux-sunxi] Re: [PATCH] ARM: sun6i: dt: Add new Mele I7 device
On Tue, Mar 03, 2015 at 08:55:36AM +0100, Hans de Goede wrote:
+/ {
+ model = Mele I7 Quad top set box;
+ compatible = mele,i7, allwinner,sun6i-a31;
+
+ chosen {
+ bootargs = earlyprintk console=ttyS0,115200;
Using earlyprintk by default is a bad idea if the kernel is configured
with DEBUG_LL support for another SoC.
While on this subject, u-boot now sets the chosen/stdout-path property
up by default, which means that the kernel will do the right thing by
default. So we we really do not need any bootargs= in our dts files.
I just tested that this weekend, and it turned out that the kernel
couldn't use it so far (ie, no output until init takes over and setup
a TTY on ttyS0).
Was it working for you?
Currently we've a random mix where we do have bootargs in some, but
not in most sunxi dts files. I believe we should simply remove it
everywhere...
We used to set them in SoCs that are not supported by U-boot yet, and
where the bootloader won't come and patch the DT (A31, A23, A80).
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] sunxi: Machine id hack to prevent loading buggy sunxi-3.4 kernels
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. 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). 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. 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. Ian. -- 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] New sunxi-tools v1.3 release planning
On Sat, 2015-02-28 at 11:24 +0100, Koen Kooi wrote: What would be actually your suggestion? For sunxi-tools: simple makefile with a working 'make install DESTDIR=/path/foo'. ...which installs not-too-generically named binaries, with that: ack from me too. WRT not-too-generically named: e.g. usb-boot and bootinfo are certainly too generic, so in Debian I add a sunxi- prefix. fel, fexc etc might be OK, but there's some potential for a clash (mostly due to them being quite short acronym fodder). I ended up prefixing them sunxi- in Debian for consistency with the other binaries. My preference would be for everything to be prefixed (perhaps unless it's not actually sunxi specific somehow and just happens to live in sunxi-tools). 1) Makefile with working make install 2) autotools That would be my order of preference too. I think the sunxi-tools build is simple enough that just supporting and correctly using $(HOSTCC) and $(CROSS_COMPILE)$(CC) (and AS, LD etc) would be sufficient, even for the sort of canadian cross-compiles discussed elsewhere in this thread, without needing to go to full autotools (but I could live with the latter). WRT needing a cross compiler, I think all which is really needed for lots of the useful stuff is a cross binutils (specifically $(CROSS_COMPILE)$(AS)). Currently the build uses gcc to drive as+ld for building .S into .elf, but I think it could use as+ld directly without much effort. There are some trivial .c programs (fel-sdboot.c) which could easily be rewritten in asm. I think there would still be one or two things which are C which couldn't be done this way, but this would get far better coverage in distro builds with very little effort. The reason I mention cross-gcc vs cross-binutils is that for distros providing a cross binutils is generally pretty trivial, it's only once you get into cross-gcc and which libc do I use type questions that things get tricky and tend to stagnate. FWIW Debian has a cross binutils package targeting arm already and will ship it in the next release (Jessie). BTW, looking at the current makefiles it seems that we pass a load of options when building .S files which only make sense when compiling from .c (e.g. -Wno-format-nonliteral etc). Ian. -- 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: WLAN SBE error: any news?
Am 03.03.2015 um 15:31 schrieb Rodrigo Pereira: I don't know if it is your problem, but maybe it helps: http://linux-sunxi.org/Cubietruck/AP6210 Module ap6210 is a modified version of module bcmdhd, which is part of linux-sunxi and Android kernel, to address some problems on Cubietruck. To my knowledge it can't be used with mainline kernel. -- 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: Re: [linux-sunxi] BananPro WiFi Module (ap6181) Problems
Hi, Hans Thanks for your reply so fast. If needed, i can help to reproduce this problem. Best Regards Peter Chen Innovations that enrich people's lives. LeMaker Team -- The Professional Makers for Hardware and Software Customization. Address: B1002, SIAT campus, Shenzhen University Town, Shenzhen, China Post Code: 518055 Email: ap...@lemaker.org (Product Trials) educat...@lemaker.org (Education User Support) supp...@lemaker.org (Technical Support) prod...@lemaker.org (Product Distribution) banan...@lemaker.org (Other Enquiries) http://www.lemaker.org/ From: Hans de Goede Date: 2015-03-03 21:33 To: linux-sunxi; Arend van Spriel Subject: Re: [linux-sunxi] BananPro WiFi Module (ap6181) Problems 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? And any luck in finding a fix for it ? 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. -- 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] [New Device] Giada Q11 Mini
On Wed, Feb 04, 2015 at 05:41:22AM -0800, alatnet wrote: Pictures of it can be found here: http://www.techpowerup.com/reviews/Giada/Q11/4.html Com port on left side does not output anything. Port in front of sata connector might be a usb connection but unknown. Multimeter shows that 1st port on left when viewing from front outputs 4.76V on 20 Vdc settings. 4th port from left pulls a 20k Ohms setting to 0. USB 3.0 port on the right side is USB OTG connection. Using a USB A to USB A connection and pressing the far back button on the left side sets it to FEL Mode. Firmware that is flashable to the device in FEL Mode: http://download.giadatech.com.cn/driver/jt/Q11_v18_4.0.4_20130226_P008.rar Booting off of SD Card slot works. Was able to boot an MK802 Linux firmware without issues. Processor is an Allwinner A10. Yes I am a noob with this stuff. If anyone needs any more info, i'll be glad to provide it. I'll see about extracting the files from /boot and the MBR and adding it to this thread. http://linux-sunxi.org/New_Device_howto 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] GSL1680 hex dump to C header: is it possible?
From: Blake Gripling blakegriplin...@gmail.com Subject: [linux-sunxi] GSL1680 hex dump to C header: is it possible? I was wondering if it is feasible at all to do a C header translation of a firmware dump I made from a working gslX680 module. Both the 3.3 and 4.5 SDKs use C headers for firmware in gslx680.c, and I'm not that up to editing them to read hex either. Someone has kindly created a good wiki page http://linux-sunxi.org/GSL1680 that includes a link to https://gitorious.org/gslx680-for-sunxi/gslx680-for-sunxi/source/c8a91b8290aca8cd5f1329292d53e8bfe88c7f68:firmware/fw_extractor -- 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 26 February 2015 at 13:53, goo...@lanrules.de wrote: From many years of industrial experience I do know that most probably those companies do not intentionally violate GPL. They are just busily struggling to survive in these extremely fast moving markets and do not have time and resources to care for this kind of 'details'. This does not excuse it or embellish anything, but that is how organizations operate. If I cannot stay in business operating legally, my business model is wrong and I deserve to go bankrupt. Operating like this for several years is nothing short of criminal. Where is the respect for the authors of the original software in this discussion? Yeah, the authors of the software you built your business on do deserve some respect. Then again, legal and criminal is not all that clear. It turns out that in China not adhering to US law does not necessarily drive you out of business. Or not honoring the rights some US geek theoretically has even under Chinese copyright law if such thing even exists. And again, even western companies like nVidia are not much different from Allwinner. They delivered (or let their hw oem partners deliver) butchered binary Android SDKs when it seemed practical and now they are starting mainline kernel work when that seems practical. And again, if you are in software business in the west then any patent troll can sue you out of business anytime unless you are the size of IBM. Seriously, it does not matter that in the EU software patents are (maybe still) illegal. The patent office did and still does grants them. And it does not matter that the patent may not actually apply to your work. You still have to hire a lawyer and go to court if they sue you. And the cost of that may very well be orders of magnitude higher than the sales of small software firm. 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] ARM: sun6i: dt: Add new Mele I7 device
Hi,
On 03-03-15 09:22, Maxime Ripard wrote:
On Tue, Mar 03, 2015 at 08:55:36AM +0100, Hans de Goede wrote:
+/ {
+ model = Mele I7 Quad top set box;
+ compatible = mele,i7, allwinner,sun6i-a31;
+
+ chosen {
+ bootargs = earlyprintk console=ttyS0,115200;
Using earlyprintk by default is a bad idea if the kernel is configured
with DEBUG_LL support for another SoC.
While on this subject, u-boot now sets the chosen/stdout-path property
up by default, which means that the kernel will do the right thing by
default. So we we really do not need any bootargs= in our dts files.
I just tested that this weekend, and it turned out that the kernel
couldn't use it so far (ie, no output until init takes over and setup
a TTY on ttyS0).
Was it working for you?
Yes, note that the kernel only honors the stdout-path property if
there is no console= argument present if there is a console= argument
present on the kernel cmdline then that will overrule the stdout-path
property.
Which board did you test with, and what u-boot and kernel version ?
Currently we've a random mix where we do have bootargs in some, but
not in most sunxi dts files. I believe we should simply remove it
everywhere...
We used to set them in SoCs that are not supported by U-boot yet, and
where the bootloader won't come and patch the DT (A31, A23, A80).
Ah, so that is (was) the logic, following that logic we should probably
remove bootargs= from at least the a23 and a31 boards (basically
from all boards but a80).
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] BananPro WiFi Module (ap6181) Problems
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. Best Regards Peter Chen Innovations that enrich people's lives. LeMaker Team -- The Professional Makers for Hardware and Software Customization. Address: B1002, SIAT campus, Shenzhen University Town, Shenzhen, China Post Code: 518055 Email: ap...@lemaker.org (Product Trials) educat...@lemaker.org (Education User Support) supp...@lemaker.org (Technical Support) prod...@lemaker.org (Product Distribution) banan...@lemaker.org (Other Enquiries) http://www.lemaker.org/ -- 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, February 25, 2015 at 4:15:38 AM UTC-8, 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 Instead of whining about him calling you out on your years of noncompliance how about you start doing your fucking job. I hope someone with standing takes this to court and sues for damages as it is the only way anything will happen in a reasonable time frame. -- 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.
From many years of industrial experience I do know that most probably those companies do not intentionally violate GPL. They are just busily struggling to survive in these extremely fast moving markets and do not have time and resources to care for this kind of 'details'. This does not excuse it or embellish anything, but that is how organizations operate. If I cannot stay in business operating legally, my business model is wrong and I deserve to go bankrupt. Operating like this for several years is nothing short of criminal. Where is the respect for the authors of the original software in this discussion? -- 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 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? And any luck in finding a fix for it ? 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] Re: Allwinner GPL violations: definitive proof.
On Wednesday, February 25, 2015 at 3:55:25 AM UTC, 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. I'd be curious where all the law practitioners stand it this. Chinese earned their bad reputation by hard work, by stealing intellectual but not only properties. It's not a prejudice that everybody dislike them, those who do have a valid reason. Again, I'm curious, I mean, we get to see all this lawyers and their petty quarrels over billions of dollars all over in popular media.. those vs this vs them vs that vs slide button, etc. Personally I'd love to see AllWinner gets their products !banned for instance in the whole US. Would this not help? -- 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] sun7i - tslib and touchscreen calibration
Hi, I have build an image with eGalax driver touchscreen, the USB module is recognized. To calibrate it, I have used ts_calibrate with success. So, I have a pointercal file with the calibration datas. Now, I know there's some files to modify to apply the new coordinates: - InputReader.ccp - InputReader.h But how to modify them? I havn't seen any patch for sun7i, only for x86. Thanks -- 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.
fre 2015-02-27 klockan 00:04 -0800 skrev pelj...@gmail.com: Personally I'd love to see AllWinner gets their products !banned for instance in the whole US. Would this not help? The western world is a relatively small market for Allwinner. Their main market is China and related countries. Regards Henrik -- 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.
I think they couldn't post the source code because is not easy as we presume. Their hardware are rip off of other hardware implementations. So if they release the source code, the hardware companies can sue them. And it is a more serious business than a gpl violation bothering some few angry developers. I hope I'm wrong. Em quarta-feira, 25 de fevereiro de 2015 00:55:25 UTC-3, Luc Verhaegen escreveu: 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. -- 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: WLAN SBE error: any news?
Em domingo, 2 de novembro de 2014 15:38:55 UTC-2, Peter Mattern escreveu: Hello. Running mainline kernel from Arch Linux ARM on a Cubietruck I have to say the so called SBE error [0] makes the on-chip WLAN interface unusable. My findings strongly suggest there's some kind of load threshold: if only few data is transferred the link remains stable for hours. But the problem can reproducibly be triggered by larger amounts of data. If e. g. some large file gets downloaded, the error will always arise once the download has been going on for some seconds. That threshold seems to be slightly higher in 802.11n than in 802.11g mode. On a side note APs operating in 5GHz band can't even seem to be detected. But that's all I could figure out. I don't know if it is your problem, but maybe it helps: http://linux-sunxi.org/Cubietruck/AP6210 So I was wondering whether there's any news about this problem or even a workaround. Obviously I'd be willing to perform further tests but needed some advice on how to do this. Regards, Peter Mattern [0] https://groups.google.com/d/msg/linux-sunxi/NngIhT-ELVc/Q2pt3UdrE-sJ -- 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] sunxi: Add Wexler TAB7200 support
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 --- board/sunxi/MAINTAINERS | 5 + configs/Wexler_TAB7200_defconfig | 13 + 2 files changed, 18 insertions(+) create mode 100644 configs/Wexler_TAB7200_defconfig diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index 3e6ce88..53a9fea 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -130,3 +130,8 @@ TZX-Q8-713B7 BOARD M: Paul Kocialkowski cont...@paulk.fr S: Maintained F: configs/TZX-Q8-713B7_defconfig + +WEXLER-TAB7200 BOARD +M: Aleksei Mamlin mamli...@gmail.com +S: Maintained +F: configs/Wexler_TAB7200_defconfig diff --git a/configs/Wexler_TAB7200_defconfig b/configs/Wexler_TAB7200_defconfig new file mode 100644 index 000..6c15dc8 --- /dev/null +++ b/configs/Wexler_TAB7200_defconfig @@ -0,0 +1,13 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER,USB_EHCI +CONFIG_FDTFILE=sun7i-a20-wexler-tab7200.dtb +CONFIG_VIDEO_LCD_MODE=x:800,y:480,depth:24,pclk_khz:33000,le:45,ri:210,up:22,lo:22,hs:1,vs:1,sync:3,vmode:0 +CONFIG_VIDEO_LCD_POWER=PH8 +CONFIG_VIDEO_LCD_BL_EN=PH7 +CONFIG_VIDEO_LCD_BL_PWM=PB2 ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN7I=y ++S:CONFIG_DRAM_CLK=384 ++S:CONFIG_DRAM_ZQ=127 ++S:CONFIG_DRAM_EMR1=4 -- 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.
Re: [linux-sunxi] BananPro WiFi Module (ap6181) Problems
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? And any luck in finding a fix for it ? 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.
Re: [linux-sunxi] BananPro WiFi Module (ap6181) Problems
I had tried to address this some months ago which unfortunately didn't yield any response (https://groups.google.com/forum/#!topic/linux-sunxi/-GejF5r-HGg). In addition to the findings described in that posting bandwidth seems to matter as well. By limiting to about 200kB/s the problem was mitigated and sometimes ceased completely. Also, when many rather small files are transferred it starts later than it does while transferring one large file. What I said about testing still applies, too. -- 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] ARM: sun6i: dt: Add new Mele I7 device
On Tue, Mar 03, 2015 at 02:20:31PM +0100, Hans de Goede wrote:
Hi,
On 03-03-15 09:22, Maxime Ripard wrote:
On Tue, Mar 03, 2015 at 08:55:36AM +0100, Hans de Goede wrote:
+/ {
+ model = Mele I7 Quad top set box;
+ compatible = mele,i7, allwinner,sun6i-a31;
+
+ chosen {
+ bootargs = earlyprintk console=ttyS0,115200;
Using earlyprintk by default is a bad idea if the kernel is configured
with DEBUG_LL support for another SoC.
While on this subject, u-boot now sets the chosen/stdout-path property
up by default, which means that the kernel will do the right thing by
default. So we we really do not need any bootargs= in our dts files.
I just tested that this weekend, and it turned out that the kernel
couldn't use it so far (ie, no output until init takes over and setup
a TTY on ttyS0).
Was it working for you?
Yes, note that the kernel only honors the stdout-path property if
there is no console= argument present if there is a console= argument
present on the kernel cmdline then that will overrule the stdout-path
property
Yeah, I removed the bootargs entirely.
Which board did you test with, and what u-boot and kernel version ?
I tested it on my A31 hummingbird, with allwinner's u-boot, but with
/chosen/stdout-path hardcoded to serial0:115200n8, with a 4.0-rc1
kernel.
But it might very well just be me. We just tested it on a Marvell
board (that uses the same serial driver) this morning and it was fine,
so I don't think it's really worth worrying about this :)
Currently we've a random mix where we do have bootargs in some, but
not in most sunxi dts files. I believe we should simply remove it
everywhere...
We used to set them in SoCs that are not supported by U-boot yet, and
where the bootloader won't come and patch the DT (A31, A23, A80).
Ah, so that is (was) the logic, following that logic we should probably
remove bootargs= from at least the a23 and a31 boards (basically
from all boards but a80).
I'm not so sure about the A31, since most boards won't even boot by
default on the SD card, and we have no way to replace U-Boot in NAND
so far (afaik). But replacing them by stdout-path is a very good
solution too.
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] GSL1680 hex dump to C header: is it possible?
Care to give me an example syntax? On Tuesday, March 3, 2015 at 7:27:01 PM UTC+8, Priit Laes wrote: On Tue, 2015-03-03 at 03:18 -0800, Blake Gripling wrote: Saw that, and I even tried it myself, but as I said earlier the dumps fw_extractor produces is in the form of a raw binary dump instead of a C header as illustrated in the wiki. The driver project you linked to does accept dumps produced by the utility, but I'm also wondering about the possibility of converting it to another format. Quite possible that you already have this program in your system: man 1 xxd See the '-i' option ;) Päikest, Priit :) -- 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] GSL1680 hex dump to C header: is it possible?
Saw that, and I even tried it myself, but as I said earlier the dumps fw_extractor produces is in the form of a raw binary dump instead of a C header as illustrated in the wiki. The driver project you linked to does accept dumps produced by the utility, but I'm also wondering about the possibility of converting it to another format. On Tuesday, March 3, 2015 at 7:02:23 PM UTC+8, Al Thomas wrote: -- *From:* Blake Gripling blakegr...@gmail.com javascript: *Subject:* [linux-sunxi] GSL1680 hex dump to C header: is it possible? I was wondering if it is feasible at all to do a C header translation of a firmware dump I made from a working gslX680 module. Both the 3.3 and 4.5 SDKs use C headers for firmware in gslx680.c, and I'm not that up to editing them to read hex either. Someone has kindly created a good wiki page http://linux-sunxi.org/GSL1680 that includes a link to https://gitorious.org/gslx680-for-sunxi/gslx680-for-sunxi/source/c8a91b8290aca8cd5f1329292d53e8bfe88c7f68:firmware/fw_extractor -- 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.
