Odroid C2 mainline kernel support

[emk2203]

@scpcom: Does USB work now with your kernel?

[scpcom]

Update 20180602
- Kernel 4.17.0
- Removed linux-4.17.y-amlogic-drm-0016-[wip]_calculate_display_params.patch
- Removed linux-4.17.y-amlogic-drm-1000-wip_calculate_display_params-fix.patch
- Removed linux-4.17.y-amlogic-drm-1001-drm-mode-32000khz-vu7plus.patch
- Added linux-4.17-amlogic-dmt-extended-0001-make_dmt_timings_parameter_generic_and_add_more_frequencies.patch (by baylibre)
- Added linux-4.17-amlogic-dmt-extended-1001-fix-32000khz.patch
- Added linux-4.17-amlogic-dmt-extended-1002-custom-mode.patch
linux-4.14-odroidc2-build.tar.gz linux-image-4.14.47-20180602-c2-arm64.zip
linux-4.17-odroidc2-build.tar.gz linux-image-4.17.0-20180602-c2-arm64.zip

The baylibre patch has a pll_base_freq of 2560000 for pixel clock 32000khz, I raised it to 5120000 again, otherwise my C2 with VU7+ freezes.

With the new patches drm-meson can handle now any custom resolution between 640x480 and 1920x1200 (+ predefined higher resolutions).
It will first do lookup in the predefined tables for standard resolutions, if nothing matches all required parameters will be calculated (timing parameters, pixel clock, pll base freq., m and frac).
The required combinations of od1, od2, od3, vid_pll_div and vclk_div are currently taken from the list of predefined params.

@emk2203
My USB devices (mouse, keyboard, VU7+ Touch, portable HDD and Cinergy HTC USB XS DVB-C/T stick) work without any problems (DVB-C/T stick works only on OTG port).

[scpcom]

Update 20180610
- Kernel 4.17.1
- Added linux-4.17-amlogic-dmt-extended-1003-calculate-clock-dividers.patch
- Added linux-4.17-le-amlogic-gx-0027-arm64-dts-meson-activate_hdmi_audio_hdmi_enabled_boards.patch
- Added linux-4.14.y-le-amlogic-gx-1002-dts-meson-gxbb-rename_audio_card.patch
- Added linux-4.17.y-amlogic-clk-1001-clk-meson-fix_broken_audio.patch
linux-4.14-odroidc2-build.tar.gz linux-image-4.14.49-20180610-c2-arm64.zip
linux-4.17-odroidc2-build.tar.gz linux-image-4.17.1-20180610-c2-arm64.zip

Th video clock dividers are calculated too now, independent from lookup tables.

I found that audio was not working in kernel 4.17.
This was caused by the "migrate the audio divider clock to clk_regmap" patch:
88a4e1283681e0f07048b2bd867cc81fbbae57cc

If you look at 4.14:
clk-audio-divider.c#L71
and 4.17:
clk-audio-divider.c#L54
you will see that a "+1" is missing in 4.17 code.
The result is a wrong value returned by clk_get_rate which causes an error here:
i2s-dai.c#L148
i2s-dai.c#L231

[moon.linux]

@scpcom If you find some bug and you solve this please send a patch upstream to fix the issue.

[miskol]

here you can find nice set of patch-es for 4.17 from Neil Armstrong
https://github.com/superna9999/meta-mes ... son64-4.17

[scpcom]

@miskol
Thank you. I already use many patches from Neil Armstrong, but I did not know this patch set.
Good to know that he already had a patch for the audio divider.

[mcloaked]

Way back in this thread around Jan 06 this year, I exchanged requests and ideas about getting the rtc working in the mainline kernel running archlinux arm on the odroid-c2 but at that time there were problems with the eMMC timing so I reverted to installing the non-mainline kernel in a clean install. Today with much more development in the kernel supporting the odroid-c2 I updated to kernel 4.17.1-1-ARCH and this seems stable. However the original problems with being unable to get the rtc working remain. The recipe for dtc changes given by campbell in January still don't work for me with the current mainline kernel in archlinuxarm, and although the rtc is not essential, since I use systemd-timesyncd to update the system clock very quickly after boot, it would be nice to know if there is a way to get the rtc working.

Code: Select all

# hwclock -r --verbose
hwclock from util-linux 2.32
System Time: 1529005387.845705
Trying to open: /dev/rtc0
Trying to open: /dev/rtc
Trying to open: /dev/misc/rtc
No usable clock interface found.
hwclock: Cannot access the Hardware Clock via any known method.

The i2c shows there is a slot at 51

Code: Select all

# i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- 51 -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

The i2c_dev and rtc_pcf8563 modules can be loaded with modprobe - but I still can't get hwclock -r to work. This seems close but I must be missing something critical.

Is the aml_i2c module crucial to using the rtc?

Code: Select all

# modprobe aml_i2c
modprobe: FATAL: Module aml_i2c not found in directory /lib/modules/4.17.1-1-ARCH

If anyone has been trying to do this and had some success I would appreciate knowing what method worked.

Thanks.

[emk2203]

Update 20180602
- Kernel 4.17.0

@emk2203
My USB devices (mouse, keyboard, VU7+ Touch, portable HDD and Cinergy HTC USB XS DVB-C/T stick) work without any problems (DVB-C/T stick works only on OTG port).

@scpcom: I tried the kernel 4.17.1 on a system with Odroid kernel and Ubuntu 18.04, but with a failure. System doesn't boot, no heartbeat LED. What would be the best way to debug it? The install was done per your instructions, everything went through with some symlinks to libmali refusing to install ("file exists"), I did these by hand. Everything else looked fine. I used the libmali .pkg for stretch, since the old Ubuntu one didn't meet dependencies.

[scpcom]

Update 20180617
- Kernel 4.17.2
- Reduced 4.17 patchset
- Synchronized 4.14 patchset with 4.17
- install-mali-driver.sh: Removed symlinking libwayland-egl.so.1.0.0 with libMali.so
linux-4.14-odroidc2-build.tar.gz linux-image-4.14.50-20180617-c2-arm64.zip
linux-4.17-odroidc2-build.tar.gz linux-image-4.17.2-20180617-c2-arm64.zip
libsdl2-c2.zip libsdl2-2.0.8-c2-bionic-arm64.zip

Additional to the kernels I built libsdl2 2.0.8 for Ubuntu 18.04 LTS (same works on Debian 9 too). Nothing special, just disabled Open GL,Open GLES will be used. Works with both libMali versions on 3.1x and 4.1x kernels.

@emk2203
Did you try to ping C2? As I wrote here you may have black screen/no signal on first boot. But if you reboot again it will show up on screen.
If you can not ping C2 something may did go wrong with new boot loader. Did you run sd_fusing.sh? Did you check fstab and boot.cmd for correct boot partition?

For debugging you can use netconsole by adding the parameters to "bootargs" in boot.cmd.
Example:

Code: Select all

netconsole=@192.168.1.234/,@192.168.1.123/

192.168.1.234 = IP of C2
192.168.1.123 = IP of PC you use for debugging

After editing boot.cmd by hand, you need to run the following on C2:

Code: Select all

sudo mkimage -C none -A arm -T script -d /media/boot/boot.cmd /media/boot/boot.scr && sudo sync

On your PC you can run the following command, before starting C2:

Code: Select all

nc -u -l -p 6666

PS: I am running and developing C2 on Xubuntu 18.04 LTS now for about 2 weeks and since sdl2 is working too now, I do not need to switch back to Debian 9 (only for testing some time).

[memeka]

did anyone try the video decoder patches?
https://github.com/superna9999/meta-mes ... 4de721b912

or the overlay plane patches?
https://github.com/superna9999/linux/co ... rm-overlay

[KARL23]

@mcloaked
basicly to get rtc via i2c working, you need to have i2c enabled in uboot, and then: either have the kernelmodules aml-i2c i2c-dev and for the rtc-chip compiled into the kernel or you need to put them into the initramfs.

These modules are need before the normal fs is mounted. See my attached dmesg log:

Code: Select all

[    1.902552] c11084c0.serial: ttyAML1 at MMIO 0xc11084c0 (irq = 10, base_baud = 1500000) is a meson_uart
[    1.902820] c1108700.serial: ttyAML3 at MMIO 0xc1108700 (irq = 13, base_baud = 1500000) is a meson_uart
[    1.903071] c81004c0.serial: ttyAML0 at MMIO 0xc81004c0 (irq = 16, base_baud = 1500000) is a meson_uart
[    2.682125] console [ttyAML0] enabled
[    2.686113] msm_serial: driver initialized
[    2.691008] libphy: Fixed MDIO Bus: probed
[    2.694106] mousedev: PS/2 mouse device common for all mice
[    2.699706] i2c /dev entries driver
[    2.705042] rtc-ds1307 1-0068: registered as rtc0
[    2.708341] ledtrig-cpu: registered to indicate activity on CPUs
[    2.713534] meson-sm: secure-monitor enabled
[    2.717703] EFI Variables Facility v0.08 2004-May-17
[    2.722588] efivars: get_next_variable: status=8000000000000007
[    2.728470] hidraw: raw HID events driver (C) Jiri Kosina
[    2.735123] registered taskstats version 1
[    2.737842] Loading compiled-in X.509 certificates
[    2.742655] zswap: loaded using pool lzo/zbud
[    2.759183] Key type big_key registered
[    2.764899] Key type encrypted registered
[    2.764938] AppArmor: AppArmor sha1 policy hashing enabled
[    2.776108] rtc-ds1307 1-0068: setting system clock to 2018-07-18 20:59:24 UTC (1531947564)

[gkkpch]

From the amlogic/ baylibre mailing list I see things are moving forward with amlogic sound/soc in 4.18/ 4.19
Does anyone have more precise planning info on i2s support in 4.19 (or perhaps 4.20) for Odroid C2?

[waka324]

What defconfig are people using for 4.17? arm64 or a modified version?

[waka324]

@emk2203
My USB devices (mouse, keyboard, VU7+ Touch, portable HDD and Cinergy HTC USB XS DVB-C/T stick) work without any problems (DVB-C/T stick works only on OTG port).

Just tried your build out (4.17.10) but found USB would only work if more than one device was plugged in at boot. Very odd.

[nayr]

I got RTC working by building my own kernel with 'Philips PCF8563/Epson RTC8564' statically linked and following the instructions earlier and putting this within i2c@8500

Code: Select all

				pcf8563@51 {
				   status = "okay";
				   compatible = "nxp,pcf8563";
				   reg = <0x51>;
				   #clock-cells = <0x0>;
				};

meson-gxbb-odroidc2.dtb

It would save alot of trouble and headache if you guys pre-building kernels included that, changing the dtb is alot simpler than rebuilding.. My service needs to maintain time even w/out internet connectivity.

Unfortunately I'm having audio issues after building it with usb-sound support (which was also missing??), I'm using my C2 as a packet radio and the TNC I'm using complains the volume input is too high, even if I mute it or I mute the radio sending packets.. dunno what the problem is but it worked fine on the 3.x kernel, so I guess I'll be downgrading after this adventure.

Code: Select all

Audio device for both receive and transmit: plughw:CARD=CODEC  (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate.
Digipeater WIDE1 (probably KC0D) audio level = 174(22/20)   [NONE]   __|______
Audio input level is too high.  Reduce so most stations are around 50.
ADEVICE0: Sample rate approx. 44.1 k, 0 errors, receive audio level CH0 174
ADEVICE0: Sample rate approx. 44.1 k, 0 errors, receive audio level CH0 179
ADEVICE0: Sample rate approx. 44.1 k, 0 errors, receive audio level CH0 177
ADEVICE0: Sample rate approx. 44.1 k, 0 errors, receive audio level CH0 171

previous kernel those audio levels were ~50, and if I turned the pots or changed the volume in the mixer i could move it up/down.. with 4.17.10 kernel it just stays here @ ~170 regardless of what knobs I turn.. and its ignoring 90% of packets, got lucky to grab that one above and was unable to decode the following 100 packets that I heard the radio receive clearly.

[scpcom]

Update 20180726
- Kernel 4.17.11
- Added UMP ioctls to drm fb (linux-4.14.y-drm-fb_helper-ump-ioctls.patch)
- Added Mali and UMP compatibility patches for Kernel 4.1x (series-mali-r6p2 and mali-r6p2-*.patch)
- Added meson drm to fbturbo (fbturbo-add-meson-and-sun4i-drm.patch)

linux-4.14-odroidc2-build.tar.gz linux-image-4.14.59-20180726-c2-arm64.zip
linux-4.17-odroidc2-build.tar.gz linux-image-4.17.11-20180726-c2-arm64.zip
xserver-xorg-video-fbturbo-c2.zip xserver-xorg-video-fbturbo-c2-stretch-arm64.zip xserver-xorg-video-fbturbo-c2-bionic-arm64.zip

Replacing mali and fbturbo is now optional. I added UMP support to mainline kernel.
I just added the missing ioctls to drm_fb_helper.c and added drm_fb_ump.c, which is based on osd_ump.c from kernel 3.14/3.16 so I kept the Hardkernel copyright statement.
Why UMP again? Because on kernel 4.14/4.17
- with armsoc and without UMP I get a glmark2-es2 score of 38 and below, sometimes if all glmark-es2 tests are done the application hangs.
- with fbturbo and UMP I get a glmark2-es2 score of 90 and even higher, nothing hangs.

Anyway the same kernel works with both variants now.
And the same fbturbo works with kernel 3.14/3.16 and 4.14/4.17 now.

Tested with UMP libs:
mali-x11 (20161003-r6p1-ee42997-15 from http://deb.odroid.in/c2/ xenial main)
mali-x11 (20180710-r6p1-10 from http://deb.odroid.in/c2/ bionic main)
mali450-odroid (20161218-r6p1-1 from http://oph.mdrjr.net/meveric/ all c2 main)

...and libs without UMP:
mali450-meson (20170630-r6p1-1, from amlogic buildroot openlinux 20170630)

@waka324
Interesting, I will take a look at it, maybe next weekend.
@nayr
I am not familiar with RTC on C2.
Is USB Audio missing? I will take a look at the defconfig. I did not recognize it myself because I lost my USB audio card So I only use HDMI audio currently.

[otec]

Update 20180726
- Kernel 4.17.11
- Added UMP ioctls to drm fb (linux-4.14.y-drm-fb_helper-ump-ioctls.patch)
- Added Mali and UMP compatibility patches for Kernel 4.1x (series-mali-r6p2 and mali-r6p2-*.patch)
- Added meson drm to fbturbo (fbturbo-add-meson-and-sun4i-drm.patch)

Sorry for a newbie question, but do you have a short guide how to install it ?

I've downloaded 4.17.11 zip, unzipped it, installed *.deb packages using dpkg -i.
I see that it updated /media/boot with new Image and uInitrd.

I tried to reboot, but c2 kept autorebooting without even loading the kernel.

Code: Select all

--- UART initialized after reboot ---
[Reset cause: unknown]
[Image: unknown, amlogic_v1.1.3046-00db630-dirty 2016-08-31 09:24:14 tao.zeng@dr                                                                     oid04]
bl30: check_permit, count is 1
bl30: check_permit: ok!
chipidLoad bl33 from eMMC, src: 0x00034200, des: 0x01000000, size: 0x00073510
: ef be ad de d f0 ad ba ef be ad de not ES chip
[0.175214 Inits done]
secure task start!
high task start!
low task start!
NOTICE:  BL3-1: v1.0(debug):4d2e34d
NOTICE:  BL3-1: Built : 17:08:35, Oct 29 2015
INFO:    BL3-1: Initializing runtime services
INFO:    BL3-1: Preparing for EL3 exit to normal world
INFO:    BL3-1: Next image address = 0x1000000
INFO:    BL3-1: Next image spsr = 0x3c9


U-Boot 2015.01-00189-g205c7b3 (Feb 27 2017 - 10:53:13)

DRAM:  2 GiB
Relocation Offset is: 76f32000
-------------------------------------------------
* Welcome to Hardkernel's ODROID-C2
-------------------------------------------------
CPU : AMLogic S905
S/N : HKC213254DFCC287
MAC : 00:1e:06:33:0f:07
BID : HKC2211602
-------------------------------------------------
register usb cfg[1][0] = 0000000077f95058
register usb cfg[0][1] = 0000000077f95078
vpu detect type: 5
vpu clk_level = 7
set vpu clk: 666667000Hz, readback: 666660000Hz(0x300)
MMC:   aml_priv->desc_buf = 0x0000000073f2ad30
aml_priv->desc_buf = 0x0000000073f2cec0
SDIO Port C: 0, SDIO Port B: 1
[mmc_init] mmc init success
In:    serial
Out:   serial
Err:   serial
----------------------------------
MMC Size : 64 GB
----------------------------------
reading boot-logo.bmp.gz
** Unable to read file boot-logo.bmp.gz **
reading boot-logo.bmp
** Unable to read file boot-logo.bmp **
movi: the partiton 'logo' is reading...

MMC read: dev # 0, block # 61024, count 2048 ... 2048 blocks read: OK
hpd_state=1
[CANVAS]addr=0x3f800000 width=3840, height=1440

set hdmitx VIC = 16
hdmitx phy setting done
set hdmitx VIC = 16
hdmitx phy setting done
Error: Bad gzipped data
There is no valid bmp file at the given address
Net:   Meson_Ethernet
Hit [Enter] key twice to stop autoboot:  0
reading boot.ini
6806 bytes read in 3 ms (2.2 MiB/s)
cfgload: applying boot.ini...
cfgload: setenv display_autodetect "true"
cfgload: setenv m "1080p60hz" # Progressive 60Hz
cfgload: setenv m_bpp "32"
cfgload: setenv hpd "true"
cfgload: setenv monitor_onoff "false" # true or false
cfgload: setenv nographics "0"
cfgload: setenv mesontimer "0"
cfgload: setenv disableuhs "false"
cfgload: setenv mmc_removable "true"
cfgload: setenv usbmulticam "false"
cfgload: setenv disable_vu7 "true"
cfgload: setenv condev "console=ttyS0,115200n8 console=tty0"   # on both
cfgload: setenv maxcpus "4"
cfgload: setenv max_freq "1536"  # 1.536GHz
cfgload: if test "${display_autodetect}" = "true"; then usb pwren; hdmitx edid;                                                                      fi
USB0:   dwc_usb driver version: 2.94 6-June-2012
USB (1) peri reg base: c0000020
USB (1) use clock source: XTAL input, div: 1
USB (1) base addr: 0xc9100000
Force id mode: Host
dwc_otg: Highspeed device found !

..............................
..............................
..............................
..............................
..............................
..............................
..............................
..............................
..............................
..............................
..............................
..............................
..............................
..............................
..............................
..............................
edid extension block number : 1
No header found
Manufacturer: @@@ Model 0 Serial Number 0
EDID version: 0.0
Analog display, Input voltage level: 0.7/0.3 V
Sync:
Established timings supported:
Standard timings supported:
non-conformant standard timing (0 horiz)
non-conformant standard timing (0 horiz)
non-conformant standard timing (0 horiz)
non-conformant standard timing (0 horiz)
non-conformant standard timing (0 horiz)
non-conformant standard timing (0 horiz)
non-conformant standard timing (0 horiz)
non-conformant standard timing (0 horiz)
Manufacturer-specified data, tag 0
Manufacturer-specified data, tag 0
Manufacturer-specified data, tag 0
Manufacturer-specified data, tag 0
Checksum: 0x0 (valid)
bestmode is 1080p60hz, IEEEOUI 0x000000
DVI Mode
cfgload: if test "${m}" = "custombuilt"; then setenv cmode "modeline=${modeline}                                                                     "; fi
cfgload: if test "${disable_vu7}" = "false"; then setenv hid_quirks "usbhid.quir                                                                     ks=0x0eef:0x0005:0x0004"; fi
cfgload: setenv bootargs "root=UUID=e139ce78-9841-40fe-8823-96a304a09859 rootwai                                                                     t ro ${condev} no_console_suspend hdmimode=${m} ${cmode} m_bpp=${m_bpp} vout=${v                                                                     out} fsck.repair=yes net.ifnames=0 elevator=noop disablehpd=${hpd} max_freq=${ma                                                                     x_freq} maxcpus=${maxcpus} monitor_onoff=${monitor_onoff} disableuhs=${disableuh                                                                     s} mmc_removable=${mmc_removable} usbmulticam=${usbmulticam} ${hid_quirks} coher                                                                     ent_pool=1M"
cfgload: setenv loadaddr "0x11000000"
cfgload: setenv dtb_loadaddr "0x1000000"
cfgload: setenv initrd_loadaddr "0x13000000"
cfgload: fatload mmc 0:1 ${initrd_loadaddr} uInitrd
reading uInitrd
11761167 bytes read in 276 ms (40.6 MiB/s)
cfgload: fatload mmc 0:1 ${loadaddr} Image
reading Image
18356736 bytes read in 429 ms (40.8 MiB/s)
cfgload: fatload mmc 0:1 ${dtb_loadaddr} meson64_odroidc2.dtb
reading meson64_odroidc2.dtb
29164 bytes read in 4 ms (7 MiB/s)
cfgload: fdt addr ${dtb_loadaddr}
cfgload: if test "${mesontimer}" = "0"; then fdt rm /meson_timer; fdt rm /cpus/c                                                                     pu@0/timer; fdt rm /cpus/cpu@1/timer; fdt rm /cpus/cpu@2/timer; fdt rm /cpus/cpu                                                                     @3/timer; fi
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
cfgload: if test "${mesontimer}" = "1"; then fdt rm /timer; fi
cfgload: if test "${nographics}" = "1"; then fdt rm /reserved-memory; fdt rm /ao                                                                     cec; fi
cfgload: if test "${nographics}" = "1"; then fdt rm /meson-fb; fdt rm /amhdmitx;                                                                      fdt rm /picdec; fdt rm /ppmgr; fi
cfgload: if test "${nographics}" = "1"; then fdt rm /meson-vout; fdt rm /mesonst                                                                     ream; fdt rm /meson-fb; fi
cfgload: if test "${nographics}" = "1"; then fdt rm /deinterlace; fdt rm /codec_                                                                     mm; fi
cfgload: booti ${loadaddr} ${initrd_loadaddr} ${dtb_loadaddr}
"Synchronous Abort" handler, esr 0x96000010
ELR:     77f3d5d0
LR:      77f3d5c4
x0 : 0000000077fa6048 x1 : 0000000000080000
x2 : 0000000001387000 x3 : 0000000001387000
x4 : 000000000000000d x5 : 0000000011000000
x6 : 0000000077f7f6f8 x7 : 0000000000000044
x8 : 0000000000000001 x9 : 0000000000000002
x10: 000000000000000f x11: 0000000077f809b8
x12: 0000000000000000 x13: 0000000000000000
x14: 0000000000000000 x15: 0000000077f330d0
x16: 0000000077f332b4 x17: 0000000000000000
x18: 0000000073f29e28 x19: 0000000077fa5f08
x20: 0000000000000003 x21: 0000000073f350b8
x22: 0000000077fa5000 x23: 0000000077fa5f08
x24: 0000000000000000 x25: 0000000073f350b0
x26: 0000000077f99188 x27: 0000000073f350e0
x28: 0000000000000000 x29: 0000000073f295d0

I'm running on eMMC card. Do I need to change anything in boot.init ?

[otec]

I followed the guide in this file http://seafile.servator.de/sbc/odroid/n ... nstall.txt

I used to have FAT partition on mmc at address 0:1 in boot.ini, it looks like now it migrated to 1:1.

Now when C2 boots it hangs on Starting Kernel:

Code: Select all

=> setenv loadaddr "0x11000000"
=> setenv dtb_loadaddr "0x1000000"
=> setenv initrd_loadaddr "0x13000000"
=> fatload mmc 1:1 ${initrd_loadaddr} uInitrd
11762175 bytes read in 260 ms (43.1 MiB/s)
=> fatload mmc 1:1 ${loadaddr} Image
18356736 bytes read in 405 ms (43.2 MiB/s)
=> fatload mmc 1:1 ${dtb_loadaddr} meson64_odroidc2.dtb
29164 bytes read in 2 ms (13.9 MiB/s)
=> fdt addr ${dtb_loadaddr}
=> booti ${loadaddr} ${initrd_loadaddr} ${dtb_loadaddr}
## Loading init Ramdisk from Legacy Image at 13000000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (uncompressed)
   Data Size:    11762111 Bytes = 11.2 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 01000000
   Booting using the fdt blob at 0x1000000
   Loading Ramdisk to 7d427000, end 7df5e9bf ... OK
   Loading Device Tree to 000000007d41c000, end 000000007d4261eb ... OK

Starting kernel ...

any ideas why it doesnt want to load kernel ?

[otec]

Re-installed Ubuntu from scratch && followed guide again. All works fine!

[scpcom]

@otec
Thank you for testing.
Sorry I did not answer earlier, I am still researching on the mainline kernels for meson and sunxi.

@memeka
I built a kernel with the video decoder patches successfuly but I really do not know yet how to test it.
Firefox & Co. still use software decoding, maybe some extra libva/libdrm is needed.
For sunxi I found this, they seem to work on a solution too:
https://github.com/bootlin/linux-cedrus ... /4.17/h264
https://github.com/bootlin/libdrm-sun4i
https://github.com/bootlin/libva-v4l2-request
But I am not done with testing to get a working result.

[memeka]

in theory, https://github.com/bootlin/libva-v4l2-request should work with C2 as well.

[lnxsrt]

@emk2203
My USB devices (mouse, keyboard, VU7+ Touch, portable HDD and Cinergy HTC USB XS DVB-C/T stick) work without any problems (DVB-C/T stick works only on OTG port).

Just tried your build out (4.17.10) but found USB would only work if more than one device was plugged in at boot. Very odd.

Same exact issue using linux-aarch64 (4.17.12-1-ARCH) on Arch. Besides that, it is very stable, even better than the standard 3.14 IMO.

[campbell]

Just tried your build out (4.17.10) but found USB would only work if more than one device was plugged in at boot. Very odd.

Same exact issue using linux-aarch64 (4.17.12-1-ARCH) on Arch. Besides that, it is very stable, even better than the standard 3.14 IMO.

On the (Arch) 4.18.0 kernel this morning, what I'm seeing is:

with an iPhone plugged in at boot:
- it works (charges, and shows up in lsusb)
- the FTDI cable shows up when plugged in after boot, any number of times
- after the iPhone is unplugged, with the FTDI cable still plugged in, the FTDI cable still works
- if the iPhone is plugged back in, with the FTDI cable still plugged in, then the iPhone works too
- if both are unplugged, then nothing works anymore when plugged back in, even if you plug in both

I did the same experiments in the same order with the iPhone and FTDI cable swapped and there was no difference. Short version: if you have something plugged in at boot, and have at least one thing plugged in at all times, then your USB will work as expected.

This is an Odroid C2 rev 20170830 with the jumper off, running vanilla latest Arch Linux with the mainline kernel and uboot.

I'm pretty disappointed that more effort hasn't been put into fixing this by people in a position to do so, after all this time. Clearly there is code in the 3.14 kernel that makes it work, what exactly is the problem with getting it into mainline?

[BarTender]

Sorry for the noobie question but I had a read through this thread and couldn't find the specific issue with eMMC.
Using a C2 Rev0.2 20160226 with 32GB red eMMC which works fine with the Ubtuntu 18 ubuntu-18.04-3.16-minimal-odroid-c2-20180626.img.xz minimal image. Then I tried to upgrade to mainline kernel following the instructions.

http://seafile.servator.de/sbc/odroid/n ... nstall.txt

Since it's minimal I only am able to upgrade the uboot and kernel as I am not using the HDMI port as this is a headless node.

Checking the serial console I see the error:

Found U-Boot script /boot.scr
6289 bytes read in 1 ms (6 MiB/s)
## Executing script at 1f000000
Unknown command 'ODROIDC2-UBOOT-CONFIG' - try 'help'
Unknown command 'usb' - try 'help'
Unknown command 'hdmitx' - try 'help'
Card did not respond to voltage select!
** Bad device mmc 0 **
Card did not respond to voltage select!
** Bad device mmc 0 **
Card did not respond to voltage select!

Inside uboot I try and get the card info and it fails
=> mmc info
Card did not respond to voltage select!

Should I build uboot and the kernel from source and start again? As doing the uboot upgrade effectively bricks the image. Is it worth doing a backup of the uboot so I can recover back to the 3.14 kernel?

[OverSun]

I wouldn't advise you to tamper with u-boot if you don't know what you're doing or you are really eager to learn what it is. As you already noticed, blindly throwing stuff in effectively prevent the board from booting. That's not something that is going to report you errors and still work.
In this case you renamed "boot.ini" to "boot.scr" which are completely different things. boot.ini is odroid specific invention which is a file with a header, possible comments and commands going one after another. and boot.scr is a memory dump of a portion of a memory that file read produces.

[BarTender]

I wouldn't advise you to tamper with u-boot if you don't know what you're doing or you are really eager to learn what it is. As you already noticed, blindly throwing stuff in effectively prevent the board from booting. That's not something that is going to report you errors and still work.
In this case you renamed "boot.ini" to "boot.scr" which are completely different things. boot.ini is odroid specific invention which is a file with a header, possible comments and commands going one after another. and boot.scr is a memory dump of a portion of a memory that file read produces.

I didn't touch the boot.ini or create a boot.scr but I suspect the uboot installer may have done that.
What is the recommended approach to upgrade uboot from U-Boot 2015.01-00014-g2e4380b-dirty to the 2018-03/head version which is required for 4.x mainline kernel?
I would think it would be logical to upgrade uboot first keeping the current 3.14 kernel, then be able to write the updated 4.x kernel and modify the boot.ini script so that I can failback to the 3.14 if it goes wrong.

[OverSun]

The recommended way would be to wait for a package that does the upgrade.
Manually that would be yes, upgrading u-boot first, so it can boot 3.14 (also can have issues, depends), then update the kernel.
Most complicated thing here that if you upgrade to the version that is not compiled from odroid github - you are not going to have odroid specific functionality that the whole boot process of odroid images is based around right now. There is going to be nothing wrong with u-boot, nothing wrong with system, it's just scripts that command u-boot what to do and where to look for kernels are going to be not working. And at this points you will need to understand how to work with u-boot and its commands. If you know what all the fatloat, booti commands are, then it's pretty ok to work that around and boot any kernel you want. But no, it's not going to "just work", you will end up with a boot prompt of u-boot on the serial port.

[scpcom]

Update 20180815
- Kernel 4.18.1
- Added yocto-meson64 v4l2-m2m patches (https://github.com/superna9999/meta-mes ... son64-4.18)
linux-4.14-odroidc2-build.tar.gz linux-image-4.14.63-20180815-c2-arm64.zip
linux-4.18-odroidc2-build.tar.gz linux-image-4.18.1-20180815-c2-arm64.zip

@BarTender and @OverSun
My install-linux.sh does automatically convert boot.ini to boot.scr (only if boot.cmd/boot.scr did not exist before).
boot.scr is the binary version of boot.cmd.
The boot.ini syntax is not odroid specific, it is the same syntax as in boot.cmd, the only lines that need to be removed are the fdt manipulations, that only work on the 3.1x device tree.
Other parameters maybe ignored because the mainline kernel does not implement them, but they do not cause any boot trouble.
The MMC problem must be something else. I also have a red 32GB eMMC module, so I can look If I find something.

[rockla]

I'm only interested in headless server the main post does not clearly explains how to upgrade to new kernel cleanly what works what does not work.

[scpcom]

Update 20180816
- Conversion from boot.ini to boot.cmd supports eMMC now (install-linux.sh)
Download links same like 20180815 above

Installing u-boot and kernel on image with 3.1x kernel (like ubuntu-18.04-3.16-minimal-odroid-c2-20180626.img.xz) runs with eMMC too know.
I just added one line to make boot.cmd independent from the MMC slot:

Code: Select all

sudo sed -i s/' mmc .:. '/' ${devtype} ${devnum}:${rootpart} '/g /media/boot/boot.cmd

You do not need to set this three new variables yourself because u-boot does this for you (no hack, tested with mainline u-boot 2018.03 and 2018.07).
PS: If you build your own u-boot, CONFIG_BOOTCOMMAND must contain "run distro_bootcmd" to make this work.

@rockia
You can find an good overview here: http://linux-meson.com/doku.php
(My extra patches/collected patches are mostly for multimedia issuses)

[rockla]

Thanks looked at doc usb support is missing

[BarTender]

Update 20180816
- Conversion from boot.ini to boot.cmd supports eMMC now (install-linux.sh)
Download links same like 20180815 above

Installing u-boot and kernel on image with 3.1x kernel (like ubuntu-18.04-3.16-minimal-odroid-c2-20180626.img.xz) runs with eMMC too know.
I just added one line to make boot.cmd independent from the MMC slot:

Code: Select all

sudo sed -i s/' mmc .:. '/' ${devtype} ${devnum}:${rootpart} '/g /media/boot/boot.cmd

You do not need to set this three new variables yourself because u-boot does this for you (no hack, tested with mainline u-boot 2018.03 and 2018.07).
PS: If you build your own u-boot, CONFIG_BOOTCOMMAND must contain "run distro_bootcmd" to make this work.

@rockia
You can find an good overview here: http://linux-meson.com/doku.php
(My extra patches/collected patches are mostly for multimedia issuses)

So would it be safe to upgrade just uboot and stick with the 3.14 kernel? or do I need to upgrade both at the same time?

[scpcom]

You need to upgrade both, u-boot and kernel.

@rockia
In the table S905 USB: Yes, USB OTG: No
USB is supported, but needs bugfixing the issue discussed above.

[BarTender]

I have found my issue, it seems I wasn't RTFMing and was running the uboot sd_fusing *after* installing the kernel. Because of that the initrd was never properly built during the kernel install and the image was toast after I ran the sd_fusing.
Now have Ubuntu 18.04 minimal with 4.14.63 and 4.18.1 and the ethernet drivers are working at 1GB as I can do a 1GB iperf3 between nodes at home getting 940Mbit.
Many thanks for the image builds

[mad_ady]

I could do ~920M on 3.14/3.16 as well.

[mix]

Over the past several weeks Amlogic's own programmers have shown up and started contributing mainline linux patches for the Meson-G12A S905D2 SoC. Maybe it's just a coincidence...

http://lists.infradead.org/pipermail/li ... hread.html

[lnxsrt]

So I upgraded to 4.18.2 in Arch and now the ethernet seems to die under full-load. I have a watchdog running so I know it isn't crashing the kernel, but the ethernet essentially stops responding. The issue did not seem to be there on 4.17.x. Downgraded for now.

[moon.linux]

Their is a revert patch to fix this issue.

Code: Select all

 https://patchwork.kernel.org/patch/10575397/

[campbell]

Their is a revert patch to fix this issue.

Code: Select all

 https://patchwork.kernel.org/patch/10575397/

They're already on 4.18.5, can we confirm that this patch made it in sometime between 4.18.2 and now?

[scpcom]

Update 20180825
- Kernel 4.18.5
- Enabled VIDEO_AML_MESON_VDEC (/dev/video0)
linux-4.14-odroidc2-build.tar.gz linux-image-4.14.67-20180825-c2-arm64.zip
linux-4.18-odroidc2-build.tar.gz linux-image-4.18.5-20180825-c2-arm64.zip

Since /dev/video0 is enabled players like mpv can use the the meson video decoder.

Code: Select all

mpv --vd=help | grep m2m

h263_v4l2m2m (h263) - V4L2 mem2mem H.263 decoder wrapper
h264_v4l2m2m (h264) - V4L2 mem2mem H.264 decoder wrapper
mpeg4_v4l2m2m (mpeg4) - V4L2 mem2mem MPEG4 decoder wrapper
mpeg1_v4l2m2m (mpeg1video) - V4L2 mem2mem MPEG1 decoder wrapper
mpeg2_v4l2m2m (mpeg2video) - V4L2 mem2mem MPEG2 decoder wrapper

You need to place the vdec firmware to /lib/firmware

• meson/gx/vmpeg4_mc_5
  meson/gx/vmjpeg_mc
  meson/gx/vmpeg12_mc
  meson/gx/h263_mc
  meson/gx/vh265_mc
  meson/gxbb/vh264_mc

I tested this in Xubuntu 18.04 with X11. The decoder works, but is still useless because mpv says the vo (video out) does not support the hardware decoder.
Maybe it works under wayland, before I can test this I must look how to switch from X11 to wayland.

@campbell
No, the revert patch is not applied in 4.18.5

[scpcom]

Update 20180830
- Kernel 4.18.5
- Added mali-r6p2-1004-ump_hack_to_force_the_memory_page_writable.patch and mali-r6p2-1005-ump_fix_bad_page_on_reboot.patch
- Added HDMI.conf for alsa
- Added meson-vdec-firmware
linux-4.18-odroidc2-build.tar.gz linux-image-4.18.5-20180830-c2-arm64.zip

Now I found some test scenario for the vdec stuff.
mpv and ffplay from (X)ubuntu 18.04 are able to use the vdec, but under X11 it is still very slow.
I will take a look at Elys repo to find out more.

Code: Select all

# software decoder, hardware output (SDL/opengles): between 130% and 290% CPU, video and audio plays normal without issue
mpv --vo=sdl --fullscreen --ontop --ao=alsa https://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov
# hardware decoder, software output (?): between 100% and 150% CPU, video very slow, audio async
mpv --vo=sdl --fullscreen --ontop --ao=alsa --vd=h264_v4l2m2m https://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov
# hardware decoder, no output
ffplay -fs -vcodec h264_v4l2m2m https://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov

# software decoder, hardware output (SDL/opengles): between 130% and 290% CPU, video and audio plays normal without issue
mpv --vo=sdl --fullscreen --ontop --ao=alsa http://distribution.bbb3d.renderfarming.net/video/mp4/bbb_sunflower_1080p_30fps_normal.mp4
# hardware decoder, software output (?): between 100% and 150% CPU, video very slow, audio async
mpv --vo=sdl --fullscreen --ontop --ao=alsa --vd=h264_v4l2m2m http://distribution.bbb3d.renderfarming.net/video/mp4/bbb_sunflower_1080p_30fps_normal.mp4
# hardware decoder, software output (?): between 100% and 150% CPU, video very slow, audio async
ffplay -fs -vcodec h264_v4l2m2m http://distribution.bbb3d.renderfarming.net/video/mp4/bbb_sunflower_1080p_30fps_normal.mp4

[brad]

Reatime kernel Update - Patches from preempt-rt git

Version: 4.18-rc8-rt1 (Development status)

The Realtime kernel group have now produced some patches for the 4.18 kernel family which can be found in the Realtime development tree on kernel.org. I have successfully built, configured and installed 4.18-rc8-rt1 and have only found some minor issues with the build. v4.18.5-rt3 is now available (still development) and I am yet to update / test.

I was expecting to see ethernet issues running at gigabit speeds as other have reported on the standard mainline but no signs of that particular issue with my setup. I was particularly interesting is testing some sound devices with RT kernel over USB and this is where I encountered some issues with realtime performance which appears to be related to the dwc2 USB host only driver.

Processing sound (input & output) using a realtime thread (jack2d sound server)

- Unable to set capture and playback channels on the same card (both channels appear to get in a race condition with each other for usb interupts and we lock up the usb alsa sound driver)
- Adding 2 sound devices and configuring 1 for capture and 1 for playback channels allows me to capture, process and playback sound via Realtime thread but I am still seeing some issues (the usb alsa sound drivers dieing after some time)
- Adding specific USB2 devices (ie Toneport UX2) causes the usb host driver to fail on boot, a failure getting a response from the USB interrupt 32 during initialization of the dwc2 driver. Not sure if this is due to the ux2 driver, usb alsa sound driver or the dwc2 drivers.

I now plan to try to add some i2s functionality to the kernel and test out a uda1380 I2S board for sound input/ output to see the results of how well I2S might work under realtime conditions in comparison to USB sound devices.

I should note that unless you have a specific use case for a Realtime kernel (ie you want to run software specifically designed for preempt-rt) then please save yourself the time and use standard. For normal applications a Realtime kernel will not be as fast or responsive as its designed for low latency time dependent applications rather than throughput of workloads. In saying this it can be very useful for debug of some hardware devices as Realtime kernel patches add threaded interrupts and corresponding debug functionality allowing us to look closely at the IRQ threads or take latency histograms. We can also see the system load of the interrupts as they now run like any other kernel process. Eg a simple top showing a mostly idle system (me posting this post in Chrominum at the time)....

Code: Select all

top - 03:00:19 up 53 min,  1 user,  load average: 1.23, 1.02, 1.00
Tasks: 171 total,   2 running, 122 sleeping,   0 stopped,   0 zombie
%Cpu(s):  7.0 us,  7.0 sy,  0.0 ni, 85.0 id,  0.0 wa,  0.9 hi,  0.0 si,  0.0 st
KiB Mem :  2028124 total,   834432 free,   526320 used,   667372 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  1356880 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                               
 1991 root      20   0  181644  90028  34784 S  17.2  4.4  10:14.76 /usr/lib/xorg/Xorg :0 -nolisten tcp vt7                               
 3511 brad      20   0 1694328 148396  99872 S  10.2  7.3   7:52.38 /usr/lib/chromium-browser/chromium-browser --type=renderer --no-sand+ 
 3330 brad      20   0 2667208 240016 142744 R   7.6 11.8   6:40.59 /usr/lib/chromium-browser/chromium-browser --disable-smooth-scrollin+ 
 1106 root     -51   0       0      0      0 S   6.9  0.0   3:52.71 [irq/34-dwc2_hso]                                                     
 1104 root     -51   0       0      0      0 S   4.0  0.0   2:05.49 [irq/34-c9100000]                                                     
 3187 brad      20   0   30332  18308  14028 S   1.0  0.9   0:39.17 xfwm4                                                                 
 5004 brad      20   0  258348  28140  15732 S   1.0  1.4   0:01.03 xfce4-terminal                                                        
 5023 brad      20   0    7632   3148   2604 R   1.0  0.2   0:00.47 top               

The interesting processes to look at in this case are the irq/34-dwc2_hso & irq/34-c9100000 ones as these are the IRQ's (or interrupts) for the usb. We have 2 processes sharing the same interrupt 34 (1 for the HCD - Host Controller driver and 1 for the 4 port OTG host mode driver). I think this is where my race issues are occuring for the usb sound devices I am using. Ill look back at usb after some testing with i2s sound.

At the time of posting preempt-rt develepment tree is at v4.18.5-rt3 https://git.kernel.org/pub/scm/linux/ke ... -4.18.y-rt
and the stable tree is still at 4.14.63-rt40 https://git.kernel.org/pub/scm/linux/ke ... h=v4.14-rt

If anyone is interested I can provide a kernel config for preempt-rt and odroid c2 from the development tree (currently its specific to my testing of sound related devices but I can produce a more stock standard version and maybe even provide a built image based on v4.18.5-rt3)

[moon.linux]

Wow their seam to be kernel rt tree that sounds exciting. v4.18.5-rt3 and 4.14.63-rt40

[scpcom]

Update 20180901
- Kernel 4.18.5
- Removed HDMI.conf
- Added v4l2-m2m patches from Elyotna
- Set CONFIG_SND_SOC_MESON=y and CONFIG_SND_SOC_MESON_I2S=y
- Made fbturbo compatible with xserver-xorg-video ABI 23 and 24 (fbturbo-adapt_block_wakeuphandler_signature_for_abi_23.patch)
linux-4.18-odroidc2-build.tar.gz linux-image-4.18.5-20180901-c2-arm64.zip
xserver-xorg-video-fbturbo-c2.zip xserver-xorg-video-fbturbo-c2-buster-arm64.zip

Before I changed the meson sound drivers from module to built-in audio output was not working sometimes and I needed to reboot multiple times until it came back. There was no way to debug this because the sound card was always shown and not error was reported on boot, but player software was not able to use it (open failed with EINVAL).
Now it is built-in and it always works.
xserver-xorg-video-fbturbo is now able to be built on distros with newer xorg, Kernel and mali-x11 ump works fine on latest Debian buster/testing (source code still works on older versions too).

[odroid]

- Made fbturbo compatible with xserver-xorg-video ABI 23 and 24 (fbturbo-adapt_block_wakeuphandler_signature_for_abi_23.patch)

Nice update! The x11 desktop responsiveness must be much better now

[Ely]

Update 20180830
- Kernel 4.18.5
- Added mali-r6p2-1004-ump_hack_to_force_the_memory_page_writable.patch and mali-r6p2-1005-ump_fix_bad_page_on_reboot.patch
- Added HDMI.conf for alsa
- Added meson-vdec-firmware
linux-4.18-odroidc2-build.tar.gz linux-image-4.18.5-20180830-c2-arm64.zip

Now I found some test scenario for the vdec stuff.
mpv and ffplay from (X)ubuntu 18.04 are able to use the vdec, but under X11 it is still very slow.
I will take a look at Elys repo to find out more.

Code: Select all

# software decoder, hardware output (SDL/opengles): between 130% and 290% CPU, video and audio plays normal without issue
mpv --vo=sdl --fullscreen --ontop --ao=alsa https://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov
# hardware decoder, software output (?): between 100% and 150% CPU, video very slow, audio async
mpv --vo=sdl --fullscreen --ontop --ao=alsa --vd=h264_v4l2m2m https://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov
# hardware decoder, no output
ffplay -fs -vcodec h264_v4l2m2m https://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov

# software decoder, hardware output (SDL/opengles): between 130% and 290% CPU, video and audio plays normal without issue
mpv --vo=sdl --fullscreen --ontop --ao=alsa http://distribution.bbb3d.renderfarming.net/video/mp4/bbb_sunflower_1080p_30fps_normal.mp4
# hardware decoder, software output (?): between 100% and 150% CPU, video very slow, audio async
mpv --vo=sdl --fullscreen --ontop --ao=alsa --vd=h264_v4l2m2m http://distribution.bbb3d.renderfarming.net/video/mp4/bbb_sunflower_1080p_30fps_normal.mp4
# hardware decoder, software output (?): between 100% and 150% CPU, video very slow, audio async
ffplay -fs -vcodec h264_v4l2m2m http://distribution.bbb3d.renderfarming.net/video/mp4/bbb_sunflower_1080p_30fps_normal.mp4

You might be able to get mpv to work in its egl/drm configuration with v4l2-m2m, but you'll need a couple of patches:

FFmpeg: lrusak patches https://github.com/lrusak/FFmpeg/commit ... rmprime-v4
Kernel: narmstrong patch for DRM overlay plane https://github.com/superna9999/linux/co ... 73d70d8f7b

Then you can try mpv with vo=gpu, gpu-context=drm, hwdec=auto (although you'll probably need to kill X11 or whatever is using the display..). This is something I've never tested so I can't guarantee that it'll work, but I'm interested..

[scpcom]

@odroid
Yes, this is the reason I still prefer fbturbo and because this is the only way mali can be used with UMP (2,5 to 3 times faster than dmabuf).

@Ely
Patched Kernel is ready (no download yet).
Patched ffmpeg is building right now. But it will take some time because I let C2 do this

[scpcom]

ffmpeg is ready now, but a short test did not work.
I stopped X11 and executed this in console:

Code: Select all

mpv --vo=gpu --gpu-context=drm --hwdec=auto https://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov

Output:

Code: Select all

 (+) Video --vid=1 (*) (h264 1920x1080 24.000fps)
 (+) Audio --aid=1 --alang=eng (*) (aac 6ch 48000Hz)
gbm: failed to open any driver (search paths /usr/lib/aarch64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri)
gbm: Last dlopen error: /usr/lib/dri/meson_dri.so: cannot open shared object file: No such file or directory
failed to load driver: meson
[vo/gpu/opengl] Failed to get EGL display.
[vo/gpu] Failed to setup EGL.
[vo/gpu] Failed initializing any suitable GPU context!
Error opening/initializing the selected video_out (--vo) device.
Video: no video


Exiting... (Errors when loading file)

I already switched to Mali fbdev but same result.

[Ely]

ffmpeg is ready now, but a short test did not work.
I stopped X11 and executed this in console:

Code: Select all

mpv --vo=gpu --gpu-context=drm --hwdec=auto https://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov

Output:

Code: Select all

 (+) Video --vid=1 (*) (h264 1920x1080 24.000fps)
 (+) Audio --aid=1 --alang=eng (*) (aac 6ch 48000Hz)
gbm: failed to open any driver (search paths /usr/lib/aarch64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri)
gbm: Last dlopen error: /usr/lib/dri/meson_dri.so: cannot open shared object file: No such file or directory
failed to load driver: meson
[vo/gpu/opengl] Failed to get EGL display.
[vo/gpu] Failed to setup EGL.
[vo/gpu] Failed initializing any suitable GPU context!
Error opening/initializing the selected video_out (--vo) device.
Video: no video


Exiting... (Errors when loading file)

I already switched to Mali fbdev but same result.

Ah, bummer. I forgot you were using mali fbdev.. The above would only maybe work with mali wayland, with libgbm/egl/glesv2 symlinked to libmali.

Thanks for taking the time. If you ever get mpv working let me know, this is very interesting.

[memeka]

you need to use mali gbm.
fbdev drivers for sure not working, x11 drivers MAYBE (probably not), wayland drivers most likely to have the gbm component.