Posted today on Free Electrons blog.
19 years old intern in Free Electrons took the Cedrus reverse engineering of Allwinners proprietary CedarX video driver who is around since mid 2014 and made patches for mainline Linux kernel.
I’m sure we use these since they were made first available and they are build in our images, so I’m really puzzled why they have made their way to mainline just now and not earlier?
Isn’t it time Linux-Sunxi community to stop working on kernel fork and start to send all development and patches upstream like Rockchip developers do already for 2 years?
Looking at mainline kernel Rockchip has way better support now than Allwinner although Linux-Sunxi community to seem many times bigger than Rockchip community.
Rockchip devices are in many Chromebooks and Google push them to send all their work upstream to latest kernels.
None of newer Allwinner chips found it’s place in Chromebooks and this is the problem, for Android kernel 3.10 is enough and they will not move from it, neither they learn (or are capable to generate quality code) to upstream all work they do.
This is pitty as since A10/A20 we can’t see anything which to beat Rockchip as productivity.
RK3288 is mainline and although Cortex-A17 still faster than any chip Allwinner have.
Now Rockchip work to release their new super duper RK3399 (2x Cortex-A72 and 4x Cortex-A53) and again they upstream code before even selling the chip.
With two USB3 hosts this chip is good candidate for next OLinuXino 🙂
EDIT1: after the posting there were interesting comments from Chen-Yu Tsai (a.k.a. wens213) who point me that what Free Electrons did is not simple commit to already existing project but did from scratch v4l2 mem-2-mem codec driver! So I appologise for the underestimated efforts!
EDIT2: I admit that what I wrote about Linux-Sunxi repository was about Kernel 3.4 which I was using two years ago and which was developed “wild west” style. I was assuming as the repositories are still there this continues, but I was wrong!
Our boards are with A10/A13/A20 and have mainline support, so I didn’t followed closely what happens with Linux-Sunxi lately.
Chen-Yu and Siarhei explained that this repo is kept there for historical reasons and now all development is focused to upstream too! Good to know 🙂
At Linux-Sunxi there is very clear table about what is done ( light green) and on what is working (ornge)
olimex 
Aug 30, 2016 @ 15:04:12
You seem to have mixed up a few things:
1. From Free Electrons post: “During the past two months, Florent Revest, a 19 years old intern at Free Electrons worked on a mainline solution for this Video Processing Unit. His work followed the reverse engineering effort of the Cedrus project…” This is a “from scratch” v4l2 mem-2-mem codec driver, not the Allwinner solution.
2. Linux-sunxi is not affiliated with Allwinner. And we do plenty of mainline work. You should ask why Allwinner themselves aren’t doing it. Rockchip and Mediatek got pushed into doing mainline by Google.
Aug 30, 2016 @ 15:16:28
thanks for the clarification about the 1. about 2. I know linux-sunxi is not affiliated with Allwinner but isn’t it better development to be done upstream instead in separate kernel fork, this way at least will restrain everyone to touch and break like now is in linux-sunxi kernel, something we compile in the morning and work is broken few hours later by someone, then fixed again few more hours by other. I do remember backlight of LCD issue – one set the driver to work with positive level to eneble it, then few days later someone got LCD which is driven with negative level and push his changes in the kernel and broke all other who have LCD with positive level enable etc etc many examples could be quoted 🙂
Aug 30, 2016 @ 15:58:36
If you haven’t noticed, linux-sunxi (the GitHub repo) is in maintenance mode. Only the sunxi-next branch gets updated often. This branch tracks whatever mainline -next progress we’re making (and either me, Maxime or Hans noticed and bothered to pick). It is not an official branch. The remaining 3.4 branches are, as I said, in maintenance mode. They will probably never get any features.
Mainline support for Allwinner SoCs has seen quite a lot of progress:
http://linux-sunxi.org/Linux_mainlining_effort
A lot of it thanks to NextThingCo and Free Electrons doing the more complicated drivers. But we’ve also gained some new active developers. And since it’s mainline, you can always use the latest release, -rc, or even use -next.
So, what features are still missing for you guys? If someone skilled finds it important and has the time, they might work on it.
Aug 30, 2016 @ 16:53:40
Probably you have noticed that we have not released new Allwinner boards for a long time.
We have skipped A31, A31s, A23, A80, A83T, H3 as we didn’t like them, we spent some efforts on H3 but give up on chip which overheats 20-30C above ambient temperature, this is just no go for our customer.
Now are are about to release A33 which behaves well and A64.
A33 has no mainline support for Audio, NAND, SPI, 3D graphics and video acceleration are not interesting for our type of customers – industrial apps which require reliable 24/7 work and has no fancy 3D graphics, just some buttons on menues, which work fine without any hardware acceleration at all.
A64 support is very preliminary.
Aug 30, 2016 @ 17:08:07
3D graphics is probably the part which is least controllable, as it depends on ARM / Allwinner giving out working blobs along with kernel drivers that work with the latest kernel. There might be some hope, though I’ve not looked into it.
Maxime is experimenting with display in his spare time. Given that the display pipeline is nearly the same (and maybe even simpler) as the A13/R8, it should be a straightforward port.
A new developer has expressed interest in A33 NAND (even sent DT patches) and audio.
I don’t know about SPI, but given the hardware is always the same, it could be that
no one has the hardware to port and test the existing drivers.
Aug 30, 2016 @ 17:41:24
> we spent some efforts on H3 but give up on chip which overheats 20-30C above ambient temperature, this is just no go for our customer.
Xunlong makes a range of some decent and very cheap Allwinner H3 boards, which do not overheat and for some unknown reason are much better than any competitors (maybe there is some secret trick or know-how): http://forum.armbian.com/index.php/topic/1351-h3-board-buyers-guide
Too bad that they are not OSHW. Still it would be very difficult for Olimex to make an Allwinner H3 board, which could successfully compete with Xunlong.
Aug 30, 2016 @ 17:50:52
I also read about this and specially ordered Orange Pi PC and Orange Pi plus to compare to our H3-OLinuXino-NANO, both overheating as any other H3 boards, maybe they sent to Olimex overheating boards to deceive us 🙂
It’s weird as I suspect A33 and H3 are same chip just with enabled/disabled this or that feature. A33 behaves same as A20 no overheating at all, while H3 is little oven
Aug 30, 2016 @ 17:55:33
> Now are are about to release A33 which behaves well and A64.
A33 has no mainline support for Audio, NAND, SPI, 3D graphics and video acceleration are not interesting for our type of customers – industrial apps which require reliable 24/7 work and has no fancy 3D graphics, just some buttons on menues, which work fine without any hardware acceleration at all.
I personally don’t like A23/A33 because of their very narrow 16-bit DRAM bus width. An extremely weak memory subsystem is probably going to be a performance bottleneck for a quad-core processor. But this depends on a workload. A weak memory bus is definitely bad for anything graphics or multimedia related. But simple IoT workloads are probably perfectly fine.
Another reliability concern is the A23/A33 DRAM initialization support in U-Boot because the A23/A33 code is a quick and dirty copy-paste from the Allwinner’s implementation without even trying to understand how it works or even stress test it. Only A10/A13/A20 and H3 are decently supported as far as the DRAM controller is concerned.
As wens213 said, the SPI controller is exactly the same as in the other Allwinner chips (there are only two variants of it: sun4i and sun6i). It should be pretty easy to make it work on A33 if anyone tries to do this work.
Aug 31, 2016 @ 08:59:55
Sad to hear that you stopped development of your H3 boards. Anyway: based on my testing the H3 heat issues are either related to overvolting (using OS images from Orange Pi forums since with wrong cpufreq governor settings H3 will be fried constantly at 1.5V), choosing Allwinner’s u-boot vs. mainline (with the latter at least the internal SoC temperature reported will be 10-15°C lower) and/or something depending on DRAM config and clockspeed (at least with NanoPi NEO with a single bank DRAM configuration both board consumption and temperature differ a lot when switching DRAM clockspeed between 672 and 408 MHz — the lowest ‘sane’ clockspeed according to Allwinner’s BSP kernel sources). Also this device deadlocks pretty fast with heavy loads anyway so we decided to limit cpufreq to 912 MHz here (remaining at 1.1V VDD_CPUX)
I let a Banana Pi M2+ (also H3) run for over 130 hours by accident with lima-memtester and got constant temperature readouts above 90°C (mainline u-boot so maybe even +100°C with Allwinner’s u-boot). This board still works fine (now offloading CPU-intensive tasks from a Lime2 🙂 ) but of course this is no real longevity test.
And as soon as you come up with a quad-core A20 successor board H3 isn’t that interesting any more to me anyway 😉
Aug 31, 2016 @ 10:34:11
Thomas, I hope you understand that having temperature -10/15C lower than 60-70C for board running at room temperature is not reliable solution! Our customers do not use our boards to watch video, but for controlling machines, some of them pretty expensive, these boards should run reliable 24/7 without glitch as downtime cost hundreds times more than board cost. This is the difference between OLinuXino and others. We continually improve them and remove any chance for problems. To run board at room temperature heating to 90-100C and to say – yes I have one board which work XXX hours means nothing. The machines may work at 50-60-70C ambient temperature. Right now A13 and A20 do not overheat more than 1-2C above room temperature. A33 does the same. You can never convince me to use H3 for anything reliable if it heats up 20-30C above ambient temperature.
Aug 31, 2016 @ 11:49:28
Well, you should question the thermal results you get with or attribute to A13/A20. There is one simple test I always make with SoCs without heatsink applied. Put my thumb on the SoC for a minute and watch thermal readouts: http://pastebin.com/B9SzsR4c
Pressed my thumb on totally idle A20 on ~08:39:16 and immediately my thumb, the large heatsink operating at 37°C temperature, cooled down A20. Ambient temperature is ~25°C so A20’s SoC temp is the usual 15°C above ambient.
Please note A20 temperature readouts are AFAIK still not calibrated and that we had a funny situation with 4.0 or 4.1 kernel when thermal readouts for A20 went upstream that A20 reported temperatures way lower then ambient temperature and even below 0°C. That’s the reason why I will never again trust any thermal readouts (it’s always just a sensor feeding an ADC, producing bits, interpreted — wrongly? — by a driver). And the thermal sensor in A20 is there by accident and not by design as in every later Allwinner SoC since unlike with A10, A13 or A20 now overheating protection is necessary (and I would suppose A33 is affected as well)
Aug 30, 2016 @ 15:25:28
If Rockchip SoCs are so well supported in mainline kernel, make an instruction how to use kernel 4.7 and mainline u-boot on Olimex RK3188-SOM 😉
Aug 30, 2016 @ 15:42:17
It should be not hard, but having so many boards, to maintain latest and greatest and to do 100% test require at least 2 man weeks efforts per board. I will put it in our long TODO list 🙂
Here is guide which Tom Cubie made for Radxa RK3188 board:
http://radxa.com/Rock/Linux_Mainline as you can see:
git clone -b stable –depth 1 git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
a little bit tweaking of device tree to match our board and extensive testing of all peripherals is what is need.
Aug 30, 2016 @ 16:01:52
> I know linux-sunxi is not affiliated with Allwinner but isn’t it better development to be done upstream instead in separate kernel fork,
I’m not sure what you are talking about. All the kernel work is happening in the mainline since a very long time ago. The old 3.4 branch has not seen any updates for more than a year – https://github.com/linux-sunxi/linux-sunxi/commits/sunxi-3.4
Nobody is really doing any work on the 3.4 kernel branch anymore.
> this way at least will restrain everyone to touch and break like now is in linux-sunxi kernel, something we compile in the morning and work is broken few hours later by someone, then fixed again few more hours by other.
Could you please elaborate? What kind of “linux-sunxi” kernel is this?
Aug 30, 2016 @ 16:31:22
https://github.com/linux-sunxi/
I speak for my past experience with 3.4
Aug 30, 2016 @ 16:44:54
> I speak for my past experience with 3.4
Okay, I guess that a description of your experience from 2 or more years ago is just here for a purely dramatic effect. But it’s 2016 now, and I believe that blog readers would prefer to have an up to date information rather than what looks like an obviously ridiculous nonsense or even slander.
Aug 30, 2016 @ 16:47:48
this is not intentional ! and this is why you are here to correct me 🙂
Aug 30, 2016 @ 20:38:56
Tsvetan, maybe add an EDIT note to the original article that the development nowadays happens upstream 😉
Aug 31, 2016 @ 08:19:12
definitely! I update the post
Aug 30, 2016 @ 16:15:56
Just to note, there is work-in-progress support for mainline uboot as well at https://github.com/mmind/u-boot-rockchip/commits/tmp/rk3188 . The SPL part is not working yet but it is possible to build bootloader images similar to what barebox does http://www.barebox.org/doc/latest/boards/rockchip.html
Aug 30, 2016 @ 16:21:13
And for comparison, with Allwinner chips you just go and take the latest upstream U-Boot from http://git.denx.de/?p=u-boot.git;a=summary
There is no need to use custom third-party branches or forks.
Aug 30, 2016 @ 19:12:13
This kind of miscommunication is very unfortunate. Everyone is working in the spirit of openness and is doing their absolute best, but details of progress aren’t very visible and so incorrect impressions are gained.
Perhaps the answer is to improve public visibility, because the whole world can’t be expected to stay in touch with a team’s progress by reading commit logs.
In this particular case, how about adding a small but prominent “News and Status” section to the front door of the wiki at https://linux-sunxi.org/Main_Page , in which you link to another page that provides full details. It needn’t be a heavy burden, just a progress update every couple of months would be sufficient to keep everyone up to date with project status.
Morgaine.
Aug 30, 2016 @ 19:40:06
I don’t know how up to date this is, but the list mentioned in the comments above seems pretty detailed and has per SoC and per Linux version info:
https://linux-sunxi.org/Linux_mainlining_effort
Aug 30, 2016 @ 19:53:47
SK: I love the Status Matrix on the page you linked. Since the key info on mainlining status seems to be summarized there already, and very nicely presented, front-page news items about progress can often just be one liners for even less communications burden.
Sep 01, 2016 @ 06:15:07
cubieboard2 is made with A20. that soc is dual core cortex-A7. soc mask is 55 nm. A20 is hot, default speed is 912MHz and at normal work (no graphic, i run it headless), i must force myself to not remove finger immediately when i thy finger-test-tempetrature. software report A20 reach 75-76 Celtius degrees when under load.
i tried radxarock RK3188 and that soc is fine because it has 28nm.
few days ago I got nanopi-neo board (H3 soc). the board is great due her low price (8 USD for 512MB, H3 and 36 GPIO in only 40x40mm). NanoPI-neo is GREAT to me because of little size, but H3 – despite is 28 nm – is too much hot even if i activate all “dirty tricks” to reduce hotness (turn off cores, reduce ram clock, reduce ethernet from giga as fast, etc).
Now: NO FAN, NO PASSIVE HEATSINK is my must.
olimex planned board with RK3399 attract me, but i am afraid it will be too much hot despite they are done at 28 nm. i will follow with attention olimex post looking for update.
Sep 01, 2016 @ 08:38:56
productivity has it’s price 🙂 if you want low power use A13-OLinuXino it will never overheat but single core at 1Ghz with large board which acts as heatsink
Sep 01, 2016 @ 13:57:40
> i tried radxarock RK3188 and that soc is fine because it has 28nm
RK3188 is a quad Cortex A9, right? Please try to run https://raw.githubusercontent.com/ssvb/cpuburn-arm/master/cpuburn-a9.S on it as a peak CPU power consumption test and report back the results.
Sep 01, 2016 @ 18:04:59
@nano: to be honest, I don’t know what’s wrong with the NEO but I agree that NEO has thermal troubles (not only caused by SoC configuration but also cheap SBC components): https://github.com/Fourdee/DietPi/issues/477#issuecomment-243807726
But this here is a H3 device (NanoPi M1 running 4.7.2 http://pastebin.com/jyGmeQcu ) lying next to an A20 device (Banana Pro running 4.6.3 http://pastebin.com/B9SzsR4c ). I used the very same thumb (the right one, operating normally at approximately 37°C) to act as heatsink: from 46°C idle down to 43°C with thumb applied. Feels reasonable (warm, does not hurt).
We already know that for whatever reasons NanoPi M1 overheats more than the small H3 Orange Pis using the same voltage regulator with same settings so we’re talking about H3 idling at 46°C vs. 40°C. If I would’ve tested with an Orange Pi (none available any more without heatsink) we would talk about even lower temperatures. So I really don’t know what’s going on here (except that we’re badly hijacking the wrong blog post).
@Tsvetan: have to set up a new mail server and get back to you then 🙂
Sep 01, 2016 @ 18:31:51
PCB size is very important as BGA heat is sink via the ground vias to ground plane which acts as big copper heatsink,
You can try to put and remove aluminum heatsink on top of the BGA and will notice that there is just few degree C difference i.e. the heat do not dissipate upward but downward through the metall BGA balls more than via the epoxy plastic BGA package
We did few tricks to improve the heat distribution like bigger via holes plugged with solder, adding additional ground layers etc, and got almost same temperature as the Orange Pi PC which is similar to H3-NANO, but again this is useless for demanding computing. I suspect something is done wrong inside H3 to be so heat dissipating. This internal PHY for instance may has some internal LDOs which to cause these troubles.
What we will try next is RK3128 which is with same specs and price as H3 and if it doesn’t overheat so much as H3 we may make RK3128-NANO.
Sep 07, 2016 @ 00:19:29
This is reply to Olimex…
AFAIK one of major reasons of H3 heat is the fact most boards go for oversimplified cpu Vcore regulator and therefore do not implement DVFS at all. So voltage-freq scaling just does not happens on most boards. Merely downclocking cpu core at high Vcore voltage makes only small difference in heat. Allwinner decided to make it cheap so it usually does not comes with a decent power manager companion IC capable of doing DVFS right (it requires fairly complex cpu to regulator interaction as well as proper software support of these tricks, since regulator and cpu core have to play as team). Not to mention it req’s smart regulator IC capable of adjusting at least Vcore voltage on the fly.
Then H3 is clearly overrated in its frequency abilities. In most cases it should run on lower freq, using lower voltage. This gives nearly quadratic (if not cubic) downscaling of heat dissipation & power usage and one could bring it to sane limits fairly easily by putting appropriate freq/voltage limits. Which would obviously impact performance.
Sep 01, 2016 @ 13:59:48
> if you want low power use A13-OLinuXino it will never overheat
Just try https://raw.githubusercontent.com/ssvb/cpuburn-arm/master/cpuburn-a8.S on it and measure the current draw and SoC temperature 🙂
Sep 01, 2016 @ 17:07:09
The table you mention at the bottom of the post is unzoomable/unclickable. Can you add the source of it? or a link? or a better resolution?
Sep 01, 2016 @ 18:50:07
https://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix
Sep 06, 2016 @ 23:52:49
> Isn’t it time Linux-Sunxi community to stop working on kernel fork
They already do!! Though since Allwinner is rather uncooperative and also Allwinner got no even slightest idea how to do kernel drivers right, all efforts are entirely community-driven and performed on “best effort” basis. It is real shame Allwinner failed to join these efforts properly, unlike many other SoC MFRs. And, honestly, we all should show our appreciation to work Linux-Sunxi devs do. Their work is just plain amazing granted it is unpaid volunteer efforts, not something from Allwinner, etc. Allwinner somehow things their shitty 3.x kernels are way to go. Which is really unfortunate, since their kernels are actually outdated crap.