FriendlyELEC-Forum

Hi,

I have T4 and noticed that after I do apt-get update/upgrade I lose gpu hardware acceleration.
Using friendlydesktop version (ubuntu 18.4)
How do you:

1) update packages and not lose gpu hardware accerelation
2) pin gpu needed packages (which are those)

Do you not update it at all or how do you do it ?

thanks

Anyone ?

do you du update - apt-get update/ upgrade and have security (but loose gpu hardware acceleration)
or
don't do update and have gpu hardware acceleration but don't have latest packages.

I know that in APT packaging we can mark some packages as "not updatable" but anyone knows which it should be ?

thanks

this is the most viewed thread in the T4 forum and yet there is still no response from anyone on the friendlyelec team. that should speak volumes to anyone considering this board or the OS options offered by friendlyelec. there are older, similar threads and they too remained unanswered. friendlyelec provides a forum, but there is no real support of their hardware within them. i suspect that friendlyelec support doesn't even monitor these forums.

with regard to OP's question, i have emailed support about this issue issue over a year ago and their answer was essentially "don't upgrade."

the T4 is a great board but it lacks support from the manufacturer. armbian is good alternative OS option and armbian support is better through their forums, but still fairly poor. between official armbian support and volunteers, most questions get addressed but there are still many which remain unanswered.

nunyabisnas wrote:
armbian is good alternative OS option and armbian support is better through their forums

Is your only alternative which needs your help, or it will (put to) die and you will lost that too.

nunyabisnas wrote:
but still fairly poor. between official armbian support and volunteers, most questions get addressed but .

Considering that users/"clients"/you doesn't even cover the download costs they create ... you have exactly zero rights to complain (respect our time). From my personal point, it would be best to shut down this support entirely, since it only creates a depth and a stress we are barely manage to sustain. Also that little help we get from the industry is no match to your free assistance hunger.

If this support is terrible, you can easily check how much is a paycheck of an engineer. Hire one, send to trainings and abuse. One is ofc nothing, you will need 10 or more. Do the math.

nunyabisnas wrote:
there are still many which remain unanswered

Because most of the questions are expensive to answer and 100% paid from our pocket. I can easily waste few hours to clarify and answer on one hard technical question. If that question includes research, days of work are attached which means I can easily lost 500, 1000 or 5000 EUR to be able to answer to you. This cheap only If I don't count training costs. Daily maintenance costs, without dealing with a hers of non paying clients, costs around 3.000 EUR of our private cash. With donation your contribute something, true. That share is 0.5%.

Get a golden subscription https://forum.armbian.com/subscriptions/ and you will legitly cover one hour of client support per month. It will cover one not very much complicated question.

https://github.com/armbian/build#support
There are people you can hire all around the globe to help you out.

So I've learned a lot about this since buying a nanopc-t4. I have bad news, but you will at least understand what you are up against.

Friendly is using a very old kernel, 4.?? which they have modified with lcd device drivers and a device tree 'dts'.
The device tree is not compatible between major kernel versions, ie. 4 and 5. The device tree is what tells the kernel where and what all the hardware is. The device tree is part of the kernel but can be compiled separately into its dtb.
The source for these live in /boot/arch/arm64 etc. Dtc is the device tree compiler. You can decompile and look at your running device tree with Dtc. The running tree is in /sys/proc/firmware/...
You can also decompile the ones in /boot/dtbs/

Creating the device tree is really the job of the vendor, friendly elec in this case.

I can tell you that the tree for the friendly elec products are barely supported in the mainline 5.x kernel, or any other kernel you didn't get here. If you go look at the kernel source it obvious many things are missing. For the t4 that means no wifi or Bluetooth or cameras or lcd. At least not their lcd which they have compiled the drivers into their version of the kernel.

The drivers should be wrapped into dkms, "dynamic kernel modules". So they can be installed and used on any kernel, dynamically. This is, for instance, how we get Nvidia drivers on x86 machines. Dkms is how avoid recompiling the kernel when a new device driver is needed for some piece of hardware.

Last, what this means that armbian, manjaro, arch linux, all linux distros for arm do not truly support these boards because friendlyarm has not integrated the necessary parts into the Linux kernel. It is not the job of the distros to add hardware support into the kernel. It is the vendor's job, much like creating a bios for boards that have them. You could add their drivers to your kernel and compile it. I doubt they will work on 5.x. And you would still need a correct dts entry for edp/panel. The device tree is at the literal root/boot of the problem. This hardware is not really supported by Linux in a fundamental way because friendly has not contributed a dts to the kernel.

All that said, I have installed manjaro arm with kde. It does work. But no lcd, no wifi or Bluetooth, and I'm pretty sure no cameras since they aren't in the official dts. So, there you go. These are barely supported boards. Go get a rock64 or rockpro64 that is supported. Pine is very active and manjaro is their officially sponsored distro and many others work as well. There is also the rockpi.

Steer clear of a board if you must download some special version of linux or Android to make it work.

Eag wrote:
Friendly is using a very old kernel, 4.?? which they have modified with lcd device drivers and a device tree 'dts'.

This is the kernel where this hardware was brought up and shipped with the SoC. Its a development kernel per se and it has best support for hardware until all features are mainlined. All is most optimistic scenario and almost never happens. Or it happens late. For example, 1st generation of Allwinner or iMX boards is more or less fully mainlined. Those are 10years old boards and not interesting any more ...

Eag wrote:
The device tree is not compatible between major kernel versions, ie. 4 and 5.

Not a Friendly ARM fault. Model is changing - also in mainline kernel you need maintainers for hardware sections. In a very divers ARM world, this is more expensive than on PC.

Eag wrote:
Creating the device tree is really the job of the vendor, friendly elec in this case.

They did this job. Now you or someone that have a desire & time can volunteer and maintain it in the mainline kernel. We do, but we can't cover everything. Basic function first.

Eag wrote:
I can tell you that the tree for the friendly elec products are barely supported in the mainline 5.x kernel

Getting the device(s) in the mainline can easily costs millions. Or you need a herd of amateurs like consumer grade product have (Rpi). You want software for free ... it doesn't go this way. Software support is more expensive than a board design and manufacturing. But since there is a lot of volunteers around projects like Armbian, you get some decent support after all.

Eag wrote:
The drivers should be wrapped into dkms, "dynamic kernel modules". So they can be installed and used on any kernel, dynamically. This is, for instance, how we get Nvidia drivers on x86 machines. Dkms is how avoid recompiling the kernel when a new device driver is needed for some piece of hardware.

DKMS works well on well maintained Linux. Armbian spent some time to get this - what you expect as granted - fixed ... but we only fix the system, which means if the driver doesn't compile ... it is your / driver authors problem. If the code is bad, DMKS will not help. This is just a method to add drivers without the need to recompile a kernel and to recompile dynamically when kernel is upgraded.

Eag wrote:
Last, what this means that armbian

Armbian is a community based non profit project which makes Linux for single board computers on the top of RAW mainline Linux. Daily R&D and maintenance costs are around 4.000 EUR, while public contribution for covering those costs is virtual non-existing but you complain and you asks for more We generate useful code and a lot of hw related know-how. That is called support. If you only distribute this know-how, you learn little. Mainline Linux is just a good start.

Eag wrote:
All that said, I have installed manjaro arm with kde. It does work. But no lcd, no wifi or Bluetooth, and I'm pretty sure no cameras since they aren't in the official dts. So, there you go.

Manjaro packs and sells that RAW material without valuable added value as a "bleeding edge" with this and that DE. Other mainstream Linux distros do similar. They usually avoid to "support" anything more than Rpi. Even Rpi, that was sold in millions and have a herd of maintainers, is very very poorly supported in a mainline Linux if we are speaking about ...

Eag wrote:
do not truly support these boards

That is correct. Support costs while their mission is to run their Logo/Linux in any form on as many devices as possible. Any you can't blame them.

Eag wrote:
It is the vendor's job, much like creating a bios for boards that have them.

I can assure you no board vendor (except Rpi) can afford that. Their job is to create a DT and they did that. Porting drivers is SoC vendors job.

Eag wrote:
You could add their drivers to your kernel and compile it. I doubt they will work on 5.x. And you would still need a correct dts entry for edp/panel. The device tree is at the literal root/boot of the problem. This hardware is not really supported by Linux in a fundamental way because friendly has not contributed a dts to the kernel.

Very little SoC vendors (and almost no board vendor) supports mainline kernels. It is too expensive and complicated.

Eag wrote:
Go get a rock64 or rockpro64 that is supported. Pine is very active and manjaro is their officially sponsored distro and many others work as well. There is also the rockpi.

Manjaro is their sales support distro and vice versa - they generate a lot of hype to sell stuff, but on the sw support are mainly upper level cosmetical adjustments. All hard work is community based, while hardware - if you are mentioning rock64 - is crap. It only looks nice on a paper https://forum.armbian.com/topic/14089-l ... orange-pis

Eag wrote:
Steer clear of a board if you must download some special version of linux or Android to make it work.

Special Linux distro. What is wrong with that? Armbian is 100% Debian or Ubuntu from application install / users perspective. Yes, its developed elsewhere, but userland package base comes from there with a few exceptions. You could also probably boot some semi official Ubuntu or Debian, but it will be on the Manjaro level at best. And support means that someone knows hardware. People around Armbian surely knows it.

In embedded world, you usually have to make your own.