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