Playing with upstream (Exynos4412)

[Panzerknacker]

Had to disable DVFS again. Gives spurious hangs with heavy eMMC access.

[Panzerknacker]

The reboot issue with eMMC has been fixed.
https://patchwork.kernel.org/patch/10778831/
Devfreq still needs to be disabled.

[tve]

Great spotting! Thanks for reporting. Are both patches necessary or only this last one?

[Panzerknacker]

The reboot issue with devfreq is resolved now in mainline, too.
https://patchwork.kernel.org/patch/10781431/

[LiquidAcid]

The reboot issue with devfreq is resolved now in mainline, too.
https://patchwork.kernel.org/patch/10781431/

Good job triaging this!

[Panzerknacker]

Just as a notice to save people's time.
During my experiments exploring the reboot issues I discovered that both my X2s do not reboot but hang, if the supply voltage is greater than 5,1 V.
The type of my boards is ODROID-X2+ Rev 0.5 20130228.
An older ODROID-X was not affected.

[tve]

Yikes, that's an odd one!

[lucabelluccini]

Hello all,
I would like to ask for some pointers to proceed further to make HDMI work on a Odroid-X.

I am trying Linux Arch Alarm ([link](https://archlinuxarm.org/platforms/armv ... g/odroid-x)).

USB, LAN, eMMC, SD card are working properly on Kernel 5.0.2.

I cannot manage HDMI work (I'm not asking even for hw acceleration, but just make it work for the console).
I can access both via SSH and Serial.

Just for a sanity check, I've tried a Debian distro to verify HDMI works and I can confirm it works properly.

I tried to pass the parameter "video=HDMI-A-1:1280x720M@60", but I get:

Code: Select all

[Sat Mar 23 16:13:07 2019] exynos-drm exynos-drm: bound 12d00000.hdmi (ops hdmi_component_ops [exynosdrm])
[Sat Mar 23 16:13:08 2019] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[Sat Mar 23 16:13:08 2019] [drm] No driver support for vblank timestamp query.
[Sat Mar 23 16:13:08 2019] s5p-mfc 13400000.codec: decoder registered as /dev/video2
[Sat Mar 23 16:13:08 2019] s5p-mfc 13400000.codec: encoder registered as /dev/video3
[Sat Mar 23 16:13:08 2019] [drm:hdmiphy_enable.part.1 [exynosdrm]] *ERROR* failed to find hdmiphy conf
[Sat Mar 23 16:13:08 2019] smsc95xx v1.0.6
[Sat Mar 23 16:13:08 2019] ------------[ cut here ]------------
[Sat Mar 23 16:13:08 2019] WARNING: CPU: 3 PID: 276 at drivers/gpu/drm/drm_atomic_helper.c:1424 drm_atomic_helper_wait_for_vblanks.part.1+0x28c/0x294
[Sat Mar 23 16:13:08 2019] [CRTC:44:crtc-0] vblank wait timed out
[Sat Mar 23 16:13:08 2019] Modules linked in: rfkill smsc95xx(+) usbnet mii s5p_mfc exynosdrm(+) analogix_dp exynos_adc s5p_jpeg v4l2_mem2mem videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common exynos_rng s5p_sss s3c2410_wdt s5p_cec evdev uio_pdrv_genirq uio sch_fq_codel ip_tables x_tables
[Sat Mar 23 16:13:08 2019] CPU: 3 PID: 276 Comm: kworker/3:3 Not tainted 5.0.2-1-ARCH #1
[Sat Mar 23 16:13:08 2019] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[Sat Mar 23 16:13:08 2019] Workqueue: events output_poll_execute
[Sat Mar 23 16:13:08 2019] [<c03111c8>] (unwind_backtrace) from [<c030bf10>] (show_stack+0x10/0x14)
[Sat Mar 23 16:13:08 2019] [<c030bf10>] (show_stack) from [<c0ee3a38>] (dump_stack+0x7c/0x90)
[Sat Mar 23 16:13:08 2019] [<c0ee3a38>] (dump_stack) from [<c03460c8>] (__warn+0xd4/0xf0)
[Sat Mar 23 16:13:08 2019] [<c03460c8>] (__warn) from [<c0345c8c>] (warn_slowpath_fmt+0x48/0x6c)
[Sat Mar 23 16:13:08 2019] [<c0345c8c>] (warn_slowpath_fmt) from [<c09a82a4>] (drm_atomic_helper_wait_for_vblanks.part.1+0x28c/0x294)
[Sat Mar 23 16:13:08 2019] [<c09a82a4>] (drm_atomic_helper_wait_for_vblanks.part.1) from [<c09a9f24>] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c)
[Sat Mar 23 16:13:08 2019] [<c09a9f24>] (drm_atomic_helper_commit_tail_rpm) from [<c09a9d6c>] (commit_tail+0x40/0x6c)
[Sat Mar 23 16:13:08 2019] [<c09a9d6c>] (commit_tail) from [<c09a9e5c>] (drm_atomic_helper_commit+0xbc/0x128)
[Sat Mar 23 16:13:08 2019] [<c09a9e5c>] (drm_atomic_helper_commit) from [<c09acca0>] (restore_fbdev_mode_atomic+0x1c4/0x1d4)
[Sat Mar 23 16:13:08 2019] [<c09acca0>] (restore_fbdev_mode_atomic) from [<c09b0638>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa4)
[Sat Mar 23 16:13:08 2019] [<c09b0638>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c09b06b8>] (drm_fb_helper_set_par+0x30/0x54)
[Sat Mar 23 16:13:08 2019] [<c09b06b8>] (drm_fb_helper_set_par) from [<c09b05a0>] (drm_fb_helper_hotplug_event.part.11+0x90/0xa8)
[Sat Mar 23 16:13:08 2019] [<c09b05a0>] (drm_fb_helper_hotplug_event.part.11) from [<c09a0184>] (drm_kms_helper_hotplug_event+0x24/0x30)
[Sat Mar 23 16:13:08 2019] [<c09a0184>] (drm_kms_helper_hotplug_event) from [<c09a0348>] (output_poll_execute+0x18c/0x1ac)
[Sat Mar 23 16:13:08 2019] [<c09a0348>] (output_poll_execute) from [<c035e4b4>] (process_one_work+0x1f0/0x408)
[Sat Mar 23 16:13:08 2019] [<c035e4b4>] (process_one_work) from [<c035f33c>] (worker_thread+0x44/0x580)
[Sat Mar 23 16:13:08 2019] [<c035f33c>] (worker_thread) from [<c0364404>] (kthread+0x148/0x150)
[Sat Mar 23 16:13:08 2019] [<c0364404>] (kthread) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
[Sat Mar 23 16:13:08 2019] Exception stack(0xed60bfb0 to 0xed60bff8)
[Sat Mar 23 16:13:08 2019] bfa0:                                     00000000 00000000 00000000 00000000
[Sat Mar 23 16:13:08 2019] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[Sat Mar 23 16:13:08 2019] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
[Sat Mar 23 16:13:08 2019] ---[ end trace e4da785b211ced60 ]---

I am trying to understand if it's something being worked on (Exynos Mainline) or not working at all.

You'll find in attachment the dmesg.

Code: Select all

[Sat Mar 23 16:13:08 2019] [drm:hdmiphy_enable.part.1 [exynosdrm]] *ERROR* failed to find hdmiphy conf <
[Sat Mar 23 16:13:08 2019] [drm] No driver support for vblank timestamp query. <
[Sat Mar 23 16:13:08 2019] [CRTC:44:crtc-0] vblank wait timed out <
[    7.928656] OF: graph: no port node found in /soc/hdmi@12d00000 <

[tve]

The reboot issue with devfreq is resolved now in mainline, too.
https://patchwork.kernel.org/patch/10781431/

@Panzerknacker, dumb question, I'm not seeing the patch in linux-4.20.y, where is it expected to show up "in mainline"?

[Panzerknacker]

Has been replaced by
https://patchwork.kernel.org/patch/10863169/
May land in 5.2?

[tve]

Ugh, at this rate it's going to maybe make it into Linux 7.x? ...

Anyway, I gave your odroid-4.20.y repo branch a shot on my U3 and reboot is still not working. Here's what happens:

Code: Select all

```
[  OK  ] Reached target Shutdown.
[  OK  ] Reached target Final Step.
         Starting Reboot...
[  649.737186] watchdog: watchdog0: watchdog did not stop!
[  650.391717] reboot: Restarting system
[  650.392573] Unable to handle kernel NULL pointer dereference at virtual address 00000049
[  650.398236] pgd = 2ac96e91
[  650.400807] [00000049] *pgd=00000000
[  650.404385] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[  650.409662] Modules linked in: xt_limit xt_recent xt_comment ipt_REJECT nf_reject_ipv4 xt_physdev br_netfilter xt_mark xt
_helper iptable_raw xt_multiport nfnetlink_log xt_NFLOG nf_log_ipv4 nf_log_common xt_LOG nf_conntrack_netlink nfnetlink aes_
arm_bs crypto_simd cryptd s5p_csis s5p_fimc exynos4_is_common v4l2_fwnode rt2800usb rt2800lib rt2x00usb rt2x00lib s5p_jpeg v
4l2_mem2mem s5p_mfc v4l2_common videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common videodev media s5p_cec
 bridge stp llc sch_fq_codel
[  650.455547] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.20.10-tve-g85a7d8e #1
[  650.462964] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[  650.469059] PC is at regulator_force_disable+0x8/0x160
[  650.474160] LR is at syscon_restart_handle+0x18/0x64
[  650.479095] pc : [<c051ffa4>]    lr : [<c0728f50>]    psr: a00f00d3
[  650.485351] sp : ee8e3de8  ip : cfeee050  fp : fffff000
[  650.490554] r10: 00000058  r9 : 00000000  r8 : cfee24b8
[  650.495762] r7 : 00000000  r6 : 00000000  r5 : 00000000  r4 : cfeee050
[  650.502280] r3 : c0728f38  r2 : 00000000  r1 : 00000000  r0 : ffffffed
[  650.508793] Flags: NzCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment none
[  650.516085] Control: 10c5387d  Table: 6c93004a  DAC: 00000051
[  650.521804] Process systemd-shutdow (pid: 1, stack limit = 0x3d71206a)
[  650.528320] Stack: (0xee8e3de8 to 0xee8e4000)
[  650.532655] 3de0:                   cfeee050 00000000 00000000 00000000 cfee24b8 00000000
[  650.540839] 3e00: 00000058 c0728f50 fffffffe 00000000 00000000 c0150530 c11bdd4a c111bc50
[  650.548994] 3e20: 00000000 00000000 ffffffff c01507b4 00000000 00000000 c0150734 c1110cb0
[  650.557154] 3e40: 000f423c 00000000 00000000 01234567 c111bc50 2da73700 fee1dead c015087c
[  650.565313] 3e60: 00000000 c111bc50 2da73700 c010c3cc c1110c88 00000000 01234567 c0152048
[  650.573472] 3e80: 00000000 00000000 00000000 00000000 ffffe000 00000000 600b0053 c1110cb0
[  650.581632] 3ea0: ee8e3f70 c018c258 c11113f0 c11bdec5 c11bfcf0 c01aa268 00000000 c02a701c
[  650.589790] 3ec0: 00000000 00000000 c1110c88 edabc140 00000024 ee8e3ef4 ee8e3f70 00000000
[  650.597950] 3ee0: be8830ec c02bf550 ee8e3ef0 ee8e3ef4 00000000 00000001 00000000 00000024
[  650.606108] 3f00: ee8e3f0c 00000005 ee8f048c be8830b0 00000004 be883ee9 00000010 be8830c4
[  650.614268] 3f20: 00000005 be88317c 0000000a b6e54b10 00000001 fffffe30 5ac3c35a c02a6808
[  650.622427] 3f40: c1110c88 fffffffe fffffffe e237d27d c1110c88 edabc140 edabc140 00000000
[  650.630586] 3f60: 00000000 c02bf5e8 00000000 c011611c 00000000 00000000 00000004 e237d27d
[  650.638746] 3f80: 00000001 e237d27d be88317c 004453ac 00000000 fffffffe 00000058 c01011c4
[  650.646907] 3fa0: ee8e2000 c0101000 004453ac 00000000 fee1dead 28121969 01234567 2da73700
[  650.655065] 3fc0: 004453ac 00000000 fffffffe 00000058 fffff000 00457590 00000000 fffff000
[  650.663224] 3fe0: 00000058 be8839cc b6f6ae35 b6eee206 600b0070 fee1dead 00000000 00000000
[  650.671396] [<c051ffa4>] (regulator_force_disable) from [<c0728f50>] (syscon_restart_handle+0x18/0x64)
[  650.680695] [<c0728f50>] (syscon_restart_handle) from [<c0150530>] (notifier_call_chain+0x44/0x84)
[  650.689619] [<c0150530>] (notifier_call_chain) from [<c01507b4>] (__atomic_notifier_call_chain+0x80/0x130)
[  650.699256] [<c01507b4>] (__atomic_notifier_call_chain) from [<c015087c>] (atomic_notifier_call_chain+0x18/0x20)
[  650.709418] [<c015087c>] (atomic_notifier_call_chain) from [<c010c3cc>] (machine_restart+0x7c/0x80)
[  650.718439] [<c010c3cc>] (machine_restart) from [<c0152048>] (sys_reboot+0x10c/0x1f8)
[  650.726243] [<c0152048>] (sys_reboot) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
[  650.733872] Exception stack(0xee8e3fa8 to 0xee8e3ff0)
[  650.738893] 3fa0:                   004453ac 00000000 fee1dead 28121969 01234567 2da73700
[  650.747073] 3fc0: 004453ac 00000000 fffffffe 00000058 fffff000 00457590 00000000 fffff000
[  650.755229] 3fe0: 00000058 be8839cc b6f6ae35 b6eee206
[  650.760249] Code: e5840008 e8bd8010 e92d47f0 e3a01000 (e590405c)
[  650.766332] ---[ end trace daf880ce50191fdc ]---
[  650.782343] watchdog: watchdog0: watchdog did not stop!
[  650.782562] printk: systemd-shutdow: 4 output lines suppressed due to ratelimiting
[  650.790044] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[  650.797214] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
```

[LiquidAcid]

Looks like you're not using the correct DT, otherwise it should find the regulator.

[LiquidAcid]

FYI, just pushed odroid-5.1.y, based on vanilla-5.1.1.

[henriku]

The lima driver which supports Mali-400 has been merged in mainline and should land in linux 5.2. Has anyone tested this with Exynos 4412?

https://github.com/torvalds/linux/commi ... e9e9a8e119

[mories]

The lima driver which supports Mali-400 has been merged in mainline and should land in linux 5.2. Has anyone tested this with Exynos 4412?

I've tested it with kernel 5.2.6 on my U3, but I get the following error messages:

Code: Select all

[   47.421227] lima 13000000.gpu: get bus clk failed -2
[   47.421237] lima 13000000.gpu: clk init fail -2
[   47.421242] lima 13000000.gpu: Fatal error during GPU init
[   47.421298] lima: probe of 13000000.gpu failed with error -2

Any idea what the problem may be?

Edit: With kernel 5.3-rc3 seems to work better

Code: Select all

[  165.659805] lima 13000000.gpu: bus rate = 24000000
[  165.659821] lima 13000000.gpu: mod rate = 50000000
[  165.661670] lima 13000000.gpu: gp - mali400 version major 1 minor 1
[  165.661795] lima 13000000.gpu: pp0 - mali400 version major 1 minor 1
[  165.661889] lima 13000000.gpu: pp1 - mali400 version major 1 minor 1
[  165.661963] lima 13000000.gpu: pp2 - mali400 version major 1 minor 1
[  165.662064] lima 13000000.gpu: pp3 - mali400 version major 1 minor 1
[  165.662118] lima 13000000.gpu: l2 cache 128K, 4-way, 64byte cache line, 64bit external bus
[  165.663083] [drm] Initialized lima 1.0.0 20190217 for 13000000.gpu on minor 1

Now I will try 3D graphics with mesa-19.1.3

[Kurtis]

With kernel 5.3-rc3 seems to work better

[...]

Now I will try 3D graphics with mesa-19.1.3

This is very exciting news that you the lima driver seems to be working with the mainline kernel now. I work with the Replicant project and some of my colleagues are working on graphic support for the samsung galaxy s3, which I assume will be beneficial for all Exynos4412 users, like the ODROID community here. You can read a bit about their current work here: https://blog.replicant.us/2019/07/graph ... plicant-9/ As you can see, right now they are mainly focused on software rendering. One big unknown is how much of GLES 2 does Lima support. We asked here but haven't gotten an answer yet: https://bugs.freedesktop.org/show_bug.cgi?id=111129 That being said, it would be great to have lima working even if only with surfaceflinger or as a backend for HWUI.

Anyways, I just set my account up here on the forums today and am excited to potentially collaborate with you all moving forward.

[mories]

@Kurtis : FYI https://gitlab.freedesktop.org/lima/mesa/issues/109

[lucabelluccini]

Latest kernels broke USB enumeration on Odroid X (4412).
Are you aware of this issue?

I'm trying to troubleshoot this issue and I've found out a potential patch which is not yet merged https://patchwork.kernel.org/patch/11060465/

[Panzerknacker]

Does this help you?
https://patchwork.kernel.org/patch/10950643/

[lucabelluccini]

Hello Panzerknacker, it should probably solve my problem.
I am using https://archlinuxarm.org/platforms/armv ... g/odroid-x and after moving from 4.10 to 5.x, I've lost all USB devices (and ethernet, which is also a USB device).
Luckly I have a serial port...

My only solution is to download the Kernel sources, compile it apply the patch you've linked?
Do you have any pointer for a guide/procedure to do so on my odroid-x?
I've already recompiled a Kernel for Android Platform development but I'm not really into this subject recently.

[AreaScout]

Here is a kernel compile guide https://github.com/umiddelb/armhf/wiki/ ... e#examples

RG

[hexdump]

in case anyone is interested you can find all my files, patches, notes about running mainline with mali on the odroid u3 here:

https://github.com/hexdump0815/linux-ma ... r/misc.exy

maybe there is some interesting stuff in there for others running mainline on the u3 (like working cpu cooling without a fan on the odroid u3 - no more turning off due to overheating and lots of other stuff)

best wishes - hexdump

[lucabelluccini]

Here is a kernel compile guide https://github.com/umiddelb/armhf/wiki/ ... e#examples

RG

I am aware of it, but I was searching something more specific to Arch and for the Odroid X (your link mentions X2, but there is no link), I'll check further though

[lucabelluccini]

I'm building the kernel using https://github.com/archlinuxarm/PKGBUIL ... nux-armv7/

I've added the patch regarding USB as you've suggested.

When compiling, I end up with:

Code: Select all

  UPD     drivers/base/firmware_loader/builtin/am335x-pm-firmware.elf.gen.S
make[4]: *** No rule to make target 'firmware/am335x-pm-firmware.elf', needed by 'drivers/base/firmware_loader/builtin/am335x-pm-firmware.elf.gen.o'.  Stop.
make[3]: *** [scripts/Makefile.build:489: drivers/base/firmware_loader/builtin] Error 2
make[2]: *** [scripts/Makefile.build:489: drivers/base/firmware_loader] Error 2
make[1]: *** [scripts/Makefile.build:489: drivers/base] Error 2
make: *** [Makefile:1071: drivers] Error 2

I've commented out the extra firmwares from the config file.

It seems related to the support of BeagleBone boards (as I'm building the generic armv7 kernel).

----

UPDATE

Applying the patch didn't solve the problem:

Code: Select all

[    3.021370] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    3.026548] ehci-pci: EHCI PCI platform driver
[    3.030992] ehci-platform: EHCI generic platform driver
[    3.036392] ehci-mxc: Freescale On-Chip EHCI Host driver
[    3.041547] ehci-omap: OMAP-EHCI Host Controller driver
[    3.046807] ehci-orion: EHCI orion driver
[    3.050825] ehci-exynos: EHCI EXYNOS driver
[    3.055294] exynos-ehci 12580000.ehci: EHCI Host Controller
umber 1
[    3.068330] exynos-ehci 12580000.ehci: irq 50, io mem 0x12580000
[    3.089911] exynos-ehci 12580000.ehci: USB 2.0 started, EHCI 1.00
[    3.090515] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.02
[    3.098639] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.105833] usb usb1: Product: EHCI Host Controller
[    3.110689] usb usb1: Manufacturer: Linux 5.2.0-1-ARCH ehci_hcd
[    3.116592] usb usb1: SerialNumber: 12580000.ehci
[    3.121757] hub 1-0:1.0: USB hub found
[    3.125043] hub 1-0:1.0: 3 ports detected
[    3.129573] tegra-ehci: Tegra EHCI driver
[    3.133219] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    3.139177] ohci-pci: OHCI PCI platform driver
[    3.143625] ohci-platform: OHCI generic platform driver
[    3.149000] ohci-exynos: OHCI EXYNOS driver
[    3.153607] usbcore: registered new interface driver uas
[    3.158315] usbcore: registered new interface driver usb-storage
[    3.164269] usbcore: registered new interface driver ums-cypress
[    3.170258] usbcore: registered new interface driver ums_eneub6250
[    3.176421] usbcore: registered new interface driver ums-freecom
[    3.182410] usbcore: registered new interface driver ums-isd200
[    3.188310] usbcore: registered new interface driver ums-usbat
[    3.214921] usb3503 0-0008: switched to HUB mode
[    3.214988] usb3503 0-0008: usb3503_probe: probed in hub mode

After applying this Patch: https://patchwork.kernel.org/patch/10950643/

I end up with the problem described here: https://lkml.org/lkml/2019/5/7/699
It seems I have to apply to changes, but I am surprised I cannot get an associated patch in patchwork.

[nijhawank]

hi, thank you for your efforts, I had been earlier trying to build the kernel's using tobiasjakobi work. However, I was running into problem that my odroid-u3 was getting hung (the heart beat indicator stops) within seconds of boot.

Is the Mali work here same as Tobiasjakobi's one, what's the delta?

Secondly, can you please provide some instructions to integrate it in an ubuntu or archlinuxarm distro? where all to put to various Mali related artifacts, x11 drivers etc.

Thanks.

in case anyone is interested you can find all my files, patches, notes about running mainline with mali on the odroid u3 here:

https://github.com/hexdump0815/linux-ma ... r/misc.exy

maybe there is some interesting stuff in there for others running mainline on the u3 (like working cpu cooling without a fan on the odroid u3 - no more turning off due to overheating and lots of other stuff)

best wishes - hexdump

[hexdump]

@nijhawank - please have a look at the included readme files (README.txt, readme.exy, redme.exy-mali) - in them i have tried to put together some notes of how to use all this (for instance the section "using gles or opengl with special rk3288 armsoc xorg server" in README.txt describes how to extract all the required mali parts) ... all the binaries are compiled for ubuntu 18.04, in case you want to run it on debian, arch linux etc. you'll most probably have to rebuild the gl4es libGL.so.1 in the mali tar.gz and the armsoc driver - both is described in readme.exy-mali)

good luck and best wishes - hexdump

[Kurtis]

Here's a success story from a person successfully running Android on MALI-400 using lima with a Orange Pi Plus 2E: https://gitlab.freedesktop.org/lima/mesa/issues/120

[Kurtis]

Here's a success story of getting lima running on an Exynos4412 Samsung Galaxy S3: https://github.com/CustomROMs/android_l ... -532308101

[nijhawank]

hi @Hexdump

You pointed to https://github.com/paolosabatino/xf86-video-armsoc.git while there's one that's forked and worked on by Tobias himself. It seems to have additional g2d acceleration related changes along with libdrm. Wouldn't that be better?

may be you can answer one more thing, completely unrelated to this. my ODROID-u3 is inside a case and the emmc or sdcard are not easily accessible so I had been trying to boot directly from usb. However, there's a problem that if the usb is already initialized in uboot, the kernel fails to detect any usb devices. So I'm able to load the kernel directly from usb, but then the boot hangs on waiting for root device to become available.
There are patches in TobiasJakobi's tree to provide a fix for that which I merged in my tree but it still works only randomly. These patches are
[PATCH v16 0/7] power: add power sequence library
[PATCH 0/4] ARM: exynos: Fix Odroid U3 USB/LAN when TFTP booting (power sequence)

can you help?

[hexdump]

@nijhawank and others interested - i have now upgraded to v5.3.1 and added the usb power sequence patches mentioned plus some more patches from tobias jakobis tree ... sadly mali got even less stable in this setup: sometimes it works, but often i'm getting strange crashes on boot or reboot and sometimes also after loading the maligpu module - something is not really ok with this - it would be interesting to see if @liquidacid is seeing the same problems with his tree on v5.3 ... new in v5.3 is that there is a mali gpu node in the tree (for lima) - initially i tried to rewrite the mali driver to use this, but this was getting a bit of a mess and ended up in a lot of debugging, so i decided to drop the new gpu node and use the old one instead for now ... i have now also built some ready to use bootable sd card images with ubuntu 18.04 and debian 10 for the odroid u3 and u3+ (i guess it might work with the x2 too?) in case someone still has an old u3 in the shelf and want to put some fresh kernel and distro on it - it seems to run very well as long as mali is off (i have blacklisted the module by default now, but it can be easily enabled)

my patches and info: https://github.com/hexdump0815/linux-ma ... -odroid-u3
the initial bootable sd card images: https://github.com/hexdump0815/imagebui ... /190924-01

@nijhawank - i did not include the g2d and other patches as i do not really feel the need for them and would like to stay closer to pure mainline with my kernel

best wishes - hexdump

[lucabelluccini]

Any chance this would work on odroid-x?
My big problem at the moment is cross compiling the kernel for odroid-x as I would like to keep using the pkgbuild and keep track of all the patches to apply in order to make the usb (and consequently Eth work).

[hexdump]

i have no idea about the odroid x - sorry

[lucabelluccini]

Basically is the X2, but 1gb of ram and 4412 instead of 4412prime

[nijhawank]

@nijhawank and others interested - i have now upgraded to v5.3.1 and added the usb power sequence patches mentioned plus some more patches from tobias jakobi

@nijhawank - i did not include the g2d and other patches as i do not really feel the need for them and would like to stay closer to pure mainline with my kernel

best wishes - hexdump

Thanks hexdump.

So I tried your ubuntu image and tried booting directly off USB, it boots but then gets stuck waiting for root (/dev/sda*) device to become available which never happens. This is similar to what was happening with my own built kernel with appropriate power sequence patches. So that means it's problem with the patches (don't work reliably) or maybe my u3.

I didn't try Mali yet (didn't try to load it) as I don't have access to a HDMI display but I encountered another problem which is when I do a poweroff, the odroid powers off within a second with no log on the serial console.
Does it seem like a crash to you? because I see an error in the dmesg log about a corrupted system journal file under /bar/log/journal directory.

Thanks for your efforts to being the latest kernel to this awesome little computer.

[hexdump]

@lucabelluccini - i had a look at the odroid x specs and it should indeed be possible to get it working on it as well i guess, besides that the odroid u-boot dts does not seem to rely on any prime features or the 2g memory, so that should work in theory too - the next kernel and image i'll build will include the odroid-x dtb as well ... but it will take a few days until i get to rebuilding it again

@nijhawank - thanks for the testing and the feedback - so i think i'll drop all the added extra patches from the last round again as they do not bring any noticable advantage it seems - maybe the kernel will then even get more stable with mali (but most probably this will not be the case) ... regarding your usb boot problem: why not simply mounting /boot from emmc/sd and load the kernel etc. during boot from there and then mount the root fs from usb? btw.: is the serial console with my mainline u-boot in the image working read/write for you? i can see the serial output, but cannot enter anything - i tried it with two different odroid serial adapters and its the same for both - i'm not really sure if my odroid has a fault or if this is a but in mainline u-boot ...

best wishes - hexdump

[lucabelluccini]

@lucabelluccini - i had a look at the odroid x specs and it should indeed be possible to get it working on it as well i guess, besides that the odroid u-boot dts does not seem to rely on any prime features or the 2g memory, so that should work in theory too - the next kernel and image i'll build will include the odroid-x dtb as well ... but it will take a few days until i get to rebuilding it again

That would be great! I can test the image and I am in no hurry

While I do not consider Mali a priority, I am interested in making USB (& related Ethernet) work again on Arch ARM Linux so I can use it as a small server.
The support for USB for Odroid-X board (and probably X2 too) is broken since 5.0 (was working 1 year ago): it seems not able to enumerate the ports.

This is the kernel they build & the patches applied for Arch ARM Linux: https://github.com/archlinuxarm/PKGBUIL ... inux-armv7
It is mainline kernel plus few patches. I am wondering if I could replicate your work, applying the same patches you have on https://github.com/hexdump0815/linux-ma ... r/misc.exy

[nijhawank]

Yes in absence of being able to boot directly from usb, I copy the boot files to MMC and the root partition remains on USB but It's a hassle to first copy the boot files to mmc/sdcard when you keep on trying new kernels and stuff. The reason is my u3 is enclosed in a case that does not have easily accessible emmc or sdcard slots.

Regarding the u-boot, I have my own compiled uboot (from 2017.05). That time extlinux was not available for Odroid in the mainline but I found a patch to enable it which I manually merged. I lost that setup but I dd'd the uboot files off my emmc. I have these attached for you to try on your Odroid. It works flawless for me.
Be sure to skip a sector when you write it to a sdcard. This is not necessary on emmc and you need to use the boot0 partition i.e. mmcblk1boot0.

one more thing. when I do a poweroff on ubuntu image, I don't see any logs on the console and the u3 powers off in a second (it seems like a crash). Then on next boot, I see an error about corrupt journal file /var/log/journal/blahblahblah/system-<something>.
This problem is not on Debian image and I can see the poweroff logs on console and no corrupt journal warning on next boot.

Again, many thanks for your efforts to bring the latest linux on this nice little box.

regarding your usb boot problem: why not simply mounting /boot from emmc/sd and load the kernel etc. during boot from there and then mount the root fs from usb? btw.: is the serial console with my mainline u-boot in the image working read/write for you? i can see the serial output, but cannot enter anything - i tried it with two different odroid serial adapters and its the same for both - i'm not really sure if my odroid has a fault or if this is a but in mainline u-boot ...

[Kurtis]

In the last few years Samsung, LineageOS, and Replicant have all done work porting various Exynos4412 dev boards, smartphones, and tablets to work with an up to date mainline u-boot. I wrote a little bit about the progress here: https://github.com/oranav/i9300_emmc_toolbox/issues/16 I'd be neat if all of these projects, including ODROID, could collaborate to further liberate and stabilize their mainline u-boot ports since they all work on the same SoC and there should be a lot of code overlap.

[nijhawank]

@hexdump and other experts,

1. I'm trying to understand the various xf86-video-xxx options available for odroid and their pros and cons. May be you can enlighten me with some more information.

I have no knowledge in this space so this is all I could understand, please correct me if I'm wrong. Also, please understand that my usage of the terms "display" / "render" etc. are more from the perspective of an end-user and these may not be very accurate.

xf86-video-fbdev - the most simplest of X11 DDX that interfaces with the GPU using the /dev/fb exposed. No 2d acceleration what so ever.

x86-video-mali - similar to fbdev but has the necessary glue for 3d apps to be displayed / rendered inside a x11 window and 3d apps accelerated by Mali

xf86-video-armsoc - x11 DDX written with newer kernel standards such as interface to GPU using kernel layer DRM, KMS. Again no 2d acceleration except what was being developed by Tobias Jakobi in his fork.

xf86-video-fbturbo - better version of xf86-video-fbdev but with 2d acceleration for allwinner, sunxi SOCs but not for Exynos

Is the understanding correct?

2. Few other questions.. I don't understand the two versions, Mali-x11 and Mali-fbdev we have for odroid-u3. The corresponding docs say that the respective versions are for the appropriate desktop platforms i.e. X11 and fbdev respectively. So my understanding is...

So Mali-X11 allows an OpenGLES app to be displayed / rendered inside an X11 window

But I'm not aware of any Linux desktop system that is directly atop fbdev. The only example I know is there are versions of XBMC/Kodi that directly run atop fbdev. So my understanding is Mali-Fbdev is used when you have such non-X11 applications. So my understanding of Mali-fbdev is that it is Mali-nonX11. Is this correct?

There is some confusion caused as there is a version of X11 DDX that is xf86-video-fbdev i.e. x11 itself draws / interfaces to graphics device using fbdev but that doesn't mean Mali-fbdev can be used here as X11 is the desktop system.

So Mali-X11 allows to coordinate an OpenGLES app inside an X11 window while Mali-fbdev allows to coordinate an OpenGLES app with another OpenGLES or 2D app directly using fbdev. Is the understand correct?

3. For the x11 2d acceleration, I understand that glamor may be used to accelerate 2d using OpenGL (may be OpenGLES, please correct me). So why is this not tried for Exynos considering we do have Mali 3d acceleration.

@hexdump, as I understand you have been able to get OpenGL emulated on Mali with gl4es library. Couldn't glamor use it to accelerate 2d?

thanks for your answers.

[Panzerknacker]

While I do not consider Mali a priority, I am interested in making USB (& related Ethernet) work again on Arch ARM Linux so I can use it as a small server.
The support for USB for Odroid-X board (and probably X2 too) is broken since 5.0 (was working 1 year ago): it seems not able to enumerate the ports.

Works again on plain 5.3:
root@odroid-x2:~# uname -a
Linux odroid-x2 5.3.1 #48 SMP Fri Sep 27 14:39:05 CEST 2019 armv7l GNU/Linux
root@odroid-x2:~# lsusb
Bus 001 Device 004: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 003: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 002: ID 0424:3503 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

[Kurtis]

It looks like there has been some recent activity on this over on github: https://github.com/hexdump0815/linux-ma ... 3/releases

Linux 5.4.5 now working on ODROID U3.

[rodolfoap]

Fantastic! just copied it to /boot, added an /etc/extlinux/extlinux.conf entry and it runs! Thanks, keep up the good work.

(kernel absolute newbie here) to compile the kernel, I was browsing https://github.com/hexdump0815/linux-ma ... -odroid-u3, tried a couple of things, but I don't understand the readme.exy procedure (where is the code? I downloaded one, didn't compile (buster), what is required to compile? what should I do on debian, what on the odroid? etc)... googled a bit, loads of confusing info, so I got lost

I would like to enable nft (compile the kernel), how should I start? Thanks in advance. Happy new year!

[hexdump]

looks like my update has been discovered before i was able to write a little note here ... happy new year btw. ...

as mentioned above i have updated my odroid u3 kernel patches, kernel build and bootable disk images at:
https://github.com/hexdump0815/linux-ma ... -odroid-u3
https://github.com/hexdump0815/linux-ma ... stb-exy%2B
https://github.com/hexdump0815/imagebui ... /191230-01

@lucabelluccini - this version now also includes the odroid x dtb - so maybe it works on that model now too ...

@rodolfoap - sorry if the documentation is not the best, but my time is limited - maybe in quick (see also the top of the readme.exy):
mkdir -p /compile/source /compile/result/stable /compile/doc
cd /compile/source
git clone https://git.kernel.org/pub/scm/linux/ke ... stable.git
cd /compile/doc
git clone https://github.com/hexdump0815/linux-ma ... oid-u3.git
mv linux-mainline-and-mali-on-odroid-u3 stable

and from then on it should work by copy and pasting the readme.exy assuming you have all the dev stuff installed on your system, a lot of disk space and time ("apt-get install build-essential git" ... maybe more might be required)

just in case anyone from here has an old samsung snow chromebook laying around somewhere (exynos cpu too) - i have done the same for it at:
https://github.com/hexdump0815/linux-ma ... chromebook
https://github.com/hexdump0815/linux-ma ... stb-cbe%2B
https://github.com/hexdump0815/imagebui ... /191230-01

by the way: i'm test-using my good old u3 as my main desktop machine right now and it works surprisingly well for normal light web and temrinal usage running off a sandisk ultra a1 sd card (a1 is good for good random read/write performance) ...

good luck and best wishes - hexdump

[sfa]

Happy New Year, hexdump and really big thanks for Your efforts! I've compiled 5.5.0-rc3-v7 and this is running very well on my u3. The only annoying issue (and from my point of view, this is a big NO GO) is present though - reboot doesn't work. Tried different versions of u-boot and older kernels with no help. So i guess, my u3 will stay to collect dust further.

[rodolfoap]

Happy new year! tHANKS, hexdump, may the force be with you.

Here's my rendition of the process: https://github.com/rodolfoap/kernel-odroid-u3
(only tested on my Odroid-U3, my config has nft enabled).

(UPDATE: cryptsetup issues solved, see the README.md file)

[hexdump]

@rodolfoap thanks a lot for your documentation - i have added a link to it to my readme as well, in case others have problems to understand my readme too

@sfa regarding your reboot problems two things come to my mind - first there is a hardware design fault on the original u3 (not the u3+):

Code: Select all

the first revision of the odroid u3 has a bug (hdmi leakage current) preventing it powering on properly:

https://forum.odroid.com/viewtopic.php?f=80&t=3322
https://forum.odroid.com/viewtopic.php?f=80&t=3605

workaround: press reset button a few secs on startup to turn it on
fix: soldering some capacitor and resistor (second link)

second i had an old patch to help with reboots on the u3 which is no longer needed for mine, but maybe it still helps with yours? - you might give it a try (i think it came from arch linux arm or so):

Code: Select all

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 8aa19ba..8e2d94e 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -423,7 +423,7 @@
 
 			buck2_reg: BUCK2 {
 				regulator-name = "vdd_arm";
-				regulator-min-microvolt = <900000>;
+				regulator-min-microvolt = <1100000>;
 				regulator-max-microvolt = <1350000>;
 				regulator-always-on;
 				regulator-boot-on;

good luck and best wishes - hexdump

[sfa]

yes i've revision v. 0.2 u3. recompiled now and the system reboots finally now, so i can confirm this is really a working solution!

[tve]

Awesome work @rodolfoap and @hexdump! Thank you so much! It rejuvenated my aging U3

[3dfx]

Hello!
Has anyone tried Ubuntu 20.04 LTS on the u3 already?

Edit: OK, I tried it myself with do-release-upgrade from 18.04 using hexdump's 5.4.14 kernel. So far it looks good and stable...

[alfie]

Hello everyone!
I have upgrade u3 to 20.04 from hexdump 18.04 image too.
It work!
Thanks to @rodolfoap and @hexdump for their great job!
For those interested: I updated the emmc-recovery image to the latest u-boot.
I can post it here.
Thanks to everybody!