Mainline kernel and mainline uboot

[macc24]

I saw no forum post tracking both of these issues, so here I am making it to share knowledge.

I have made a proof-of-concept: https://github.com/Maccraft123/dtg-ng
Login is root, and password is empty
Console is on internal UART header with 115200 speed.

Mainline kernel part:
- I couldn't get USB to recognize devices after booting, it has to be investigated UPDATE: it works now
- DRM driver for display works well enough to display framebuffer console
- 3D acceleration should work on OpenGL 2.1 level with open-source Panfrost driver
- For wifi, SDIO support is needed, it looks like @valadaa48 has experimented with that. https://github.com/al177/esp8089/issues/44

Mainline u-boot:
- Display isn't supported
- USB isn't supported
- Enough to boot Linux kernel
- Needs "recovery" button to be pressed to not launch uboot from spi flash chip

If anyone wants to talk, I'm on #go2-mainline Freenode IRC channel

[macc24]

UPDATE:
Now working in kernel:
USB - both peripheral and host modes working
3D acceleration - OpenGL 2.1 works, but it's unstable with mesa compiled using https://github.com/Maccraft123/armhf-to ... build-mesa and user needs write access to /dev/dri/*
WiFi - still nothing...
Speaker/Headphone jack - not working?
Buttons - tested and working fine
Joystick - not tested

[valadaa48]

Hey macc24. I've been playing around with the kernels posted on the android thread. I can post some of my unorganized notes/thoughts here:

4.19 would be nice and maybe easier but I agree there is much more to be gained from 5.x.

On 5.9, I had the same experience as you, mainly that USB worked but I could not get wifi to work at all (none of my usb wifi dongles or internal esp8089 for that matter). drm/kms worked, but I forget if I tried an app with it or not. I did upstream a patch for retroarch that fixed a race condition in the plain_drm driver so that should be testable now. I think I tried librga but I believe I ran into issues there, I haven't looked into it.

Sound works but none of the sound controls (volume, headphone, etc..) were seen in alsamixer, probably a wiring issue somewhere.

I got panfrost working in wayland but at least retroarch was horribly slow in 2D (I didn't try 3D) so I didn't pursue that any further (it's also too difficult iterating without ssh).

My userland is void linux and as such, all libraries and apps are pretty much latest (including mesa).

If panfrost indeed proves to be a no-go (too slow), there is a chance the r16 version of the bifrost proprietary drivers might help. We're using r6 I think. I don't know what the differences are but I was able to boot r16 on kernel 5.9 and it appeared to work except for rainbow colored textures as in the outline of what should be displayed was there but everything was colored in rainbows. I don't know a thing about opengl/egl, etc.. so that's the best I can describe it.

For the r16 drivers, Shanti found https://github.com/LibreELEC/libmali/bl ... 6p0-gbm.so (there are 64bit versions as well) and also https://github.com/batocera-linux/mali-bifrost. The kernel driver can also be downloaded from ARM directly.

Since I personally don't use the 3D capabilities of this device, I would be happy to have a 5.9 setup using just kms/drm + rga with wifi, sound working. OpenDingux folks reported a single to low double-digit increase in performance on their new 5.9 kernel. I don't have specific details but they also mentioned huge pages helped (which I think is also available in kernel 3.x, but not sure).

[macc24]

Yes, 5.11 mainline kernel boots on Super, https://i.imgur.com/tZpoTEd.jpeg

macromorgan got it running around the same time on 5.11 Android kernel

In the meantime Panfrost picked up GL3 support on Bifrost

[macc24]

Update:
RK817 Power button now works and it can suspend and resume just fine with exception of one issue that macromorgan is working on
Battery now works, but why does driver take few THOUSAND lines and randomly not work every so often?
I got *something* out of that adc mux in OGS, but adc-joystick refused to work with it
Battery charging works fine with charging-sdl borrowed from postmarketOS, but I couldn't get mainline kernel to work with initramfs for couple of days and gave up.

[macc24]

Yeah input now works perfectly fine on both GO-A and GO-S(had to write a new driver from scratch for that to be compatible with existing Linux's infrastructure for muxes), it's few times smaller than what Hardkernel wrote and needs no changes between GO-A and GO-S
Some supertuxkart gameplay with Panfrost(it's hard to play it when you only see it through camera):
https://www.youtube.com/watch?v=lSreCxlhIII

BTW, that "Minecraft" entry in menu is foreshadowing

[notime2d8]

Yeah input now works perfectly fine on both GO-A and GO-S(had to write a new driver for that), it's few times smaller than what Hardkernel wrote and needs no changes between GO-A and GO-S
Some supertuxkart gameplay with Panfrost(it's hard to play it when you only see it through camera):
https://www.youtube.com/watch?v=lSreCxlhIII

Aye, the performance is a lot better now with Panfrost from the last time I saw supertuxkart running. Are you posting changes to your github or just submitting upstream?

Edit: I found the changes on your GitHub.

[macc24]

Aye, the performance is a lot better now with Panfrost. Are you posting changes to your github or just submitting upstream?

https://github.com/Maccraft123/linux/tree/odroidgo
@macromorgan has his Android tree in https://github.com/macromorgan/odroid_g ... ux_android

[macromorgan]

I'm trying to submit upstream. Been quiet here recently as I've been keeping my head down focusing on the audio driver.

https://mailman.alsa-project.org/piperm ... 82320.html

This one should be louder, smaller, and use less power than the downstream Rockchip one. The GPIO works to detect the headphones but doesn't disable the speaker path yet though. Microphone seems to work just fine too, but unfortunately there is no detect pin for it so it just assumes there is always one present even when there isn't.

[valadaa48]

Yeah input now works perfectly fine on both GO-A and GO-S(had to write a new driver from scratch for that to be compatible with existing Linux's infrastructure for muxes), it's few times smaller than what Hardkernel wrote and needs no changes between GO-A and GO-S
Some supertuxkart gameplay with Panfrost(it's hard to play it when you only see it through camera):
https://www.youtube.com/watch?v=lSreCxlhIII

BTW, that "Minecraft" entry in menu is foreshadowing

That's one of most amazing launchers I've ever seen! Glad to see others liking to keep things simple!

[macc24]

That's one of most amazing launchers I've ever seen! Glad to see others liking to keep things simple!

???
I wrote it in literally 4 hours with simple linux evdev and ncurses
All it does is just bundling system() functions into something usable with a gamepad

https://github.com/maccraft123/dtg-launcher

[valadaa48]

That's one of most amazing launchers I've ever seen! Glad to see others liking to keep things simple!

???
I wrote it in literally 4 hours with simple linux evdev and ncurses
All it does is just bundling system() functions into something usable with a gamepad

https://github.com/maccraft123/dtg-launcher

Still good taste, kudos and thanks for sharing

[loaidheach]

Yeah input now works perfectly fine on both GO-A and GO-S(had to write a new driver from scratch for that to be compatible with existing Linux's infrastructure for muxes), it's few times smaller than what Hardkernel wrote and needs no changes between GO-A and GO-S
Some supertuxkart gameplay with Panfrost(it's hard to play it when you only see it through camera):
https://www.youtube.com/watch?v=lSreCxlhIII

BTW, that "Minecraft" entry in menu is foreshadowing

This is pretty awesome and hopefully the future for OGA/OGS. So much has changed since kernel 4.4 especially for drivers (e.g. WIFI) and with panVK in the works we may also get proper vulkan support in the forseeable future. I will definitely try the 5.11 kernel when I have some time.

[macromorgan]

Just a quick update, the audio has now been officially accepted into the mainline kernel as of 5.14.

https://git.kernel.org/pub/scm/linux/ke ... 296d3bee0f

On that note, I could strongly use some additional help in testing a patch series for the Rockchip Serial Flash Controller. There may be some errata with the Odroid Go Advance. I was working on a patch, but deferred to the Rockchip engineers when they wanted to take over. The issue is that erase/write works inconsistently when dual tx mode is enabled. So far it only occurs on my Odroid Go Advance. I don't know if the problem is with the SFC of the RK3326 (unlikely), the XT25F128B chip (possible), or the Odroid Go Advance board layout (most likely). Dual read appears to work fine, and achieves an average read speed of about 5MBps. Writes are about 50KBps though...

https://marc.info/?l=linux-spi&m=162339189921686&w=2 (SFC Patch Series)
https://lore.kernel.org/linux-mtd/9930c ... hip.com/t/ (XT25F128B patch series)

[marcellus]

Hi, first of all thank you for your work on trying to get the odroid go run on the mainline kernel.

I tried to get it to run too by populating the sdcard with: https://github.com/Maccraft123/dtg-ng
The chroot part in fs/install doesn't work as I'm running on x86_64 and the root has aarch64 binaries, qemu-static-aarch64 works somewhat, but won't complete the xbps update. So at the moment I'm using a generic void aarch64 rootfs with /lib/modules and /boot copied from the official odroid go super image.

Uboot works fine (with the 4.4 kernel), however when I try to boot with the mainline kernel after the hardkernel logo shows up the screen goes blank, only showing a blinking underscore. I haven't set up a serial console yet, so I can't tell if it actually boots, however my guess would be that the boot.ini is wrong. Could you post your boot.ini? I couldn't find it in the repository

Thanks

[macc24]

Hi, first of all thank you for your work on trying to get the odroid go run on the mainline kernel.

I tried to get it to run too by populating the sdcard with: https://github.com/Maccraft123/dtg-ng
The chroot part in fs/install doesn't work as I'm running on x86_64 and the root has aarch64 binaries, qemu-static-aarch64 works somewhat, but won't complete the xbps update. So at the moment I'm using a generic void aarch64 rootfs with /lib/modules and /boot copied from the official odroid go super image.

Uboot works fine (with the 4.4 kernel), however when I try to boot with the mainline kernel after the hardkernel logo shows up the screen goes blank, only showing a blinking underscore. I haven't set up a serial console yet, so I can't tell if it actually boots, however my guess would be that the boot.ini is wrong. Could you post your boot.ini? I couldn't find it in the repository

Thanks

>The chroot part in fs/install doesn't work
Guess that's what i get for developing solely on AArch64 machines

>So at the moment I'm using a generic void aarch64 rootfs with /lib/modules and /boot copied from the official odroid go super image
???? why would you even do that
The dtg-ng kernel and u-boot are *entirely* different. I'm reimplementing entire BSP.
There is nothing that official images and dtg-ng share.
n o t h i n g

>Uboot works fine (with the 4.4 kernel), however when I try to boot with the mainline kernel after the hardkernel logo shows up the screen goes blank, only showing a blinking underscore
If you see this then it doesn't work. Mainline u-boot won't display due to missing drivers(I'll boot kernel so quickly that it won't matter) and it only talks on serial port

I'll write up some documentation for 1.0 release

[marcellus]

...
>The chroot part in fs/install doesn't work
Guess that's what i get for developing solely on AArch64 machines

If you want to get around this you could

Code: Select all

# REPO=https://alpha.de.repo.voidlinux.org/current
# XBPS_ARCH=aarch64 xbps-install -S -r /mnt -R "$REPO" base-system

But this would require to run the setup on a void installation.

>So at the moment I'm using a generic void aarch64 rootfs with /lib/modules and /boot copied from the official odroid go super image
???? why would you even do that

The void rootfs tarball has everything I want besides a working kernel and uboot so copying the image, dtb, uInitrd and kernel modules at least allows to run with a nice userland. With this setup I could replace the old uboot with your version and still boot into the 4.4 kernel. But yes it is pretty ugly.

The dtg-ng kernel and u-boot are *entirely* different. I'm reimplementing entire BSP.

Sorry, I'm pretty new at digging into arm systems, whats a BSP?

I'll write up some documentation for 1.0 release

Thanks I really appreciate your work. Is there anything I can help with?

[macromorgan]

A few updates on the current status (macc24 can help if I miss anything).
The audio driver is now upstream starting with the 5.14 kernel that's in RC at the moment: https://git.kernel.org/pub/scm/linux/ke ... 17_codec.c

The SFC driver is currently under final review by the Rockchip engineers. Near as I can tell there are no remaining bugs with it: https://patchwork.kernel.org/project/li ... chips.com/
The U-boot portion is still in development; I haven't had time to mess with it but the most recent version I was working on failed to work due to an issue with enabling the clocks. Still a work in progress on that one...

The SPI NOR chip is also currently under review: https://patchwork.ozlabs.org/project/li ... ochip.com/

Macc24 and I have been working for the past month on a battery driver, which was just submitted for comments earlier today: https://patchwork.kernel.org/project/li ... gmail.com/

The video codecs are being worked on and appear to be close to ready as well: https://patchwork.kernel.org/project/li ... abora.com/

The onboard crypto chip is pretty much the only hardware for the OGA that isn't yet mainlined or in the process of being mainlined. For the OGA-BE there needs to be a devicetree modification (for the additional buttons) and the Wifi driver. For the OGS the screen and ADC mux (for the analog sticks) needs to be added as well as a devicetree.

edit: ohh yeah, and some bugs were found too:
Affects Mainline Only - On the mainline kernel with the mainline devicetree the USB voltage drops to 3.7v if you are on battery. This can be fixed by adding the BOOST converter in the devicetree. (I can't find the patch right now but it was submitted upstream for fixing).
Affects Mainline Kernel, unknown if it affects Distribution Kernel - It appears that the register that stores the maximum USB current and voltage input value (0xe5) resets every time you unplug the power cord to its default value, at least it did for me. What happens then is the charger refuses to pull more than 2.5W or so from the power cord, meaning if you want charging to speed up you have to restart the device after you unplug it and replug it. It's possible it does this on mainline because of the way the driver is set up, but it might be worth seeing if the kernel used by the different distributions also face this problem. If they also have this same problem, making sure that the register 0xe5 is always set correctly after the plug is re-inserted could lead to faster charging times.

[macc24]

A few updates on the current status (macc24 can help if I miss anything).
The audio driver is now upstream starting with the 5.14 kernel that's in RC at the moment: https://git.kernel.org/pub/scm/linux/ke ... 17_codec.c

The SFC driver is currently under final review by the Rockchip engineers. Near as I can tell there are no remaining bugs with it: https://patchwork.kernel.org/project/li ... chips.com/
The U-boot portion is still in development; I haven't had time to mess with it but the most recent version I was working on failed to work due to an issue with enabling the clocks. Still a work in progress on that one...

The SPI NOR chip is also currently under review: https://patchwork.ozlabs.org/project/li ... ochip.com/

Macc24 and I have been working for the past month on a battery driver, which was just submitted for comments earlier today: https://patchwork.kernel.org/project/li ... gmail.com/

The video codecs are being worked on and appear to be close to ready as well: https://patchwork.kernel.org/project/li ... abora.com/

The onboard crypto chip is pretty much the only hardware for the OGA that isn't yet mainlined or in the process of being mainlined. For the OGA-BE there needs to be a devicetree modification (for the additional buttons) and the Wifi driver. For the OGS the screen and ADC mux (for the analog sticks) needs to be added as well as a devicetree.

edit: ohh yeah, and some bugs were found too:
Affects Mainline Only - On the mainline kernel with the mainline devicetree the USB voltage drops to 3.7v if you are on battery. This can be fixed by adding the BOOST converter in the devicetree. (I can't find the patch right now but it was submitted upstream for fixing).
Affects Mainline Kernel, unknown if it affects Distribution Kernel - It appears that the register that stores the maximum USB current and voltage input value (0xe5) resets every time you unplug the power cord to its default value, at least it did for me. What happens then is the charger refuses to pull more than 2.5W or so from the power cord, meaning if you want charging to speed up you have to restart the device after you unplug it and replug it. It's possible it does this on mainline because of the way the driver is set up, but it might be worth seeing if the kernel used by the different distributions also face this problem. If they also have this same problem, making sure that the register 0xe5 is always set correctly after the plug is re-inserted could lead to faster charging times.

You missed one thing:
- Panfrost picking up some optimizations for bifrost(performance still is underwhelming :/)
- I got dmc frequency scaling to mostly work fine

So we have almost everything done in kernel?

I also have been tinkering around with some video games:

Minecraft crashes after loading screen, really weird since it works on my ARM64 laptop that closely matches Odroid Go Super hardware:
https://i.imgur.com/lhKnqs9.jpg

re3(and probably by extension reVC and reLCS) work mostly fine, but I had to drop render distance a lot to get it to be fluid:
https://cdn.discordapp.com/attachments/ ... aleria.png

In-game demo, I didn't drop render distance so it's kinda slow:
https://www.youtube.com/watch?v=_ZnZbvggqXI

Still working on xash3d, kodi, thextech(super mario bros x reimplementation), ppsspp, retroarch support, supertuxkart also broke

[macromorgan]

You missed one thing:
- Panfrost picking up some optimizations for bifrost(performance still is underwhelming :/)
- I got dmc frequency scaling to mostly work fine

So we have almost everything done in kernel?

I also have been tinkering around with some video games:

Minecraft crashes after loading screen, really weird since it works on my ARM64 laptop that closely matches Odroid Go Super hardware:
https://i.imgur.com/lhKnqs9.jpg

re3(and probably by extension reVC and reLCS) work mostly fine, but I had to drop render distance a lot to get it to be fluid:
https://cdn.discordapp.com/attachments/ ... aleria.png

In-game demo, I didn't drop render distance so it's kinda slow:
https://www.youtube.com/watch?v=_ZnZbvggqXI

Still working on xash3d, kodi, thextech(super mario bros x reimplementation), ppsspp, retroarch support, supertuxkart also broke

Awesome... are you finding the issues are mostly Panfrost related? What version of Mesa are you running, as I'm finding that the newer the Mesa the better the Panfrost experience. Or do you think RAM might be a concern?

[macc24]

You missed one thing:
- Panfrost picking up some optimizations for bifrost(performance still is underwhelming :/)
- I got dmc frequency scaling to mostly work fine

So we have almost everything done in kernel?

I also have been tinkering around with some video games:

Minecraft crashes after loading screen, really weird since it works on my ARM64 laptop that closely matches Odroid Go Super hardware:
https://i.imgur.com/lhKnqs9.jpg

re3(and probably by extension reVC and reLCS) work mostly fine, but I had to drop render distance a lot to get it to be fluid:
https://cdn.discordapp.com/attachments/ ... aleria.png

In-game demo, I didn't drop render distance so it's kinda slow:
https://www.youtube.com/watch?v=_ZnZbvggqXI

Still working on xash3d, kodi, thextech(super mario bros x reimplementation), ppsspp, retroarch support, supertuxkart also broke

Awesome... are you finding the issues are mostly Panfrost related? What version of Mesa are you running, as I'm finding that the newer the Mesa the better the Panfrost experience. Or do you think RAM might be a concern?

I'm *always* running mesa-git on all my arm machines, nowadays I rarely run into panfrost bugs as bifrost support is in much better shape now, especially compared to beginning of this year.
RAM? GTA3 is from 2001 and 1GB was pretty high for a PC to have maybe I think?

My best guess is that re3 and gta 3 do something stupid to tilers which wasn't an issue until now as slow gpus were immediate mode renderers and anything faster than g31(like g72 in my laptop, below) brute-forces through it.
https://cdn.discordapp.com/attachments/ ... 202817.mp4

[marcellus]

Hey, could one of you post an image? I tried running dtg-ng but can't get it to work as my odroid is the only aarch64 computer I have and it fails at one place or another.

I want to use my odroid go super as robot remote control, I only need something that can run the opencv gui with hw acceleration.

[vurpo]

I was also pretty interested in this. I went through the scripts in dtg-ng and tweaked them until they built successfully, and I got it to boot and run correctly. (Oracle Cloud offers free ARM64 VMs with 4 cores and 24 GB of RAM, and that was the fastest and easiest option for building this for me, since I didn't get cross compilation to work!)

My tweaked repo is at https://github.com/vurpo/dtg-ng. The scripts and README are also modified with instructions on creating an image rather than writing directly to an SD card. After writing to the SD card I also needed to press the button on the back of the device to boot it.

However, I'm still more interested in the mainlining efforts for this SoC and the OGA/OGS. Is anyone still working on getting it upstreamed, or is there anything left to upstream?

[vurpo]

Also, I tried compiling and running Sonic Robo Blast 2 on this image, in Wayland. Both the software and OpenGL video modes activate correctly, however the OpenGL mode has significantly worse performance than the software rendered mode. I wonder if this is just the way that the game is, or if there's some kind of misconfiguration.