Slackware inside Pyra

[TrashyMG]

As a workaround, I was able to use a X rotation using etnaviv:

/etc/X11/xorg.conf.d/10-video-etnaviv.conf

Section "Device"
    Identifier "etnaviv"
    Driver "modesetting"
    Option "kmsdev" "/dev/dri/card1"
    Option "AccelMethod" "glamor"
EndSection

Section "ServerFlags"
    Option "AutoAddGPU" "false"
EndSection

Cool, I wasn't sure etnaviv and the Vivanti core was actually usable on the OMAP5

 

[ingoreis]

This is very interresting..i do not know much about this but i am very very impressed about your Progress
When you need one testing Person..maybe i can Test some Things for you

 

[Linux-SWAT]

Well I use the hard work of other people ;^)
I'll let you know when things will fit together. For now it's still ugly, e.g. starting X gives a black screen half of the time. I guess I should rotate with xorg, not with the user config.

 

[netcat]

Why are you rotating the screen? Playing Ikaruga??

 

[Linux-SWAT]

^^ I would let the screen vertical to play it.

The screen has a default smartphone-like orientation. That's why it must be rotated for the Pyra.

 

[Linux-SWAT]

I was able to fix the blueman-applet crash:
hciconfig -a gave:

Name: ''
Service Classes: Unspecified
Device Class: Invalid Device Class

I modified the /etc/rc.d/rc.bluetooth file.
bluetoothd must be called with the --noplugin=hostname option:

/usr/sbin/bluetoothd --noplugin=hostname &

But I can't keep the devices down by default without triggering another crash.

 

[Linux-SWAT]

Boot:
For some reason, I had to use an extlinux/extlinux.conf instead of uEnv.txt .

Here's extlinux/extlinux.conf:

TIMEOUT 30
DEFAULT primary

MENU TITLE SL4P SD Card boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /uImage
      FDT /omap5-letux-cortex15-v5.3+pyra-v5.3.dtb
      APPEND console=ttyO2,115200n8 console=tty1 no_console_suspend=1 root=/dev/mmcblk0p2 ro rootfstype=ext4 console=tty0 vram=12M omapfb.vram=0:8M,1:4M omapfb.rotate_type=0 omapdss.def_disp=lcd rootwait twl4030_charger.allow_usb=1 musb_hdrc.preserve_vbus=1 log_buf_len=8M ignore_loglevel earlyprintk drm_kms_helper.fbdev_rotation=8

#vram=12M omapfb.vram=0:8M,1:4M omapfb.rotate_type=0 omapdss.def_disp=lcd
#omapfb.rotate_type=0 omapdss.def_disp=lcd drm_kms_helper.fbdev_rotation=8 drm.force_hw_rotation=true

 

[Linux-SWAT]

I guess I should rotate with xorg, not with the user config.

Done with /etc/X11/xorg.conf.d/10-video-etnaviv.conf :

Section "Screen"
    Identifier "DSI-1" # Use the one reported by xrandr
    Device "etnaviv"
EndSection

Section "Device"
    Identifier "etnaviv"
    Driver "modesetting"
    Option "kmsdev" "/dev/dri/card1"
    Option "AccelMethod" "glamor"
EndSection

Section "ServerFlags"
    Option "AutoAddGPU" "false"
EndSection

and /etc/X11/xorg.conf.d/10-screen.conf :

Section "Monitor"
    Identifier "DSI-1"
    Option     "Rotate" "Right"
EndSection

 

[Linux-SWAT]

Well I've just spent 6 hours trying to boot another kernels. All of them fail.
Letux 5.4.243 -> kernel panic ti_dt_clocks_register: failed to lookup clock node l4per_cm
Letux 5.10.18 -> kernel panic ti_dt_clocks_register: failed to lookup clock node l4per_cm then it's stuck
Official aTc 5.6.19 -> I can mount / , then kernel panic

The only which boots is Letux 6.4.0-rc2. But it lack a lot of features.

The big problem here is that many things are like locked, hard-written.
Some uboot parameters can't be overriden (can't switch back to mmc0 when it goes mmc0->mmc1), and uEnv is very picky when using < 6.4.0 .
Official kernel wants a F2FS root filesystem.
Sometimes / is mmcblk0, sometimes mmcblk3...
This is a mess.

I sent logs to hns and asked a few questions to aTc. Let's see...

--EDIT:
I'm recompiling aTc kernel without hardcoded boot commands...
I have to sleep now...

 

[Linux-SWAT]

I have to convert the zImage to uImage format, unfortunately I don't know the <load-address> and <entry-point> parameters, do somebody know them ?
Do I have to change the "-n" parameter ?

mkimage -A arm -O linux -T kernel -C none -a <load-address> -e <entry-point> -n "Linux kernel" -d arch/arm/boot/zImage uImage

 

[netcat]

Wow you wake up and kernel hack immediately. Kudos.

 

[Linux-SWAT]

Looks like it's possible to get it from another uImage:

$ file uImage
uImage: u-boot legacy uImage, Linux-5.4.242-letux-lpae+, Linux/ARM, OS Kernel Image (Not compressed), 5380376 bytes, Thu Apr 27 10:55:17 2023, Load Address: 0X80008000, Entry Point: 0X80008000

Post automatically merged: May 25, 2023

Wow you wake up and kernel hack immediately. Kudos.

Not to mention that I'm sick and tremendously late for work.

 

[Linux-SWAT]

Lol, official kernel is not a uImage, it's a zImage:

$ file vmlinuz-5.6.19-daveiii-pyradef-aufs
vmlinuz-5.6.19-daveiii-pyradef-aufs: Linux kernel ARM boot executable zImage (little-endian)

And when I try to boot a zImage, uboot says "wrong format" and I have to convert to uImage.
Such a mess...

 

[Linux-SWAT]

FATAL: kernel too old
So recompiled official 5.6.19 kernel doesn't boot on Slackware.

 

[hns]

The only which boots is Letux 6.4.0-rc2. But it lack a lot of features.

What are the lot of lacking features? I only know about issues with X11 screen rotation and nobody having PVR/SGX up and running. There are some glitches but not missing features.

 

[Risca]

Well I've just spent 6 hours trying to boot another kernels. All of them fail.
Letux 5.4.243 -> kernel panic ti_dt_clocks_register: failed to lookup clock node l4per_cm
Letux 5.10.18 -> kernel panic ti_dt_clocks_register: failed to lookup clock node l4per_cm then it's stuck

Maybe a dumb question, but have you verified that the correct dtb is used?

 

[Linux-SWAT]

What are the lot of lacking features? I only know about issues with X11 screen rotation and nobody having PVR/SGX up and running. There are some glitches but not missing features.

Indeed most of the hardware I tested is working but https://projects.goldelico.com/p/gta04-kernel/ shows nothing about state so I guessed many work still had to be done.
Also 5.4 and 5.10 don't work so why 6.4 would be in a good shape ?

Maybe a dumb question, but have you verified that the correct dtb is used?

Well I always use omap5-letux-cortex15-v5.3+pyra-v5.3.dtb taken from the kernel used, e.g.:

Index of /letux-kernel/letux-5.4.243-lpae

I guess I should double check everything in my rootfs build scripts or maybe recompile from source...

 

[Linux-SWAT]

FATAL: kernel too old
5.4.243-letux-lpae

 

[Linux-SWAT]

5.10.180 boots !!!

Maybe a dumb question, but have you verified that the correct dtb is used?

Thanks, I double-checked and noticed something messy, I think the dtb was overwritten at some point in the build.
Worst part is that I md5summed everything on the SD cards because it drove me nuts, and the md5sums were correct. I was probably too sleepy and missed something.
Now I'm pissed off at myself, need to cool down.
Thanks again Risca.

 

[hns]

but https://projects.goldelico.com/p/gta04-kernel/ shows nothing about state so I guessed many work still had to be done.
Also 5.4 and 5.10 don't work so why 6.4 would be in a good shape ?

Because there were some years of development in between

Well, there are not many updates on the summary table. The best reference is the CHANGES log: http://download.goldelico.com/letux-kernel/letux-6.4-rc3/src/CHANGES
Of course it can't be easily filtered for "Pyra". You must search e.g. for bq2429x to find out that there were improvements between v5.15 and v5.17 to the charger driver. So the best assumption is that it is working best in kernels after v5.17. This may be the reason why there is good operation time with LetuxOS but not so good with PyraOS.

But, there may also be changes in upstream code where others tried to improve something else and did break a feature. This may remain unnoticed to us until someone complains. So there is no warranty that kernels after v5.17 are really better for charging. It is likely but not granted. But there may be other important fixes after v5.17... For example it is unlikely that we backport AESS fixes (as soon as they work) to anything before v6.1.

Ideally a team of volunteers would permanently test devices and update this list: https://git.goldelico.com/letux-kernel-featurelist.php
But the regression problem is difficult to properly handle in this table. Which information helps most: "is not working (in latest kernel)", "was working from 4.19 to 4.20 and 5.3 to 5.5 and for 5.16.32", "was working but currently broken" etc.? I don't know...

So that list should become multi-dimensional: list the status for each combination of features, devices and kernel version.