Re: The choice of OS of the new QWERTY device project
 

That from your mouth is very encouraging, we'll see then :)

Re: The choice of OS of the new QWERTY device project
 

That definitely helps!! And thank you for your information!

To make sure I understand correctly, so Fremantle is the last development on a mobile ARM platform for a GNU/Linux? Perhaps Harmattan as well.

Unfortunately TI has stopped mobile chipset business, that leaves Tegra being the only SoC that has mainline Linux Kernel driver support?

On the other hand, if we developed a Tegra solution from scratch, that should be able to power the mainline Linux?

And my last question, is it technically possible developing a graphic driver for mainline linux, on for example, Qualcomm chipsets?

And thank you for your knowledge!

Re: The choice of OS of the new QWERTY device project
 

I'm not an expert, so please take this with a grain of salt, and wait for someone like Venemo to confirm/correct me.

Anyway, linux support is not a yes/no question, there are several levels of linux availability for graphics drivers:
* only Android available through libhybris (with the drawbacks Venemo explained)
* linux version available as a proprietary binary blob, probably tied to a specific kernel version (like Mali drivers are on the user-space, the kernel side being open, see Odroid C2 discussions about mainlining it)
* linux version available as open-source, maybe mainlined (probably only Intel, Nvidia and AMD here ?)

There are a lot of ARM platforms having graphical acceleration under linux without using libhybris, but it is more common for industrial CPU (like Freescale iMx or TI OMAP) than consumers products. And it is probably not fully open to follow mainstream kernel.

And there are also open-source initiatives to reverse engineer GPU to make open-source drivers for the closed platforms, like freedreno for qualcomm, lima for ARM's Mali, etnaviv for Freescale's vivante, grate for Tegra... but it takes time and is usually quite behind the closed blobs (when available).

Re: The choice of OS of the new QWERTY device project
 

Well blobs are not as bad as libhybris but not ideal. As long there is a open driver currently in development we can sit at the blobs for time being. We survived the blobs of the n900 too. ;)

Re: The choice of OS of the new QWERTY device project
 

If I recall correctly, Tizen is still a GNU/Linux system, although I'm not entirely sure about its low-level driver infrastructure ― I haven't followed Tizen for a while now, but it might be worth checking out what kind of hardware they are using and what kind of kernel they deliver. (Not sure if Tizen as an OS is feasible or not, haven't seen it for a long time. But it is still in development by Samsung.)

There are others, see Zeta's post. A Tizen phone has a Mali GPU, so maybe there are some drivers for Mali. I think Broadcom also has something (at least the Raspberry Pi does have hardware graphic acceleration). We should look around to see what alternatives are there.

Possibly. They have "Linux for Tegra" although I have personally never worked with it. We should ask a guy like Vgrade, Sledges or Stskeeps who might know more about this, and other possible alternatives.

Technically, everything is possible, but not everything is feasible. If there were mainstream commercial interest in developing such drivers, every chipmaker would develop them. It is also a matter of hardware documentation, but some people are doing it regardless, eg. the reverse engineering efforts that Zeta mentioned.

Re: The choice of OS of the new QWERTY device project
 

Chen, I posted your questions in the tinkerphones community mailinglist (built around Gta04 phone). And I got a reply from Nikolaus Schaller, the maker of this phone.

http://lists.goldelico.com/pipermail...ly/001660.html

Re: The choice of OS of the new QWERTY device project
 

He conveniently forgot to mention how to deal with graphics drivers...

Re: The choice of OS of the new QWERTY device project
 

Yes, thanks a lot for clearing this up.
So for me it looks like the choice of the appropriate graphics hardware is the most crucial issue.

Re: The choice of OS of the new QWERTY device project
 

Barriers are:
* not having any support from oem towards having a mainline kernel or at least an open source kernel
* no support for _linux_ graphics driver, libhybris conveniently goes around this by using android drivers so that linux can use them
* DIY licensing fee from ARM to make a processor oneself and everything included is what I consider the most expensive and craziest alternative (alongside the enormous amount of elbowgrease to make it work)

So there are very limited to nonexistent choices here:

* Freescale iMX 6,, this has yocto support to at least morty version, with vivante gpu, etnaviv in mesa

* RISC-V boards from SiFive, https://dev.sifive.com/freedom-soc/evaluate/fpga/ this is essentially coding the processor and gpu using fpga, which is quite painful and expensive

At least according to my own research (can't say if its extensive or brief yet) this is all I've come up with.

Peripherals themselves are quite easy to come by source code wise, counting out the baseband modem of course. For the latter problem, I'd suggest figuring out ways to connect to a modem in a non-cpu or memory bound way, like using the SDI bus.

Re: The choice of OS of the new QWERTY device project
 

So to summarize (thanks go to @Venemo for the indepth explanations)

- the main problems are drivers.

- most hardware make write driver for android which works differently than standard Linux.
(e.g.: standard graphics - both opensource and some semi-open - in Linux use an infrastructure called DRI. Android uses flinger).

- also most hardware manufacturer only write binary-only drivers which can only work with the specific kernel versions that exist at this time.
(This is much more noticeable with Android, where SoC manufacturer writes drivers for the exact specific Linux kernel that is used by the Android version of that moment (e.g.: that's why Jolla Phone is stuck at kernel version 3.4.xxxx , even if current modern kernel is at version 4.11, 4.12 will be out anytime soon, and 4.9 is the last LTS
I think on the mobile front, Nvidia puts a little bit more effort)


So basically you're stuck with 3 solutions :



-1- Use the official Android drivers, paired with the corresponding android drivers (GPU: "Flinger").

Jolla does this way. They use the libhybris they've created to be able to use these driver under a full blown GNU/Linux.

The also need to backport newer feature that aren't availble in kernel 3.4.xx (e.g.: they backport some fixes and enhancement of the BTRFS filesystem featured in later kernels).

Ubuntu was also doing that with Ubuntu Touch. But they've abandonned.
I haven't heard of any other distribution bothering to develop a functional libhybris stack (though Gentoo, and Arch are the most likely to get one, eventually).


- Use the official GNU/Linux binary driver (usually a kernel .ko DRM paired with a closed source binary openGL driver).
You might get more choice of kernel versions.

But less choice of actual vendor doing this.
- Nvidia is still making efforts, because GNU/Linux is still a choice in cars, specially for the infotainment part
(the few in-car computer which are plugged into the use-facing displays, and sound system. Real-time kernels like QNX might be popular instead on more critical computers)
and Tegra is a popular chip here (see Tesla cars - though in that case they even use Linux for the other in-car computers).
Also Tegra (by being equipped with a built-in Nvidia GPU and some parts even featuring PCIe lanes that could communicate with full blown Nvidia graphic cards) is a very interesting platform for some computing tasks (things that are purely done on GPU - e.g.: using CUDA) such as neural nets. And as Linux is basically *king* in the scientific research domain, they are putting some effort.

(Most of the netbooks have gone this route.
Most of the chromebooks have also gone this route.
Both provide most of the hardware on which you see "standard Linux distro such as Debian/OpenSUSE/Arch installed")



- Use the latest Linux kernel and try whatever open-source drivers are availble.

The big problem here is that unlike the desktop - where both Intel and AMD are even having developpers on their own payroll - much of the development is done by independent developers that need to reverse engineer everything from scratch.
There are few chipset that are a little bit supported.

Nvidia's Tegra are supported by the Nouveau drivers, because they share a lot with the mainstream Nvidia cards, and because Nvidia is a tiny bit less reluctant to publish some information from time to time.
Still, support isn't perfect.

Qualcom's Adreno are supported by the Freedreno driver, (because they have a shared parentage with Radeon and are massively popular chips, so there's some efforts).
Still, support isn't perfect.

Mali are support by Lima driver.
Still support isn't perfect.

Broadcom's VC4 and upcoming VC5 also have a driver (because of the massive popularity of the Raspberry Pi series of boards).

Non of the other GPU has any decent support (e.g.: Power VR is closed source).