Playing with upstream (Exynos4412)

Share here your ideas for new projects
User avatar
Panzerknacker
Posts: 250
Joined: Sat Feb 22, 2014 10:08 pm
languages_spoken: German, English
ODROIDs: U3, X2, XU3, XU4, W
Has thanked: 1 time
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Unread post by Panzerknacker » Fri Jan 18, 2019 5:47 pm

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

User avatar
Panzerknacker
Posts: 250
Joined: Sat Feb 22, 2014 10:08 pm
languages_spoken: German, English
ODROIDs: U3, X2, XU3, XU4, W
Has thanked: 1 time
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Unread post by Panzerknacker » Thu Jan 24, 2019 11:16 pm

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

tve
Posts: 47
Joined: Sun Jul 13, 2014 4:02 pm
languages_spoken: english
ODROIDs: odroid-u3, odroid-c1, odroid-c1+
Has thanked: 0
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Unread post by tve » Fri Jan 25, 2019 1:18 am

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

User avatar
Panzerknacker
Posts: 250
Joined: Sat Feb 22, 2014 10:08 pm
languages_spoken: German, English
ODROIDs: U3, X2, XU3, XU4, W
Has thanked: 1 time
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Unread post by Panzerknacker » Sat Jan 26, 2019 12:19 am

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

LiquidAcid
Posts: 1093
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2
Has thanked: 0
Been thanked: 1 time
Contact:

Re: Playing with upstream (Exynos4412)

Unread post by LiquidAcid » Sat Jan 26, 2019 5:57 am

Panzerknacker wrote:
Sat Jan 26, 2019 12:19 am
The reboot issue with devfreq is resolved now in mainline, too.
https://patchwork.kernel.org/patch/10781431/
Good job triaging this!

User avatar
Panzerknacker
Posts: 250
Joined: Sat Feb 22, 2014 10:08 pm
languages_spoken: German, English
ODROIDs: U3, X2, XU3, XU4, W
Has thanked: 1 time
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Unread post by Panzerknacker » Fri Feb 01, 2019 7:05 pm

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
Posts: 47
Joined: Sun Jul 13, 2014 4:02 pm
languages_spoken: english
ODROIDs: odroid-u3, odroid-c1, odroid-c1+
Has thanked: 0
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Unread post by tve » Sat Feb 02, 2019 2:07 am

Yikes, that's an odd one!

lucabelluccini
Posts: 28
Joined: Mon Feb 25, 2013 8:03 am
languages_spoken: english
ODROIDs: X
Has thanked: 0
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Unread post by lucabelluccini » Sun Mar 24, 2019 2:15 am

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 <
Attachments
output.drmparam.txt
(60.59 KiB) Downloaded 128 times

tve
Posts: 47
Joined: Sun Jul 13, 2014 4:02 pm
languages_spoken: english
ODROIDs: odroid-u3, odroid-c1, odroid-c1+
Has thanked: 0
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Unread post by tve » Tue Mar 26, 2019 2:21 pm

Panzerknacker wrote:
Sat Jan 26, 2019 12:19 am
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"?

User avatar
Panzerknacker
Posts: 250
Joined: Sat Feb 22, 2014 10:08 pm
languages_spoken: German, English
ODROIDs: U3, X2, XU3, XU4, W
Has thanked: 1 time
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Unread post by Panzerknacker » Tue Mar 26, 2019 5:12 pm

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

tve
Posts: 47
Joined: Sun Jul 13, 2014 4:02 pm
languages_spoken: english
ODROIDs: odroid-u3, odroid-c1, odroid-c1+
Has thanked: 0
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Unread post by tve » Thu Mar 28, 2019 6:06 am

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
Posts: 1093
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2
Has thanked: 0
Been thanked: 1 time
Contact:

Re: Playing with upstream (Exynos4412)

Unread post by LiquidAcid » Sat Mar 30, 2019 3:27 am

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

LiquidAcid
Posts: 1093
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2
Has thanked: 0
Been thanked: 1 time
Contact:

Re: Playing with upstream (Exynos4412)

Unread post by LiquidAcid » Sat May 11, 2019 5:28 pm

FYI, just pushed odroid-5.1.y, based on vanilla-5.1.1.
These users thanked the author LiquidAcid for the post:
Panzerknacker (Sat May 11, 2019 5:44 pm)

henriku
Posts: 12
Joined: Tue May 05, 2015 6:32 am
languages_spoken: english
ODROIDs: U3
Has thanked: 0
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Unread post by henriku » Sun May 19, 2019 12:34 am

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
Posts: 32
Joined: Fri Mar 21, 2014 6:23 pm
languages_spoken: english
Has thanked: 0
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Unread post by mories » Tue Aug 06, 2019 5:07 pm

henriku wrote:
Sun May 19, 2019 12:34 am
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
Posts: 4
Joined: Thu Aug 22, 2019 10:52 am
languages_spoken: english
Has thanked: 0
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Unread post by Kurtis » Thu Aug 22, 2019 1:17 pm

mories wrote:
Tue Aug 06, 2019 5:07 pm
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
Posts: 32
Joined: Fri Mar 21, 2014 6:23 pm
languages_spoken: english
Has thanked: 0
Been thanked: 0
Contact:

Lima and Mesa3d

Unread post by mories » Sun Sep 01, 2019 11:14 pm


lucabelluccini
Posts: 28
Joined: Mon Feb 25, 2013 8:03 am
languages_spoken: english
ODROIDs: X
Has thanked: 0
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Unread post by lucabelluccini » Tue Sep 03, 2019 1:50 am

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/

User avatar
Panzerknacker
Posts: 250
Joined: Sat Feb 22, 2014 10:08 pm
languages_spoken: German, English
ODROIDs: U3, X2, XU3, XU4, W
Has thanked: 1 time
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Unread post by Panzerknacker » Tue Sep 03, 2019 3:11 am


lucabelluccini
Posts: 28
Joined: Mon Feb 25, 2013 8:03 am
languages_spoken: english
ODROIDs: X
Has thanked: 0
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Unread post by lucabelluccini » Tue Sep 03, 2019 4:08 am

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.

User avatar
AreaScout
Posts: 1127
Joined: Sun Jul 07, 2013 3:05 am
languages_spoken: german, english
ODROIDs: X2, U3, XU3, C2, HiFi Shield, XU4, XU4Q,
N1, Go, VU5A, Show2, CloudShell2,
H2, N2, VU7A, VuShell
Has thanked: 25 times
Been thanked: 76 times
Contact:

Re: Playing with upstream (Exynos4412)

Unread post by AreaScout » Tue Sep 03, 2019 4:45 pm


hexdump
Posts: 11
Joined: Sat Jan 26, 2019 12:37 am
languages_spoken: english, german
ODROIDs: odroid u3
Has thanked: 0
Been thanked: 1 time
Contact:

Re: Playing with upstream (Exynos4412)

Unread post by hexdump » Sun Sep 08, 2019 6:37 am

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
Posts: 28
Joined: Mon Feb 25, 2013 8:03 am
languages_spoken: english
ODROIDs: X
Has thanked: 0
Been thanked: 0
Contact:

Re: Playing with upstream (Exynos4412)

Unread post by lucabelluccini » Sun Sep 08, 2019 6:31 pm

AreaScout wrote:
Tue Sep 03, 2019 4:45 pm
    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
    Posts: 28
    Joined: Mon Feb 25, 2013 8:03 am
    languages_spoken: english
    ODROIDs: X
    Has thanked: 0
    Been thanked: 0
    Contact:

    Re: Playing with upstream (Exynos4412)

    Unread post by lucabelluccini » Mon Sep 09, 2019 3:41 pm

    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
    Posts: 42
    Joined: Sat Aug 03, 2013 7:35 am
    languages_spoken: english
    Has thanked: 0
    Been thanked: 1 time
    Contact:

    Re: Playing with upstream (Exynos4412)

    Unread post by nijhawank » Tue Sep 10, 2019 2:00 pm

    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.
    hexdump wrote:
    Sun Sep 08, 2019 6:37 am
    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
    Posts: 11
    Joined: Sat Jan 26, 2019 12:37 am
    languages_spoken: english, german
    ODROIDs: odroid u3
    Has thanked: 0
    Been thanked: 1 time
    Contact:

    Re: Playing with upstream (Exynos4412)

    Unread post by hexdump » Sat Sep 14, 2019 6:14 pm

    @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
    Posts: 4
    Joined: Thu Aug 22, 2019 10:52 am
    languages_spoken: english
    Has thanked: 0
    Been thanked: 0
    Contact:

    Re: Playing with upstream (Exynos4412)

    Unread post by Kurtis » Tue Sep 17, 2019 1:17 pm

    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
    Posts: 4
    Joined: Thu Aug 22, 2019 10:52 am
    languages_spoken: english
    Has thanked: 0
    Been thanked: 0
    Contact:

    Re: Playing with upstream (Exynos4412)

    Unread post by Kurtis » Wed Sep 18, 2019 1:02 pm

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

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

    Re: Playing with upstream (Exynos4412)

    Unread post by nijhawank » Sat Sep 21, 2019 4:26 pm

    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
    Posts: 11
    Joined: Sat Jan 26, 2019 12:37 am
    languages_spoken: english, german
    ODROIDs: odroid u3
    Has thanked: 0
    Been thanked: 1 time
    Contact:

    Re: Playing with upstream (Exynos4412)

    Unread post by hexdump » Wed Sep 25, 2019 2:06 am

    @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
    Posts: 28
    Joined: Mon Feb 25, 2013 8:03 am
    languages_spoken: english
    ODROIDs: X
    Has thanked: 0
    Been thanked: 0
    Contact:

    Re: Playing with upstream (Exynos4412)

    Unread post by lucabelluccini » Wed Sep 25, 2019 2:09 am

    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
    Posts: 11
    Joined: Sat Jan 26, 2019 12:37 am
    languages_spoken: english, german
    ODROIDs: odroid u3
    Has thanked: 0
    Been thanked: 1 time
    Contact:

    Re: Playing with upstream (Exynos4412)

    Unread post by hexdump » Wed Sep 25, 2019 2:12 am

    i have no idea about the odroid x - sorry

    lucabelluccini
    Posts: 28
    Joined: Mon Feb 25, 2013 8:03 am
    languages_spoken: english
    ODROIDs: X
    Has thanked: 0
    Been thanked: 0
    Contact:

    Re: Playing with upstream (Exynos4412)

    Unread post by lucabelluccini » Wed Sep 25, 2019 2:19 am

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

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

    Re: Playing with upstream (Exynos4412)

    Unread post by nijhawank » Wed Sep 25, 2019 11:09 am

    hexdump wrote:
    Wed Sep 25, 2019 2:06 am
    @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
    Posts: 11
    Joined: Sat Jan 26, 2019 12:37 am
    languages_spoken: english, german
    ODROIDs: odroid u3
    Has thanked: 0
    Been thanked: 1 time
    Contact:

    Re: Playing with upstream (Exynos4412)

    Unread post by hexdump » Thu Sep 26, 2019 6:03 am

    @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
    Posts: 28
    Joined: Mon Feb 25, 2013 8:03 am
    languages_spoken: english
    ODROIDs: X
    Has thanked: 0
    Been thanked: 0
    Contact:

    Re: Playing with upstream (Exynos4412)

    Unread post by lucabelluccini » Thu Sep 26, 2019 6:57 am

    hexdump wrote:
    Thu Sep 26, 2019 6:03 am
    @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
    Posts: 42
    Joined: Sat Aug 03, 2013 7:35 am
    languages_spoken: english
    Has thanked: 0
    Been thanked: 1 time
    Contact:

    Re: Playing with upstream (Exynos4412)

    Unread post by nijhawank » Thu Sep 26, 2019 8:02 am

    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.
    hexdump wrote:
    Thu Sep 26, 2019 6:03 am
    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 ...
    Attachments
    mmcblk1boot0.zip
    (417.63 KiB) Downloaded 18 times

    Kurtis
    Posts: 4
    Joined: Thu Aug 22, 2019 10:52 am
    languages_spoken: english
    Has thanked: 0
    Been thanked: 0
    Contact:

    Re: Playing with upstream (Exynos4412)

    Unread post by Kurtis » Sat Sep 28, 2019 1:32 am

    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
    Posts: 42
    Joined: Sat Aug 03, 2013 7:35 am
    languages_spoken: english
    Has thanked: 0
    Been thanked: 1 time
    Contact:

    Re: Playing with upstream (Exynos4412)

    Unread post by nijhawank » Wed Oct 02, 2019 3:32 pm

    @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.

    User avatar
    Panzerknacker
    Posts: 250
    Joined: Sat Feb 22, 2014 10:08 pm
    languages_spoken: German, English
    ODROIDs: U3, X2, XU3, XU4, W
    Has thanked: 1 time
    Been thanked: 0
    Contact:

    Re: Playing with upstream (Exynos4412)

    Unread post by Panzerknacker » Wed Oct 02, 2019 10:12 pm

    lucabelluccini wrote:
    Thu Sep 26, 2019 6:57 am
    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

    Post Reply

    Return to “The Ideas”

    Who is online

    Users browsing this forum: No registered users and 1 guest