Audio Driver (with bounty!)


That's not good indeed. Maybe @hns knows why this offline?

His server also gives an error as response "service temporarily disabled": https://projects.goldelico.com/p/gta04-kernel/
I had a local copy so I didn't check (or did any pull requests lately).
Maybe were using outdated URL's.
Well I have no idea about the dev.pyra-handheld.com server/service.
Yes, https://projects.goldelico.com/p/gta04-kernel had to be restricted due to too much web traffic (scanning every deep link). Maybe it will come back in the future (needs a server upgrade and bandwidth control without breaking other things).
The latest kernel is here - a brand-new v7.3.0 with some latest AESS stuff: https://github.com/goldelico/letux-kernel/tree/letux-current - but I don't know if and how it integrates with any Pyra distribution.
There is also a special omap-aess project which mirrors some stuff (a little behind in syncing): https://github.com/goldelico/omap-aess
But I just found another phenomenon these days: When playing music over channel 11 (the legacy mode without AESS) and then through channel 5 (with AESS) and going back to channel 11 makes music run at double speed and one octave higher.
TILER is included for a very long time, and pvrsgx as well (as they are not Pyra specific but OMAP5) - but untested. Pyrainput is not.
 
Someone on discord showed where to get the kernel sources:
This user is working on the Pyra's trixie build with already working GPU power-down on idle and Cortex-M4 Support.
We should collect all the working (and maybe still in development) fixes, list them somewhere, so people can have a latest-greatest build.
I'm really looking forward to the Cortext-M4 support to get native H264 acceleration working.
 
I told codex to include Cortex-M4 support and also backport some features from Letux 7.3 to Pyra's current 5.6.19 kernel:

Kernel base: Original PyraOS kernel sources, "5.6.19-pyradef-10"
New kernel release: "5.6.19-pyradef-m4test"
Target hardware: DragonBox Pyra, OMAP5432, ARMv7-A, Pyra V5.3

1. Cortex-M4 / Remoteproc Support

The main addition is experimental support for the OMAP5432's integrated dual-core Cortex-M4 IPU subsystem.

- Backported the Device Tree-aware OMAP Remoteproc driver from Linux 5.7 to Linux 5.6.19.
- Added an OMAP5 IPU Device Tree node at physical address "0x55020000".
- Integrated the existing IPU IOMMU, mailbox, clock and reset controllers.
- Adapted the Remoteproc timer API, address translation callback and boot-address formatting for Linux 5.6.19.
- Enabled "CONFIG_REMOTEPROC", "CONFIG_OMAP_REMOTEPROC" and "CONFIG_OMAP2PLUS_MBOX".
- Added a separate "omap5-letux-cortex15-v5.3+pyra-v5.3-m4test.dtb" with the IPU enabled.
- Disabled automatic Remoteproc firmware startup as a precaution.

The original Pyra V5.3 Device Tree remains unchanged in its behavior, allowing initial kernel testing without activating the IPU.

Status: Kernel integration implemented. Actual Cortex-M4 firmware execution has not yet been validated on the Pyra.

2. Kernel Stability and Bug Fixes

Battery Charger – BQ2429x

File: "drivers/power/supply/bq2429x_charger.c"

Fixed two incorrect semicolons following conditional statements.

Previously, the driver could program precharge and charge termination currents even when the corresponding Device Tree properties had not been read successfully.

The correction ensures these optional values are applied only after successful retrieval.

Benefits: More reliable charger initialization and prevention of unintended register programming.

No battery charging limits have been changed.

SD/eMMC – OMAP HSMMC

File: "drivers/mmc/host/omap_hsmmc.c"

Fixed a possible 32-bit arithmetic overflow when converting MMC command busy-timeout values from milliseconds to nanoseconds.

The calculation now explicitly uses 64-bit arithmetic.

Benefits: More reliable timeout handling during long-running SD/eMMC operations, including potentially lengthy erase commands.

OMAP DMM/TILER

File: "drivers/gpu/drm/omapdrm/omap_dmm_tiler.c"

Corrected the error return value when allocation of the DMM refill buffer fails.

The driver now explicitly returns "-ENOMEM" instead of potentially reporting success after an unsuccessful allocation.

Benefits: Improved error handling and more predictable behavior under memory pressure.

The TILER rendering logic and DMA behavior remain unchanged.

3. USB OTG and VBUS Improvements

File: "drivers/usb/dwc3/dwc3-omap.c"

Several targeted fixes have been backported from the newer Letux kernel.

Explicit USB Initial State

The USB controller now receives explicit VBUS and USB-host identification states during initialization, including when no USB cable or host connection is detected.

Expected benefit: More consistent USB OTG initialization and device-role detection.

Safer VBUS Regulator Handling

The driver now checks whether the VBUS regulator is enabled before attempting to disable it.

This avoids unnecessary or unbalanced regulator-disable operations.

Optional VBUS Regulator Support

Replaced the previous Device Tree property check with "devm_regulator_get_optional()".

A genuinely absent optional regulator is accepted, while other errors, including probe deferral, are preserved.

Improved USB Error Cleanup

If IRQ registration fails after DWC3 child devices have been created, those devices are now explicitly removed before the remaining cleanup steps.

Expected benefits: More robust USB initialization, improved error recovery and cleaner resource management.

4. Kernel Build Compatibility

Several adjustments improve compatibility between the older Linux 5.6.19 kernel sources and modern Debian 12 development tools.

ARM/GCC compatibility

Moved the kernel's "-msoft-float" option earlier in the ARM build configuration so architecture detection works correctly with newer GCC toolchains.

This prevents incorrect fallback architecture selection and related ARM assembler errors.

SELinux host-tool compatibility

Adjusted the address-family check to accommodate newer host-system headers when building SELinux utilities, while retaining the original check for kernel code.

5. Build and Deployment Improvements

- Uses the original PyraOS kernel sources and the official Debian package revision "-10".
- Builds the kernel image, kernel modules and both standard and M4-enabled Device Trees.
- Uses a separate staging directory rather than installing files directly into the running system.
- Includes a read-only IPU diagnostic script for checking Remoteproc registration without starting firmware.

The experimental kernel uses a distinct release name so its modules can coexist with those of the original kernel.

6. Components Deliberately Left Unchanged

To minimize the risk of regressions, the following areas have not been modified by these improvements:

- PowerVR SGX544MP2 graphics driver sources, including version "1.14.3699939".
- AESS/ABE audio subsystem.
- Battery charging limits and battery-related Device Tree parameters.
- Keyboard backlight brightness tables.
- WWAN wakeup configuration.
- Existing Pyra V5.3 board configuration and default IPU-disabled behavior.

My Pyra is compiling right now at home and I can test and hopefully provide this kernel tomorrow.
 
Last edited:
I told codex to include Cortex-M4 support and also backport some features from Letux 7.3 to Pyra's current 5.6.19 kernel:

Kernel base: Original PyraOS kernel sources, "5.6.19-pyradef-10"
New kernel release: "5.6.19-pyradef-m4test"
Target hardware: DragonBox Pyra, OMAP5432, ARMv7-A, Pyra V5.3

...

My Pyra is compiling right now at home and I can test and hopefully provide this kernel tomorrow.
Oh, interesting.

Well, I wonder why we never receive suggestions (patches) for such changes tobe applied to the LetuxOS Kernels. And why people prefer to backport to End of Life kernels (even 5.10 has been phased out and 5.15 will be end of the year), instead of switching to a long-term kernel. Even Standard Debian Trixie uses 6.12 (and provides 6.18) which is available as letux-variant and debian packages (and to some extent tested on the Pyra): https://download.goldelico.com/letux-kernel/letux-rolling-lts-lpae/
 
Oh, interesting.

Well, I wonder why we never receive suggestions (patches) for such changes tobe applied to the LetuxOS Kernels. And why people prefer to backport to End of Life kernels (even 5.10 has been phased out and 5.15 will be end of the year), instead of switching to a long-term kernel. Even Standard Debian Trixie uses 6.12 (and provides 6.18) which is available as letux-variant and debian packages (and to some extent tested on the Pyra): https://download.goldelico.com/letux-kernel/letux-rolling-lts-lpae/
I was trying 6.1 myself, but I'll take any working kernel with Cortex-M4 support at this moment.
 
Oh, interesting.

Well, I wonder why we never receive suggestions (patches) for such changes tobe applied to the LetuxOS Kernels. And why people prefer to backport to End of Life kernels (even 5.10 has been phased out and 5.15 will be end of the year), instead of switching to a long-term kernel. Even Standard Debian Trixie uses 6.12 (and provides 6.18) which is available as letux-variant and debian packages (and to some extent tested on the Pyra): https://download.goldelico.com/letux-kernel/letux-rolling-lts-lpae/
For me it'ts just for fun until others take over that part (I hope for a full-fledged pyra7.3 kernel as well)
If you can't wait until I test myself, I provide my compiled kernel and an AI generated manual to install it as a second test-kernel.
Codex made a little test program for the Cortex-M4 and it ran into a kernel bug, described here.
I will integrate the kernel patch and offer the kernel again in a new thread.
 
Last edited:
The new firmware with M4 support is working! When following the manual, just make sure to adapt the env BUILD from part 2 to the location where you extracted the kernel archive.
In the /boot/extlinux/user.cfg from part 6 just delete <BOOT_PREFIX> when your system runs from SD, or replace it with /boot when running the OS from eMMC.
You get the <SD_ROOT_PARAMETERS> from /boot/extlinux/linux.cfg: copy the append line under label l0 and replace APPEND <SD_ROOT_PARAMETERS> in the user.cfg accordingly.
To boot the new kernel, /boot/extlinux/extlinux.conf should look like this:

Code:
default m4ipu
menu title Extlinux Boot Menu
prompt 0
timeout 30


menu include /extlinux/linux.cfg
menu include /extlinux/user.cfg
 
Back
Top