Kernel 5.4 Development Party

Test and fix the Kernel 5.4 features
User avatar
memeka
Posts: 4415
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Has thanked: 2 times
Been thanked: 57 times
Contact:

Re: Kernel 5.4 Development Party

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

User avatar
odroid
Site Admin
Posts: 33001
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID
Has thanked: 286 times
Been thanked: 410 times
Contact:

Re: Kernel 5.4 Development Party

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.

User avatar
AreaScout
Posts: 1204
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: 43 times
Been thanked: 105 times
Contact:

Re: Kernel 5.4 Development Party

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

    User avatar
    odroid
    Site Admin
    Posts: 33001
    Joined: Fri Feb 22, 2013 11:14 pm
    languages_spoken: English
    ODROIDs: ODROID
    Has thanked: 286 times
    Been thanked: 410 times
    Contact:

    Re: Kernel 5.4 Development Party

    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.

    User avatar
    AreaScout
    Posts: 1204
    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: 43 times
    Been thanked: 105 times
    Contact:

    Re: Kernel 5.4 Development Party

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

      That's great news ! 😀

      RG
      Last edited by AreaScout on Thu Dec 05, 2019 4:15 pm, edited 1 time in total.

      User avatar
      rooted
      Posts: 7113
      Joined: Fri Dec 19, 2014 9:12 am
      languages_spoken: english
      Location: Gulf of Mexico, US
      Has thanked: 375 times
      Been thanked: 102 times
      Contact:

      Re: Kernel 5.4 Development Party

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

      AreaScout wrote:
        That's great news ! Image

        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.
        These users thanked the author rooted for the post:
        AreaScout (Thu Dec 05, 2019 9:37 pm)

        User avatar
        AreaScout
        Posts: 1204
        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: 43 times
        Been thanked: 105 times
        Contact:

        Re: Kernel 5.4 Development Party

        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
          Last edited by AreaScout on Thu Dec 05, 2019 6:38 pm, edited 1 time in total.
          These users thanked the author AreaScout for the post (total 2):
          odroid (Thu Dec 05, 2019 6:33 pm) • rooted (Fri Dec 06, 2019 5:08 am)

          User avatar
          odroid
          Site Admin
          Posts: 33001
          Joined: Fri Feb 22, 2013 11:14 pm
          languages_spoken: English
          ODROIDs: ODROID
          Has thanked: 286 times
          Been thanked: 410 times
          Contact:

          Re: Kernel 5.4 Development Party

          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.
          These users thanked the author odroid for the post:
          rooted (Fri Dec 06, 2019 5:08 am)

          User avatar
          AreaScout
          Posts: 1204
          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: 43 times
          Been thanked: 105 times
          Contact:

          Re: Kernel 5.4 Development Party

          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
            These users thanked the author AreaScout for the post:
            odroid (Thu Dec 05, 2019 7:13 pm)

            User avatar
            odroid
            Site Admin
            Posts: 33001
            Joined: Fri Feb 22, 2013 11:14 pm
            languages_spoken: English
            ODROIDs: ODROID
            Has thanked: 286 times
            Been thanked: 410 times
            Contact:

            Re: Kernel 5.4 Development Party

            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. :)

            User avatar
            AreaScout
            Posts: 1204
            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: 43 times
            Been thanked: 105 times
            Contact:

            Re: Kernel 5.4 Development Party

            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 :o

              RG
              These users thanked the author AreaScout for the post:
              tobetter (Thu Dec 05, 2019 8:53 pm)

              User avatar
              tobetter
              Posts: 4420
              Joined: Mon Feb 25, 2013 10:55 am
              languages_spoken: Korean, English
              ODROIDs: X, X2, U2, U3, XU3, C1
              Location: Paju, South Korea
              Has thanked: 66 times
              Been thanked: 292 times
              Contact:

              Re: Kernel 5.4 Development Party

              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 :o

                RG
                Ok, now you can.
                These users thanked the author tobetter for the post (total 2):
                AreaScout (Thu Dec 05, 2019 9:03 pm) • rooted (Fri Dec 06, 2019 5:08 am)

                joshua.yang
                Posts: 335
                Joined: Fri Sep 22, 2017 5:54 pm
                languages_spoken: Korean, English
                ODROIDs: XU4, XU4Q + Cloudshell2, H2, N2
                Has thanked: 9 times
                Been thanked: 63 times
                Contact:

                Re: Kernel 5.4 Development Party

                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.
                These users thanked the author joshua.yang for the post (total 3):
                rooted (Mon Dec 09, 2019 6:37 pm) • emk2203 (Mon Dec 09, 2019 11:41 pm) • AreaScout (Mon Dec 23, 2019 10:00 pm)

                User avatar
                rooted
                Posts: 7113
                Joined: Fri Dec 19, 2014 9:12 am
                languages_spoken: english
                Location: Gulf of Mexico, US
                Has thanked: 375 times
                Been thanked: 102 times
                Contact:

                Re: Kernel 5.4 Development Party

                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
                Posts: 305
                Joined: Mon Aug 26, 2013 6:05 pm
                languages_spoken: english
                Has thanked: 18 times
                Been thanked: 4 times
                Contact:

                Re: Kernel 5.4 Development Party

                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.

                User avatar
                rooted
                Posts: 7113
                Joined: Fri Dec 19, 2014 9:12 am
                languages_spoken: english
                Location: Gulf of Mexico, US
                Has thanked: 375 times
                Been thanked: 102 times
                Contact:

                Re: Kernel 5.4 Development Party

                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.
                These users thanked the author rooted for the post:
                MastaG (Tue Dec 10, 2019 2:55 am)

                MastaG
                Posts: 305
                Joined: Mon Aug 26, 2013 6:05 pm
                languages_spoken: english
                Has thanked: 18 times
                Been thanked: 4 times
                Contact:

                Re: Kernel 5.4 Development Party

                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.

                User avatar
                rooted
                Posts: 7113
                Joined: Fri Dec 19, 2014 9:12 am
                languages_spoken: english
                Location: Gulf of Mexico, US
                Has thanked: 375 times
                Been thanked: 102 times
                Contact:

                Re: Kernel 5.4 Development Party

                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.
                These users thanked the author rooted for the post:
                MastaG (Tue Dec 10, 2019 9:00 pm)

                User avatar
                memeka
                Posts: 4415
                Joined: Mon May 20, 2013 10:22 am
                languages_spoken: english
                ODROIDs: XU rev2 + eMMC + UART
                U3 + eMMC + IO Shield + UART
                Has thanked: 2 times
                Been thanked: 57 times
                Contact:

                Re: Kernel 5.4 Development Party

                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!

                User avatar
                odroid
                Site Admin
                Posts: 33001
                Joined: Fri Feb 22, 2013 11:14 pm
                languages_spoken: English
                ODROIDs: ODROID
                Has thanked: 286 times
                Been thanked: 410 times
                Contact:

                Re: Kernel 5.4 Development Party

                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
                These users thanked the author odroid for the post:
                MastaG (Tue Dec 10, 2019 9:00 pm)

                MastaG
                Posts: 305
                Joined: Mon Aug 26, 2013 6:05 pm
                languages_spoken: english
                Has thanked: 18 times
                Been thanked: 4 times
                Contact:

                Re: Kernel 5.4 Development Party

                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.
                These users thanked the author MastaG for the post:
                rooted (Wed Dec 11, 2019 12:18 am)

                User avatar
                emk2203
                Posts: 46
                Joined: Fri Oct 16, 2015 12:29 am
                languages_spoken: english, german
                ODROIDs: C1+, C2, XU4, HC1, HC2, N2
                Has thanked: 6 times
                Been thanked: 0
                Contact:

                Re: Kernel 5.4 Development Party

                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.

                User avatar
                rooted
                Posts: 7113
                Joined: Fri Dec 19, 2014 9:12 am
                languages_spoken: english
                Location: Gulf of Mexico, US
                Has thanked: 375 times
                Been thanked: 102 times
                Contact:

                Re: Kernel 5.4 Development Party

                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
                Posts: 142
                Joined: Thu Mar 14, 2019 8:34 pm
                languages_spoken: english and norwegian
                Has thanked: 5 times
                Been thanked: 38 times
                Contact:

                Re: Kernel 5.4 Development Party

                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 :)
                These users thanked the author escalade for the post (total 8):
                luukvbaal (Thu Dec 12, 2019 6:20 am) • emk2203 (Thu Dec 12, 2019 6:49 am) • tobetter (Thu Dec 12, 2019 8:51 am) • odroid (Thu Dec 12, 2019 9:28 am) • MastaG (Thu Dec 12, 2019 7:44 pm) • rooted (Fri Dec 13, 2019 2:52 am) • meveric (Fri Dec 13, 2019 8:39 am) • memeka (Sun Dec 15, 2019 6:09 am)
                Maintainer of RetroELEC (XU4 support!)

                User avatar
                emk2203
                Posts: 46
                Joined: Fri Oct 16, 2015 12:29 am
                languages_spoken: english, german
                ODROIDs: C1+, C2, XU4, HC1, HC2, N2
                Has thanked: 6 times
                Been thanked: 0
                Contact:

                Re: Kernel 5.4 Development Party

                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
                Posts: 335
                Joined: Fri Sep 22, 2017 5:54 pm
                languages_spoken: Korean, English
                ODROIDs: XU4, XU4Q + Cloudshell2, H2, N2
                Has thanked: 9 times
                Been thanked: 63 times
                Contact:

                Re: Kernel 5.4 Development Party

                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?

                User avatar
                emk2203
                Posts: 46
                Joined: Fri Oct 16, 2015 12:29 am
                languages_spoken: english, german
                ODROIDs: C1+, C2, XU4, HC1, HC2, N2
                Has thanked: 6 times
                Been thanked: 0
                Contact:

                Re: Kernel 5.4 Development Party

                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.
                Last edited by emk2203 on Thu Dec 12, 2019 8:31 pm, edited 2 times in total.

                User avatar
                mad_ady
                Posts: 7087
                Joined: Wed Jul 15, 2015 5:00 pm
                languages_spoken: english
                ODROIDs: XU4, C1+, C2, N1, H2, N2
                Location: Bucharest, Romania
                Has thanked: 304 times
                Been thanked: 208 times
                Contact:

                Re: Kernel 5.4 Development Party

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

                That fbi error happens every time, ignore it

                User avatar
                emk2203
                Posts: 46
                Joined: Fri Oct 16, 2015 12:29 am
                languages_spoken: english, german
                ODROIDs: C1+, C2, XU4, HC1, HC2, N2
                Has thanked: 6 times
                Been thanked: 0
                Contact:

                Re: Kernel 5.4 Development Party

                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
                Posts: 335
                Joined: Fri Sep 22, 2017 5:54 pm
                languages_spoken: Korean, English
                ODROIDs: XU4, XU4Q + Cloudshell2, H2, N2
                Has thanked: 9 times
                Been thanked: 63 times
                Contact:

                Re: Kernel 5.4 Development Party

                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. :)
                These users thanked the author joshua.yang for the post:
                emk2203 (Fri Dec 13, 2019 7:06 pm)

                User avatar
                emk2203
                Posts: 46
                Joined: Fri Oct 16, 2015 12:29 am
                languages_spoken: english, german
                ODROIDs: C1+, C2, XU4, HC1, HC2, N2
                Has thanked: 6 times
                Been thanked: 0
                Contact:

                Re: Kernel 5.4 Development Party

                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
                Posts: 305
                Joined: Mon Aug 26, 2013 6:05 pm
                languages_spoken: english
                Has thanked: 18 times
                Been thanked: 4 times
                Contact:

                Re: Kernel 5.4 Development Party

                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.

                User avatar
                rooted
                Posts: 7113
                Joined: Fri Dec 19, 2014 9:12 am
                languages_spoken: english
                Location: Gulf of Mexico, US
                Has thanked: 375 times
                Been thanked: 102 times
                Contact:

                Re: Kernel 5.4 Development Party

                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
                Posts: 305
                Joined: Mon Aug 26, 2013 6:05 pm
                languages_spoken: english
                Has thanked: 18 times
                Been thanked: 4 times
                Contact:

                Re: Kernel 5.4 Development Party

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

                User avatar
                rooted
                Posts: 7113
                Joined: Fri Dec 19, 2014 9:12 am
                languages_spoken: english
                Location: Gulf of Mexico, US
                Has thanked: 375 times
                Been thanked: 102 times
                Contact:

                Re: Kernel 5.4 Development Party

                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

                User avatar
                memeka
                Posts: 4415
                Joined: Mon May 20, 2013 10:22 am
                languages_spoken: english
                ODROIDs: XU rev2 + eMMC + UART
                U3 + eMMC + IO Shield + UART
                Has thanked: 2 times
                Been thanked: 57 times
                Contact:

                Re: Kernel 5.4 Development Party

                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.
                These users thanked the author memeka for the post (total 4):
                rooted (Sat Dec 14, 2019 10:48 pm) • ffwd (Sat Dec 14, 2019 11:04 pm) • emk2203 (Sun Dec 15, 2019 4:09 am) • joshua.yang (Mon Dec 16, 2019 12:15 pm)

                joshua.yang
                Posts: 335
                Joined: Fri Sep 22, 2017 5:54 pm
                languages_spoken: Korean, English
                ODROIDs: XU4, XU4Q + Cloudshell2, H2, N2
                Has thanked: 9 times
                Been thanked: 63 times
                Contact:

                Re: Kernel 5.4 Development Party

                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. :shock:
                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
                Posts: 335
                Joined: Fri Sep 22, 2017 5:54 pm
                languages_spoken: Korean, English
                ODROIDs: XU4, XU4Q + Cloudshell2, H2, N2
                Has thanked: 9 times
                Been thanked: 63 times
                Contact:

                Re: Kernel 5.4 Development Party

                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.

                User avatar
                memeka
                Posts: 4415
                Joined: Mon May 20, 2013 10:22 am
                languages_spoken: english
                ODROIDs: XU rev2 + eMMC + UART
                U3 + eMMC + IO Shield + UART
                Has thanked: 2 times
                Been thanked: 57 times
                Contact:

                Re: Kernel 5.4 Development Party

                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.
                These users thanked the author memeka for the post:
                rooted (Mon Dec 16, 2019 2:31 pm)

                joshua.yang
                Posts: 335
                Joined: Fri Sep 22, 2017 5:54 pm
                languages_spoken: Korean, English
                ODROIDs: XU4, XU4Q + Cloudshell2, H2, N2
                Has thanked: 9 times
                Been thanked: 63 times
                Contact:

                Re: Kernel 5.4 Development Party

                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
                Posts: 326
                Joined: Tue Feb 28, 2017 3:55 am
                languages_spoken: english
                ODROIDs: C2, XU4, MC1, N1, N2
                Location: Lake Superior Basin, USA
                Has thanked: 13 times
                Been thanked: 25 times
                Contact:

                Re: Kernel 5.4 Development Party

                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] 

                User avatar
                rooted
                Posts: 7113
                Joined: Fri Dec 19, 2014 9:12 am
                languages_spoken: english
                Location: Gulf of Mexico, US
                Has thanked: 375 times
                Been thanked: 102 times
                Contact:

                Re: Kernel 5.4 Development Party

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

                Disregard this post, it was on a different device.

                joshua.yang
                Posts: 335
                Joined: Fri Sep 22, 2017 5:54 pm
                languages_spoken: Korean, English
                ODROIDs: XU4, XU4Q + Cloudshell2, H2, N2
                Has thanked: 9 times
                Been thanked: 63 times
                Contact:

                Re: Kernel 5.4 Development Party

                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.

                User avatar
                memeka
                Posts: 4415
                Joined: Mon May 20, 2013 10:22 am
                languages_spoken: english
                ODROIDs: XU rev2 + eMMC + UART
                U3 + eMMC + IO Shield + UART
                Has thanked: 2 times
                Been thanked: 57 times
                Contact:

                Re: Kernel 5.4 Development Party

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


                joshua.yang
                Posts: 335
                Joined: Fri Sep 22, 2017 5:54 pm
                languages_spoken: Korean, English
                ODROIDs: XU4, XU4Q + Cloudshell2, H2, N2
                Has thanked: 9 times
                Been thanked: 63 times
                Contact:

                Re: Kernel 5.4 Development Party

                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. :)

                User avatar
                memeka
                Posts: 4415
                Joined: Mon May 20, 2013 10:22 am
                languages_spoken: english
                ODROIDs: XU rev2 + eMMC + UART
                U3 + eMMC + IO Shield + UART
                Has thanked: 2 times
                Been thanked: 57 times
                Contact:

                Re: Kernel 5.4 Development Party

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

                Great, no change then :)

                MastaG
                Posts: 305
                Joined: Mon Aug 26, 2013 6:05 pm
                languages_spoken: english
                Has thanked: 18 times
                Been thanked: 4 times
                Contact:

                Re: Kernel 5.4 Development Party

                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
                Posts: 335
                Joined: Fri Sep 22, 2017 5:54 pm
                languages_spoken: Korean, English
                ODROIDs: XU4, XU4Q + Cloudshell2, H2, N2
                Has thanked: 9 times
                Been thanked: 63 times
                Contact:

                Re: Kernel 5.4 Development Party

                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
                These users thanked the author joshua.yang for the post:
                rooted (Thu Dec 19, 2019 12:48 pm)

                User avatar
                tobetter
                Posts: 4420
                Joined: Mon Feb 25, 2013 10:55 am
                languages_spoken: Korean, English
                ODROIDs: X, X2, U2, U3, XU3, C1
                Location: Paju, South Korea
                Has thanked: 66 times
                Been thanked: 292 times
                Contact:

                Re: Kernel 5.4 Development Party

                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
                These users thanked the author tobetter for the post:
                rooted (Fri Dec 20, 2019 12:51 pm)

                INdek
                Posts: 1
                Joined: Sun Dec 22, 2019 2:02 am
                languages_spoken: english
                ODROIDs: xu4
                Has thanked: 0
                Been thanked: 0
                Contact:

                Re: Kernel 5.4 Development Party

                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!

                Post Reply

                Return to “Linux Kernel 5.4 Development Party”

                Who is online

                Users browsing this forum: joy and 0 guests