[kernel] mainline support evolution

since 5.4.rc8 a mainline patch need to be reversed, else screen flicker

patching file sun4i-i2s.c seem no more needed in recent kernel

compiled 5.4.1 kernel, untested on debian > kernel, headers


I really envy those who understand kernel development


i nearly know about nothing about kernel development ^^"
others like godzil must know pretty much more on the subject

it make me some try & time to find the faulty commit, same thing for tweaking kernel config
since i made a real pkgbuild without (for now) cross compile, each kernel compilation took about 1h on gs …

i still have some trouble with bluetooth and xorg still fall to llvmpipe,
got a full working system but it need some more work :slight_smile:

1 Like

5.5 branch with the latest rc1 release change the backlight driver system, so our ocp8178 driver need to be patched




I would honestly not go bleeding edge like that, and avoid RC version as much as possible. Using LTS would be better, but there is no 5.x LTS yet, at least a stable branch, but you would need to move forward until they put a LTS branch if you do so.

The other problem with the stable branch is they are not necessarily that well tested unlike LTS or a bit older branches, and you may encounter some unexpected bugs.

For the TL;DR, I would prefer to avoid too recent kernel for an official OS release, and try to use a reasonably well tested stable version

that’s a valuable point of view but as our hardware mainline support is pretty recent, like lima, use latest release mean latest support & real evolution

but yes it could include problems like the one i point in #1 or this recent backlight driver change

Would backporting the relevant drivers be a possibility? Or are the necessary parts too interlinked to have a go on that?

yes, driver seem to use the “skeleton” of generic one to speak with kernel api, with aside all additional & custom code to interface with our backlight hardware

on a first see we just need applying the same modification of generic driver got to port our one to the new api

i’m not an expert but api change seem to have removed from driver all code related to catch gpio pins, now directly asking kernel to catch them from device tree

Doesn’t the kernel provide legacy bindings for some releases until LTS is over for the older kernel? Or what about (will be difficult though) rewriting the lima driver as a module which can be loaded with dkms? Or adding the gpio pins to a dts file and rewrite the driver to get the necessary pins from that file

it’s the screen backlight driver who need a patch, not the gpu one
for lima, since kernel 5.2 it is hopefully directly included in mainline :slight_smile:

yes i think all kernel before this 5.5 branch will continue support for older api

Oh yeah, sorry, mixed them up. Would be very bad if gpu drivers for a common chip weren’t mainlined (looking at you nVidia). As the backlight driver is smaller it seems even more realistic to backport it without too much hassle

The ClockworkPi/Gameshell are recent devices, yes, the AllWinner chip is not.

@beckerichmika Yes to some extend, but not everything. They back-port driver only and only if that’s a really important thing to support on that LTS. New hardware are generally not added until the next LTS, but well we will see!

@r043v: I have nothing against using a recent kernel version; just that for an official release it is better to stick to the closest stable or LTS release. Of course if we don’t have the choice well…

@Godzil off course you have choice, the repo keep contain all previous compiled revisions!

also compile a previous version is pretty simple, edit pkgbuild file (eventually downgrade it since it need itself keep patch evolution), change wanted version in the header, run updpkgsums, makepkg, and wait one hour ^^


just compiled 5.6.rc2, now driver structure for declare access callback function have changed,
for us affected files are :


fix is trivial, replacing struct file_operations with struct proc_ops, it need also patching all containing properties names, prefixing them with proc_

example onto /drivers/leds/leds-gpio.c file :

previous :

static const struct file_operations leds_gpio_proc_fops = {
	.open		= leds_gpio_proc_open,
	.read		= leds_gpio_proc_read,
	.write		= leds_gpio_proc_write,
	.llseek		= seq_lseek,
	.release	= single_release,

new :

static const struct proc_ops leds_gpio_proc_ops = {
	.proc_open		= leds_gpio_proc_open,
	.proc_read		= leds_gpio_proc_read,
	.proc_write		= leds_gpio_proc_write,
	.proc_lseek		= seq_lseek,
	.proc_release		= single_release,

for cleaner patch, changed also the instance name used, to remove the f (meaning file), that’s mean patch a single line more by file :

r = proc_create(buf, S_IRWXUGO, NULL, &leds_gpio_proc_fops);
r = proc_create(buf, S_IRWXUGO, NULL, &leds_gpio_proc_ops);

work fine, on arch can be tested manually for now :

wget http://gs.dread.fr/arch/armv7h/linux-gameshell-5.6.rc2-1-armv7h.pkg.tar.xz
wget http://gs.dread.fr/arch/armv7h/linux-gameshell-headers-5.6.rc2-1-armv7h.pkg.tar.xz
sudo pacman -U linux-gameshell-*5.6.rc2*.pkg.tar.xz




good news, patch latest kernel (5.6.rc3) with lima-next work fine

just need replace kernel lima implementation with current latest one :

drivers/gpu/drm/lima/ folder with all these files :
and file include/uapi/drm/lima_drm.h :

[    0.693177] lima 1c40000.gpu: IRQ ppmmu2 not found
[    0.695612] lima 1c40000.gpu: IRQ ppmmu3 not found
[    0.698043] lima 1c40000.gpu: gp - mali400 version major 1 minor 1
[    0.700521] lima 1c40000.gpu: pp0 - mali400 version major 1 minor 1
[    0.703035] lima 1c40000.gpu: pp1 - mali400 version major 1 minor 1
[    0.705496] lima 1c40000.gpu: IRQ pp2 not found
[    0.707907] lima 1c40000.gpu: IRQ pp3 not found
[    0.710320] lima 1c40000.gpu: l2 cache 64K, 4-way, 64byte cache line, 64bit external bus
[    0.714399] lima 1c40000.gpu: bus rate = 200000000
[    0.716826] lima 1c40000.gpu: mod rate = 384000000
[    0.719496] [drm] Initialized lima 1.1.0 20191231 for 1c40000.gpu on minor 1

like previous release candidate can be manually setup on arch :

wget http://gs.dread.fr/arch/armv7h/linux-gameshell-5.6.rc3-1-armv7h.pkg.tar.xz
wget http://gs.dread.fr/arch/armv7h/linux-gameshell-headers-5.6.rc3-1-armv7h.pkg.tar.xz
sudo pacman -U linux-gameshell-*5.6.rc3*.pkg.tar.xz

as well updated mesa-lima to today one, setup it aside using classic system upgrade


Amazing! Just confirming, is this both compatible with your arch based OS and the official Debian stretch, ie OS0.5 image? I am very interested to try this out!

yes it must work,

take note distributed file is an arch package, but like a deb it’s just an archive, manually copy contained files will work (ie only /boot/zImage and /usr/lib/modules/ must be ok)

my kernel defconfig have variation with your one, by example wifi driver is as a module so you’ll need to copy the module folder as well

also in arch port first partition is mounted to /boot and uboot was configured (with boot.scr) to directly boot the zImage, on your side this is legacy method with the use of uImage file

to convert zImage to uImage just use the mkimage utility :
mkimage -A arm -O linux -T kernel -C none -a 0x40008000 -e 0x40008000 -n “Linux kernel” -d zImage uImage

you could also change your boot.scr file to directly boot zImage,
arch port use an initrd and debian not, arch boot.scr try load initrd but there is fallback if file is not here so it must work, but you will have console show, no logo

you could also recreate a boot.scr dedicated to debian,
this boot.txt must work with your setup (untested) :

part uuid ${devtype} ${devnum}:2 uuid

setenv bootargs earlyprintk no_console_suspend root=PARTUUID=${uuid} rootfstype=ext4 noinitrd rw rootwait init=/sbin/init panic=10 ${extra}

if load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} /zImage; then
  if load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} /sun8i-r16-clockworkpi-cpi3.dtb; then
      bootz ${kernel_addr_r} - ${fdt_addr_r};

and convert the .txt with mkimage to have your boot.scr :
mkimage -C none -A arm -T script -d boot.txt boot.scr

edit >

i compiled the boot.scr specific to debian, http://gs.dread.fr/boot.debian.scr rename it to boot.scr, place it in boot partition along with zImage and copy modules folder content into /usr/lib/modules/