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: 11250
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, HC4
Has thanked: 52 times
Been thanked: 423 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: 11250
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, HC4
Has thanked: 52 times
Been thanked: 423 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 43 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: 20
Joined: Sat Jan 26, 2019 12:37 am
languages_spoken: english, german
ODROIDs: odroid u3
Has thanked: 0
Been thanked: 15 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: 20
Joined: Sat Jan 26, 2019 12:37 am
languages_spoken: english, german
ODROIDs: odroid u3
Has thanked: 0
Been thanked: 15 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 3):
AreaScout (Mon Aug 24, 2020 3:19 pm) • robgue (Tue Aug 25, 2020 1:40 pm) • 3dfx (Tue Aug 25, 2020 10:07 pm)

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: 20
Joined: Sat Jan 26, 2019 12:37 am
languages_spoken: english, german
ODROIDs: odroid u3
Has thanked: 0
Been thanked: 15 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 11 times
tv-dmesg.log
dmesg boot log on tv 1920x1080
(37.82 KiB) Downloaded 8 times
monitor-Xorg.0.log
Xorg log on monitor 1920x1080
(17.53 KiB) Downloaded 11 times
monitor-dmesg.log
dmesg boot log on monitor 1920x180
(37.47 KiB) Downloaded 8 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: 20
Joined: Sat Jan 26, 2019 12:37 am
languages_spoken: english, german
ODROIDs: odroid u3
Has thanked: 0
Been thanked: 15 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

User avatar
meveric
Posts: 11250
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, HC4
Has thanked: 52 times
Been thanked: 423 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: 1 time
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: 1 time
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

Post Reply

Return to “The Ideas”

Who is online

Users browsing this forum: No registered users and 1 guest