• Announcements

    • 1. Check power supply, check SD card and check other people experiences

      Power supply issues are one of the three biggest issues you'll face when starting with Single Board Computers (SBCs). SD card issues, whether fake or faulty, are another and issues resulting from poor board design is the other common issues you can encounter.   Power supply issues can be tricky. You might have a noisy power supply that works with one board because it has extra filtering, but won't work with another. Or you're using that cheap phone charger because your board has a microUSB connector, and it is either erratic, or doesn't start up, or even becomes the cause of some SD card issues.    Some tips to avoid the most common causes of problems reported:   Don't power via micro USB  - unless you have optimised your setup for low power requirements. Micro USB is great for mobile phones because they are simply charging a battery. It's bad for SBCs. Yes, it does work for a lot of people, but it also causes more problems and headaches over time than it is worth, unless you know exactly what you are doing. If you have a barrel jack power connector on your SBC, use it instead! If there is an option for powering via header connections, use that option!
        Don't use mobile phone chargers. They might be convenient and cheap, but this is because they are meant for charging phones, not powering your SBC which has particular power requirements.
        When you are evaluating a power supply, make sure you run some stress tests on your system to ensure that it will not cause issues down the path.   (Micro) SD card issues can be sneaky. They might appear right at the start causing strange boot and login errors, or they might cause problems over time. It is best to run a test on any new SD card you use, to ensure that it really is what it is, and to ensure that isn't faulty. Armbian provides you a simple way to do this   --   armbianmonitor -c /path/to/device/to/test  
    • 2. Make sure to collect and provide all necessary information

      We can only help if you provide quality information for us to work with. All stable images from the download section are tested, most stable upgrades are tested and we have tens of thousands of users. Even with regular and extensive testings, bugs sometimes do slip through. This is a voluntary support service and is unrelated to board makers, and is not obligated to provide you any answers. Repeated asking the same questions because you're not happy with the answers will result in you being ignored.

      Before you post a question, use the forum search as someone else might have already had the same problem and resolved it. And make sure you've read the Armbian documentation. If you still haven't found an answer, make sure you include the following in your post:   1. Logs when you can boot the board: armbianmonitor -u (paste URL to your forum post)   2. If your board does not boot, provide a log from serial console or at least make a picture, where it stops.   3. Describe the problem the best you can and provide all necessary info that we can reproduce the problem. We are not clairvoyant or mind readers. Please describe your setup as best as possible so we know what your operating environment is like.     We will not help in cases you are not using stable official Armbian builds, you have a problem with 3rd party hardware or reported problem would not be able to reproduced.

CuBox-i4Pro and X11 GPU support
0

6 posts in this topic

Recommended Posts

Hi there,

is there a chance to have hardware acceleration for the armbian images for stretch?

I build the debian stretch default desktop version, but there is no xserver-xorg-video-imx-viv and thus the desktop feels really laggy.

 

Regards
   Georg

Share this post


Link to post
Share on other sites

OK, so I build Armbian 5.35 Xenial Next Desktop out of the git repo with 24fbb01.

 

After I startup and configure the user X doesn't come up , see the attached Xorg.0.log :

 

[    68.024] (EE) modeset(0): Failed to initialize glamor at ScreenInit() time.
[    68.024] (EE)
Fatal server error:
[    68.024] (EE) AddScreen/ScreenInit failed for driver 0
[    68.025] (EE)
[    68.025] (EE)

 

Regards

  Georg

Xorg.0.log

Share this post


Link to post
Share on other sites

Unfortunately, you hit another (known) Ubuntu Xenial bug.

Only Debian Stretch desktop is currently available to build for imx6 based boards. I didn't have time to get to the bottom of the issue so I don't know exactly where is the problem and how to solve it.

Share this post


Link to post
Share on other sites

Well thanks to @Astralix at least I could start X now. :-) It was the X server setting for the fb device. With this setting X is starting up.

 

But unfortunately X is not accelerated and performance is very poor. I think there is some X/GLX driver missing. I tried glmark2-drm on the console using the framebuffer directly it was smooth (gave me a score of 20). glmark2 under X gave me a score of 8, because it was using software rendering (Gallium llvm pipe).

 

I will check more details next week.

 

@Astralix Did you manage to get an accelerated X?

 

Regards

  Georg

 

 

 

Share this post


Link to post
Share on other sites

Hi @AnArmbianUser!

There are two acceleration systems, 2D/3D graphics and video. I did not focus on these, as I am using the desktop only for controlling the unit. I will investigate on the graphics system around end of January, as till then the most needed features of the project itself are implemented. As it is an amateur radio, there is no primary focus on graphics acceleration. But I really would appreciate, if all the GPU and VPU stuff would work in a modern kernel 4.1x.y more or less out of the box. It is so easy to get all the needed licenses for legal use of the CoDecs but it is so hard to get the licensed code from the company who manufactures the iMX SOC... Whichever company that might be tomorrow, or next week ;)

 

Regards

Ulrich

 

 

Share this post


Link to post
Share on other sites

Hi @Astralix ,

 

in the meanwhile I was able to build the XF86 video driver for 2D and 3D acceleration follwing the instructions in this repo. It looks a bit strange, because the driver is developed in the unstable_devel branch and master hasn't been touched for a while plus it uses code from two other external repos. Nevertheless compilation worked out of the box (I followed the etnadrm path described at the bottom of the README file).

 

To enable the XF86 driver you have to add the following to the XF86 config:


 

    Section "Device"
        Identifier      "Driver0"
        Screen          0
        Driver          "armada"
    EndSection

With this I was able to get glmark2 and glxgears to show up and apparently both are running with hardware acceleration. For glmark2 I had to set "MESA_GL_VERSION_OVERRIDE=2.1", because the etnaviv mesa driver reported only 1.4 .

 

Also chromium reports support for hardware acceleration now. Please note that the chromium ubuntu armhf build by default uses the setting "enable-low-end-device-mode" which shows webpages and especially pictures in a distored way. To use standard rendering you have to override the default chromium flags (set in /etc/chromium-browser/default):

 

echo CHROMIUM_FLAGS=>~/.chromium-browser.init

Regards

   Georg

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

0

  • Support the project

    We need your help to stay focused on the project.

    Choose the amount and currency you would like to donate in below.