[Mini210s] Creating a fully open source kernel

Hi all,

Did someone build a fully open source kernel for Mini210s / Tiny210 the
same way buserror or Juergen did for mini2440? I'm working on this subject
alone for the moment: I'm using the FriendlyARM 3.0.8 linux kernel and
trying to replace all closed source drivers with open source ones. Next
step will be porting all the drivers in a vanilla kernel.

I'm actually working on the audio part; I took mango310 sound driver and
integrated it in the FriendlyARM kernel in place of the provided driver.
The compilation is working fine, but during boot I get an error saying
"samsung-audio" is already registered. No entries are created in /dev.

As I'm not an expert, I would need help.

nope, no one built a fully opensource kernel for the 210 boards, it's not
possible.  You'll never get the source for the graphics drivers.

As for the audio, I'm not sure what you're porting there but the audio is
already open.

Damned, I completely forgot this graphics driver problem. Do you know where
are the closed source drivers located in the kernel tree ?

For audio, I'm using the driver of mango310 board from www.mangoboard.com
They have a mini210 based on S5PV210 and WM8960. The mango310 uses a newer
kernel but it is based on an Exynos4210.

Erm, the closed source drivers aren't really in the tree as such, I'm not
sure entirely how it works but they probably lifted them from the samsung
binary blobs for android.  And that's entirely why we're stuck with 2.6.35
and 3.0.8.

This is such a pity and wasted opportunity to sell a good piece of
hardware. It forces one to look at alternatives such as the BeagleBone and
not so humble Pi. Undoubtedly there will be a plethora of such alternatives
 with open source software in the near future.

but the pi also has closed source gpu, you're bound by whatever the pi
foundation/broadcom actually release, so whilst it seems open it's still no
more open than a mini210.  most of the manufacturers of arm chips don't
release the gpu source code.

@Reggie:
If I understand what you mean, the GPU drivers are included in the
FriendlyARM stock kernel, but if we compile our own kernel from the DVD
sources, we have no more GPU acceleration ?
I thought they did the same trick as for the NAND driver, touchscreen and
so on.

I don't know why mainly all chip makers don't release drivers for GPU, I
don't see anything strategic in that. I thought Samsung provided it and was
looking at the Odroid XU from hardkernel. I know Freescale opened the specs
of its iMX6 chip, I'm also looking at the Zealz GK802 on another side. But
I would prefer a Cortex A15 based board and as far as I know, there is no
A15 chip in Freescale's offer.

Anyway, GPU acceleration is not necessary useful to anybody, maybe it can
be interesting to have an updated kernel with opensource drivers, but
unfortunately without acceleration? Mainly for Linux designs, ubuntu/debian
etc.

What do you think about that?

@Reggie : I'm interested in your solution to make the WM8960 work, mine is
not so easy as I thought and my skills are too limited.

Hi Screwface,

> I don't know why mainly all chip makers don't
> release drivers for GPU,

Simply license issues. The GPU core is just an IP Core bought by Samsung
and added to their SoCs. Same for TI, Freescale and so on. The GPU vendors
define the license. Not the SoC manufacturers.

> I know Freescale opened the specs of its iMX6 chip,

No. Where do you have such an information? Perhaps you mean AMD here, which
is the GPU vendor for the i.MX6 GPUs. And yes: AMD *started* to puplish
their GPU documentation. But until now it is far from being helpfully.

Hi Juergen,

Maybe I was a bit fast in my sentence, thank you to correct me. But I still
don't understand this principle. Even if the GPU vendors put the drivers
for their GPU under GPL, SoCs maker would need to buy the license to get
the schematics and all stuffs to integrate the GPU in their SoC. I don't
see what they try to protect by keeping their drivers closed. Maybe they
fear reverse engeneering from competitors, they could imagine how the GPU
works and develop same new technologies/principles on their own GPU?
Graphics battle is more important on mobile phone segment I think.

I don't know exactly where I read that Freescale provided information about
i.MX6, and maybe "opened the specs" is not the right way to say it, to be
precise. Here is what I just found, searching the information again.
 
http://liliputing.com/2013/03/ubuntu-for-the-gk802-mini-pc-now-with-hard...

Hi Screwface,

yes, there is some open source activity around the i.MX6 GPU. But it is
always the same. The available documentation describes a more recent GPU
core and the i.MX6 comes with an older core. Not that trivial and still
needs a lot of reverse engineering.

So there is no way to have a full open source low power and powerful board.
We are stuck at the Arm11 step or we can't get any GPU working if not with
the stock kernel...

But maybe you can answer my previous question : board suppliers deliver the
kernel sources with it, in our case 3.0.8 for mini210/tiny210. There are
some already compiled modules with it. Is it the same thing with GPU? I
can't find them. Or should I understand that if we compile the kernel by
ourselves we loss the GPU acceleration?

http://lxr.free-electrons.com/source/sound/soc/codecs/wm8960.c?a=arm

That's my solution screwface :-)  You'll notice along the top there is the
kernel version number, just check and see if it's available for the kernel
you want to produce.

Yes Reggie, I know there is already a WM8960 codec in the vanilla kernel
tree. But I assume you need to use a driver which refers to it, right?
Something like that but for WM8960
http://lxr.free-electrons.com/source/sound/soc/samsung/smdk_wm8580.c?a=arm

This the kind of file I took from mango310 board. It compiles fine, the
codec is detected by the kernel but there are no entries in /dev directory.
Madplay plays sound put it seems it is very slow. And if I try to play
sound with Qtopia apps, it reports an error, maybe because of the missing
entries in /dev.

if you want the 8960 driver, use the 8960 driver :-D  Alsa etc. will figure
everything else out for you as such, if not then you can use the existing
kernel+driver to figure out what needs setting.

I doubt that there is much in the way of a difference and tbh, I suspect if
we kick up enough they may actually give us the audio driver anyway, *IT's
NOT* closed source ;-)

you do know that the wm8960 is an external chip?

Of course I do!
In fact, as my knowledge is very limited in kernel programming and all that
stuff, I tried to imitate FriendlyARM with some public files. That's why I
search for a board using the same audio chip, if possible on the same SoC
to prevent from incompatible kernel or compiling errors.

I'll try to look at the alsa side, I have to say I understood your
explanation but I do not know how to do it. And I also don't know why the
different approach I mentionned before exists. There should be some
differences, but which...

in theory there shouldn't be any differences, it's an external chip, it is
what it is and does what it does.  you many need to go through the kernel
to look for power supply related things but if it's coming up and telling
you it's already allocated, then some other driver must be grabbing it.

Essentially, any register settings etc. can be grabbed dumped and grabbed
from the original kernels, the driver source code might or might not change
but the registers never will.

Hi Screwface,

too many GPUs around me. Sorry, the vendor for the i.MX6 GPU is Vivante.
And there is still no open documentation available.

Hi Juergen,

So you mean the persons who develop ubuntu images (for example) with
partial hardware acceleration do it by reverse engineering closed source
drivers?

Screwface,

Ubuntu on ARM or INTEL?

Closest I've seen:
http://home.g8.net/index.php/articles
http://www.rikomagic.co.uk/forum/viewtopic.php?f=13&t=5135

http://lists.phcomp.co.uk/pipermail/arm-netbook/

Spent a few hours reading through this and haven't been back to it for
months.

My conclusion is that there is a lot of reverse engineering going on to
even get video to work on ARM platforms, let alone hardware acceleration.

Only my 2 cents worth!

Dave

http://www.gplsquared.com/eoma_boot/eoma_boot.html#Ubunt_13_04_3D

and go to the bottom of the page.  Looks like somebody is putting in quite
a bit of effort!

Terminology
Opengl is a graphics lib, but a lot of it is proprietary despite wanting to
calling itself open, opengl ES is a cut down version for embedded CPUs, and
mesa is the 'real' gpl'd version of opengl.
What is working is the cut down opengl ES. So if the software requires
opengl or mesa then it may not work. If it can use opengl ES then it can
work fairly well.
If software can use emulation of opengl, then that too will work, though it
will be slow. Software rendering has advantage that it works over X/ssh
tunnel.

Hi Davef,

I talked about i.MX6 ARM SoC. You can find some articles here
http://liliputing.com/2013/03/ubuntu-for-the-gk802-mini-pc-now-with-hard...

or here
http://jas-hacks.blogspot.fr/2013/03/gk802-ubuntu-update-1-gpuvpu.html

I read the 1st link when you first posted it.  The comments and lack of
current comments didn't inspire confidence.

On the 2nd link comments dried up back in July.  Any reason?

I don't know why, maybe because there are not so much people interested in
running Linux on TV sticks? I assume buyers only buy it to have stock
Androïd running and use this stick the way it was designed for.

By the way, I also hesitate to buy as there is nothing really public, I did
not search deeply but I find no git trees to modify the kernel /
distribution by yourself

I was under the impression there were a lot of people trying to run Linux
on these sticks.

http://www.slatedroid.com/topic/70505-mk808rk3066-linux-system-image-pic...

etc 

Also, http://www.cnx-software.com/ is usually a good source of what's
happening in the embedded world.

Yes, but there are so many sticks. I don't know in fact. So maybe I'll wait
for A15 based sticks, maybe for christmas? But the problem is Freescale has
no A15 chip and I don't think there will be anything relased in a few
months. And the problem will be the same with Rockchip, Allwinner etc. A15
chips...

It's a bit like if nvidia released drivers for it's GPUs for the current
Windows version and do not release any updated driver fot the next Windows
version.

Hi Screwface,

> So you mean the persons who develop ubuntu images (for example)
> with partial hardware acceleration do it by reverse engineering
> closed source drivers?

We believe they just made the binary blob working somehow. Thats all.

What do you call the "binary blob" ? Is it some kind of compiled driver
module ?

Screwface. Yes, much like a module. Binary that is included in building the
kernel. They all have it because they get their graphics IP from people who
specialize in graphics and they require NDA and full secrecy. There is big
money in having the fastest graphics for gamers and heavy number crunchers,
commercial video rendering, etc.

I think we should look at the Linaro tool chain for better floating point
and other ARM specific hardware support.

I'm not entirely sure it's even supplied with the kernel sources like the
friendlyarm nand driver which is a binary blob (or at least it was  :-D), I
believe the graphics drivers that we have have come from images of phones
that use the same chip, i-9000 or maybe 9001, which is why we are stuck on
kernel versions 2.6.35? which is gingerbread and 3.0.8 which is Ice Cream
Sandwich.

As far as I understand things, we don't need to build the kernel with the
blobs in the kernel sources, so I'm not even sure they're usable in linux? 
Has anyone tested glxgears?

I've never actually seen any discussion on how you could or whether it
would be possible to actually ask samsung for updated blobs?  It's never
like 99% of people actually need the source code, all we need are updates. 
I wonder if it's possible to look at other targets that have the same
graphics hardware and leverage newer binary blobs/kernel versions that way?

Clearly it would need some transplantation of drivers from what we have but
I wonder if that's a viable path to try and head down too?

I wonder the same thing. I looked at other S5PV210 based boards and for
what I saw, they mainly come with the same kernel versions as our boards.
For some other boards, I found no download link so I could not find any
information. But should we look at S5PV210 based boards only, or any SoC
with SGX540 GPU is ok?
Another idea could be trying to contact Kukjin Kim who is the maintainer of
SMDKV210 board in samsung. Maybe he could give some advices or have
information about this topic?

I would like to hope that there would be a path through other CPUs that
have the sgx-540 hardware on them.

And yes, contacting the maintainers is about the best we can hope for.

Screwface,

did you already read http://powervr.gnu.org.ve/doku.php ?

Another nice comment (on https://github.com/laanwj/etna_viv/wiki):

"[...] (Avoid Imgtec PowerVR like the plague if you're building an open
source SoC. Not only is Imgtec actively hostile towards open source, their
GPUs have a crazy HW architecture even they have problems building stable
drivers for)"

so, realistically, unless there's some stuff we can pull from pandaboard,
then we're stuck on 3.0.xx kernels we should be able to do something with
3.0.31 and upgrade to jellybean so that might be a little help.

https://android.googlesource.com/kernel/samsung/+/android-samsung-3.0-jb

https://android.googlesource.com/device/samsung/crespo/

https://android.googlesource.com/device/samsung/crespo4g/

in fact, panda kernels appear to go to 3.0.72, so we know the powervr
driver should in theory be good up to at least there.

@Juergen : I knew your first link, but didn't look at it deeply as it is
mainly for TI SoCs. I tried to look at the SDK to see if it was possible to
find something interesting for our Samsung SoC.
The sentence you point at with your second link is not to make us feel
confident...

@Reggie : I looked on realv210 and mango210 side, they seems to have 2.6
kernel only, maybe 2.6.35. The problem is we can find many Exynos boards
with newer kernel, but GPU is Mali on those SoCs.
I wondered why nobody tried to port JB on the mini210/Tiny210 platform.
Should I understand it requires a kernel upgrade and as we have no GPU
driver for a higher kernel than 3.0.8, it is not possible to have HW
acceleration in JB ?

I also looked on Google Nexus kernel, and it seems to be also 3.0.72. It
seems to be the kernel of Android 4.3, so as you said, it is the most up to
date release we can reach.

> I knew your first link, but didn't look at it deeply as it is
> mainly for TI SoCs.

Sure. But the OMAP4460 comes with an SGX540 GPU as well. I assume they have
the same problem.

Of course, are the interface the same, is there something HW dependant or
not? That's the question I had. Now I understood it should be the same. A
bit like to PC world, a same GPU uses the same drivers on an Intel or AMD
platform.

The question I have now is where are those drivers located and under which
form in the kernel tree.

I don't think there's such a thing as a google nexus kernel per say, it's a
generic samsung kernel, which as far as I could tell goes to 3.0.31, the
panda ES kernels in android seem to go to 3.0.72, the panda ES omap chip
uses the same SGX540 gpu as the samsung s5pv210 chip, so I'm hoping that
they are entirely the same and it's just a question of the headers needing
to match.

wow, this is getting a bit circular :-) the gpu drivers are mostly NOT in
the kernel sources, its a binary blob, there might be some headers and you
build against those + the binary but that's going to be about it.

Google Nexus is an OMAP based device. Kernel is the same as PandaBoard.
(http://source.android.com/source/building-kernels.html)
That's why it is also 3.0.72.

The discussion is not circular Reggie, I understood the fact that the
drivers sources are not in the kernel tree. I understood they are some kind
of compiled binaries called binary blob. But as we got the kernel from
FriendlyARM, those binary blobs should be somewhere in the kernel, to allow
users to compile their own kernel, isn't it? So I wonder where are they
located. It would help me to understand and know what I have to search
for...

I wanted to understand this GPU drivers/binary blob things, so I made a
diff between the 3.0.8 kernel coming from FriendlyARM (FA) and the 3.0.8
vanilla kernel coming from kernel.org.

Wow, I didn't expect so much differences! Now it seems to be clear to my
eyes that FA got the kernel directly from Samsung (maybe SMDKV210 one?) and
made some modifications inside : there are many files in coming from
Samsung or Google in FA's kernel which are not present in the vanilla one.
I initially thought they took an original kernel, made some modifications
and added some drivers provided by Samsung...

What catches my attention is the fact that in the documentation directory
also, we can find a few differences. Maybe it was release candidate kernel?

But what I discovered is we can find some Imagination Technologies files in
FA's kernel which are not present in the vanilla one also. Mainly the pvr
folder in drivers/gpu. But I assume it can not be so easy as Imgtec doesn't
release GPL drivers...

Creating an upgraded kernel won't be as easy as for mini2440 with such a
sophisticated SoC, and it is clearly out of my skills. Maybe applying
vanilla patched to update FA's kernel could be an option, but one more
time, I'm not sure it can be so easy with alle the modifications already
made.

PS : I also noticed a FriendlyARM.cpio in scripts folder, does anyone know
what it is ?

Hacking a kernel until it does something useful on the hardware is what
many vendors do.

FriendlyARM.cpio -> maybe a base for an initrd

It was getting circular because we'd discussed this, the binary blobs that
we get are supplied via the samsung nexus S phones (i-9000 and a couple of
others I believe).  so the binaries that are supplied are ostensibly for
Android and I'm not sure whether they're tied to specific kernels or not
but the kernel sources were originally made for phones too, so any updates
to those kernels and drivers would ultimately rely on updates to the
phones.

The imgtec files that you've found are undoubtedly going to be headers and
perhaps an api to allow us access to the internals of the binary blobs.
Those binary blobs are more likely to be in the rootfs than the kernel
sources, or they could be (most likely are) in the android sources.

Ok, it is clear to my mind now. Thank you and sorry to make you explain
again, but I didn't understand everything until now.

I'll try the FriendlyARM Ubuntu / Debian versions to see if there is
hardware acceleration or not. I fear I'll destroy my actual system for
nothing but after that, I'll be sure.

It shouldn't destroy anything, there's no reason it should :-)

I finally found time to test graphics under Ubuntu. I managed to get
glxgears working, but it used software rasterizer. The test ran about 14,5
fps. (Out of the topic, I discovered the Ubuntu version is an adapted OMAP
version, maybe from pandaboard or something similar.)

But reading some posts, I'm not sure it is the best way to test if there is
hardware acceleration in Ubuntu or not. I've seen glxgears used OpenGL
which is not supported by SGX540 which supports OpenGL ES instead.


http://www.raspberrypi.org/phpBB3/viewtopic.php?f=2&t=5751
http://forum.odroid.com/viewtopic.php?f=9&t=1607&hilit=glxgears

indeed, the mini210s is not using open GL, so glxgears is not the right
thing to use to profile graphics acceleration on the 210 chips.

I tested today with es2gears and glmark2-es which are respectively an
openGL ES equivalent to glxgears and a graphics benchmark. The answer to
the previous posts question is there is clearly no hardware acceleration
provided out of the box on ubuntu. Mesa library is used instead of a
potential SGX driver. If I find time, I'll try on FriendlyARM's Debian
distro.

On my side, I contacted imgtec but with no particular hope. And the answer
was as expected: they are not able to provide driver binaries for their
customer’s platforms.  The user-mode part of the driver is closed and only
provided in binary form, the kernel-mode source is distributed under a GPL
license by many of their customers. We are suggested to contact Samsung
directly to see if they can share the kernel-mode driver source with us.
The person stated that even if we can get the kernel driver source, he
suspects that a significant amount of work will be required to get it
working with a newer Linux kernel.

Next step is trying to contact Samsung and see...

 
On the other hand, I'll try to look at the pandaboard side, I know they use
ubuntu / Linaro. I don't know if they have HW acceleration or not, and with
which kernel

 
http://omappedia.org/wiki/PandaBoard_FAQ#What_will_Graphics.2FGFX_suppor...

https://groups.google.com/forum/#!topic/pandaboard/WUnMJ3SC1sw