Any plan for basic mainline linux support?

Post Reply
odroidn2user
Posts: 409
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2, C4
Has thanked: 115 times
Been thanked: 107 times
Contact:

Re: Any plan for basic mainline linux support?

Post by odroidn2user »

chewitt wrote:
Sat Apr 10, 2021 2:01 pm
I'd be interested to see a comparison using the same windowing system and desktop environment, but switching between panfrost and libmali, because GL/GLES is what's responsible for blending the different visual layers for rendering/output.
Well, that would be a lot of work, to create those side by sides.
However, I have this same problem with the tobetter's Ubuntu Wayland images as well.
So this with Panfrost as well as with the Wayland Mali drivers/infrastructure.

Also, I tested Manjaro ARM (KDE Plasma) a while ago, which used neither Panfrost nor the Wayland Mali driver. And the problem was there as well, using llvmpipe for graphics.

I also installed both KDE and Gnome on the N2, on jgmdev's arch linux image, if I remember correct: so same distro, same drivers, different desktop environment, made no difference.

It might be worthwhile to mention again that if you take a screenshot of the desktop using the printscreen button or some such, the screenshot itself is clear.

Which led me to think it of being some kind of monitor or HDMI driver issue. Keep in mind on some monitors, it goes right, on other monitors it doesn't. Same installation.

Update: yeah, just hooked up the N2 with jgmdev's arch linux image (Gnome 40, Panfrost) to my old old monitor, no issues on a Samsung Syncmaster 203B on 1400x1050. So not really comparable, but it really is monitor specific.
Same thing hooked up to my Dell P2319H and LG smallscreen TV/monitor, has these issues. And then, only with the mainline kernel, never saw this with the 4.9 kernel series or with other computers.
Last edited by odroidn2user on Sat Apr 10, 2021 8:09 pm, edited 1 time in total.

brad
Posts: 1449
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 C4 HC4 N1 N2 N2+ H2 H2+ (64 bit ftw)
Location: Australia
Has thanked: 135 times
Been thanked: 222 times
Contact:

Re: Any plan for basic mainline linux support?

Post by brad »

I'm suspecting the color issues will be related to hdmi / drm / monitor rather than GPU or GLES. If i recall correctly have you had the issues prior to any panfrost / libMali acceleration.

I have been running displays on N2 since 5.0 kernel with Gnome and have not seen this issue before using libMali, panfrost or no acceleration. I'm currently running panfrost mostly on C4 at the moment and the display shows no sign of this issue.

i'd be interested in seeing a test using only uboot (prior to even loadiing linux kernel) and displaying a colour test image as the startup logo to see if the problem occurs there. Do you notice any issues at all with the hardkernel logo on boot?

odroidn2user
Posts: 409
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2, C4
Has thanked: 115 times
Been thanked: 107 times
Contact:

Re: Any plan for basic mainline linux support?

Post by odroidn2user »

brad wrote:
Sat Apr 10, 2021 8:07 pm
I'm suspecting the color issues will be related to hdmi / drm / monitor rather than GPU or GLES. If i recall correctly have you had the issues prior to any panfrost / libMali acceleration.
Indeed. And I also suspect it is not on the GL/GLES side, given the consistency over all the different configurations I've tested.
Also, as the screenshots look good, I suspect it also isn't the rendering within the DRM? Not sure technically how that works, but the rendered end result looks good on screenshots.
Not sure where exactly the shown image gets composed before display, but it probably works correctly there, given the good screenshots.
Which lead me to think it might be the hdmi / monitor driver, perhaps even a compatibility issue in the HDMI handshake somehow?
Not sure how that causes image disruption, but still... Perhaps some wrong mode, compressions gone wrong, colour negotiation, who knows.
brad wrote:
Sat Apr 10, 2021 8:07 pm
Do you notice any issues at all with the hardkernel logo on boot?
Well, that test would be inconclusive.
The white line around the HK logo looks a little jagged, but then that could well be the quality of the bitmap used. There is no red in that would makes this issue very visible.
Also, the Samsung monitor which works right, doesn't react quick enough to show the bitmap. So I can't compare. Also, it is 1400x1050 / 4:3, so even if I do get it on screen, it probably won't look right compared to 16:9.
Petitboot also doesn't display right, as it seems to be fixed on 1080p.

Also, remember, it looks OK on kernel 4.9. So I'm not thinking the firmware uboot myself. Perhaps if there is an additional uboot on the loading OS, but...

I usually boot my images without SPI and without Petitboot. And using jgmdev's image, I immediately get the ALARM bootlogo, skipping the hardkernel logo.
The ALARM logo doesn't look quite right to me, but again, difficult to determine if that is just me being picky, the bitmap or the monitor driver.

trwn2p
Posts: 75
Joined: Fri Oct 16, 2020 5:12 am
languages_spoken: english
ODROIDs: N2 Plus
Has thanked: 3 times
Been thanked: 13 times
Contact:

Re: Any plan for basic mainline linux support?

Post by trwn2p »

Code: Select all

   screenfetch
                             muser@manj-n2p
                             OS: Manjaro-ARM 21.04
                             Kernel: aarch64 Linux 5.11.11-1-ARCH
         #####               Uptime: 2h 16m
        #######              Packages: Unknown
        ##O#O##              Shell: bash 5.1.4
        #######              Resolution: 2560x1440
      ###########            DE: KDE 5.80.0 / Plasma 5.21.3
     #############           WM: KWin
    ###############          GTK Theme: Breeze [GTK2], Breath-Dark [GTK3]
    ################         Icon Theme: breath2-dark
   #################         Disk: 9.1G / 296G (4%)
 #####################       CPU: Unknown @ 6x 1.8GHz
 #####################       GPU: Mali G52 (Panfrost)
   #################         RAM: 1205MiB / 3696MiB
   
My Manjaro KDE with fresh update. I boot direct to external 2.5 hdd caddy over usb3 and a QHD hdmi mon @2560x1440. Been great for months. I also use jdmdev's repo for his patched 5.11.x for latest panfrost drm.

crashoverride
Posts: 5408
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 465 times
Contact:

Re: Any plan for basic mainline linux support?

Post by crashoverride »

I have seen this issue reported before, so thought I would post some info in case its of use to someone:
https://patchwork.kernel.org/project/li ... gmail.com/
fix green/pink color distortion from HDR set during vendor Uboot
These users thanked the author crashoverride for the post (total 2):
tobetter (Wed Apr 21, 2021 9:43 pm) • jgmdev (Fri Apr 23, 2021 3:09 am)

chewitt
Posts: 126
Joined: Mon Aug 12, 2019 12:27 pm
languages_spoken: english
Has thanked: 1 time
Been thanked: 112 times
Contact:

Re: Any plan for basic mainline linux support?

Post by chewitt »

The submitter didn't come back with a v2 patch yet, but it appears to work. I've been able to boot a no-name S905X2 device with vendor u-boot and I don't see the normal washed out blue screen, and I'm not chainloading u-boot.

odroidn2user
Posts: 409
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2, C4
Has thanked: 115 times
Been thanked: 107 times
Contact:

Re: Any plan for basic mainline linux support?

Post by odroidn2user »

odroidn2user wrote:
Sun Apr 11, 2021 5:46 pm
brad wrote:
Sat Apr 10, 2021 8:07 pm
I'm suspecting the color issues will be related to hdmi / drm / monitor rather than GPU or GLES. If i recall correctly have you had the issues prior to any panfrost / libMali acceleration.
Indeed. And I also suspect it is not on the GL/GLES side, given the consistency over all the different configurations I've tested.
Also I've hooked up an active HDMI to Displayport adapter, and the distortion isn' t showing up there. Plug in a normal HDMI-cable, it happens. Plug in the active adapter, and it´s gone.
So, it really depends on the chipset you attach to the HDMI port. In this case the adapter chipset is well supported, whereas the chipsets in my Dell and LG monitors are not.
I have 4 chipsets/monitors, of which 2 work normally. So, the HDMI driver is about 50% done?

Tassadar
Posts: 36
Joined: Sun Aug 18, 2019 7:04 pm
languages_spoken: english
ODROIDs: C2, XU4, N2
Has thanked: 3 times
Been thanked: 3 times
Contact:

Re: Any plan for basic mainline linux support?

Post by Tassadar »

What driver from 5.x kernel should be used to enable audio on odroid n2?

User avatar
istanbulls
Posts: 584
Joined: Tue May 14, 2019 10:18 pm
languages_spoken: Turkish
ODROIDs: ODROID; N2, C4, XU4, N2+, CH4
Location: Istanbul-Turkey
Has thanked: 359 times
Been thanked: 97 times
Contact:

Re: Any plan for basic mainline linux support?

Post by istanbulls »

sudo apt install odroid-alsa
or
sudo apt install --reinstall odroid-alsa
These users thanked the author istanbulls for the post:
Tassadar (Fri Jun 04, 2021 3:29 am)

Tassadar
Posts: 36
Joined: Sun Aug 18, 2019 7:04 pm
languages_spoken: english
ODROIDs: C2, XU4, N2
Has thanked: 3 times
Been thanked: 3 times
Contact:

Re: Any plan for basic mainline linux support?

Post by Tassadar »

I mean a linux kernel driver. What particular audio hardware (AXG,GX,etc.) does n2 have? And which kernel modules should be compiled and loaded?

Tassadar
Posts: 36
Joined: Sun Aug 18, 2019 7:04 pm
languages_spoken: english
ODROIDs: C2, XU4, N2
Has thanked: 3 times
Been thanked: 3 times
Contact:

Re: Any plan for basic mainline linux support?

Post by Tassadar »

istanbulls wrote:
Fri Jun 04, 2021 2:01 am
sudo apt install odroid-alsa
or
sudo apt install --reinstall odroid-alsa
Thank you anyway, these configs are also required for proper audio operation, but only AFTER hardware initialization.

Tassadar
Posts: 36
Joined: Sun Aug 18, 2019 7:04 pm
languages_spoken: english
ODROIDs: C2, XU4, N2
Has thanked: 3 times
Been thanked: 3 times
Contact:

Re: Any plan for basic mainline linux support?

Post by Tassadar »

Finally got hdmi audio working by compiling snd-soc-simple-amplifier.ko (selected in ALSA for SoC audio support -> CODEC drivers) in addition to the meson audio drivers and setting mixer settings in accordance to this script: https://github.com/chewitt/LibreELEC.tv ... oundconfig.

Tassadar
Posts: 36
Joined: Sun Aug 18, 2019 7:04 pm
languages_spoken: english
ODROIDs: C2, XU4, N2
Has thanked: 3 times
Been thanked: 3 times
Contact:

Re: Any plan for basic mainline linux support?

Post by Tassadar »

What is the exact procedure to set up power (wake up) button with kernel 5.x?

Tassadar
Posts: 36
Joined: Sun Aug 18, 2019 7:04 pm
languages_spoken: english
ODROIDs: C2, XU4, N2
Has thanked: 3 times
Been thanked: 3 times
Contact:

Re: Any plan for basic mainline linux support?

Post by Tassadar »

It seems that the mainline kernel does not have support for generating IRQ's by GPIO pins on meson platforms, so no wakeup by GPIO for now :( .
These users thanked the author Tassadar for the post:
m_ueberall (Tue Jun 15, 2021 5:20 pm)

Tassadar
Posts: 36
Joined: Sun Aug 18, 2019 7:04 pm
languages_spoken: english
ODROIDs: C2, XU4, N2
Has thanked: 3 times
Been thanked: 3 times
Contact:

Re: Any plan for basic mainline linux support?

Post by Tassadar »

If you want just a poweroff button (no wakeup), add this to your source dtb file and rebuild the database:

Code: Select all

gpio-keys-polled {
                compatible = "gpio-keys-polled";
                #address-cells = <1>;
                #size-cells = <0>;
                poll-interval = <100>;

                power-button {
                        label = "power";
                        linux,code = <KEY_POWER>;
                        gpios = <&gpio GPIOX_3 GPIO_ACTIVE_LOW>;
                };
        };
Make sure your kernel is compiled with CONFIG_KEYBOARD_GPIO_POLLED=y. This gives a poweroff button on pins 11 (GPIOX_3) and 9 (ground).
Funny thing though, the Hardkernel's kernel 4.9.19x, which does have a GPIO wakeup capability doesn't use GPIO interrupts.

User avatar
tobetter
Posts: 8388
Joined: Mon Feb 25, 2013 10:55 am
languages_spoken: Korean, English
ODROIDs: Many
Location: Paju, South Korea
Has thanked: 490 times
Been thanked: 1323 times
Contact:

Re: Any plan for basic mainline linux support?

Post by tobetter »

Tassadar wrote:
Wed Jun 16, 2021 2:49 am
If you want just a poweroff button (no wakeup), add this to your source dtb file and rebuild the database:

Code: Select all

gpio-keys-polled {
                compatible = "gpio-keys-polled";
                #address-cells = <1>;
                #size-cells = <0>;
                poll-interval = <100>;

                power-button {
                        label = "power";
                        linux,code = <KEY_POWER>;
                        gpios = <&gpio GPIOX_3 GPIO_ACTIVE_LOW>;
                };
        };
Make sure your kernel is compiled with CONFIG_KEYBOARD_GPIO_POLLED=y. This gives a poweroff button on pins 11 (GPIOX_3) and 9 (ground).
Funny thing though, the Hardkernel's kernel 4.9.19x, which does have a GPIO wakeup capability doesn't use GPIO interrupts.
Thanks, I'd like take this change and merge to my branch for power key and other use cases. :)
Also as you mentioned, the interrupt feature is not required to make wake up through GPIO. I believe the missing part of wake-up in the mainline kernel is to inform the wake up source to SCP firmware.

brad
Posts: 1449
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 C4 HC4 N1 N2 N2+ H2 H2+ (64 bit ftw)
Location: Australia
Has thanked: 135 times
Been thanked: 222 times
Contact:

Re: Any plan for basic mainline linux support?

Post by brad »

tobetter wrote:
Wed Jun 16, 2021 11:27 am
Tassadar wrote:
Wed Jun 16, 2021 2:49 am
If you want just a poweroff button (no wakeup), add this to your source dtb file and rebuild the database:

Code: Select all

gpio-keys-polled {
                compatible = "gpio-keys-polled";
                #address-cells = <1>;
                #size-cells = <0>;
                poll-interval = <100>;

                power-button {
                        label = "power";
                        linux,code = <KEY_POWER>;
                        gpios = <&gpio GPIOX_3 GPIO_ACTIVE_LOW>;
                };
        };
Make sure your kernel is compiled with CONFIG_KEYBOARD_GPIO_POLLED=y. This gives a poweroff button on pins 11 (GPIOX_3) and 9 (ground).
Funny thing though, the Hardkernel's kernel 4.9.19x, which does have a GPIO wakeup capability doesn't use GPIO interrupts.
Thanks, I'd like take this change and merge to my branch for power key and other use cases. :)
Also as you mentioned, the interrupt feature is not required to make wake up through GPIO. I believe the missing part of wake-up in the mainline kernel is to inform the wake up source to SCP firmware.
There was some discussion in the mailing groups few years back about how to integrate the the amlogic GPIO interrupt feature into mainline. Apparently it is a bit different to other SOC's already implemented as amlogic has a number of interrupts (8 if I recall) that could be assigned to almost any pin whereas other systems have dedicated interrupts to interrupt compatible pins. So the discussion was about how to implement the dynamic interrupts (ie do they get assigned in devicetree, configurable at runtime via api, etc). I have been meaning to ask about this myself as it would be more power efficient to have the interrupt indicate rather than having to poll the GPIO's constantly. I will try to find the old thread on the mailing list and send an email in the next few days to see current status or plans.

Edit: It does appear it made it in - https://git.kernel.org/pub/scm/linux/ke ... =v5.13-rc6

And it looks like the defined pins are set in devicetree on this line - https://git.kernel.org/pub/scm/linux/ke ... -rc6#n2187

so some testing needed maybe
These users thanked the author brad for the post (total 3):
tobetter (Wed Jun 16, 2021 5:27 pm) • m_ueberall (Wed Jun 16, 2021 11:09 pm) • elatllat (Sat Jun 19, 2021 1:09 am)

Tassadar
Posts: 36
Joined: Sun Aug 18, 2019 7:04 pm
languages_spoken: english
ODROIDs: C2, XU4, N2
Has thanked: 3 times
Been thanked: 3 times
Contact:

Re: Any plan for basic mainline linux support?

Post by Tassadar »

I analyzed gpio wake support in drivers/amlogic/input/keyboard/gpio_keypad.c in 4.9.x kernel. All it takes is to write the upper half of a 32-bit hardware register with gpio pin export number (see https://wiki.odroid.com/odroid-n2/hardw ... connectors); i.e. for pin 11 it is 479. With a quick and dirty approach I wrote the module source file gpio-wakeup.c:

Code: Select all

#include <linux/init.h>
#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/gpio.h>

MODULE_LICENSE("Dual BSD/GPL");

#define AO_DEBUG_REG0           ((0x28 << 2))

static unsigned long gpiopower=479;

static int gpio_wakeup_init(void)
{
        void __iomem *ao_reg=NULL;
        int val;

        printk(KERN_INFO "gpio wakeup test driver loaded\n");
        
        /* Values are taken from gpio_keypad section of meson64_odroidn2.dts 
         * file from Hardkernel's 4.9.x kernel: */

        ao_reg=ioremap(0xFF800000,0x400);

        if (ao_reg) {
                val = readl((ao_reg + AO_DEBUG_REG0));
                val |= (gpiopower << 16);
                writel(val, (ao_reg + AO_DEBUG_REG0));
                /*EDIT*/
                iounmap(ao_reg);
        }
        
        return 0;
}
static void gpio_wakeup_exit(void)
{
        printk(KERN_INFO "gpio wakeup test driver exit\n");
}

module_init(gpio_wakeup_init);
module_exit(gpio_wakeup_exit);
and a Makefile:

Code: Select all

ifneq ($(KERNELRELEASE),)
        obj-m := gpio-wakeup.o
else
        KERNELDIR ?= /lib/modules/$(shell uname -r)/build
        PWD := $(shell pwd)
default:
        $(MAKE) -C $(KERNELDIR) M=$(PWD) modules
endif
and executed commands:

Code: Select all

$ make
$ sudo insmod gpio-wakeup.ko
After that a power button on pins 11 and 9 wakes up the N2 as expected.
EDIT: Should allocate i/o memory first before remapping.
But request_mem_region(0xFF800000,0x400,0) fails, and in order to use platform_get_resource(pdev, IORESOURCE_MEM, 0), as in the original code, you need a working platform driver.

Tassadar
Posts: 36
Joined: Sun Aug 18, 2019 7:04 pm
languages_spoken: english
ODROIDs: C2, XU4, N2
Has thanked: 3 times
Been thanked: 3 times
Contact:

Re: Any plan for basic mainline linux support?

Post by Tassadar »

The sources for the experimental N2 GPIO wakeup driver have been uploaded to https://github.com/tassadar777/gpio-wakeup.
These users thanked the author Tassadar for the post (total 2):
odroid (Tue Jun 22, 2021 2:37 pm) • m_ueberall (Wed Sep 08, 2021 5:11 pm)

jgmdev
Posts: 359
Joined: Tue Jan 28, 2020 2:28 pm
languages_spoken: english, spanish
ODROIDs: U2, N2, N2+, C4, HC4
Has thanked: 148 times
Been thanked: 259 times
Contact:

Re: Any plan for basic mainline linux support?

Post by jgmdev »

Reporting that pinky grays are back with latest 5.13 kernels up to 5.14 as far as tetested

trwn2p
Posts: 75
Joined: Fri Oct 16, 2020 5:12 am
languages_spoken: english
ODROIDs: N2 Plus
Has thanked: 3 times
Been thanked: 13 times
Contact:

Re: Any plan for basic mainline linux support?

Post by trwn2p »

jgmdev your 5.14.0-1-ARCH #1 SMP PREEMPT Fri Sep 3 18:11:05 AST 2021 aarch64 GNU/Linux has them too. FYI

jgmdev
Posts: 359
Joined: Tue Jan 28, 2020 2:28 pm
languages_spoken: english, spanish
ODROIDs: U2, N2, N2+, C4, HC4
Has thanked: 148 times
Been thanked: 259 times
Contact:

Re: Any plan for basic mainline linux support?

Post by jgmdev »

trwn2p wrote:
Mon Sep 13, 2021 3:16 am
jgmdev your 5.14.0-1-ARCH #1 SMP PREEMPT Fri Sep 3 18:11:05 AST 2021 aarch64 GNU/Linux has them too. FYI
Yep, I'm pulling directly from tobetter and noticed this issue is back, not sure if some updated uboot is required to make colors look normal but as far as I see uboot hasn't seen any changes on hardkernel repo. I think someone reported that using mainstream uboot solved the issue but I haven't got my hands into it...

On the positive side, changing to resolutions like 720p now doesn't produces messy purple colors like before at least on my setup.

Edit: ahh I think tobetter already fixed it
https://github.com/tobetter/linux/commi ... c461ffb092

Edit #2: yep, it is fixed, next 5.14 build should fix the issue

chewitt
Posts: 126
Joined: Mon Aug 12, 2019 12:27 pm
languages_spoken: english
Has thanked: 1 time
Been thanked: 112 times
Contact:

Re: Any plan for basic mainline linux support?

Post by chewitt »

I want to correct the terminology being used. Tobetter has not "fixed" the problem. He's hacked a workaround. There are probably more DRM properties that vendor u-boot has set that the kernel DRM layer needs to understand and correctly handle, similar to https://github.com/tobetter/linux/commi ... 7ace11cc6b (which for some inexplicable reason has been reverted).

To explain: I'm very picky about the use of "fix" in vendor forums because when everyone believes hacks and workarounds are fixes, nobody makes the effort to find the real fix and the upstream codebase doesn't evolve and improve. The number of developers working on Amlogic in the upstream kernel is far too small, so we all need to encourage manufacturers with full-time staff working on kernel support to always work for a proper fix, and to always upstream it. I'm pleased to see a /* FIX ME */ in code, which I hope means @tobetter is looking into a proper fix :?:

NB: The other workaround is to use mainline u-boot which doesn't support and set all the unsupported DRM properties in the first place, and thus avoids the problem. You will only see these colour issues with Amlogic u-boot sources.
These users thanked the author chewitt for the post (total 2):
jgmdev (Tue Sep 14, 2021 10:24 am) • brad (Tue Sep 14, 2021 11:13 am)

trwn2p
Posts: 75
Joined: Fri Oct 16, 2020 5:12 am
languages_spoken: english
ODROIDs: N2 Plus
Has thanked: 3 times
Been thanked: 13 times
Contact:

Re: Any plan for basic mainline linux support?

Post by trwn2p »

I mostly boot using petitboot not uboot so not sure that's a full or correct explanation for this issue. PB reads the /boot on sda1 of the 2.5" hdd sata caddy over usb3. Kern 5.14.1 was rebuilt and it fixed the issue. I'm not an expert on the exact workings of how petitboot works vs u-boot though. I do this with Ubu Impish KDE and Arch/Manjaro KDE.

Post Reply

Return to “General Topics”

Who is online

Users browsing this forum: No registered users and 2 guests