Kernel 5.4 Development Party

memeka · Unread post by **memeka** » Wed Dec 04, 2019 8:54 am

hominoid wrote: ↑
Tue Dec 03, 2019 10:55 am

memeka wrote: ↑
Mon Dec 02, 2019 5:55 pm
Can someone else post some sd card benchmarks?
This is a 32GB SanDisk Ultra
Code: Select all
hominoid@xu4-lab:~$ uname -a
Linux xu4-lab 5.4.0+ #2 SMP Sat Nov 30 23:09:24 EST 2019 armv7l armv7l armv7l GNU/Linux

hominoid@xu4-lab:~$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"; rm ddfile
250000+0 records in
250000+0 records out
2048000000 bytes (2.0 GB, 1.9 GiB) copied, 93.7846 s, 21.8 MB/s

real	1m38.407s
user	0m0.437s
sys	0m25.387s

This is my 16GB Sandisk Ultra - class 10, not UHS:

Code: Select all

odroid@odroid:~$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"; rm ddfile
dd: error writing 'ddfile': No space left on device
151778+0 records in
151777+0 records out
1243361280 bytes (1.2 GB, 1.2 GiB) copied, 750.181 s, 1.7 MB/s

real    12m30.194s
user    0m0.129s
sys     0m12.217s

Maybe there's something wrong with it.... this is my Samsung 8GB UHS-1:

Code: Select all

odroid@hc1:~$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"; rm ddfile
250000+0 records in
250000+0 records out
2048000000 bytes (2.0 GB, 1.9 GiB) copied, 64.5513 s, 31.7 MB/s

real    1m8.663s
user    0m0.214s
sys     0m26.716s

Unread post by **odroid** » Wed Dec 04, 2019 10:48 am

We've test the micro SD card performance between Kernel 4.14 and 5.4.
There was no serious performance difference.

- 5.4 (W/R, MiB/sec)
UHS-1: 31.2 / 80.5
Class10: 6.4 / 20.2
- 4.14 (W/R)
UHS-1: 33.9 / 84.3
Class10: 6.4 / 19.5

5.4 kernel UHS-1

Code: Select all

root@odroid:/media/microsd# dd if=/dev/zero of=test oflag=direct bs=8M count=64
64+0 records in
64+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 17.2109 s, 31.2 MB/s
root@odroid:/media/microsd# dd if=test of=/dev/null iflag=direct bs=8M
64+0 records in
64+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 6.67027 s, 80.5 MB/s

5.4 kernel Non-UHS Class 10

Code: Select all

root@odroid:/media/microsd# !239
dd if=/dev/zero of=test oflag=direct bs=8M count=64
64+0 records in
64+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 84.2938 s, 6.4 MB/s
root@odroid:/media/microsd# !240
dd if=test of=/dev/null iflag=direct bs=8M
64+0 records in
64+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 26.5162 s, 20.2 MB

4.14 kernel UHS-1

Code: Select all

root@odroid:/media/microsd# dd if=/dev/zero of=test oflag=direct bs=8M count=64
64+0 records in
64+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 15.8499 s, 33.9 MB/s
root@odroid:/media/microsd# dd if=test of=/dev/null iflag=direct bs=8M
64+0 records in
64+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 6.36845 s, 84.3 MB/s

4.14 kernel Non-UHS Class 10

Code: Select all

root@odroid:/media/microsd# dd if=/dev/zero of=test oflag=direct bs=8M count=64
64+0 records in
64+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 83.2994 s, 6.4 MB/s
root@odroid:/media/microsd# !52
dd if=test of=/dev/null iflag=direct bs=8M
64+0 records in
64+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 27.5477 s, 19.5 MB/s

I think memeka's old card seems to have too many worn out NAND cells.

AreaScout · Unread post by **AreaScout** » Wed Dec 04, 2019 6:45 pm

@odroid

Any news on the LCD driver ? I would love to test this

RG

Unread post by **odroid** » Thu Dec 05, 2019 9:55 am

@AreaScout,
We need around one week to implement the SPI LCD drivers due to some other urgent jobs.

AreaScout · Unread post by **AreaScout** » Thu Dec 05, 2019 4:11 pm

That's great news !

RG

rooted · Unread post by **rooted** » Thu Dec 05, 2019 4:13 pm

AreaScout wrote:
That's great news !

RG

I've had no problems with 5.4 on the original cloudshell but an waiting for this since I enjoy your display application on the CS2.

AreaScout · Unread post by **AreaScout** » Thu Dec 05, 2019 5:50 pm

@rooted

Good to here, there is quite a "fan-base" around that tool, it's been downloaded more then 1000 times

P.S.: I can't find the thank you button any more, bug ?

RG

Unread post by **odroid** » Thu Dec 05, 2019 6:30 pm

We've just updated the server and rebooted. Its uptime was over 2.5 years and there were too much garbage in the RAM probably.
The forum and wiki responsiveness seems to be much faster now but there are a few minor SQL related problems. We are trying to fix it.

AreaScout · Unread post by **AreaScout** » Thu Dec 05, 2019 6:39 pm

@odroid

Yes site response is better now, the 'thank you' button is only disabled for this sub-forum it seems, so it's just a setup I think

RG

Unread post by **odroid** » Thu Dec 05, 2019 7:14 pm

I've pressed the "Thank you" button on your post and it seems to be working.

AreaScout · Unread post by **AreaScout** » Thu Dec 05, 2019 8:19 pm

This is strange, I see that you liked the post but I can't like yours, the button is missing

RG

tobetter · Unread post by **tobetter** » Thu Dec 05, 2019 8:53 pm

AreaScout wrote: ↑
Thu Dec 05, 2019 8:19 pm

This is strange, I see that you liked the post but I can't like yours, the button is missing

RG

Ok, now you can.

joshua.yang · Unread post by **joshua.yang** » Mon Dec 09, 2019 6:26 pm

We've been working on @memeka's 5.4 kernel. We hope this kernel could be used as a daily driver on XU4.

I did some essential jobs for XU4, and just made a PR to @memeka's Github repository. Please check it @memeka, if you see this post before checking your Github.

Here's the link: https://github.com/mihailescu2m/linux/pull/4

The comments of the PR.
-----
Hi, @memeka.

I'm working on making your terrific 5.4 kernel more fit into our Odroid XU4.
Major changes:

Replaced defconfig for GUI compatibility (Thanks to rooted from our forum)
Enabled I2C, SPI on 40 pin header
Added /dev/gpiomem
Modified /proc/cpuinfo
Added fb_hktft3* modules for our TFT LCD hats and Cloudshell, Cloudshell2, OGST.
Please refer to the commits for details.

Before publishing 5.4 kernel on our Hardkernel Github repository, I would like to make PR for those who want to use 5.4 kernel on their XU4 although it is on an experimental state so far.

Thanks.

-----

And, FB driver for CS1, CS2, OGST are ready.
To enable LCD on them, edit arch/arm/boot/dts/exynos5422-odroidxu4.dts with referring to the below steps.
1. Make the below nodes' "status" value to "disabled".
- i2c_1
- hsi2c_5
- spidev
2. Make hktft_cs_ogst node's status to "okay".

Then, the diff can be generated like,

Code: Select all

diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
index 6e7da591654f..e0cc24919e33 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
@@ -143,13 +143,13 @@

 /* i2c@12C70000 */
 &i2c_1 {
-       status = "okay";
+       status = "disabled";
        samsung,i2c-max-bus-freq = <400000>;
 };

 /* i2c@12cb0000 */
 &hsi2c_5 {
-       status = "okay";
+       status = "disabled";
        samsung,hs-mode;
        clock-frequency = <400000>;
 };
@@ -161,7 +161,7 @@
        cs-gpios = <&gpa2 5 GPIO_ACTIVE_HIGH>, <&gpx2 1 GPIO_ACTIVE_HIGH>;

        spidev: spidev@0 {
-               status = "okay";
+               status = "disabled";
                reg = <0>;
                compatible = "odroid,spidev";
                spi-max-frequency = <1000000>;
@@ -173,7 +173,7 @@
        };

        hktft_cs_ogst: hktft_cs_ogst@0 {
-               status = "disabled";
+               status = "okay";
                compatible = "odroid,hktft32";
                reg = <0>;
                pinctrl-names = "default";

Thanks.

rooted · Unread post by **rooted** » Mon Dec 09, 2019 6:38 pm

Will test it out once it's merged, I can get my display working again on the original cloudshell and build it for the cloudshell 2. Great news.

MastaG · Unread post by **MastaG** » Mon Dec 09, 2019 8:51 pm

Well I know the XU3 is basically a discontinued product.
However the smsc95xx ethernet driver is giving timeouts which hang the system or a while when doing heavy stuff (such as "dnf upgrade") on linux 5.4.

Code: Select all

[  196.834737] ------------[ cut here ]------------
[  196.834806] WARNING: CPU: 5 PID: 0 at net/sched/sch_generic.c:447 dev_watchdog+0x30c/0x310
[  196.834817] NETDEV WATCHDOG: eth0 (smsc95xx): transmit queue 0 timed out
[  196.834833] Modules linked in: xt_CHECKSUM xt_MASQUERADE nf_nat_tftp nf_conntrack_tftp nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_REJECT nf_reject_ipv6 ip6t_rpfilter ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ebtable_broute ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat iptable_mangle iptable_raw iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 tun bridge stp llc ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua sch_fq_codel nfsd ip_tables
[  196.834959] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 5.4.0+ #8
[  196.834967] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[  196.835008] [<c011397c>] (unwind_backtrace) from [<c010e490>] (show_stack+0x10/0x14)
[  196.835028] [<c010e490>] (show_stack) from [<c0cdd814>] (dump_stack+0x90/0xa4)
[  196.835050] [<c0cdd814>] (dump_stack) from [<c012c610>] (__warn+0xd0/0xf8)
[  196.835065] [<c012c610>] (__warn) from [<c012ca04>] (warn_slowpath_fmt+0x98/0xc4)
[  196.835076] [<c012ca04>] (warn_slowpath_fmt) from [<c0b6e954>] (dev_watchdog+0x30c/0x310)
[  196.835094] [<c0b6e954>] (dev_watchdog) from [<c019bb68>] (call_timer_fn+0x3c/0x204)
[  196.835108] [<c019bb68>] (call_timer_fn) from [<c019c2c8>] (run_timer_softirq+0x1e4/0x5b8)
[  196.835120] [<c019c2c8>] (run_timer_softirq) from [<c01022c0>] (__do_softirq+0x118/0x3f4)
[  196.835134] [<c01022c0>] (__do_softirq) from [<c0133310>] (irq_exit+0xb0/0xd8)
[  196.835151] [<c0133310>] (irq_exit) from [<c017f244>] (__handle_domain_irq+0x60/0xb0)
[  196.835172] [<c017f244>] (__handle_domain_irq) from [<c06f3274>] (gic_handle_irq+0x4c/0x90)
[  196.835189] [<c06f3274>] (gic_handle_irq) from [<c0101a8c>] (__irq_svc+0x6c/0xa8)
[  196.835199] Exception stack(0xee137f60 to 0xee137fa8)
[  196.835209] 7f60: 00000000 00019e14 00000005 c011f500 ee136000 00000005 c1204fac c1204fec
[  196.835218] 7f80: c11a5568 00000000 ee137fb8 00000000 0000ea60 ee137fb0 c010aaac c010aab0
[  196.835225] 7fa0: 600f0013 ffffffff
[  196.835238] [<c0101a8c>] (__irq_svc) from [<c010aab0>] (arch_cpu_idle+0x4c/0x50)
[  196.835253] [<c010aab0>] (arch_cpu_idle) from [<c015e2b0>] (do_idle+0x22c/0x29c)
[  196.835266] [<c015e2b0>] (do_idle) from [<c015e618>] (cpu_startup_entry+0x18/0x1c)
[  196.835279] [<c015e618>] (cpu_startup_entry) from [<4010262c>] (0x4010262c)
[  196.835297] ---[ end trace d5405240bf3ad462 ]---

This happens every now and then on heavy load, not just when attempting to suspend.

rooted · Unread post by **rooted** » Mon Dec 09, 2019 9:18 pm

Have you tried moving the irq to the big cores? Not a fix but maybe it could make a difference.

I'm sure it won't help with any issues with suspend.

Could you verify the power output of your supply under load with a DMM to see if your getting a dip in voltage? The smsc95xx is known to be sensitive to power variations and perhaps the 5.4 kernel is using a bit more power vs the older kernel.

MastaG · Unread post by **MastaG** » Mon Dec 09, 2019 10:44 pm

Thanks @rooted for the suggestions, I'll try another power brick

How can I move the irq to the big cores?

I'm now using a Digitus USB 3.0 ethernet adapter and that one works fine, no hangs or hickups.

rooted · Unread post by **rooted** » Tue Dec 10, 2019 5:17 am

MastaG wrote:Thanks @rooted for the suggestions, I'll try another power brick
How can I move the irq to the big cores?

I'm now using a Digitus USB 3.0 ethernet adapter and that one works fine, no hangs or hickups.

See this link, gives a really nice how-to:

https://obihoernchen.net/1416/odroid-xu ... usb-speed/

I was going to suggest adding a USB 3 adapter but wasn't sure what your port situation was.

memeka · Unread post by **memeka** » Tue Dec 10, 2019 8:40 am

I’ll check the PR later today when I get home.
Things are looking good!

Unread post by **odroid** » Tue Dec 10, 2019 8:53 am

@MastaG,
I think we need to make slightly different device tree files for XU3 and XU3-Lite. We will look into that a couple of weeks later.
Meanwhile, it is worth to compare the device tree files in our 4.14 branch. exynos5422-odroidxu3.dts

MastaG · Unread post by **MastaG** » Tue Dec 10, 2019 9:00 pm

@rooted and @odroid Thanks for all tips and information, that gives me something to bite my teeth in regarding the XU3.
For the record suspend/resume is working great on the XU3, also analog audio is working great (with the speaker volume patch I posted earlier).
Which makes it a nice second PC (as I can plug my speakers in lol).

It's just that the smsc95xx is not playing nice.. it panics due to timeouts which temporary hang the system.
But I'll look into moving the IRQ's and try to find some differences with 4.14's exynos5422-odroidxu3.dts.

emk2203 · Unread post by **emk2203** » Wed Dec 11, 2019 4:59 am

This worked quite well with @joshua.yang PR on a HC1 running Ubuntu 20.04 dev. Compiled on the same machine with the compiler versions from 20.04. Tnanks to @memeka for his efforts!

One thing I'd like to ask: My exynos5422-odroidxu4.dts contains nothing which could be changed for the cloudshell1 on my XU4. How can I get the display activated?

Normal operations seem to be fine; a dmesg --level=err,warn gives

Code: Select all

[    0.000031] genirq: irq_chip COMBINER did not update eff. affinity mask of irq 49
[    0.013418] CPU4: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
[    0.014549] CPU5: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
[    0.015651] CPU6: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
[    0.016755] CPU7: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
[    0.891960] samsung-usb2-phy 12130000.phy: 12130000.phy supply vbus not found, using dummy regulator
[    0.892836] exynos5_usb3drd_phy 12100000.phy: 12100000.phy supply vbus not found, using dummy regulator
[    0.892934] exynos5_usb3drd_phy 12100000.phy: 12100000.phy supply vbus-boost not found, using dummy regulator
[    0.893287] exynos5_usb3drd_phy 12500000.phy: 12500000.phy supply vbus not found, using dummy regulator
[    0.893395] exynos5_usb3drd_phy 12500000.phy: 12500000.phy supply vbus-boost not found, using dummy regulator
[    0.972144] samsung-uart 12c00000.serial: IRQ index 1 not found
[    0.972637] samsung-uart 12c10000.serial: IRQ index 1 not found
[    0.973063] samsung-uart 12c20000.serial: IRQ index 1 not found
[    1.865413] samsung-uart 12c30000.serial: IRQ index 1 not found
[    2.024568] devfreq devfreq0: Couldn't update frequency transition information.
[    2.404939] s2mps11-clk s2mps11-clk: DMA mask not set
[    2.489670] s5p-mfc 11000000.codec: Direct firmware load for s5p-mfc-v8.fw failed with error -2
[    2.498232] s5p_mfc_load_firmware:69: Firmware is not present in the /lib/firmware directory nor compiled in kernel
[    2.874032] exynos-adc 12d10000.adc: IRQ index 1 not found
[    2.995046] OF: graph: no port node found in /soc/hdmi@14530000
[    3.050494] dwc3 12000000.dwc3: Failed to get clk 'ref': -2
[    3.188594] dwc3 12400000.dwc3: Failed to get clk 'ref': -2
[    3.326009] rtc rtc1: invalid alarm value: 1900-01-18T00:00:00
[    3.510956] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[    5.355505] samsung-i2s 3830000.i2s-sec: DMA channels sourced from device 3830000.i2s
[    5.384355] dma-pl330 3880000.adma: PM domain MAU will not be powered off
[    9.104862] sd 1:0:0:0: [sdb] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
[   18.876480] .ready
[   18.889339] sd 0:0:0:0: [sda] No Caching mode page found
[   18.893346] sd 0:0:0:0: [sda] Assuming drive cache: write through

as noteworthy lines.

Scratching my head about the spectre warning, and if somebody can give more information about the others, I would appreciate it.

rooted · Unread post by **rooted** » Wed Dec 11, 2019 8:33 am

I assume the Spectre fix isn't enabled to avoid the hit in performance, personally I prefer it this way.

escalade · Unread post by **escalade** » Thu Dec 12, 2019 5:24 am

I'm happy to report that although not officially supported yet, I've got Panfrost working on the XU4 with just a few patches to Mesa and libdrm:

Code: Select all

XU4:~ # glmark2-es2-drm
=======================================================
    glmark2 2017.07
=======================================================
    OpenGL Information
    GL_VENDOR:     panfrost
    GL_RENDERER:   panfrost
    GL_VERSION:    OpenGL ES 2.0 Mesa 20.0.0-devel
=======================================================
[build] use-vbo=false: FPS: 59 FrameTime: 16.949 ms
[build] use-vbo=true: FPS: 60 FrameTime: 16.667 ms
[texture] texture-filter=nearest: FPS: 60 FrameTime: 16.667 ms
[texture] texture-filter=linear: FPS: 60 FrameTime: 16.667 ms
[texture] texture-filter=mipmap: FPS: 60 FrameTime: 16.667 ms
[shading] shading=gouraud: FPS: 60 FrameTime: 16.667 ms
[shading] shading=blinn-phong-inf: FPS: 60 FrameTime: 16.667 ms
[shading] shading=phong: FPS: 60 FrameTime: 16.667 ms
[shading] shading=cel: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=high-poly: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=normals: FPS: 60 FrameTime: 16.667 ms
[bump] bump-render=height: FPS: 60 FrameTime: 16.667 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 60 FrameTime: 16.667 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 54 FrameTime: 18.519 ms
[pulsar] light=false:quads=5:texture=false: FPS: 60 FrameTime: 16.667 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 59 FrameTime: 16.949 ms
[desktop] effect=shadow:windows=4: FPS: 60 FrameTime: 16.667 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 55 FrameTime: 18.182 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 55 FrameTime: 18.182 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 59 FrameTime: 16.949 ms
[ideas] speed=duration: FPS: 41 FrameTime: 24.390 ms
[jellyfish] <default>: FPS: 60 FrameTime: 16.667 ms
[terrain] <default>: FPS: 14 FrameTime: 71.429 ms
[shadow] <default>: FPS: 56 FrameTime: 17.857 ms
[refract] <default>: FPS: 48 FrameTime: 20.833 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 58 FrameTime: 17.241 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 60 FrameTime: 16.667 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 60 FrameTime: 16.667 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 60 FrameTime: 16.667 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 60 FrameTime: 16.667 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 60 FrameTime: 16.667 ms
=======================================================
                                  glmark2 Score: 56 
=======================================================

XU4:~ # eglinfo 
EGL client extensions string:
    EGL_EXT_client_extensions EGL_EXT_device_base
    EGL_EXT_device_enumeration EGL_EXT_device_query EGL_EXT_platform_base
    EGL_KHR_client_get_all_proc_addresses EGL_KHR_debug
    EGL_EXT_platform_wayland EGL_EXT_platform_x11 EGL_MESA_platform_gbm
    EGL_EXT_platform_device

GBM platform:
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4
EGL client APIs: OpenGL OpenGL_ES 
EGL extensions string:
    EGL_ANDROID_blob_cache EGL_EXT_buffer_age
    EGL_EXT_image_dma_buf_import EGL_KHR_cl_event2 EGL_KHR_config_attribs
    EGL_KHR_create_context EGL_KHR_create_context_no_error
    EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses
    EGL_KHR_gl_colorspace EGL_KHR_gl_renderbuffer_image
    EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_3D_image
    EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base
    EGL_KHR_image_pixmap EGL_KHR_no_config_context EGL_KHR_partial_update
    EGL_KHR_reusable_sync EGL_KHR_surfaceless_context
    EGL_EXT_pixel_format_float EGL_KHR_wait_sync
    EGL_MESA_configless_context EGL_MESA_drm_image
    EGL_MESA_image_dma_buf_export EGL_MESA_query_driver
    EGL_WL_bind_wayland_display
Configurations:
     bf lv colorbuffer dp st  ms    vis   cav bi  renderable  supported
  id sz  l  r  g  b  a th cl ns b    id   eat nd gl es es2 vg surfaces 
---------------------------------------------------------------------
0x01 32  0  8  8  8  8  0  0  0 0 0x34325241--         y  y  y     win
0x02 32  0  8  8  8  8 24  0  0 0 0x34325241--         y  y  y     win
0x03 32  0  8  8  8  8 24  8  0 0 0x34325241--         y  y  y     win
0x04 32  0  8  8  8  8 32  0  0 0 0x34325241--         y  y  y     win
0x05 24  0  8  8  8  0  0  0  0 0 0x34325258--         y  y  y     win
0x06 24  0  8  8  8  0 24  0  0 0 0x34325258--         y  y  y     win
0x07 24  0  8  8  8  0 24  8  0 0 0x34325258--         y  y  y     win
0x08 24  0  8  8  8  0 32  0  0 0 0x34325258--         y  y  y     win

Wayland platform:
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4
EGL client APIs: OpenGL OpenGL_ES 
EGL extensions string:
    EGL_ANDROID_blob_cache EGL_EXT_buffer_age
    EGL_EXT_image_dma_buf_import EGL_EXT_swap_buffers_with_damage
    EGL_KHR_cl_event2 EGL_KHR_config_attribs EGL_KHR_create_context
    EGL_KHR_create_context_no_error EGL_KHR_fence_sync
    EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace
    EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image
    EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image
    EGL_KHR_image_base EGL_KHR_no_config_context EGL_KHR_partial_update
    EGL_KHR_reusable_sync EGL_KHR_surfaceless_context
    EGL_KHR_swap_buffers_with_damage EGL_EXT_pixel_format_float
    EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image
    EGL_MESA_image_dma_buf_export EGL_MESA_query_driver
    EGL_WL_bind_wayland_display EGL_WL_create_wayland_buffer_from_image
Configurations:
     bf lv colorbuffer dp st  ms    vis   cav bi  renderable  supported
  id sz  l  r  g  b  a th cl ns b    id   eat nd gl es es2 vg surfaces 
---------------------------------------------------------------------
0x01 32  0  8  8  8  8  0  0  0 0 0x00--         y  y  y     win
0x02 32  0  8  8  8  8 24  0  0 0 0x00--         y  y  y     win
0x03 32  0  8  8  8  8 24  8  0 0 0x00--         y  y  y     win
0x04 32  0  8  8  8  8 32  0  0 0 0x00--         y  y  y     win
0x05 24  0  8  8  8  0  0  0  0 0 0x00--         y  y  y     win
0x06 24  0  8  8  8  0 24  0  0 0 0x00--         y  y  y     win
0x07 24  0  8  8  8  0 24  8  0 0 0x00--         y  y  y     win
0x08 24  0  8  8  8  0 32  0  0 0 0x00--         y  y  y     win

X11 platform:
libEGL warning: MESA-LOADER: failed to open swrast (search paths /usr/lib/dri)

libEGL warning: MESA-LOADER: failed to open swrast (search paths /usr/lib/dri)

eglinfo: eglInitialize failed

Device platform:
eglinfo: eglInitialize failed

I've got Sway, Emulationstation and RetroArch working. There's some glitching and artifacts during GL operations, but this is looking very promising

emk2203 · Unread post by **emk2203** » Thu Dec 12, 2019 7:04 am

@joshua.yang: How am supposed to get the dtb file from the dts?

I edited the dts file with vim according to instructions, but a dtc -O dtb -o exynos5422-odroidxu4.dtb exynos5422-odroidxu4.dts afterwards yields an error:

Code: Select all

Error: exynos5422-odroidxu4.dts:12.1-9 syntax error
FATAL ERROR: Unable to parse input tree

EDIT: Solved it myself, just running make dtbs again after editing the dts file is the solution.

joshua.yang · Unread post by **joshua.yang** » Thu Dec 12, 2019 9:51 am

emk2203 wrote: ↑
Thu Dec 12, 2019 7:04 am
@joshua.yang: How am supposed to get the dtb file from the dts?

I edited the dts file with vim according to instructions, but a dtc -O dtb -o exynos5422-odroidxu4.dtb exynos5422-odroidxu4.dts afterwards yields an error:
Code: Select all
Error: exynos5422-odroidxu4.dts:12.1-9 syntax error
FATAL ERROR: Unable to parse input tree
EDIT: Solved it myself, just running make dtbs again after editing the dts file is the solution.

Glad to hear you solved that.

That's right, after editing a device tree source, you should build again according to the kernel sources' Makefile rules.

By the way, LCD works with the edited device tree?

emk2203 · Unread post by **emk2203** » Thu Dec 12, 2019 8:16 pm

joshua.yang wrote: ↑
Thu Dec 12, 2019 9:51 am
By the way, LCD works with the edited device tree?

Yes, but the backlight options don't. I had my cloudshell's backlight (it's a cloudshell 1) switched off via

echo 1 | sudo tee /sys/class/backlight/*/bl_power

before. Now after restart, the backlight is on again, but nothing on the display (HDMI detached). The /sys/class/backlight/ is empty.

When I do a find /sys/ -iname '*backlight*', I get:

Code: Select all

find: ‘/sys/kernel/debug’: Permission denied
/sys/class/backlight
/sys/firmware/devicetree/base/soc/spi@12d30000/hktft_cs_ogst@0/backlight
/sys/firmware/devicetree/base/soc/spi@12d30000/hktft32@0/backlight
find: ‘/sys/fs/bpf’: Permission denied
/sys/bus/platform/drivers/pwm-backlight

This seems to indicate that the dtb changes are there. I didn't change any module options etc from the old configuration for the cloudshell1.

There is just a blank screen (HDMI detached) after restart. But I can get picture output the LCD, so it works!

When I try to force something on /dev/fb0, the one fb device existing in /dev, by doing sudo fbi -d /dev/fb0 -noverbose -a -t 10 --once Pictures/test.gif, I get ioctl VT_GETSTATE: Inappropriate ioctl for device (not a linux console?). But the test.gif shows on the lcd.

mad_ady · Unread post by **mad_ady** » Thu Dec 12, 2019 8:24 pm

That fbi error happens every time, ignore it

emk2203 · Unread post by **emk2203** » Thu Dec 12, 2019 8:30 pm

@Yeah, it's wise to look at the lcd and not only to the ssh session. besides the error, it works now. I corrected my post above.

joshua.yang · Unread post by **joshua.yang** » Fri Dec 13, 2019 10:46 am

emk2203 wrote: ↑
Thu Dec 12, 2019 8:16 pm
Yes, but the backlight options don't. I had my cloudshell's backlight (it's a cloudshell 1) switched off via echo 1 | sudo tee /sys/class/backlight/*/bl_power before. Now after restart, the backlight is on again, but nothing on the display (HDMI detached). The /sys/class/backlight/ is empty.

When I do a find /sys/ -iname '*backlight*', I get:
Code: Select all
find: ‘/sys/kernel/debug’: Permission denied
/sys/class/backlight
/sys/firmware/devicetree/base/soc/spi@12d30000/hktft_cs_ogst@0/backlight
/sys/firmware/devicetree/base/soc/spi@12d30000/hktft32@0/backlight
find: ‘/sys/fs/bpf’: Permission denied
/sys/bus/platform/drivers/pwm-backlight
This seems to indicate that the dtb changes are there. I didn't change any module options etc from the old configuration for the cloudshell1.

There is just a blank screen (HDMI detached) after restart. But I can get picture output the LCD, so it works!

When I try to force something on /dev/fb0, the one fb device existing in /dev, by doing sudo fbi -d /dev/fb0 -noverbose -a -t 10 --once Pictures/test.gif, I get ioctl VT_GETSTATE: Inappropriate ioctl for device (not a linux console?). But the test.gif shows on the lcd.

Looks activating LCD with DTS approach seems working (partly).

For now, you can disable the LCD backlight using WiringPi.
Install our WiringPi first and turn the LED pin off.

This is a simple installation guide. WiringPi needs the machine information on /proc/cpuinfo so that it is needed to use my PR on memeka's Github repository. Or you have to edit the WiringPi source code to install.
If you use Ubuntu 18.04 or higher, you can install WiringPi via our PPA.

Code: Select all

sudo apt install software-properties-common
sudo add-apt-repository ppa:hardkernel/ppa
sudo apt update
sudo apt install odroid-wiringpi

Or you can build WiringPi on your side.

Code: Select all

sudo apt install git
git clone https://github.com/hardkernel/wiringPi
cd wiringPi
sudo ./build

Then enter the following command to disable the backlight. The backlight pin is GPX1-2 (#18) in the system, which is #7 in the WiringPi.

Code: Select all

gpio write 7 0

To enable it back, enter,

Code: Select all

gpio write 7 1

It seems FBTFT core automatically registers a backlight node under the /sys if an LED GPIO pin decided.
In our case, the LED GPIO pin exists as a property, the FBTFT core recognizes that, but no backlight node.

I will look into that.

emk2203 · Unread post by **emk2203** » Sat Dec 14, 2019 2:07 am

I did install odroid-wiringpi as suggested via the ppa, but I only get this:

Code: Select all

sudo gpio write 7 0
gpio: symbol lookup error: gpio: undefined symbol: getPadDrive

Any ideas?

Apart from that, 5.4.0+ performs nicely on the XU4, the CloudShell1 also works as it should.

MastaG · Unread post by **MastaG** » Sat Dec 14, 2019 5:49 am

Is there a way to control the minimum fan speed in kernel 5.4?
The XU4 fan drives me crazy.. it goes on off on off on off on off... normally I set a minimum speed so it always cools just enough so it doesn't blast at full speed every 10 seconds.

rooted · Unread post by **rooted** » Sat Dec 14, 2019 8:35 am

MastaG wrote:Is there a way to control the minimum fan speed in kernel 5.4?
The XU4 fan drives me crazy.. it goes on off on off on off on off... normally I set a minimum speed so it always cools just enough so it doesn't blast at full speed every 10 seconds.

What happens when you try to set it?

MastaG · Unread post by **MastaG** » Sat Dec 14, 2019 9:00 am

rooted wrote: ↑
Sat Dec 14, 2019 8:35 am

MastaG wrote:Is there a way to control the minimum fan speed in kernel 5.4?
The XU4 fan drives me crazy.. it goes on off on off on off on off... normally I set a minimum speed so it always cools just enough so it doesn't blast at full speed every 10 seconds.
What happens when you try to set it?

/sys/devices/platform/pwm-fan/hwmon/hwmon0/fan_speed seems missing.
Also I get permission denied (even as root) when I try to alter the trip_point_X_temp entries.
I'd rather have the fan always spin at a low rate so that it doesn't have to go on and off all the time.

The XU3 is much better in that regard.. I cut a hole our of the case and put a bigger fan.. however unlike the XU4 it never goes on when being idle..

rooted · Unread post by **rooted** » Sat Dec 14, 2019 11:16 am

MastaG wrote:
rooted wrote: ↑
Sat Dec 14, 2019 8:35 am

MastaG wrote:Is there a way to control the minimum fan speed in kernel 5.4?
The XU4 fan drives me crazy.. it goes on off on off on off on off... normally I set a minimum speed so it always cools just enough so it doesn't blast at full speed every 10 seconds.
What happens when you try to set it?
/sys/devices/platform/pwm-fan/hwmon/hwmon0/fan_speed seems missing.
Also I get permission denied (even as root) when I try to alter the trip_point_X_temp entries.
I'd rather have the fan always spin at a low rate so that it doesn't have to go on and off all the time.

The XU3 is much better in that regard.. I cut a hole our of the case and put a bigger fan.. however unlike the XU4 it never goes on when being idle..

I think the fan driver was Odroid specific, I would have to look at the code.

To fix the permission issue you need to build the kernel with this enabled:

Code: Select all

CONFIG_THERMAL_WRITABLE_TRIPS=y

memeka · Unread post by **memeka** » Sat Dec 14, 2019 5:48 pm

@escalade

wow thanks for your efforts to try panfrost!

@everyone

I added most of that patches from the odroidizing pull, there are a few that I am not sure about (the ones with just info in cpuinfo)...
So I pushed 5.4.3.
Please be aware it's again rebased, I removed a patch for Mali (you should get an error about regulator, but it should work fine), and also I backported a very important patch from 5.5 for CPU topology.

joshua.yang · Unread post by **joshua.yang** » Mon Dec 16, 2019 9:55 am

emk2203 wrote: ↑
Sat Dec 14, 2019 2:07 am
I did install odroid-wiringpi as suggested via the ppa, but I only get this:
Code: Select all
sudo gpio write 7 0
gpio: symbol lookup error: gpio: undefined symbol: getPadDrive
Any ideas?

Apart from that, 5.4.0+ performs nicely on the XU4, the CloudShell1 also works as it should.

I've never seen that problem so far.

Sorry for your inconvenience, I'll look into that problem to be solved.

For more details, how's your environment? Thinking that you're using CS1 with Ubuntu 18.04 minimal, right?
And, have you tried to build our WiringPi by yourself? If not, could you try and let me know the results?

joshua.yang · Unread post by **joshua.yang** » Mon Dec 16, 2019 10:58 am

memeka wrote: ↑
Sat Dec 14, 2019 5:48 pm
@escalade

wow thanks for your efforts to try panfrost!

@everyone

I added most of that patches from the odroidizing pull, there are a few that I am not sure about (the ones with just info in cpuinfo)...
So I pushed 5.4.3.
Please be aware it's again rebased, I removed a patch for Mali (you should get an error about regulator, but it should work fine), and also I backported a very important patch from 5.5 for CPU topology.

Thank you @memeka to look into my PR.

I replied to your comments. I agree with that /proc/cpuinfo not to have the other information like just a board name.

But as I mentioned in the reply on PR, some other third party images/applications (very thankful) seem to use /proc/cpuinfo to identify the boards.
If it could be they no longer use /proc/cpuinfo, we can use device-tree files instead of /proc/cpuinfo. Our WiringPi can be patched.

Edit) I think it is better that we have internal discuss on our side, too.

Any ideas always welcome.

memeka · Unread post by **memeka** » Mon Dec 16, 2019 2:00 pm

joshua.yang wrote: ↑
Mon Dec 16, 2019 10:58 am
I agree with that /proc/cpuinfo not to have the other information like just a board name.
But as I mentioned in the reply on PR, some other third party images/applications (very thankful) seem to use /proc/cpuinfo to identify the boards.
If it could be they no longer use /proc/cpuinfo, we can use device-tree files instead of /proc/cpuinfo. Our WiringPi can be patched.

Edit) I think it is better that we have internal discuss on our side, too.
Any ideas always welcome.

Only patch left is: https://github.com/mihailescu2m/linux/p ... 5657484c48 with the 2 extra commits (which can be squashed) to add "Hardkernel" and "pm_init_late".
I understand that WiringPi needs the revision information so that patch I already added.
If Wiring Pi uses the info in cpuinfo and you want to maintain "Hardkernel ODROID" in cpuinfo instead of the default EXYNOS Device Tree from mainline, I'll squash those 3 commits into one and add it on top.

joshua.yang · Unread post by **joshua.yang** » Mon Dec 16, 2019 2:43 pm

memeka wrote: ↑
Mon Dec 16, 2019 2:00 pm
Only patch left is: https://github.com/mihailescu2m/linux/p ... 5657484c48 with the 2 extra commits (which can be squashed) to add "Hardkernel" and "pm_init_late".
I understand that WiringPi needs the revision information so that patch I already added.
If Wiring Pi uses the info in cpuinfo and you want to maintain "Hardkernel ODROID" in cpuinfo instead of the default EXYNOS Device Tree from mainline, I'll squash those 3 commits into one and add it on top.

In fact, currently, WiringPi needs not only revision information but also board name too.

hominoid · Unread post by **hominoid** » Tue Dec 17, 2019 12:38 am

I have been running 5.4.0 on a 20 node cluster for about two weeks now and when I rolled kernel 5.4.3 out this weekend it seems that core temperature increased across all nodes. Is anyone else seeing an increase in operating temperature of about 3-4 degrees Celsius while running kernel 5.4.3 under load? Here is an example from a quad MC-1 cluster running the same workload on both kernels. The ambient room temperature is being regulated at 66F.

Code: Select all

hominoid@neanderthal:~$ pssh -h /home/hominoid/Work/Cluster/cluster4 -l root -A -i "uname -a && showtemps && odroid-cpu-control -l"
Warning: do not enter your password if anyone else has superuser
privileges or access to your account.
Password: 
[1] 22:15:02 [SUCCESS] c4n3
Linux c4n3 5.4.0+ #1 SMP Fri Nov 29 20:18:02 EST 2019 armv7l armv7l armv7l GNU/Linux
Core4=67°C, Core5=65°C, Core6=70°C, Core7=69°C, GPU=51°C
CPU0: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU1: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU2: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU3: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU4: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU5: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU6: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU7: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
[2] 22:15:02 [SUCCESS] c4n1
Linux c4n1 5.4.0+ #1 SMP Fri Nov 29 20:18:02 EST 2019 armv7l armv7l armv7l GNU/Linux
Core4=64°C, Core5=63°C, Core6=73°C, Core7=73°C, GPU=54°C
CPU0: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU1: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU2: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU3: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU4: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU5: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU6: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU7: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
[3] 22:15:02 [SUCCESS] c4n2
Linux c4n2 5.4.0+ #1 SMP Fri Nov 29 20:18:02 EST 2019 armv7l armv7l armv7l GNU/Linux
Core4=69°C, Core5=65°C, Core6=71°C, Core7=71°C, GPU=51°C
CPU0: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU1: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU2: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU3: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU4: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU5: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU6: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU7: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
[4] 22:15:03 [SUCCESS] c4n0
Linux c4n0 5.4.0+ #1 SMP Fri Nov 29 20:18:02 EST 2019 armv7l armv7l armv7l GNU/Linux
Core4=67°C, Core5=63°C, Core6=70°C, Core7=71°C, GPU=53°C
CPU0: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU1: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU2: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU3: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU4: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU5: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU6: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU7: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz]

Code: Select all

hominoid@neanderthal:~$ pssh -h /home/hominoid/Work/Cluster/cluster4 -l root -A -i "uname -a && showtemps && odroid-cpu-control -l"
Warning: do not enter your password if anyone else has superuser
privileges or access to your account.
Password: 
[1] 22:30:54 [SUCCESS] c4n0
Linux c4n0 5.4.3+ #1 SMP PREEMPT Sat Dec 14 22:00:23 EST 2019 armv7l armv7l armv7l GNU/Linux
Core4=71°C, Core5=65°C, Core6=73°C, Core7=75°C, GPU=55°C
CPU0: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU1: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU2: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU3: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU4: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU5: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU6: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU7: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
[2] 22:30:54 [SUCCESS] c4n1
Linux c4n1 5.4.3+ #1 SMP PREEMPT Sat Dec 14 22:00:23 EST 2019 armv7l armv7l armv7l GNU/Linux
Core4=72°C, Core5=68°C, Core6=77°C, Core7=77°C, GPU=57°C
CPU0: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU1: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU2: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU3: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU4: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU5: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU6: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU7: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
[3] 22:30:54 [SUCCESS] c4n3
Linux c4n3 5.4.3+ #1 SMP PREEMPT Sat Dec 14 22:00:23 EST 2019 armv7l armv7l armv7l GNU/Linux
Core4=72°C, Core5=68°C, Core6=74°C, Core7=74°C, GPU=54°C
CPU0: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU1: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU2: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU3: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU4: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU5: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU6: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU7: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
[4] 22:30:54 [SUCCESS] c4n2
Linux c4n2 5.4.3+ #1 SMP PREEMPT Sat Dec 14 22:00:23 EST 2019 armv7l armv7l armv7l GNU/Linux
Core4=73°C, Core5=68°C, Core6=75°C, Core7=75°C, GPU=54°C
CPU0: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU1: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU2: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU3: governor ondemand	current 1.40GHz	min 200.00MHz [200.00MHz]	max 1.40GHz [1.40GHz] 	
CPU4: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU5: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU6: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz] 	
CPU7: governor ondemand	current 1.90GHz	min 200.00MHz [200.00MHz]	max 1.90GHz [2.00GHz]

rooted · Unread post by **rooted** » Tue Dec 17, 2019 6:43 am

Disregard this post, it was on a different device.

joshua.yang · Unread post by **joshua.yang** » Tue Dec 17, 2019 12:26 pm

memeka wrote: ↑
Mon Dec 16, 2019 2:00 pm
Only patch left is: https://github.com/mihailescu2m/linux/p ... 5657484c48 with the 2 extra commits (which can be squashed) to add "Hardkernel" and "pm_init_late".
I understand that WiringPi needs the revision information so that patch I already added.
If Wiring Pi uses the info in cpuinfo and you want to maintain "Hardkernel ODROID" in cpuinfo instead of the default EXYNOS Device Tree from mainline, I'll squash those 3 commits into one and add it on top.

Hi @memeka,

We've decided to remove Odroid model name from /proc/cpuinfo, from 5.4 kernel.
Please do not merge my 3 commits to do with adding board name to /proc/cpuinfo.
So that I will make WiringPi parses device tree files to get the board name.

Thanks.

memeka · Unread post by **memeka** » Tue Dec 17, 2019 12:41 pm

Ok, thanks.
Is https://github.com/awesometic/linux/com ... 0eb610f08e still required?

joshua.yang · Unread post by **joshua.yang** » Tue Dec 17, 2019 1:40 pm

memeka wrote: ↑
Tue Dec 17, 2019 12:41 pm
Ok, thanks.
Is https://github.com/awesometic/linux/com ... 0eb610f08e still required?

Yes, remain that please.

memeka · Unread post by **memeka** » Tue Dec 17, 2019 3:02 pm

Great, no change then

MastaG · Unread post by **MastaG** » Tue Dec 17, 2019 5:37 pm

@memeka
Here's my PR for the XU3 headphone jack: https://github.com/mihailescu2m/linux/pull/5

Would you like to commit your DRM plane fix as well? (I believe it was renaming the CURSOR plane to OVERLAY) so Kodi GBM can run on two planes.

joshua.yang · Unread post by **joshua.yang** » Thu Dec 19, 2019 11:56 am

@memeka,

I made a PR for supporting DTBO. Please check viewtopic.php?f=184&t=37073#p275382

tobetter · Unread post by **tobetter** » Fri Dec 20, 2019 1:04 am

I've updated X11 driver support with 5.4 kernel to my repository (ppa.linuxfactory.or.kr), please visit the link for more detail.
viewtopic.php?f=184&t=37108&p=275405#p275405

INdek · Unread post by **INdek** » Sun Dec 22, 2019 2:08 am

@escalade Would you be able to post the patches to mesa and libdrm? I've been trying to build & use mesa as well without much success.

Thanks!