ODROBIAN Jessie (64bit) & (32bit)

User avatar
mad_ady
Posts: 5096
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1
Location: Bucharest, Romania
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by mad_ady » Thu Apr 07, 2016 9:03 pm

The vanilla image has no GUI, so you need to ssh into the box and install a gui (either through oh-gui, or directly through tasksel).

Iceflower
Posts: 12
Joined: Thu Apr 07, 2016 8:17 pm
languages_spoken: german, (english)
ODROIDs: Odroid C2
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by Iceflower » Thu Apr 07, 2016 11:16 pm

i didnt expect a gui, just a console or something :D so theres nothing of such things which can be displayed?

PeterRavnMikkelsen
Posts: 153
Joined: Sun Apr 14, 2013 10:34 pm
languages_spoken: English, Swedish, Danish
ODROIDs: U2, C2
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by PeterRavnMikkelsen » Thu Apr 07, 2016 11:22 pm

Edit your boot.ini and uncomment your screen's native mode and setenv dvi. When hopefully you boot up with a display run tasksel.

User avatar
XeoSal
Posts: 925
Joined: Sun Aug 30, 2015 11:21 pm
languages_spoken: English
ODROIDs: C1, C1+, C2 & XU4
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by XeoSal » Thu Apr 07, 2016 11:27 pm

Iceflower wrote:i didnt expect a gui, just a console or something :D so theres nothing of such things which can be displayed?
The TTY consoles are all visible through HDMI for server usage, although it's probably better to use SSH for such activity. You can have desktop environments as well like MATE, XFCE, LXDE by using Tasksel which is a tool created by Debian team to install DEs with one click through a simple GUI configured already with most suitable settings.

If you need to set a specific resolution for your monitor, you should SSH to the device from any other Linux/Windows workstation to set the correct resolution parameter by editing the /media/boot/boot.ini file, then restart to take effect.

Iceflower
Posts: 12
Joined: Thu Apr 07, 2016 8:17 pm
languages_spoken: german, (english)
ODROIDs: Odroid C2
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by Iceflower » Thu Apr 07, 2016 11:42 pm

XeoSal wrote:
Iceflower wrote:i didnt expect a gui, just a console or something :D so theres nothing of such things which can be displayed?
The TTY consoles are all visible through HDMI for server usage, although it's probably better to use SSH for such activity. You can have desktop environments as well like MATE, XFCE, LXDE by using Tasksel which is a tool created by Debian team to install DEs with one click through a simple GUI configured already with most suitable settings.

If you need to set a specific resolution for your monitor, you should SSH to the device from any other Linux/Windows workstation to set the correct resolution parameter by editing the /media/boot/boot.ini file, then restart to take effect.
I dont want any gui :D because a sevrver does not need this. I will try now via SSH

Iceflower
Posts: 12
Joined: Thu Apr 07, 2016 8:17 pm
languages_spoken: german, (english)
ODROIDs: Odroid C2
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by Iceflower » Fri Apr 08, 2016 1:41 am

At least SSH works! Thanks from a newbie :DD

PS.
This link should be more highlighted http://forum.odroid.com/viewtopic.php?f=52&t=19014

tp1360
Posts: 69
Joined: Thu Sep 10, 2015 10:06 pm
languages_spoken: english
ODROIDs: C1+
Contact:

webcam and chromium

Unread post by tp1360 » Fri Apr 08, 2016 9:51 pm

Hi, I am using the mate desktop and chromium-browser but can't seem to get chromium to see my Logitech webcam even though it shows up properly on lsusb, does anyone have any suggestions?

Also, I understand we do not have video acceleration due to some missing drivers that are coming soon(?), if this is correct can someone provide an estimate of when we might see video acceleration in chromium?

Thanks

penguinist
Posts: 27
Joined: Mon Mar 14, 2016 12:05 pm
languages_spoken: english, german, spanish
ODROIDs: odroid-c2
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by penguinist » Sat Apr 09, 2016 4:12 am

@tp1360:

One suggestion would be to check if your kernel is up to date. The last kernel update brought in some kernel driver fixes.

In my case I'm using this kernel: Linux odroid64 3.14.29-18-odrobian+ and web cam works fine here.

Another idea would be to partition the problem between kernel and chromium. Use a different user space app like vlc or cheese to view your web cam. If you can see the cam on everything except chromium then you know that chromium is the location of the problem. In my case, cheese displays a web cam image perfectly.

Good luck...

User avatar
mad_ady
Posts: 5096
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1
Location: Bucharest, Romania
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by mad_ady » Sat Apr 09, 2016 6:22 pm

@penguinist: what type of webcam do you have (driver)? I'm having problems on Odrobian (32bit and 64bit) to get the HardKernel 720p camera working reliably. It takes a lot of time to initialize it to grab an image... I even recompiled the kernel with mainline uvc driver and it still is flakey

penguinist
Posts: 27
Joined: Mon Mar 14, 2016 12:05 pm
languages_spoken: english, german, spanish
ODROIDs: odroid-c2
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by penguinist » Sat Apr 09, 2016 8:31 pm

@mad_ady:

from /var/log/messages:

Code: Select all

Apr  9 07:24:24 odroid64 kernel: [30702.307760] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (0c45:62c0)
Apr  9 07:24:24 odroid64 kernel: [30702.312078] input: USB 2.0 Camera as /devices/dwc2_b/usb1/1-1/1-1.4/1-1.4:1.0/input/input7
Apr  9 07:24:24 odroid64 kernel: [30702.312261] usbcore: registered new interface driver uvcvideo
Apr  9 07:24:24 odroid64 kernel: [30702.312267] USB Video Class driver (1.1.1)
from lsmod:

Code: Select all

uvcvideo               70488  0 
videobuf2_vmalloc       3043  1 uvcvideo
from lsusb:

Code: Select all

Bus 001 Device 006: ID 0c45:62c0 Microdia Sonix USB 2.0 Camera
The image comes up slowly in cheese and even slower in vlc since we are driving 4k X11 with software. It will be great when the hardware accelerated X11 is ready.

Pienoet
Posts: 386
Joined: Sun May 10, 2015 10:04 pm
languages_spoken: english Dutch
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by Pienoet » Sat Apr 09, 2016 9:02 pm

Hello xeosal,

I have a usb spdif from hardkernel i can select the device in kodi but i have no sound.

Is there usb spdif support for C2?

I tried LibreELEC from wrxtasy but i have the same issue..

Thanks!

EDIT: I put the asound.conf from my c1+ to /etc and i have soun now :mrgreen:

How to get rid of the blinking cursor in kodi gui?

And is there support for pulse8 cec adapter?

Raybuntu
Posts: 1245
Joined: Mon Nov 30, 2015 4:23 pm
languages_spoken: english, german
ODROIDs: C1+, C2
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by Raybuntu » Sun Apr 10, 2016 3:47 am

I found a bug.

https://github.com/Owersun/xbmc/blob/Ja ... MC_addon.h

I've compiled pvr.addon.vnsi and it can't find the libraries with suffix _i483-linux. Problem is that Arm64 is not included for ADDON_HELPER_ARCH. Can we get that fixed?
BTC: 12zLUYC7JzwM7a8cQKekAvZr9kWxjzTfxm

olihey
Posts: 33
Joined: Mon Sep 23, 2013 5:20 pm
languages_spoken: english
ODROIDs: C2
Location: Germany
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by olihey » Sun Apr 10, 2016 4:18 pm

Pienoet wrote:EDIT: I put the asound.conf from my c1+ to /etc and i have soun now :mrgreen:
Any chance you could share that asound.conf?

Pienoet
Posts: 386
Joined: Sun May 10, 2015 10:04 pm
languages_spoken: english Dutch
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by Pienoet » Sun Apr 10, 2016 9:31 pm

olihey wrote:
Pienoet wrote:EDIT: I put the asound.conf from my c1+ to /etc and i have soun now :mrgreen:
Any chance you could share that asound.conf?
Yes off course here you are:

Code: Select all

pcm.!default {
    type plug
    slave {
        pcm "hw:1,0"
        format S16_LE
        rate 48000
    }
}

ctl.!default {
    type hw
    card 1
}

mlask
Posts: 11
Joined: Mon Apr 11, 2016 6:20 am
languages_spoken: english, polish
ODROIDs: C1+, C2, HC1
Location: Warsaw, Poland
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by mlask » Mon Apr 11, 2016 6:30 am

Is there any progress with WiFi drivers for Realtek devices?
I tried to use TP-Link WN823N v1 (with RTL8192CU), TP-Link WN725N v1 (RTL8188CUS) and TP-Link WN725 v2 (RTL8188EUS) and only second one was working for a longer time. Others worked fine until they stopped, after few minutes of connection. Speeds are terrible - iperf reports less than 1Mbps. On Raspberry Pi 2 everything worked well, with almost full speeds (more than 100Mbps).

Also, I cannot build anything because I can't install build-essential package (dependency errors).

Also - and that may be important - hardware acceleration isn't working on hybrid kernel. It works perfectly on 64bit version only.

tp1360
Posts: 69
Joined: Thu Sep 10, 2015 10:06 pm
languages_spoken: english
ODROIDs: C1+
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by tp1360 » Tue Apr 12, 2016 1:47 am

Hi;

Can you please include watchdog in your os the next time you are compiling the kernel, thanks.

User avatar
mad_ady
Posts: 5096
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1
Location: Bucharest, Romania
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by mad_ady » Tue Apr 12, 2016 5:48 pm

I have an open question for the Debian gurus around here. I'm trying to install ffmpeg/mencoder/avconv in odrobian, but it seems they are not in the repo.

Actually, ffmpeg is in the armhf repo, but when I try to install it, it insists in uninstalling kodi and vlc, but the other two are not. I find this weird, since Hardkernel's Ubuntu image for C2 can install ffmpeg and mencoder for arm64 out of the box...

Are there other (non-free?) repos I can enable under Debian?

mi7chy
Posts: 59
Joined: Sat Mar 19, 2016 3:22 pm
languages_spoken: english
ODROIDs: C2
Future XU5
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by mi7chy » Wed Apr 13, 2016 2:15 am

How do we update to latest kernel and boot loader from Odrobian hybrid? Tried Odrobian Hook and "apt-get dist-upgrade" but it's still on 3.14.29-18 while latest is 3.14.29-52. Try to see if the updated kernel fixes an issue that appears to be common across different Odrobian hybrid, Android and Kali running the same kernel 3.14.29-18.

Lepage
Posts: 2
Joined: Wed Apr 13, 2016 3:28 am
languages_spoken: english
ODROIDs: C1, C2
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by Lepage » Wed Apr 13, 2016 3:38 am

First post here so, hey everyone =)

I installed ODROBIAN 32bit, upgraded all packages(update && upgrade), installed MATE using tasksel - got good desktop environment. Then I tried to install vlc:armhf - and it installed. So far so good.
Then I got a problem - tried to play downloaded youtube video. And it didn't work. The picture is there, it's just isn't moving... I suppose something is wrong with video decoding, but I don't know what is. Can anyone help?

deivid
Posts: 54
Joined: Wed Jun 05, 2013 11:34 pm
languages_spoken: english, spanish
ODROIDs: U2
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by deivid » Wed Apr 13, 2016 9:40 am

How do you set kernel parameters? I'd like to try if loglevel=3 + console=tty2 shuts the tty up

User avatar
XeoSal
Posts: 925
Joined: Sun Aug 30, 2015 11:21 pm
languages_spoken: English
ODROIDs: C1, C1+, C2 & XU4
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by XeoSal » Thu Apr 14, 2016 2:09 am

mad_ady wrote:I have an open question for the Debian gurus around here. I'm trying to install ffmpeg/mencoder/avconv in odrobian, but it seems they are not in the repo.

Actually, ffmpeg is in the armhf repo, but when I try to install it, it insists in uninstalling kodi and vlc, but the other two are not. I find this weird, since Hardkernel's Ubuntu image for C2 can install ffmpeg and mencoder for arm64 out of the box...

Are there other (non-free?) repos I can enable under Debian?
Yes, there is no version of FFmpeg available on official Debian repositories however, you should find one in Debmultimedia repository. Anyways, I will backport it already to be available on our own repository. :)
deivid wrote:How do you set kernel parameters? I'd like to try if loglevel=3 + console=tty2 shuts the tty up
I think you can set that inside the (/media/boot/boot.ini) file.

Code: Select all

# Default Console Device Setting
setenv condev "console=ttyS0,115200n8 console=tty0"   # on both
Right there.

mlask
Posts: 11
Joined: Mon Apr 11, 2016 6:20 am
languages_spoken: english, polish
ODROIDs: C1+, C2, HC1
Location: Warsaw, Poland
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by mlask » Thu Apr 14, 2016 4:24 am

What about updated kernel (with Realtek driver)?

User avatar
XeoSal
Posts: 925
Joined: Sun Aug 30, 2015 11:21 pm
languages_spoken: English
ODROIDs: C1, C1+, C2 & XU4
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by XeoSal » Thu Apr 14, 2016 10:55 pm

mlask wrote:What about updated kernel (with Realtek driver)?
A new kernel with latest updates from HardKernel is already available, you can upgrade to version (20-odrobian) right now, follow instructions here if you need help.

Lepage
Posts: 2
Joined: Wed Apr 13, 2016 3:28 am
languages_spoken: english
ODROIDs: C1, C2
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by Lepage » Fri Apr 15, 2016 1:06 am

Tried to install ffmpeg - no additional repo (thanks btw). The issue is... well this:

Code: Select all

odroid@odroid32:~$ ffplay /home/odroid/Documents/521.mp4
ffplay version 2.6.5 Copyright (c) 2003-2015 the FFmpeg developers
  built with gcc 4.9.2 (Debian 4.9.2-10)
  configuration: --prefix=/usr --extra-cflags='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security ' --extra-ldflags='-Wl,-z,relro' --cc='ccache cc' --enable-shared --enable-libmp3lame --enable-gpl --enable-nonfree --enable-libvorbis --enable-pthreads --enable-libfaac --enable-libxvid --enable-postproc --enable-x11grab --enable-libgsm --enable-libtheora --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libx264 --enable-libspeex --enable-nonfree --disable-stripping --enable-libvpx --enable-libschroedinger --disable-encoder=libschroedinger --enable-version3 --enable-libopenjpeg --enable-librtmp --enable-avfilter --enable-libfreetype --enable-libvo-aacenc --disable-decoder=amrnb --enable-libvo-amrwbenc --enable-libaacplus --libdir=/usr/lib/arm-linux-gnueabihf --disable-vda --enable-libbluray --enable-libcdio --enable-gnutls --enable-frei0r --enable-openssl --enable-libass --enable-libopus --enable-fontconfig --enable-libpulse --disable-mips32r2 --disable-mipsdspr1 --disable-mipsdspr2 -  libavutil      54. 20.100 / 54.  3.  0
  libavcodec     56. 26.100 / 56.  1.  0
  libavformat    56. 25.101 / 56.  1.  0
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 11.102 /  5.  0.  0
  libavresample   2.  1.  0 /  2.  1.  0
  libswscale      3.  1.101 /  3.  0.  0
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  3.100 / 53.  3.100
ffplay: relocation error: ffplay: symbol av_gettime_relative, version LIBAVUTIL_54 not defined in file libavutil.so.54 with link time reference
Tried to google error - no luck so far. Any help?

mlask
Posts: 11
Joined: Mon Apr 11, 2016 6:20 am
languages_spoken: english, polish
ODROIDs: C1+, C2, HC1
Location: Warsaw, Poland
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by mlask » Fri Apr 15, 2016 4:16 am

XeoSal wrote:A new kernel with latest updates from HardKernel is already available, you can upgrade to version (20-odrobian) right now, follow instructions here if you need help.
Great! Thanks, I already tested updated kernel on meveric's build of Debian Jessie and it worked perfectly. So it will here too ;)

deivid
Posts: 54
Joined: Wed Jun 05, 2013 11:34 pm
languages_spoken: english, spanish
ODROIDs: U2
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by deivid » Fri Apr 15, 2016 6:44 am

Why is the cpu locked to performance governor? When playing video(kodi-fbdev) for a few hours (I think the rtmp stream is decoding on cpu ) I get a hang... Something like this.

Code: Select all

[ 1132.710744] DVDPlayer[551]: unhandled level 2 translation fault (11) at 0x7fec334078, esr 0x92000006
[ 1132.711143] pgd = ffffffc05c3b5000
[ 1132.711338] [7fec334078] *pgd=000000005bb2d003, *pmd=0000000000000000

[ 1132.715484] CPU: 1 PID: 551 Comm: DVDPlayer Not tainted 3.14.29-14-odrobian+ #2
[ 1132.715490] task: ffffffc05bcbe000 ti: ffffffc05956c000 task.ti: ffffffc05956c000
[ 1132.715507] PC is at 0x1a0a7c4
[ 1132.715511] LR is at 0x1616ee0
[ 1132.715515] pc : [<0000000001a0a7c4>] lr : [<0000000001616ee0>] pstate: 80000000
[ 1132.715518] sp : 0000007f0fffe270
[ 1132.715522] x29: 0000007f0fffe8f0 x28: 0000007f5831e170 
[ 1132.715528] x27: 0000007ef8ec1b70 x26: 0000007f582eae40 
[ 1132.715533] x25: 0000007eec334078 x24: 0000007f58323fa0 
[ 1132.715538] x23: 00000000000005b8 x22: 0000007f582ead10 
[ 1132.715543] x21: 0000007f58329170 x20: 000000000007165c 
[ 1132.715548] x19: 0000007f58323170 x18: 0000007f583296f7 
[ 1132.715552] x17: 0000007f583296f5 x16: 0000007f5831e2b0 
[ 1132.715557] x15: 0000007f583296fb x14: 0000000000000000 
[ 1132.715562] x13: 0000000000000000 x12: 0000000000000000 
[ 1132.715568] x11: 0000000000000000 x10: 0000000000000078 
[ 1132.715572] x9 : 00000000000002d8 x8 : 0000007eec334078 
[ 1132.715577] x7 : 0000000000000000 x6 : 0000000000000000 
[ 1132.715582] x5 : 0000000000000000 x4 : 0000000000000040 
[ 1132.715587] x3 : 00000000fffffffe x2 : 00000000000003c0 
[ 1132.715592] x1 : 0000007f403aef28 x0 : 0000007eec334078 

[ 1132.887365] aiu i2s playback disable
[ 1132.887378] audio_hw_958_enable 0


My temps are ~75° on a 22° room with AC. Limiting max freq to 1.3Ghz for now to see if something changes

misaki
Posts: 3
Joined: Wed Mar 23, 2016 2:07 am
languages_spoken: english
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by misaki » Fri Apr 15, 2016 9:41 pm

Hi.
I am new user od c2. I have problem with desktop envirement installation. Using oh --gui and selecting envirement nothing is installed. Tasksel is closed and it back to main menu of oh --gui. May you help me. How to install desktop envirement on c2 odrobian.

Thank you

sash11
Posts: 19
Joined: Fri Mar 11, 2016 7:07 am
languages_spoken: english
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by sash11 » Sat Apr 16, 2016 12:39 am

@misaki
What card are you booting from? I had a similar issue on a 128GB UHS-1 card that turned out to be faulty so I could not install MATE desktop. Swapping to 16GB card solved my issue.

deivid
Posts: 54
Joined: Wed Jun 05, 2013 11:34 pm
languages_spoken: english, spanish
ODROIDs: U2
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by deivid » Sat Apr 16, 2016 4:12 am

at the moment mpv is not able to install because of a dependency with libsdl2-2.0-0 which conflicts with libsdl2-odrobian-fbdev. Would you repackage mpv to accept either of those libraries?

Edit: Sorry, it seems libsdl2-odrobian-fbdev is poorly packaged:

Code: Select all

 mpv depends on libsdl2-2.0-0 (>= 2.0.0); however:
  Package libsdl2-2.0-0 is not installed.
  Version of libsdl2-2.0-0 on system, provided by libsdl2-odrobian-fbdev:arm64, is <none>.

penguinist
Posts: 27
Joined: Mon Mar 14, 2016 12:05 pm
languages_spoken: english, german, spanish
ODROIDs: odroid-c2
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by penguinist » Sat Apr 16, 2016 7:50 am

This may not be the best thread for this question, but I don't seem to find discussion elsewhere.

I'm really super happy with Odrobian and I'm using it as my OS of choice on the C2. The philosophy of a tiny starting point that can be tailored and customized via the full debian repository is perfect for small projects as well as large ones.

At this point I have only one thing on my wishlist and that is a hardware accelerated X11. I understand that Hardkernel is working on this, but I'm not seeing any discussion or progress reports on this project. Have I missed an important thread? Perhaps someone can either provide a status update or point me to the thread where this activity is discussed.

User avatar
mad_ady
Posts: 5096
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1
Location: Bucharest, Romania
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by mad_ady » Sat Apr 16, 2016 3:44 pm

I think the X11 acceleration has to come from amlogic, that's why it's not discussed

Raybuntu
Posts: 1245
Joined: Mon Nov 30, 2015 4:23 pm
languages_spoken: english, german
ODROIDs: C1+, C2
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by Raybuntu » Sun Apr 17, 2016 2:08 am

Actually hardware acceleration has to come from ARM. Because it's a mali gpi and there is no free open source driver for that. You need nonfree blobs and that really sucks.
BTC: 12zLUYC7JzwM7a8cQKekAvZr9kWxjzTfxm

User avatar
mad_ady
Posts: 5096
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1
Location: Bucharest, Romania
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by mad_ady » Sun Apr 17, 2016 3:08 am

So, ARM designed the GPU as well? I thought they designed just the cpu cores and Amlogic implemented them and designed the system-on-a-chip.

crashoverride
Posts: 4176
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by crashoverride » Sun Apr 17, 2016 3:42 am

ARM designs and licenses both the CPU (Cortex-A53) and GPU(Mali-450MP3). Amlogic purchases licenses to both and produces the actual chips with other components integrated on silicon.

"X11 acceleration" is one of the most misunderstood concepts when related to ARM Single Board Computers (SBC). On a PC what is collectively referred to as a GPU is actually different components from different manufactures on an ARM SBC. This means the display controller, framebuffer, and hardware codecs are entirely separate from the GPU on an ARM SBC. The Mali (GPU) takes in a command byte stream representing 3D data and processes it to produce a 2D bitmap image in memory. The memory is then copied to the framebuffer and output by the display controller or, in some cases, the display controller is instructed to directly output the memory without a copy.

X11 is a very old protocol. It was designed before many Odroid users were even born. It does not have provisions for many modern day concepts. The EAX protocol extension to X11 defines 2D "X11 acceleration". It consists of API calls to copy rectangles from one block of memory to another block (sometimes with the rectangles overlapping). Acceleration is achieved by optimizing these copies either through software or hardware. Traditionally, the GPU is not even involved. This means that even with Mali GPU drivers, X11 will not be accelerated in any way.

The driver that enables X11 and the EAX acceleration extension is referred to as a DDX. This X11 driver is independent from the Mali GPU driver. The DDX handles the X11 protocol display requirements while the Mali GPU driver handles the EGL/OpenGL ES API requirements. Currently, X11 is using the generic fbdev DDX on OdroidC2. For an accelerated X11 experience, a new DDX (not GPU driver) is required. The archaic design of X11 is what makes this difficult for modern ARM SBCs.

There is active development to replace the antique X11 API in Linux with something modern. This takes the form of Wayland/Weston for most and Mir for Ubuntu.

LiquidAcid
Posts: 1088
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by LiquidAcid » Sun Apr 17, 2016 4:37 am

You mean EXA, EAX is Creative Labs ;)

User avatar
mad_ady
Posts: 5096
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1
Location: Bucharest, Romania
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by mad_ady » Sun Apr 17, 2016 2:26 pm

That is a very detailed explanation, thank you crashoverride. It belongs on a wiki page so that it doesn't get lost on the forum.
Sorry for the continued offtopic, but since the C1 has the same MALI GPU, would this mean we could have full X11 acceleration on a 32bit C2 OS with the mali and ddx taken from C1? Is it safe to assume that the same approach would not work on a 64bit OS because of the architecture difference/dependencies?

LiquidAcid
Posts: 1088
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by LiquidAcid » Sun Apr 17, 2016 7:34 pm

The explanation is wrong though, e.g. Intel hardware doesn't have a dedicated 2D engine since quite some time (gen5 or something, go look it up). Their DDX implements blitting operations and other stuff by using the 3D engine on this type of hardware.
Point is, nothing hinders ARM to write a DDX or at least a DDX skeleton that implements EXA using the Mali 3D engine. They are just not doing it. Instead they supply a binary blob with limited feature set. It's the closed source nature of things that is the issue here, not X11 being a archaic protocol (which is still true, but not the reason for anything here).

Raybuntu
Posts: 1245
Joined: Mon Nov 30, 2015 4:23 pm
languages_spoken: english, german
ODROIDs: C1+, C2
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by Raybuntu » Sun Apr 17, 2016 11:27 pm

LiquidAcid wrote:...They are just not doing it. Instead they supply a binary blob with limited feature set. It's the closed source nature of things that is the issue here, not X11 being a archaic protocol (which is still true, but not the reason for anything here).
+1
BTC: 12zLUYC7JzwM7a8cQKekAvZr9kWxjzTfxm

crashoverride
Posts: 4176
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by crashoverride » Mon Apr 18, 2016 12:50 pm

LiquidAcid wrote:nothing hinders ARM to write a DDX or at least a DDX skeleton that implements EXA using the Mali 3D engine.
ARM does make a display controller; however, they do not make the display controller used in any Odroids. They can only provide a generic implementation which can be found on their website already. GPUs did not exist at the time X11 was designed and support for multi-vendor hardware integration suffers as a result.
http://malideveloper.arm.com/resources/ ... y-drivers/

Ideally, we would use DMS/DRM/GEM enabled display driver and a generic mode-switching DDX. However, this too only seems to work in theory as evidence by the issues with Odroid XU4.

The design of EGL/GLES is independent of any windowing system. It is outside the GLES driver's scope and responsibility to provide windowing system and/or display support. Its possible to implement a X11 server on top of GLES, but that is a general Linux software issue. It is not part of the design of X11 or GLES.

[edit]
TL;DR - No matter what we get as a X11 DDX, something will be broken or lacking. This is due to the archaic X11 architecture. It would require significant time and money to identify each issue and work around it. PC X11 drivers are proof of this as is the XU4. There are no ARM boards that I know of that have a perfect X11 story at this time.

[edit 2]
One of the things required for OS, display controller, and GPU to cooperate is a common definition of a graphics memory buffer. Android uses ION for this purpose. Linux decided to go a different route with GEM. While desktop OpenGL provides API calls to move memory to and from GPU buffers (Pixel Buffer Objects), OpenGL ES 2 does not mandate it. Therefore, framebuffer read back is a very "expensive" operation. Furthermore, since X11 defines its own Pixmap format, a translation is required when uploading window contents to the GPU. Since we have a shared memory architecture between CPU and GPU, both are wasted operations. This is one of the reason that graphics on Android are better supported than graphics on Linux. Android has a modern GUI architecture that does does not have the integration challenges presented by X11.

crossover
Posts: 113
Joined: Wed Jul 22, 2015 2:23 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, USB-IO, HC2, Tinkering kits
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by crossover » Mon Apr 18, 2016 1:19 pm

Too muuuch out of topic. But very informative. :)
Is the new Vulkan can be a great solution in '2018 or '2019 for the ARM world?
Or any possible hope ARM releases an OpenGL 3.x~4.x driver instead of GLES for their Mali GPU?

crashoverride
Posts: 4176
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by crashoverride » Mon Apr 18, 2016 1:24 pm

Vulkan requires GLES 3.1 or better hardware capabilities. The Mali-4xx series will not support it.

[edit]
Because off-topic is now the topic... :lol:
Both the C1/C2 provide a hardware bitblit engine (GE2D) that could be used for X11 acceleration. I have a proof-of-concept of this on my github. The issue with making it production ready again comes down to X11. The EXA API does not provide source and destination rectangle dimensions when determining whether an operation can be accelerated. Without this information, it can no be determined whether the data is properly aligned for a hardware blit. Instead, the information is only provided when the blit should be performed and you have no choice but to do it. This means a combination of hardware and software blit will need to be implemented making the driver needlessly over complex.

User avatar
mad_ady
Posts: 5096
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1
Location: Bucharest, Romania
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by mad_ady » Mon Apr 18, 2016 2:07 pm

One last question from me as well: how would newer display servers/engines such as wayland/mir/weston work with what we currently have for our odroid boards? I assume that at some point in the future apps could run on them or an adaptation layer like Xnest or Xpra could provide backward compatibility.
Would we still be out of luck in that case, or is the future looking brighter?

crashoverride
Posts: 4176
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by crashoverride » Mon Apr 18, 2016 2:28 pm

mad_ady wrote:how would newer display servers/engines such as wayland/mir/weston work with what we currently have for our odroid boards?
Most apps that use a toolkit like GTK or QT should support Wayland/Weston as part of an update to the toolkit itself rather than the app. For more complicated apps, there will be a X11 server running on top of Wayland/Weston. I am not familiar with Ubuntu's strategy for Mir but it is likely the same.

User avatar
mad_ady
Posts: 5096
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1
Location: Bucharest, Romania
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by mad_ady » Mon Apr 18, 2016 2:42 pm

Yes, but how will Wayland/Weston/Mir work with Odroid's hardware acceleration? Would they require special drivers, or would the mali blobs provide enough for them to do their thing directly?

crashoverride
Posts: 4176
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by crashoverride » Mon Apr 18, 2016 2:59 pm

There is an EGL/GLES2 backend for Weston. Just as today we have fbdev drivers and X11 drivers, a Wayland interface for EGL/GLES will need to be provided by ARM to HardKernel who will then perform any necessary modifications and provide us with a compatible libmali.so binary.

lepniak
Posts: 21
Joined: Sat Mar 19, 2016 6:26 pm
languages_spoken: english
ODROIDs: Odroid C2
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by lepniak » Mon Apr 18, 2016 5:50 pm

Hi Everyone!
I had problem with black screen after 10 minutes running of odroid and I see that some people had the same problem. I found responsible service and solution for this.
On file: /etc/lightdm/lightdm.conf
Find section:

Code: Select all

[SeatDefaults]
and insert this line under section:

Code: Select all

xserver-command=X -s 0 dpms
My screen working for two days now without any restart.

Maybe You add this command to default config on repository?


Also I have problem with install retroarch from oh --gui:

Code: Select all

The following packages have unmet dependencies:
 retroarch-odrobian-fbdev:arm64 : Depends: python3:arm64 but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
When I try manually install python3:arm64:

Code: Select all

The following packages have unmet dependencies:
 python3:arm64 : Depends: dh-python:arm64 but it is not installable
E: Unable to correct problems, you have held broken packages.
And dh-python:

Code: Select all

Package dh-python:arm64 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'dh-python:arm64' has no installation candidate

Also could I install kodi-pvr-addons-odrobian from this topic

Thanks for answers!
Last edited by lepniak on Tue Apr 19, 2016 6:34 am, edited 1 time in total.

sash11
Posts: 19
Joined: Fri Mar 11, 2016 7:07 am
languages_spoken: english
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by sash11 » Mon Apr 18, 2016 8:10 pm

@lepniak
To answer your last question, you would use kodi-pvr-addons command for our distro:
root@odroid64:/home/odroid# apt-cache search kodi-pvr-addons
kodi-pvr-addons - Kodi Jarvis PVR Addons from Git for ODROBIAN

Also, I believe, it is plural: [SeatDefaults]
http://oph.mdrjr.net/odrobian/doc/configuration.html

LiquidAcid
Posts: 1088
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by LiquidAcid » Tue Apr 19, 2016 3:52 am

Preliminaries:

You should forget EGL/GLES for a moment, since it is orthogonal to the issue. I'm solely talking about one thing, hardware accelerated EXA in X11. By which I mean hwaccel in the sense that computation (in the form of EXA operations) is offloaded from the CPU to some other processor. And in this particular case the other processor is the Mali GPU.

Corresponding example in the x86 world: I can run an X server with hw accelerated EXA on an Intel Skylake without having Mesa installed (just xf86-video-intel and libdrm). This of course removes the ability to create any GL or EGL contexts, but EXA is still offloaded from the CPU. And it is offloaded to the 3D engine of the GPU. EXA blitting operations are implemented by feeding a corresponding command stream to the engine. Engine then works on source buffer, writes to destination buffer. Process repeats.

In particular I should point out that this is the same unified memory situation as on ARM. The Skylake also uses normal system memory.

The commands streams / render programs can be found here:
https://cgit.freedesktop.org/xorg/drive ... er_program

At this point there is no GL or EGL involved at all. Not even the display engine plays a role. I can further reduce this setup by switching to xf86-video-modesetting. I lose EXA acceleration then, the display engine still works the same. This is the equivalent of working with the generic DRM API (create dumb buffer, set crtc, issue pageflip, etc.).

Why this doesn't work for ARM's Mali is solely due to everything being 'closed' in the following sense.
1) Userspace library is a binary blob. Functionality is largely unclear, even with the Lima reverse engineering efforts. Lima has done RE on r3p2, while we're currently on what? r9p0 or something IIRC...
2) Kernel driver is opensource, but the interfaces are not documented. Not documented in the sense that you can figure out from the API how to construct command buffers that do a specific thing.

The hardware is perfectly capable of doing this. I have used lima when it was still compatible to the kernel interface to implement copy, scale and solid fill. ARM however has decided that this not how their hw should be used.

crashoverride wrote:ARM does make a display controller; however, they do not make the display controller used in any Odroids.
See above, the display controller is irrelevant to the discussion.
crashoverride wrote:They can only provide a generic implementation which can be found on their website already.
See above, they e.g. don't provide any command streams to implement EXA ops. They could because these programs don't depend on the display controller.

crashoverride wrote:GPUs did not exist at the time X11 was designed and support for multi-vendor hardware integration suffers as a result.
It may "suffer" but it's perfectly possible. My secondary system uses its Intel hardware for output to display, while the AMD hardware does the rendering work (DRI3).
Also let's make clear that we're still talking about EXA here, which was introduced at around 2000, so it's much younger than the X11 protocol itself.

crashoverride wrote:Ideally, we would use DMS/DRM/GEM enabled display driver and a generic mode-switching DDX.
Yes to the first part, but no to the second part. As I said above, xf86-video-modesetting doesn't provide hwaccel for EXA.
crashoverride wrote:However, this too only seems to work in theory as evidence by the issues with Odroid XU4.
The issues with the XU4 stem from somewhere else.

1) The kernel. The mere concept of creating something like a BSP by heavily modifying the upstream kernel is a flawed concept to begin with. It only leads to one situation, you now sitting on a pile of crap that is "more or less" working, with no chance of ever catching up.
More and more vendors realize that you have to have your kernel code ready for upstream integration as soon as silicon tape-out is done. And we know this works because again Intel is doing it since quite some time.
2) The closed source nature of the Mali userspace driver that I already touched upon above. ARM has decided that the only thing you're allowed to do with the hardware is to use EGL/GLES (and maybe a bit of OpenCL). And on top of that you get lousy window system glue code which bounces around buffers like 10 times before they end up at the display hardware. And no, that's not due how the X protocol works.

However you raise an interesting point, at least for Amlogic hardware and that is a DRM kernel driver for the display hardware. As far as I see the current driver in the vendor kernel is still using the fbdev subsystem. If the aim is now to upstream code for the display hardware, this driver, even with a rewrite, won't get accepted since no new fbdev drivers are accepted anymore. So the only way is to make a DRM driver out of it, and I heavily doubt that Amlogic is capable of doing that. Well, they might be able to cook something up but if it gets accepted or when is a different story. Which would bring us back to point (1).

Also let us hear what Greg has to say about this:
https://www.youtube.com/watch?v=fMeH7wqOwXA (at around 6:58)

It's a bit older, but remains to be so true. And in my opinion the problems that Greg raises are the main reason for all the misery here as well. There are still too many vendors in the ARM world that don't work closely or don't work at all with upstream, in the sense that code always goes just one direction. And this is not only true for the kernel, but for userspace as well.

crashoverride wrote:The design of EGL/GLES is independent of any windowing system. It is outside the GLES driver's scope and responsibility to provide windowing system and/or display support. Its possible to implement a X11 server on top of GLES, but that is a general Linux software issue. It is not part of the design of X11 or GLES.
See above, EGL/GLES is irrelevant here. If you hint at GLAMOR, then yes, that would be _another_ means which isn't the topic here (which is EXA).
crashoverride wrote:No matter what we get as a X11 DDX, something will be broken or lacking.
I don't consider xf86-video-intel to be either broken or lacking.
crashoverride wrote:This is due to the archaic X11 architecture.
No, it's due to ARM's and its integrator's decision to not be interested in providing a good DDX. [*]
crashoverride wrote:It would require significant time and money to identify each issue and work around it.
Everything takes time and money. This is a null-argument.
crashoverride wrote:PC X11 drivers are proof
xf86-video-intel is proof that this works very well. Even xf86-video-nouveau works better than any of ARM's DDX, and nouveau is based on reverse engineered code. This situation is just one thing, an embarassing state of affairs for ARM and integrators.
crashoverride wrote:of this as is the XU4.
The XU4 is a trainwreck on the kernel level. I assume you knew this by now. And that makes it impossible to build anything good on top of it. You have seen the work-arounds that people discuss here, switching to VT and back to recover framebuffer update, freezing tasks and killing them so you don't get an Oops during application does cleanup. I can only say this: WHAT THE FUCK?!?!

crashoverride wrote:There are no ARM boards that I know of that have a perfect X11 story at this time.
Which is more an indication that my comment [*] above is very much true.

crashoverride wrote:One of the things required for OS, display controller, and GPU to cooperate is a common definition of a graphics memory buffer. Android uses ION for this purpose. Linux decided to go a different route with GEM. While desktop OpenGL provides API calls to move memory to and from GPU buffers (Pixel Buffer Objects), OpenGL ES 2 does not mandate it. Therefore, framebuffer read back is a very "expensive" operation. Furthermore, since X11 defines its own Pixmap format, a translation is required when uploading window contents to the GPU. Since we have a shared memory architecture between CPU and GPU, both are wasted operations. This is one of the reason that graphics on Android are better supported than graphics on Linux. Android has a modern GUI architecture that does does not have the integration challenges presented by X11.
Again, this is irrelevant since it assumes that you need some kind of GL/EGL support for EXA. Furthermore the unified memory argument is wrong as well, since we have the same situation for Intel hardware as well.

crashoverride wrote:Both the C1/C2 provide a hardware bitblit engine (GE2D) that could be used for X11 acceleration. I have a proof-of-concept of this on my github. The issue with making it production ready again comes down to X11. The EXA API does not provide source and destination rectangle dimensions when determining whether an operation can be accelerated. Without this information, it can no be determined whether the data is properly aligned for a hardware blit. Instead, the information is only provided when the blit should be performed and you have no choice but to do it. This means a combination of hardware and software blit will need to be implemented making the driver needlessly over complex.
You don't have alignment restrictions concerning the source and destination rectangle position and dimension. What you have are restrictions on the source and destination base addresses (!), which you can control by telling EXA how you want your pixmap offset to be aligned.
Even if you have size restrictions on the blitting rectangles, you can derive these from the src and dst pixmap pointer. And the pixmap object carry the information if the backing memory is physically contiguous. Nothing of this is particularly difficult to implement.
This is not without saying that the GE2D API is badly designed. E.g. userspace should never handle physical/bus addresses. And this is just the tip of the iceberg. It again doesn't help that Amlogic is still using the fbdev subsystem. This could be handled more elegantly by passing GEM handles around.

tk501
Posts: 124
Joined: Thu Dec 26, 2013 3:57 am
languages_spoken: english
ODROIDs: C1+
Contact:

What does this mean for HTML5 video on C2?

Unread post by tk501 » Tue Apr 19, 2016 7:19 am

A very deep discussion that I expect is useful for those of you who are much better versed in linux systems programming, I wish I could do something with this information so let me ask a very basic but I think relevant question for me and other pure applications programmers who may wish to use the C2 for their projects.

Will the C2 be able to support video acceleration for HTML5 video?

For example, I have very good (30+fps, 35% cpu utilization) performance using the XU4 but as my project is very cost sensitive, I hope to move to the C2 using chromium, webRTC and video acceleration which works well on the XU4 and not bad on the C1(15fps).

Should I expect that the C2 will ever be able to come at least in the middle of the XU4 and C1 (i.e 22-25fps) or should I accept it can never achieve this level of video performance and stick with the UX4?

I want to say in advance that I very much appreciate any and all answers as this will be an important business decision for our project.

Thanks in advance.

crashoverride
Posts: 4176
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: ODROBIAN Jessie (64bit) & (32bit)

Unread post by crashoverride » Tue Apr 19, 2016 9:56 am

LiquidAcid wrote:You should forget EGL/GLES for a moment
Removing EGL/GLES also removes libmali.so and ARM entirely from the situation. This was the point of the original post. ARM does not make the display controller and can not provide anything to assist with X11 acceleration (ie window dragging). Whether libmali.so is closed source or not is also irrelevant because it has nothing to do with the display controller or X11 hardware acceleration.

The Intel PC comparison is also not relevant as Intel provides both the display controller and GPU for Skylake. Again, ARM does not provide the display controller. They do not have secret documentation to withhold. There is nothing ARM/Mali can do about X11 acceleration. That is why the reference code they provide only includes stubs for EXA.

The reason the display controller is relevant is because it converts a block of memory to a HDMI signal. Dragging windows requires updates to that block of memory. GE2D was designed to perform that operation. The display controller, GE2D, and X11 all have to agree what an image is in memory. This includes alignment, height, width, bits per pixel, color space, stride and coordinate orientation. Additionally, limitations such as scatter/gather abilities must be taken into consideration. Note that NONE of the hardware involved in producing a picture on the monitor/TV are made or licensed by ARM. Its trivial logic to conclude that this implies ARM can not provide a X11 acceleration solution since they do not make ANY of the hardware (sans CPU).

As I stated before, the subject matter is very complex. Its completely understandable that someone would think its a problem for ARM to solve.

Locked

Return to “Other OS”

Who is online

Users browsing this forum: No registered users and 1 guest