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 onto the LCD pins too. Consider this -- take existing high volume tablet boards with LCD connectors. Now reuse those boards in embedded applications without LCDs. Program the pins on the LCD connector to expose all of the peripherals. I'd buy a bunch of tablet boards right now if the LCD connectors could be reconfigured that way. We'd just run a FPC cable over to another PCB with our application specific hardware on it. On Wed, Mar 4, 2015 at 8:35 AM, Simos Xenitellis <[email protected]> wrote: > 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_item&px=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 [email protected]. > For more options, visit https://groups.google.com/d/optout. -- Jon Smirl [email protected] -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
