Playing with upstream (Exynos4412)

Share here your ideas for new projects
Post Reply
Obloczkus
Posts: 3
Joined: Thu Mar 13, 2014 6:42 pm
languages_spoken: english, polish
ODROIDs: U3
Has thanked: 0
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Post by Obloczkus »

If You can, please share with emmc-recovery image with the latest u-boot.
Cheers

jonB
Posts: 4
Joined: Sat Mar 23, 2019 5:53 am
languages_spoken: english, italian, brazilian portuguese
ODROIDs: U3
Has thanked: 1 time
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Post by jonB »

This is great news! Have had my good old U3 on jessie for way too long. Hoping to find some documentation as this is as first for me on this board. I appreciate if you have any links to point me to to get started. Thanks.

X-MAN
Posts: 2
Joined: Mon Jun 01, 2020 6:50 pm
languages_spoken: english, german
ODROIDs: U3+
Has thanked: 0
Been thanked: 1 time
Contact:

Re: Playing with upstream (Exynos4412)

Post by X-MAN »

Did someone have the login for the hexdump images? I want to login via SSH, thanks.

User avatar
meveric
Posts: 11545
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go, H2 (N4100), N2, H2 (J4105), GoA, C4, GoA v1.1, H2+, HC4, GoS
Has thanked: 69 times
Been thanked: 482 times
Contact:

Re: Playing with upstream (Exynos4412)

Post by meveric »

the login is on the github page..
user: linux
password: changeme
These users thanked the author meveric for the post:
anatife (Wed Jul 22, 2020 5:15 am)
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

X-MAN
Posts: 2
Joined: Mon Jun 01, 2020 6:50 pm
languages_spoken: english, german
ODROIDs: U3+
Has thanked: 0
Been thanked: 1 time
Contact:

Re: Playing with upstream (Exynos4412)

Post by X-MAN »

Thanks. Found it myself about an hour ago. It's a little bit hidden =) I also upgraded it to 20.04 LTS. Works like a charm :D Boinc running very good. Nearly half the computing time as on 14.04
Image
These users thanked the author X-MAN for the post:
odroid (Tue Jun 02, 2020 9:26 am)

User avatar
meveric
Posts: 11545
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go, H2 (N4100), N2, H2 (J4105), GoA, C4, GoA v1.1, H2+, HC4, GoS
Has thanked: 69 times
Been thanked: 482 times
Contact:

Re: Playing with upstream (Exynos4412)

Post by meveric »

yeah I used the image as well, removed the XUbuntu desktop and installed MATE as well as updated to Ubuntu 20.04.
I also installed a freshly build Kernel 5.7 without any alteration, just straight from upstream no changes whatsoever.
Worked right out of the box.
3D was working via LIMA opensource driver, which does even support OpenGL 2.1.

It was "ok-ish" but performance is really not that great only about 30~33 FPS in glmark2-es2 and glmark2.
But hey it means you can run from default Kernels with no patches :)
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

EWIuser
Posts: 22
Joined: Sat Dec 27, 2014 11:25 pm
languages_spoken: French and English
ODROIDs: U3
Location: Montreal, Quebec Canada
Has thanked: 0
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Post by EWIuser »

Hey guys is this update to 20.04 also valid for the U3 ? I thought it was only available in 64bit and the U3 is 32bit.
Also is there a procedure written somewhere on how to transfer this image to EMMC on a U3 ?

3dfx
Posts: 15
Joined: Thu Aug 07, 2014 12:48 am
languages_spoken: English
ODROIDs: H2+, U3
Location: Bulgaria
Has thanked: 4 times
Been thanked: 2 times
Contact:

Re: Playing with upstream (Exynos4412)

Post by 3dfx »

@meveric, would you please provide a little bit more info on the kernel installation?
Did you compile it yourself, or it was precompiled?
Can you provide any short tutorial?
Thank you in advance!

ScottE
Posts: 4
Joined: Thu Nov 20, 2014 1:47 am
languages_spoken: english
ODROIDs: ODROID-U2
Has thanked: 0
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Post by ScottE »

I have 5.7.x (current 5.7.2, ala vanilla-sources on Gentoo) working on my odroid-u2, but am struggling with USB. EHCI works enough for the NIC to work if I disable DWC2, but the external USB ports don't work (and looks like OHCI doesn't probe properly).

Code: Select all

    0.953903] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    0.960442] ehci-exynos: EHCI Exynos driver
[    0.965182] exynos-ehci 12580000.ehci: EHCI Host Controller
[    0.970169] exynos-ehci 12580000.ehci: new USB bus registered, assigned bus number 1
[    0.978065] exynos-ehci 12580000.ehci: irq 46, io mem 0x12580000
[    1.005241] exynos-ehci 12580000.ehci: USB 2.0 started, EHCI 1.00
[    1.005816] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.07
[    1.013933] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.021157] usb usb1: Product: EHCI Host Controller
[    1.026013] usb usb1: Manufacturer: Linux 5.7.2-scotte ehci_hcd
[    1.031900] usb usb1: SerialNumber: 12580000.ehci
[    1.036989] hub 1-0:1.0: USB hub found
[    1.040342] hub 1-0:1.0: 3 ports detected
[    1.044869] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    1.050495] ohci-exynos: OHCI Exynos driver
[    1.054830] usbcore: registered new interface driver usb-storage
[    1.348662] hid: raw HID events driver (C) Jiri Kosina
[    1.405220] usb 1-2: new high-speed USB device number 2 using exynos-ehci
[    1.606577] usb 1-2: New USB device found, idVendor=0424, idProduct=9730, bcdDevice= 1.00
[    1.612585] usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    1.623027] smsc95xx v1.0.6
[    1.721591] smsc95xx 1-2:1.0 eth0: register 'smsc95xx' at usb-12580000.ehci-2, smsc95xx USB 2.0 Ethernet, ce:6a:2d:3a:a2:da
If I enable DWC2 (which is the right thing to do), then USB doesn't seem to probe at all, and I see errors related to dwc. :-/

Anyone have a working "modern" config I can compare against? (or have some clues about my current config that's attached? Note that it's headless/multimedia-less.)
Attachments
572_scotte-config.txt
(80.16 KiB) Downloaded 70 times

ScottE
Posts: 4
Joined: Thu Nov 20, 2014 1:47 am
languages_spoken: english
ODROIDs: ODROID-U2
Has thanked: 0
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Post by ScottE »

ScottE wrote:
Wed Jun 17, 2020 4:34 am
I have 5.7.x (current 5.7.2, ala vanilla-sources on Gentoo) working on my odroid-u2, but am struggling with USB. EHCI works enough for the NIC to work if I disable DWC2, but the external USB ports don't work (and looks like OHCI doesn't probe properly).
Looks like this patch at least fixes external USB up enough that I can use EHCI based umass and rtk network adapters:

Code: Select all

--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -2018,6 +2018,9 @@
                struct usb_interface *intf = cp->interface[i];

                if (intf->dev.of_node &&
+                   /* Fix odroud-u2/u3 USB
+                   From https://lore.kernel.org/lkml/26ff3deb-4b8d-7dd2-2418-d56f6dcea313@samsung.com/ */
+                   of_device_is_compatible(intf->dev.of_node, NULL) &&
                    !of_device_is_available(intf->dev.of_node)) {
                        dev_info(&dev->dev, "skipping disabled interface %d\n",
                                 intf->cur_altsetting->desc.bInterfaceNumber);


anatife
Posts: 18
Joined: Wed May 14, 2014 10:52 am
languages_spoken: english french spanish c c++ java perl python
ODROIDs: U3 , C1
Has thanked: 3 times
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Post by anatife »

I have a couple of problems and I hope someone can assist.

After the log-in screen, I get a blank screen. How to diagnose this? I am able to get a terminal (e.g. ctrl-alt-F2) if I don't log in. I have apt-get updated/upgraded.

Second problem, is it possible to resize the SD card to use the full space? I wrote hexdump's image to a 16 GB SD card.

It is *awesome* to have Debian Buster for my U3. Thank you, friends!

hexdump
Posts: 21
Joined: Sat Jan 26, 2019 12:37 am
languages_spoken: english, german
ODROIDs: odroid u3
Has thanked: 0
Been thanked: 19 times
Contact:

Re: Playing with upstream (Exynos4412)

Post by hexdump »

@anatife there is a script to extend the root fs to the full space of the sd card in /root - just run it and / should use all remaining space afterwards ...

btw. i have built new odroid images, which have a new u-boot (v2020.07) with /boot/uEnv.txt support and a separat dtb for the u3 (without the plus - called u3noplus) ... you can find them here: https://github.com/hexdump0815/imagebui ... /200719-01

i'm not reading this forum here regularly, so maybe consider opening an issue on the above git repo in case of problems or ideas, but please do not expect professional grade response times :)

more info: some notes about building mainline u-boot for the u3 and how to write it to sd or emmc: https://github.com/hexdump0815/u-boot-m ... readme.exy

best wishes - hexdump

anatife
Posts: 18
Joined: Wed May 14, 2014 10:52 am
languages_spoken: english french spanish c c++ java perl python
ODROIDs: U3 , C1
Has thanked: 3 times
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Post by anatife »

Hello hexdump, it's kind of you to reply! I know that you do this for fun and not for the riches. (o;

I did the resize commands manually and it worked well. Video is still not working but having Debian Buster with ssh is good enough for my needs.

I'll join your project on github. Thank you for the new images!

hexdump
Posts: 21
Joined: Sat Jan 26, 2019 12:37 am
languages_spoken: english, german
ODROIDs: odroid u3
Has thanked: 0
Been thanked: 19 times
Contact:

Re: Playing with upstream (Exynos4412)

Post by hexdump »

i got my hands on an odroid x meanwhile and have added support for it to my u-boot build and my images now ... i have built new debian buster and ubuntu bionic images for the odroid u3/x2/x and maybe u2/u too - i have no access to any u2/u, so i cannot test them - feel free to donate me one if you have one and like to :) ... the images are available now here:
https://github.com/hexdump0815/imagebui ... /200823-01

kernel build info:
https://github.com/hexdump0815/linux-ma ... readme.exy

u-boot build info:
https://github.com/hexdump0815/u-boot-m ... readme.exy

they are based on the linux kernel v5.4.58 and have some other small fixes and changes. besides them i have also added a ubuntu focal test build of my dev branch at the same place ... some of the changes of the dev branch are mentioned on the download link above

in case you want try to do something completely different with your odroid, you might give my odroid u3/x2/x build of the sonaremin a try, which is a virtual modular synthesizer based on vcvrack:
https://github.com/hexdump0815/sonaremi ... v7l.img.gz

best wishes - hexdump
These users thanked the author hexdump for the post (total 4):
AreaScout (Mon Aug 24, 2020 3:19 pm) • robgue (Tue Aug 25, 2020 1:40 pm) • 3dfx (Tue Aug 25, 2020 10:07 pm) • CrispyDragon (Thu Mar 04, 2021 10:08 am)

robgue
Posts: 5
Joined: Thu Mar 28, 2013 5:49 am
languages_spoken: english
ODROIDs: U2
Has thanked: 1 time
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Post by robgue »

Thanks for this! I'm going to get my old U2 out of the junk drawer.

LiquidAcid
Posts: 1094
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2
Has thanked: 0
Been thanked: 2 times
Contact:

Re: Playing with upstream (Exynos4412)

Post by LiquidAcid »

Pushed odroid-5.4.y and odroid-5.8.y to my repo. I also migrated from Gentoo to Debian 10 on the board, since compilation of some packages is just not feasible anymore (due to increasing amount of memory consumption, in particular during the linking stage).

Surprisingly the migration worked rather smoothly. I just prepared a Debian 10 armhf environment on my desktop via debootstrap --foreign --arch=armhf and then allocated some space on the X2's SD card and moved the environment there. Then I just changed to bootloader to use the Debian filesystem as rootfs, /bin/sh as init and rootfs r/w mounting. First boot was done via serial console where I did the second stage of debootstrap, after which I changed init back to default. Second boot already got me a working Debian environment. Things are still a bit rough around the edges, but it's coming along.
These users thanked the author LiquidAcid for the post:
odroid (Thu Sep 03, 2020 9:32 am)

jonB
Posts: 4
Joined: Sat Mar 23, 2019 5:53 am
languages_spoken: english, italian, brazilian portuguese
ODROIDs: U3
Has thanked: 1 time
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Post by jonB »

hexdump wrote: imagebuilder scripts available at:
https://github.com/hexdump0815/imagebuilder
Hi hexdump,

Have been playing with your imagebuilder script... thanks for sharing - quite useful to revive my Odroid-U3 into something quite useful...At the moment am trying to add module fuse to it to attach external storage... but need to dig deeper on how to achieve this... any pointers or info please?

Also, the imagebuilder script does it support cross-compilation i.e. build a u3 arm image from a different device like x64 or another arm device?

Thanks in advance.

hansan
Posts: 14
Joined: Fri Jan 03, 2014 6:47 am
languages_spoken: English, Dutch, German, Japanese
ODROIDs: ODROID-U3
2x ODROID-HC1
Has thanked: 1 time
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Post by hansan »

anatife wrote:
Sat Jul 25, 2020 8:57 pm
Video is still not working but having Debian Buster with ssh is good enough for my needs.
Dear Anatife,

I believe I have the same issue. I can "login" with lightdm but I end up with a black screen. Both the Debian buster and the ubuntu 18.04 image have this problem for me. Were you able to solve this?

Needless to say is the ssh access working great.

Kind regards.

Hansan

hexdump
Posts: 21
Joined: Sat Jan 26, 2019 12:37 am
languages_spoken: english, german
ODROIDs: odroid u3
Has thanked: 0
Been thanked: 19 times
Contact:

Re: Playing with upstream (Exynos4412)

Post by hexdump »

@anatife @hansen - can you maybe give this image a try: https://github.com/hexdump0815/imagebui ... dev.img.gz - this is my dev image for ubuntu focal and for me it works perfectly fine on a odroid x, x2 and u3 and two different monitors (1280x1024 and 1980x1080, both via hdmi or vga to hdmi adapters) - if this image does not work neither then you might try to play around with forcing a certain hdmi mode (something like drm.edid_firmware=edid/1280x1024.bin or video=HDMI-A-1:1280x1024@60 on the kernel cmdline - for a mode the monitor supports of course)

@jonB for adding fuse support you might need to build a new kernel - see: https://github.com/hexdump0815/linux-ma ... readme.exy for how i build the kernel ... the scripts are not ment for cross compiling - i'm always building kernels and images on arm boxes directly

btw. i'm currently testing how useable those devices (2gb versions) are as desktop system and i'm surprised how well this works - i'm typing this on an odroid x2 overclocked to 1.7ghz right now which i'm currently using as my main desktop system using my above mentioned focal dev image - not that bad for an 8 years old sbc which was never really ment as a desktop system (ok - not as fast as a contemporary pc or laptop, but still quite useable)

i also noticed that even suspend/resume is working on the u3 (not yet tested on the x2) - tested with the same focal dev image - suspend via xfce logout menu and resume via that button on the u3 - root fs is on a usb stick in this case

best wishes - hexdump
These users thanked the author hexdump for the post:
hansan (Sat Oct 31, 2020 6:50 am)

hansan
Posts: 14
Joined: Fri Jan 03, 2014 6:47 am
languages_spoken: English, Dutch, German, Japanese
ODROIDs: ODROID-U3
2x ODROID-HC1
Has thanked: 1 time
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Post by hansan »

Dear Hexdump,

Thanks for your work on this. I will check the ubuntu focal image and report back to you. In all honesty I cannot really exclude a questionable micro HDMI cable.

Greetings,

Han

mories
Posts: 33
Joined: Fri Mar 21, 2014 6:23 pm
languages_spoken: english
Has thanked: 0
Been thanked: 0
Contact:

How to get the kernel to define /dev/fb0

Post by mories »

I want to use framebuffer-vncserver (VNC server for Linux framebuffer devices), but neither in the hexdump's last image for U3 nor in other vanilla 5.4.y kernels that I have compiled, /dev/fb0 is generated.
In old hardkernel's 3.8.y kernel there was /dev/fb0.
Someone knows how to configure a kernel 5.4.y for such a device to be created in U3.?

hansan
Posts: 14
Joined: Fri Jan 03, 2014 6:47 am
languages_spoken: English, Dutch, German, Japanese
ODROIDs: ODROID-U3
2x ODROID-HC1
Has thanked: 1 time
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Post by hansan »

The new ubuntu focal image did not work for me. That means the screen still stays black and I do not get an graphical login prompt on my monitor. On my TV I can get a text mode terminal; but it does not fully reproduce... and the graphical login does not show up. I assume that this means that my micro-hdmi cable is bad. I will get a new cable / micro HDMI to HDMI adapter and try again.

I have installed the image to a 32Gbyte micro sd card. I did do

Code: Select all

sudo apt-get update
sudo apt-get upgrade
I have added my boot log (dmesg) and Xorg log maybe it shows why my screen stays black. (I did not recognize a clear error....)

To be continued....
Attachments
tv-Xorg.0.log
Xorg log on TV 1920x1080
(17.53 KiB) Downloaded 20 times
tv-dmesg.log
dmesg boot log on tv 1920x1080
(37.82 KiB) Downloaded 17 times
monitor-Xorg.0.log
Xorg log on monitor 1920x1080
(17.53 KiB) Downloaded 23 times
monitor-dmesg.log
dmesg boot log on monitor 1920x180
(37.47 KiB) Downloaded 18 times

nijhawank
Posts: 43
Joined: Sat Aug 03, 2013 7:35 am
languages_spoken: english
Has thanked: 0
Been thanked: 1 time
Contact:

Re: Playing with upstream (Exynos4412)

Post by nijhawank »

For the people who get black screen after logging, try removing video=HDMI-A-1:1280x1024@60 from the extlinux.conf

hansan
Posts: 14
Joined: Fri Jan 03, 2014 6:47 am
languages_spoken: English, Dutch, German, Japanese
ODROIDs: ODROID-U3
2x ODROID-HC1
Has thanked: 1 time
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Post by hansan »

by nijhawank » Fri Oct 16, 2020 6:09 am
For the people who get black screen after logging, try removing video=HDMI-A-1:1280x1024@60 from the extlinux.conf
I can more or less confirm this. When I use something to fix a monitor format (I mainly checked 1920x1080) with

Code: Select all

video=HDMI-A-1:1920x1080@60
my screen stays black but with the following

Code: Select all

video=HDMI-A-1:e
I can get a login screen when I restart the display manager (lightdm).

So I think that things / timing is rather sensitive, but my cable is / was not the problem. My monitor has a resolution of 1920x1200 and this format is not supported; this can be also a reason why things don't work. However on my 1920x1080 television was I also not successful.

I have this in my "extlinux.conf":

Code: Select all

linux@changeme:~$ cat /boot/extlinux/extlinux.conf 
TIMEOUT 30
DEFAULT linux

MENU TITLE odroid u3 boot options

LABEL linux
      MENU LABEL linux
      LINUX ../zImage-5.4.58-stb-exy+
      INITRD ../initrd.img-5.4.58-stb-exy+
# odroid u3
      FDT ../dtb-5.4.58-stb-exy+/exynos4412-odroidu3noplus.dtb
# use this line instead of the one below in case hdmi video is unstable for a 1024x768 video mode
#      APPEND earlycon console=ttySAC1,115200n8 console=tty1 mem=2047M smsc95xx.macaddr=ba:5d:6d:41:68:6f root=PARTUUID=cf4c6c41-02 ro loglevel=8 rootwait net.ifnames=0 pv6.disable=1 fsck.repair=yes drm.edid_firmware=edid/1024x768.bin video=HDMI-A-1:e
#      APPEND earlycon console=ttySAC1,115200n8 console=tty1 mem=2047M smsc95xx.macaddr=ba:5d:6d:41:68:6f root=PARTUUID=cf4c6c41-02 ro loglevel=8 rootwait net.ifnames=0 ipv6.disable=1 fsck.repair=yes drm.edid_firmware=edid/1920x1080.bin video=HDMI-A-1:1920x1080@60
# this line works for me:
      APPEND earlycon console=ttySAC1,115200n8 console=tty1 mem=2047M smsc95xx.macaddr=ba:5d:6d:41:68:6f root=PARTUUID=cf4c6c41-02 ro loglevel=8 rootwait net.ifnames=0 ipv6.disable=1 fsck.repair=yes video=HDMI-A-1:e
Furthermore I have added the following line to my rc.local to restart the lightdm.service after 20 seconds. (This time is relative arbitrary; I can imagine that moving the service to a later start time with systemd could work as well.)

Code: Select all

linux@changeme:~$ tail /etc/rc.local
# uncomment this to get rid of the blinking blue led
#echo none > /sys/class/leds/led1:heart/trigger

# I question if this all is working
MYLOG=/var/log/hanrc.log

echo `date` >> ${MYLOG}
(sleep 20;  /usr/bin/systemctl restart lightdm.service 2>&1 >> ${MYLOG}) &

exit 0
This makes that I am greeted by a login screen and I can login into the desktop version. So a success !!

I do have sometimes a bit of a "wiggle" in the screen; just if the timing of the video signal gets lost. Occasionally is the screen becoming black for a few seconds. Maybe it is due to my unsupported monitor size....

Next I have to get this image on my emmc and I am up and running again!
Thanks for making these images and kernels for this Odroid U3!!

hansan
Posts: 14
Joined: Fri Jan 03, 2014 6:47 am
languages_spoken: English, Dutch, German, Japanese
ODROIDs: ODROID-U3
2x ODROID-HC1
Has thanked: 1 time
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Post by hansan »

Just an update from my side.

It was not the success I thought; the occasional wiggle in the screen was a bit distracting. But the monitor started to become black quite often and I had to change to the console and back to get my screen back. I think there went something wrong with the timing in the HDMI which doesn't did work with my monitor. (Nothing special: an AOC P2460Pxqu https://eu.aoc.com/de/monitors/p2460pxqu/support

I have upgraded my kernel to version 5.9.0 with the information from here: https://github.com/hexdump0815/linux-ma ... readme.exy and now is the image on my monitor not becoming black anymore. (The wiggle is occasionally still there.) My compliments to hexdump for his good work on this.

I did had to correct this post. I forgot one patch and therefore was my Mali driver not working / not loaded. When i use the right patches is it of course working.

For now I am quite satisfied. Greetings!

hansan
Posts: 14
Joined: Fri Jan 03, 2014 6:47 am
languages_spoken: English, Dutch, German, Japanese
ODROIDs: ODROID-U3
2x ODROID-HC1
Has thanked: 1 time
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Post by hansan »

I noticed that the Mali driver is loading, but X does not look to be accelerated / using Mali. Got someone else this working?

The Mali driver is loading:

Code: Select all

dmesg | grep -i Mali
[    8.060132] Mali<2>: Inserting Mali v600 device driver. 
[    8.060137] Mali<2>: Driver revision: r5p0-01rel0
[    8.060138] Mali<2>: mali_module_init() registering driver
[    8.060686] Mali<2>: mali_probe(): Called for platform device 13000000.gpu
[    8.060696] mali-utgard 13000000.gpu: Mali platform: init()
[    8.076636] mali-utgard 13000000.gpu: Mali platform: G3D clock rate = 24 MHz
[    8.076938] mali-utgard 13000000.gpu: Mali platform: initial G3D core clock rate = 160 MHz
[    8.082524] mali-utgard 13000000.gpu: Mali platform: OPP check (freq = 160, down = 0, up = 700)
[    8.082533] mali-utgard 13000000.gpu: Mali platform: OPP check (freq = 266, down = 620, up = 900)
[    8.082537] mali-utgard 13000000.gpu: Mali platform: OPP check (freq = 350, down = 850, up = 900)
[    8.082541] mali-utgard 13000000.gpu: Mali platform: OPP check (freq = 440, down = 850, up = 1000)
[    8.082694] Mali<2>: initialize_subsystems() called
[    8.082722] Mali<2>: Mali memory settings (shared: 0xFFFFFFFF)
[    8.082725] Mali<2>: Using device defined frame buffer settings (0x06000000@0xB7000000)
[    8.082728] Mali<2>: Memory Validator installed for Mali physical address base=0xB7000000, size=0x06000000
[    8.082733] Mali<2>: Mali PM domain: Creating Mali PM domain (mask=0x00001000)
[    8.082738] mali-utgard 13000000.gpu: Mali platform: enable()
[    8.082743] Mali<2>: initialize_hardware() called
[    8.083155] Mali<2>: Mali PP: Creating Mali PP core: Mali_PP0
[    8.083162] Mali<2>: Mali PP: Base address of PP core: 0x13008000
[    8.083323] Mali<2>: Found Mali GPU Mali-400 MP r1p1
[    8.087516] Mali<2>: Mali L2 cache: Created Mali_L2: 128K, 4-way, 64byte cache line,  64bit external bus
[    8.087529] Mali<2>: Mali MMU: Creating Mali MMU: Mali_GP_MMU
[    8.087581] Mali<2>: mali_mmu_probe_irq_acknowledge: intstat 0x3
[    8.087583] Mali<2>: Probe: Page fault detect: PASSED
[    8.087585] Mali<2>: Probe: Bus read error detect: PASSED
[    8.087614] Mali<2>: Mali GP: Creating Mali GP core: Mali_GP
[    8.087659] Mali<2>: Mali MMU: Creating Mali MMU: Mali_PP0_MMU
[    8.087695] Mali<2>: mali_mmu_probe_irq_acknowledge: intstat 0x3
[    8.087697] Mali<2>: Probe: Page fault detect: PASSED
[    8.087699] Mali<2>: Probe: Bus read error detect: PASSED
[    8.087720] Mali<2>: Mali PP: Creating Mali PP core: Mali_PP0
[    8.087723] Mali<2>: Mali PP: Base address of PP core: 0x13008000
[    8.087760] Mali<2>: Mali MMU: Creating Mali MMU: Mali_PP1_MMU
[    8.087799] Mali<2>: mali_mmu_probe_irq_acknowledge: intstat 0x3
[    8.087801] Mali<2>: Probe: Page fault detect: PASSED
[    8.087802] Mali<2>: Probe: Bus read error detect: PASSED
[    8.087824] Mali<2>: Mali PP: Creating Mali PP core: Mali_PP1
[    8.087826] Mali<2>: Mali PP: Base address of PP core: 0x1300a000
[    8.087873] Mali<2>: Mali MMU: Creating Mali MMU: Mali_PP2_MMU
[    8.087903] Mali<2>: mali_mmu_probe_irq_acknowledge: intstat 0x3
[    8.087905] Mali<2>: Probe: Page fault detect: PASSED
[    8.087906] Mali<2>: Probe: Bus read error detect: PASSED
[    8.087926] Mali<2>: Mali PP: Creating Mali PP core: Mali_PP2
[    8.087929] Mali<2>: Mali PP: Base address of PP core: 0x1300c000
[    8.087980] Mali<2>: Mali MMU: Creating Mali MMU: Mali_PP3_MMU
[    8.088011] Mali<2>: mali_mmu_probe_irq_acknowledge: intstat 0x3
[    8.088013] Mali<2>: Probe: Page fault detect: PASSED
[    8.088015] Mali<2>: Probe: Bus read error detect: PASSED
[    8.088035] Mali<2>: Mali PP: Creating Mali PP core: Mali_PP3
[    8.088038] Mali<2>: Mali PP: Base address of PP core: 0x1300e000
[    8.088084] Mali<2>: 4+0 PP cores initialized
[    8.088093] Mali<2>: Mali GPU Timer: 100
[    8.088096] Mali<2>: Mali GPU Utilization: Utilization handler installed 
[    8.088590] Mali<2>: mali_probe(): Successfully initialized driver for platform device 13000000.gpu
[    8.088880] Mali: Mali device driver loaded
But with glxinfo I do not see any acceleration.

Somehow I would think that the lima driver is maybe the better choice for this platform, because it is really open source and supported in upstream mesa.

So I took the kernel of hexdump (https://github.com/hexdump0815/linux-ma ... ble-kernel). From which I have removed the mali related patches. (And I installed a latest mesa version.)

This gives me a working lima driver:

Code: Select all

uname -a
Linux coralu3 5.9.0-stb-exy+ #5 SMP PREEMPT Mon Nov 2 21:56:31 CET 2020 armv7l armv7l armv7l GNU/Linux
dmesg | grep lima
[    9.039097] lima 13000000.gpu: gp - mali400 version major 1 minor 1
[    9.039140] lima 13000000.gpu: pp0 - mali400 version major 1 minor 1
[    9.039174] lima 13000000.gpu: pp1 - mali400 version major 1 minor 1
[    9.039207] lima 13000000.gpu: pp2 - mali400 version major 1 minor 1
[    9.039242] lima 13000000.gpu: pp3 - mali400 version major 1 minor 1
[    9.039267] lima 13000000.gpu: l2 cache 128K, 4-way, 64byte cache line, 64bit external bus
[    9.075377] lima 13000000.gpu: bus rate = 24000000
[    9.075386] lima 13000000.gpu: mod rate = 50000000
[    9.092567] lima 13000000.gpu: _opp_add: OPP not supported by regulators (160000000)
[    9.092996] lima 13000000.gpu: Failed to register cooling device
[    9.115142] [drm] Initialized lima 1.1.0 20191231 for 13000000.gpu on minor 1
And this delivers hardware acceleration according the glxinfo:

Code: Select all

glxinfo -B
ame of display: :0.0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: lima (0x13b5)
    Device: Mali400 (0xffffffff)
    Version: 20.3.0
    Accelerated: yes
    Video memory: 0MB
    Unified memory: yes
    Preferred profile: compat (0x2)
    Max core profile version: 0.0
    Max compat profile version: 2.1
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 2.0
OpenGL vendor string: lima
OpenGL renderer string: Mali400
OpenGL version string: 2.1 Mesa 20.3.0-devel (git-ea83fd9 2020-11-01 focal-oibaf-ppa)
OpenGL shading language version string: 1.20

OpenGL ES profile version string: OpenGL ES 2.0 Mesa 20.3.0-devel (git-ea83fd9 2020-11-01 focal-oibaf-ppa)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
I don't know if video memory 0MB is expected, but otherwise I see this as good news.

However I have two items that I don't understand:
1. glxgears gives actually a lower frame rate than before.... 38 vs 140
2. I have the following in my kernel log, which I don't know what it means:

Code: Select all

[  951.961786] exynos-drm exynos-drm: [drm:exynos_user_fb_create] *ERROR* failed to lookup gem object
Did someone else experiment with this?

hexdump
Posts: 21
Joined: Sat Jan 26, 2019 12:37 am
languages_spoken: english, german
ODROIDs: odroid u3
Has thanked: 0
Been thanked: 19 times
Contact:

Re: Playing with upstream (Exynos4412)

Post by hexdump »

@mories - i have no idea what the problem with the framebuffer is, but i think its not very odroid specific, but most probably relevant for some other hardware too, so maybe searching the net in general for solutions might help - maybe compiling a kernel with CONFIG_FB_VIRTUAL helps in your case?

@hansan - looks like you got most of your problems solved already and its nice to see your progress ... i'm still using the old mali driver as lima still has some problems if used with more complex opengl apps (see https://gitlab.freedesktop.org/mesa/mes ... ote_679569 for instance) but lima should work quite well in many cases as you found out yourself already ... for using the mali blobs you will have to set some env variables - basically you need the armsoc xserver in case you want to use egl and make sure the mali blob dir in /opt is in your LD_LIBRARRY_PATH or i'm often using gl4es to wrap it for full opengl support (i.e. putting the gl4es and then the mali blob dir into the LD_LIBRARRY_PATH) and one can then even use LIBGL_FB=3 and the fbdev mali blob to even use it with the default modesetting xorg server

mali (legacy or lima) is very slow in xorg as all the screen content has to be copied around in memory a few times as on most arm devices the display hardware and 3d gpu are separate devices instead of one united device like on intel ... wayland and lima should give much better performance than xorg ... also please keep in mind that a mali400 is not really the fastest gpu by todays standards ... with software rendering you'll get higher fps rates, but also have a much higher cpu usage as the cpu has to do all the work

one final note: in case you want to use linux more as a server, you might have a look at this other image which is now avaiable too: viewtopic.php?p=307479#p307479 in case you do not know it yet ... btw. i have meanwhile compiled a new v5.9.3 kernel too - see: https://github.com/hexdump0815/linux-ma ... stb-exy%2B

it is very nice to see the odroid x & u community to be still quite alive and those now nearly 8 year old sbc's to be still in use - i think they are still very useable hardware ...

best wishes - hexdump
These users thanked the author hexdump for the post:
glodi (Fri Dec 04, 2020 3:31 am)

User avatar
meveric
Posts: 11545
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go, H2 (N4100), N2, H2 (J4105), GoA, C4, GoA v1.1, H2+, HC4, GoS
Has thanked: 69 times
Been thanked: 482 times
Contact:

Re: Playing with upstream (Exynos4412)

Post by meveric »

a few remarks to that:
hexdump wrote:
Thu Nov 05, 2020 3:17 am
@hansan - looks like you got most of your problems solved already and its nice to see your progress ... i'm still using the old mali driver as lima still has some problems if used with more complex opengl apps (see https://gitlab.freedesktop.org/mesa/mes ... ote_679569 for instance) but lima should work quite well in many cases as you found out yourself already ... for using the mali blobs you will have to set some env variables - basically you need the armsoc xserver in case you want to use egl and make sure the mali blob dir in /opt is in your LD_LIBRARRY_PATH or i'm often using gl4es to wrap it for full opengl support (i.e. putting the gl4es and then the mali blob dir into the LD_LIBRARRY_PATH) and one can then even use LIBGL_FB=3 and the fbdev mali blob to even use it with the default modesetting xorg server
First lima implements OpenGL 2.0 as well, so there would be no need for gl4es as lima supports this in MESA.
Mali blobs on the other hand do need gl4es to support OpenGL calls.
hexdump wrote:
Thu Nov 05, 2020 3:17 am
mali (legacy or lima) is very slow in xorg as all the screen content has to be copied around in memory a few times as on most arm devices the display hardware and 3d gpu are separate devices instead of one united device like on intel ... wayland and lima should give much better performance than xorg ... also please keep in mind that a mali400 is not really the fastest gpu by todays standards ... with software rendering you'll get higher fps rates, but also have a much higher cpu usage as the cpu has to do all the work
See, that's actually a misconception "The GPU is slow"... "CPU Software rendering is faster"... what would be the point of having a GPU in first place?
The original implementation for the GPU and the drivers, running on the old 3.8 Kernel under X11 was actually able to render fullscreen 3D application in 80~100 FPS (lima and upstream Kernel can't even keep up with 60 FPS).
glmark2-es2 in window mode even went as high as 180 FPS (and just finished with an average of 141 FPS), so saying the GPU is "slow" is really not the case.
While it's fun and all that it's running on opensource drivers with a recent Kernel, it took a HUGE performance hit cause of this.
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

hansan
Posts: 14
Joined: Fri Jan 03, 2014 6:47 am
languages_spoken: English, Dutch, German, Japanese
ODROIDs: ODROID-U3
2x ODROID-HC1
Has thanked: 1 time
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Post by hansan »

Hello Hexdump and Meveric; many thanks for the additional information. I will check kernel 5.9.3 as well.

For my application (playing around with google coral https://coral.ai/ ) is the gpu speed not really an important thing. I need a somewhat working desktop environment to be able to check what the camera is doing.

But while I don't really use/need the gpu is it a pitty that the lima (MALI400) support become some much slower. Is there a specific reason for and is it fixable?

I am still unhappy about the errors in my kernel log:

Code: Select all

[154239.399867] exynos-drm exynos-drm: [drm:exynos_user_fb_create] *ERROR* failed to lookup gem object
[154299.456566] exynos-drm exynos-drm: [drm:exynos_user_fb_create] *ERROR* failed to lookup gem object
[154359.403227] exynos-drm exynos-drm: [drm:exynos_user_fb_create] *ERROR* failed to lookup gem object
[154419.401178] exynos-drm exynos-drm: [drm:exynos_user_fb_create] *ERROR* failed to lookup gem object
[154479.457146] exynos-drm exynos-drm: [drm:exynos_user_fb_create] *ERROR* failed to lookup gem object
[154539.431516] exynos-drm exynos-drm: [drm:exynos_user_fb_create] *ERROR* failed to lookup gem object
[154599.455404] exynos-drm exynos-drm: [drm:exynos_user_fb_create] *ERROR* failed to lookup gem object
[154659.459856] exynos-drm exynos-drm: [drm:exynos_user_fb_create] *ERROR* failed to lookup gem object
[154719.401198] exynos-drm exynos-drm: [drm:exynos_user_fb_create] *ERROR* failed to lookup gem object
[154734.250702] exynos-drm exynos-drm: [drm:exynos_user_fb_create] *ERROR* failed to lookup gem object
I find it difficult to debug this because I miss some understanding.
The error comes from the exynos_user_fb_create function in the exynos_drm_fb.c file. The object that is returned is some how "NULL" which triggers this message.
It looks like that the issue is related with how memory is allocated (in older kernels with DMA, but that is with the IOMMU of Samsung also not so easy I understood from some forum posts.). Or is just X sending chaos over?

I can imagine that the artificial slow GPU has something to do with the limited support base. And that is again due to the relative short market time of this type of socs. This does not create enough traction to get a very good support for all the features and goodies in mainline. The Raspberry Pi team does in that sense a better job with (up to Pi4) a worse soc.

Mark1250
Posts: 29
Joined: Fri Jan 09, 2015 1:26 am
languages_spoken: english
ODROIDs: U3, XU4, C1+, C2, N2
Has thanked: 1 time
Been thanked: 2 times
Contact:

Re: Playing with upstream (Exynos4412)

Post by Mark1250 »

I'm looking for information on what people are using as a build environment for u-boot.

I have a U3 that I had updated u-boot on and I was running Ubuntu 18.04 with a newer self built kernel, but somehow I messed up my eMMC and it would no longer boot. I used the eMMC Recovery image. Now I'm unable to boot newer operating systems. I tried building u-boot without success. So I have the following questions:
  1. I plan on using a virtual machine running Ubuntu to cross compile. What version of Ubuntu should I be using?
  2. What architecture, 32 bit or 64 bit?
  3. What tool chain should I use to cross compile?
I see https://github.com/hexdump0815/u-boot-m ... r/misc.exy has boot.tar.gz . It seems that all components except the dtb are present. If a have a dtb, can I dd these to my eMMC as explained in hexdumps readme.exy without having to compile u-boot?

I'm trying to wrap my brain around how this all works.

Thanks for any assistance.

Mark

hansan
Posts: 14
Joined: Fri Jan 03, 2014 6:47 am
languages_spoken: English, Dutch, German, Japanese
ODROIDs: ODROID-U3
2x ODROID-HC1
Has thanked: 1 time
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Post by hansan »

Using the eMMC with u-boot gives indeed some challenges.

You have to overcome two hurdles:
Point 1. that can go wrong.
The boot part of the eMMC is not the same as for an miroSD card. There is a secure block/partition that is used for the boot process. That means that when you write your image to the eMMC with a micro sd adapter you are basically not upgrading the boot part (u-boot and all Samsung specific primary loaders) but just filling the first normal sectors with not used information.
This problem you can be solved in two ways:
A. Use a microSD card image / other system that has a kernel that can access the secure boot block on the eMMC. (Probably you have to boot from SD and then stick the eMMC to the U3 or other board.)
This should work but I have never used this method. Hexdumps description where you were looking at assumes that you have this kernel/adapter that supports this access to the secure partition. And therefore he can dd u-boot to the secure eMMC partition. I cannot do this with my eMMC to microSD card converter.
B. Use the eMMC rescue image to update the boot partition on the eMMC. This image is copying all files from the update directory in the right way to the eMMC. When you copy your own u-boot to this partition then your eMMC is correctly updated. See also https://haokof.blogspot.com/2017/03/odr ... emory.html for some more information. I use always this method. If you do not update the u-boot version in the standard rescue image then you are stuck again with a very old u-boot which is probably trying to load the kernel with the wrong name from the wrong location.

Point 2. that can go wrong.
The process to load u-boot is more or less standard but not so the process to load the linux kernel by u-boot. Depending on your u-boot generation are different kernel formats, kernel locations and different "setting" files expected. Using one distribution and an u-boot made for a different one will often not work out of the box. You need to change the hard-coded environmental variables in uboot and/or make the correct setting file (boot.src, boot.txt. uEnv.txt. Extlinux.conf etc.) in the right type of partition / location on disk. In practice doable but a very painful process.

From which source did you get this Ubuntu 18.04 image?
How is your /boot or boot partition contents / layout?
Is this hexdump u-boot compatible with our distribution image?

If it is an image from hexdump then you can follow this: https://github.com/hexdump0815/u-boot-m ... readme.exy until he starts to dd the u-boot and other loaders to a disk. From there you have to copy (=use cp) those files to your eMMC rescue image. With that image on a micro SD card you can update your eMMC again with the latest version of u-boot.

I like the extlinux support of this u-boot version very much; makes changes much easier than with the older uEnv.txt and boot.txt like config files. And you can have a boot menu for different kernel versions.

I hope this help. When needed I can generate you a rescue image.

To be honest when I think about it I think it is strange that you was able, despite the secure sectors, to damage your u-boot on the eMMC . What did you do? Can it be that your u-boot configuration file is damaged?

Mark1250
Posts: 29
Joined: Fri Jan 09, 2015 1:26 am
languages_spoken: english
ODROIDs: U3, XU4, C1+, C2, N2
Has thanked: 1 time
Been thanked: 2 times
Contact:

Re: Playing with upstream (Exynos4412)

Post by Mark1250 »

@hansan I couldn't get rrd's Ubuntu 20.04 viewtopic.php?f=77&t=40419 image to boot so I foolishly used the eMMC recovery image which then left me with a very old u-boot.

After some trials and a lot of errors, I figured out how to cross-compile u-boot for the U3, and install it to my eMMC.

This is all based on hexdump0815 hard work.

Code: Select all

I created a KVM VM start with Ubuntu 18.04 minimal image. I run openSuse on my desktop computer, so it was simpler to just use a VM.

After the VM is installed and fully updated.

As root or use sudo
apt install:
git
build-essential
g++-8-arm-linux-gnueabi
gcc-8-arm-linux-gnueabi
device-tree-compiler
bison
flex
unzip

Create symlinks to the installed CROSS_COMPILE C & C++ binaries:

ln -s /usr/bin/arm-linux-gnueabi-gcc-8 /usr/bin/arm-eabi-gcc
ln -s /usr/bin/arm-linux-gnueabi-as /usr/bin/arm-eabi-as
ln -s /usr/bin/arm-linux-gnueabi-ld /usr/bin/arm-eabi-ld
ln -s /usr/bin/arm-linux-gnueabi-ar /usr/bin/arm-eabi-ar
ln -s /usr/bin/arm-linux-gnueabi-objcopy /usr/bin/arm-eabi-objcopy
ln -s /usr/bin/arm-linux-gnueabi-readelf /usr/bin/arm-eabi-readelf
ln -s /usr/bin/arm-linux-gnueabi-objdump /usr/bin/arm-eabi-objdump
ln -s /usr/bin/arm-linux-gnueabi-nm /usr/bin/arm-eabi-nm

As regular user:

export CROSS_COMPILE=arm-eabi-

The following section comes from https://github.com/hexdump0815/u-boot-misc/blob/master/readme.exy

git clone https://gitlab.denx.de/u-boot/u-boot.git/
mv u-boot u-boot-mainline-exy
cd u-boot-mainline-exy
git checkout v2020.07
wget https://github.com/hexdump0815/u-boot-misc/raw/master/misc.exy/add-odroid-x-support-and-uenv-txt.patch
patch -p1 < add-odroid-x-support-and-uenv-txt.patch
make odroid_defconfig
make -j4

cp u-boot.bin exy-u-boot.bin
cd ..

mkdir u-boot-workdir-exy
cd u-boot-workdir-exy
wget https://github.com/hexdump0815/u-boot-misc/raw/master/misc.exy/boot.tar.gz
tar -xzf boot.tar.gz
cd boot
cp ../../u-boot-mainline-exy/u-boot-dtb.bin .

dd iflag=dsync oflag=dsync if=./E4412_S.bl1.HardKernel.bin of=exy-boot.dd seek=1
dd iflag=dsync oflag=dsync if=./bl2.signed.bin of=exy-boot.dd seek=31
dd iflag=dsync oflag=dsync if=./u-boot-dtb.bin of=exy-boot.dd seek=63
dd iflag=dsync oflag=dsync if=./E4412_S.tzsw.signed.bin of=exy-boot.dd seek=2111

Copy exy-boot.dd to a microSD card with a suitable image for OdroidU3. - I used rrd's Ubuntu 20.04 image.
  Either mount the microSD on desktop computer or scp the file to the running U3
  
With the U3 running off of the microSD card carefully install eMMC onto U3 board

As root or via sudo

fdisk -l Should show both the microSD and eMMC
  Use the mount command to see which mmcblk is mounted on root (which is the microSD card.  - It was mmcblk0 for me.
  
You can make a copy of the hidden boot partion of the eMMC with:
  dd if=/dev/mmcblk1boot0 of=old-boot-block.dd iflag=dsync oflag=dsync status=progress
  
Make the hidden boot partion writable:
  echo 0 > /sys/block/mmcblk1part0/force_ro
  
Write the boot block to the eMMC.
  dd if=exy-boot.dd of=/dev/mmcblk1boot0 bs=512 skip=1 iflag=dsync oflag=dsync status=progress


I had already dd'ed rrd's Ubuntu 20.04 image on the eMMC, so I shut the U3 down removed the microSD card and booted from the eMMC.
Hopefully this helps somebody else.

Mark

Steevee28
Posts: 17
Joined: Tue Jan 30, 2018 4:55 pm
languages_spoken: english, german
ODROIDs: U3
Has thanked: 1 time
Been thanked: 4 times
Contact:

Re: Playing with upstream (Exynos4412) - instable HDMI output

Post by Steevee28 »

Hi all,

I'm struggling since days to get a stable HDMI output with my U3+ (Rev0.5) using these kernels. Installing the image from @rrd and upgrading it to a graphical desktop worked like a charm. The system boots, the kernel boot messages are displayed via HDMI, but almost every time when I'm about to reach the graphical login screen, the HDMI output suddenly switches itself off.
Using hexdump's generic build I now tried several different mainline kernels from 5.4.20 up to 5.10.32, some in Mali, some in Lima configuration, I also tried several different display managers - but all with no difference at all :? Still, the HDMI output only works sporadically for me. Strangely, there is no error in the logs, so the software still thinks that HDMI is working.

Although it seems now for that reason that the HDMI output of my U3+ is somehow defective, I'm pretty sure that it is okay, because when I change SD-Cards and switch back to the original installation based on Hardkernel's kernel 3.8.y, the HDMI output works again without any flaws. So for me, it seems that the problem is still caused by some hardware settings of the new kernel, e.g. some voltage regulator configuration or some clock PLL configuration or some floating voltage level somewhere or whatever.

Is there any progress in understanding what the reason for this could be?

EDIT: I didn't realize than @hansan obviously got rid of this problems with kernel 5.9.0, which is strange, because I also tried later kernels and still none of them gave me a reliable HDMI. So I guess that its just "luck" that it currently works for him. Note also that he has a U3, and I have a U3+, but it seems to make no difference.

Btw. my current kernel parameters are (...) video=HDMI-A-1:e drm.edid_firmware=edid/1024x768.bin, but I also tried different resolutions and also let monitor and Odroid handshake a format. All this still didn't help.

UPDATE: The problem seems to be all about misconfigured HDMI Audio Infoframes that unfortunately also get sent when HDMI is in DVI mode (when using drm.edid_firmware kernel parameter).
I'm working on it.
Last edited by Steevee28 on Wed Apr 28, 2021 7:57 pm, edited 1 time in total.

Steevee28
Posts: 17
Joined: Tue Jan 30, 2018 4:55 pm
languages_spoken: english, german
ODROIDs: U3
Has thanked: 1 time
Been thanked: 4 times
Contact:

Re: Playing with upstream (Exynos4412) - instable HDMI output

Post by Steevee28 »

Update: enabling all drm debug messages revealed the following strange messages meanwhile booting:

Code: Select all

[   41.139288] [drm:drm_atomic_get_connector_state] Added [CONNECTOR:47:HDMI-A-1] 8671bfa8 state to 7c9a5cdf
[   41.139317] [drm:drm_atomic_check_only] checking 7c9a5cdf
[   41.139347] [drm:drm_atomic_helper_check_modeset] Updating routing for [CONNECTOR:47:HDMI-A-1]
[   41.139373] [drm:drm_atomic_helper_check_modeset] [CONNECTOR:47:HDMI-A-1] keeps [ENCODER:46:TMDS-46], now on [CRTC:45:crtc-0]
[   41.139399] [drm:drm_atomic_add_encoder_bridges] Adding all bridges for [encoder:46:TMDS-46] to 7c9a5cdf
[   41.139423] [drm:drm_atomic_add_encoder_bridges] Adding all bridges for [encoder:46:TMDS-46] to 7c9a5cdf
[   41.139453] [drm:drm_mode_object_get] OBJ ID: 47 (7)
[   41.139484] exynos-hdmi 12d00000.hdmi: [drm:hdmi_mode_valid] xres=1920, yres=1080, refresh=26, intl=0 clock=65000000
[   41.139500] [drm:drm_mode_object_put.part.0] OBJ ID: 47 (7)
[   41.139519] [drm:drm_atomic_commit] committing 7c9a5cdf
[   41.139605] exynos-drm exynos-drm: [drm:drm_calc_timestamping_constants] crtc 45: hwmode: htotal 2200, vtotal 1125, vdisplay 1080
[   41.139632] exynos-drm exynos-drm: [drm:drm_calc_timestamping_constants] crtc 45: clock 65000 kHz framedur 38076923 linedur 33846
note the absurd 1920x1080@26Hz timing... hm... I don't know where this comes from. I configured the device to startup in 1024x768@60Hz !???

Steevee28
Posts: 17
Joined: Tue Jan 30, 2018 4:55 pm
languages_spoken: english, german
ODROIDs: U3
Has thanked: 1 time
Been thanked: 4 times
Contact:

Re: Playing with upstream (Exynos4412) - instable HDMI output

Post by Steevee28 »

Ok, now I have a patch file, see attachment. Perhaps someone here is willing to review / test.

This definitely fixes two things:
  • Audio InfoFrames will now no longer accidentally be sent when HDMI is switched to DVI mode (which is the case when drm.edid_firmware kernel parameter is used, because the built-in EDIDs don't have CEA extensions)
  • Now, when Audio is on, the Audio InfoFrames that are passed down from the driver will be used (see hdata->audio.params.cea) instead of a dummy Audio InfoFrame
Unfortunately, this does NOT fix the problems for me, which is really odd, because I also (re-)added code doing a full Exynos HDMI register dump (not included in this patch) and compared the results to what the original 3.8 kernel wrote down to the chip and there seems no more difference.
So, I think I'm giving up at this point. :cry:
Attachments
exynos_hdmi-infoframes-patch.txt
(3.4 KiB) Downloaded 10 times

hexdump
Posts: 21
Joined: Sat Jan 26, 2019 12:37 am
languages_spoken: english, german
ODROIDs: odroid u3
Has thanked: 0
Been thanked: 19 times
Contact:

Re: Playing with upstream (Exynos4412)

Post by hexdump »

@Steevee28 - thanks for your investigations. sadly i can not help much here as you seem to understand more of those hdmi topics than me. i have added your audio frame fix patch to my kernel build notes and it should be included in the next build. for me hdmi seems to work quite ok meanwhile even without the drm.edid_firmware kernel cmdline option - did you test that already? i think somehow the hdmi timing seems to be a bit off so that some monitors are not happy with it anymore - one thing which helped sometimes in such cases for me was to use one of those small hdmi to vga converters and the vga input of the monitor - this sometimes seemed to compensate for the inaccurate timing.

while i'm posting here already and just cleaned up my repos and notes a bit, some updates:
- kernel build info: https://github.com/hexdump0815/linux-ma ... readme.exy
- u-boot build info: https://github.com/hexdump0815/u-boot-m ... readme.exy
- system image build info and ressources: https://github.com/hexdump0815/imagebui ... /odroid_u3

i also build a newer ubuntu 20.04 (focal) image for the odroid u3 with the following maybe interesting aspects:
- based on the new imagebuilder framework
- based on ubuntu 20.04 focal (debian 11 bullseye support will most probably be added after it is released)
- supported systems: odroid_u3 (default), odroid u2, x & x2 (they require adjustments in the /boot/extlinux/extlinux.conf - see comments in the file) ... odroid u untested as i have no access to any
- using zstd compressed btrfs as root fs, this way a full system including xorg can run from a 4gb sd card, 8gb even has some space, 16gb is plenty of space this way :)
- the new images use the open source lima gpu driver now
- in /scripts are some useful scripts to change or extend the installation - please read them before using them, as they are very basic
- lots of fixes and improvements here and there
- it can be found here: https://github.com/hexdump0815/imagebui ... /210508-01

best wishes - hexdump

Steevee28
Posts: 17
Joined: Tue Jan 30, 2018 4:55 pm
languages_spoken: english, german
ODROIDs: U3
Has thanked: 1 time
Been thanked: 4 times
Contact:

Re: Playing with upstream (Exynos4412)

Post by Steevee28 »

hexdump wrote:
Sat May 22, 2021 6:07 am
for me hdmi seems to work quite ok meanwhile even without the drm.edid_firmware kernel cmdline option - did you test that already?
yes, I did, but I couldn't get clear results - sometimes one monitor worked, another didn't - another time I saw the boot messages but HDMI output was lost when login screen was about to appear, sometimes vice-versa, another time the boot messages and the login screen were displayed, but the monitor turned black when the desktop was about to appear... I still don't understand. But anyway, I think that the patch fixes something, at least. I'd be happy to read here that the patch helped someone...
hexdump wrote:
Sat May 22, 2021 6:07 am
i also build a newer ubuntu 20.04 (focal) image for the odroid u3 (...)
Thank you!
Did you think about adding this SHT_RELR relocations support patch for glibc in your images? See the Latest Widevine 4.10.2252.0 fails to load issue of inputstream.adaptive Kodi plugin.

I've already built patched deb packages for testing and uploaded them here: libc6_2.31-0ubuntu9.2_armhf.deb, libc-bin_2.31-0ubuntu9.2_armhf.deb. Use at own risk! (EDIT: for me, Widevine works again then - together with LD_PRELOAD=libtcmalloc_minimal.so.4)

Steevee28
Posts: 17
Joined: Tue Jan 30, 2018 4:55 pm
languages_spoken: english, german
ODROIDs: U3
Has thanked: 1 time
Been thanked: 4 times
Contact:

EDID for 1280x720@60Hz

Post by Steevee28 »

See attached an EDID for 1280x720.
Simply uncompress the 1280x720.tgz tarball to your Odroid, afterwards update the initramfs by sudo update-initramfs -u.
Now, you can start the device with kernel parameter drm.edid_firmware=edid/1280x720.bin.

I also attached the source file 1280x720.S this EDID is created from. (EDIT: fixed comment at beginning of file)
Attachments
1280x720.S.txt
(1.25 KiB) Downloaded 5 times
1280x720.tgz
(520 Bytes) Downloaded 7 times

Steevee28
Posts: 17
Joined: Tue Jan 30, 2018 4:55 pm
languages_spoken: english, german
ODROIDs: U3
Has thanked: 1 time
Been thanked: 4 times
Contact:

Re: Playing with upstream (Exynos4412)

Post by Steevee28 »

Can someone please help me configure X11 in /etc/X11/xorg.conf.d?
I'm currently on a 5.10.32-stb-exy+ kernel using Lima, but I'm unable to properly activate Vsync to get rid of tearing and I'm also unable to activate a HW cursor in the X11 desktop.

I'm currently using the 01-modesetting.conf with the following content:

Code: Select all

Section "Device"
	Identifier	"device"
	Driver		"modesetting"
EndSection

Section "Monitor"
        Identifier      "monitor"
#       Option          "PreferredMode" "1024x768"
#       Option          "PreferredMode" "1280x1024"
#       Option          "PreferredMode" "1920x1080"
        Option          "DPMS" "false"
EndSection

Section "Screen"
        Identifier      "screen"
        Device          "device"
        Monitor         "monitor"
        DefaultDepth    24
EndSection

Section "ServerLayout"
        Identifier      "serverlayout"
        Option          "StandbyTime" "0"
        Option          "SuspendTime" "0"
        Option          "OffTime" "0"
        Option          "BlankTime" "0"
EndSection
Back on old 3.8.13.30 kernel, I once had this configuration:

Code: Select all

Section "Device"
        Identifier      "Mali FBDEV"
        Driver          "armsoc"
        Option          "fbdev"                 "/dev/fb0"
        Option          "Fimg2DExa"             "false"
        Option          "DRI2"                  "true"
        Option          "DRI2_PAGE_FLIP"        "false"
        Option          "DRI2_WAIT_VSYNC"       "true"
#       Option          "Fimg2DExaSolid"        "false"
#       Option          "Fimg2DExaCopy"         "false"
#       Option          "Fimg2DExaComposite"    "false"
        Option          "SWcursorLCD"           "false"
EndSection

Section "Screen"
        Identifier      "DefaultScreen"
        Device          "Mali FBDEV"
        DefaultDepth    24
EndSection
Is there a way to achieve a similar result using Lima? The DRI2_WAIT_VSYNC and SWcursorLCD option seem to not being accepted by the exynos/modesetting driver.

Steevee28
Posts: 17
Joined: Tue Jan 30, 2018 4:55 pm
languages_spoken: english, german
ODROIDs: U3
Has thanked: 1 time
Been thanked: 4 times
Contact:

Re: Playing with upstream (Exynos4412) - strange glmark2-es2 results

Post by Steevee28 »

hexdump wrote:
Sat May 22, 2021 6:07 am
i also build a newer ubuntu 20.04 (focal) image for the odroid u3 (...) it can be found here: https://github.com/hexdump0815/imagebui ... /210508-01
Using your image, I just made a very interesting observation: glmark2-es2 shows very bad results on xfce4 desktop (only around 40fps) , but pretty nice results on Lubuntu desktop (around 180fps!!! :o ).

In both configurations, on my Odroid U3+, the same Lima kernel is in use, so what the hell is going on??? It's X11 in both cases.
But for me, that is okay, because I prefer Lubuntu over Xfce4.

User avatar
mad_ady
Posts: 9472
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, C4, N1, N2, H2, Go, Go Advance
Location: Bucharest, Romania
Has thanked: 604 times
Been thanked: 679 times
Contact:

Re: Playing with upstream (Exynos4412)

Post by mad_ady »

glmark2-es2 shows very bad results on xfce4 desktop (only around 40fps)
Make sure to disable Compositor in the window manager settings. I think it's on by default.

Steevee28
Posts: 17
Joined: Tue Jan 30, 2018 4:55 pm
languages_spoken: english, german
ODROIDs: U3
Has thanked: 1 time
Been thanked: 4 times
Contact:

Re: Playing with upstream (Exynos4412)

Post by Steevee28 »

mad_ady wrote:
Tue Jun 08, 2021 1:26 pm
glmark2-es2 shows very bad results on xfce4 desktop (only around 40fps)
Make sure to disable Compositor in the window manager settings. I think it's on by default.
Ah, of course, you're perfectly right. When the Compositor is switched off, the results are identical on Xfce4 and Lubuntu. Thank you!

Steevee28
Posts: 17
Joined: Tue Jan 30, 2018 4:55 pm
languages_spoken: english, german
ODROIDs: U3
Has thanked: 1 time
Been thanked: 4 times
Contact:

Re: Playing with upstream (Exynos4412) - Announce: Kodi 19.1 for Odroid U3

Post by Steevee28 »

Based upon the Odroid U3 Ubuntu 20.04 focal image from @hexdump I've built Kodi 19.1 Matrix packages featuring MFC hardware accelerated video decoding and using GLESv2 for rendering.

It can be downloaded from here. Feel free to test it!

Post Reply

Return to “The Ideas”

Who is online

Users browsing this forum: No registered users and 1 guest