I purchased 2 versions of the Transpeed m98 stick. 2Gb/16Gb and 4Gb/64Gb. Coreelec 22 successfully installs on the 4/64 version with dtb s905y4_2g. As it turned out later, the 2Gb version only has 1Gb of RAM, while the 4Gb version has 2Gb of RAM. For the fake 4Gb (real 2Gb) version, there is a dtb, but for the fake 2Gb (real 1Gb) version, there is no dtb… In the android system, the dtb partition was removed and decompressed into dts. I am attaching it below.
You may get more help than I do.
I apologize if something is wrong.
AI’s thoughts on the subject.
Let’s break it down step by step:
1. Why the panic happens
CoreELEC (and Linux on Amlogic in general) relies heavily on framebuffer initialization at boot.
If the dtb or u-boot describes memory incorrectly (for example, the kernel thinks there are memory regions that don’t actually exist), drivers may write into non-existent addresses.
That’s why it crashes inside meson_fb_destroy → the kernel dies during framebuffer initialization/freeing.
2. Where the problem may be
The dtb was built for 1 GB, but it might not fully match your specific hardware revision (different memory maps exist for S905Y4).
Since the RAM is fake, your u-boot might still report 2 GB, and the kernel still tries to access invalid regions, even with the fixed dtb.
The issue might be in the reserved-memory section of the dtb (used for VPU/GPU/FB). If those reserved regions are set beyond the 1 GB limit, the kernel will crash for sure.
3. What you can try
Check the DTB with a hex editor:
In the reserved-memory nodes, the ranges must be below 0x40000000 (1 GB).
If you see anything like 0x50000000 or higher → that’s definitely wrong.
Try CoreELEC 21 (Matrix) or even 20.
CoreELEC 22 uses a newer kernel that is stricter about memory issues.
Older versions may boot without panicking.
Force memory limit via bootargs:
In uEnv.ini add:
mem=1024M
or even mem=896M (leaving some room for GPU).
Sometimes this prevents framebuffer crashes.
Rebuild or patch the dtb:
The key fix is to set memory@0 to 0x40000000.
Then make sure all reserved-memory regions fall within that range.
It worked!
Taking the dtb from s905y4_2g as a basis, I used a hex editor to edit it.
After reviewing the files from “dtb-unpack” earlier (comparing s4-s905y4-1g.dts and s4-s905y4-2g.dts, specifically the RAM), I came across a code block in the 2GB version:
memory@00000000 {
device_type = “memory”;
linux,usable-memory = <0x0 0x0 0x0 0x80000000>;
and in the 1GB version, the ending was:
linux,usable-memory = <0x0 0x0 0x0 0x40000000>;
After finding and replacing this value in dtb using a hex editor, I decided to run it one last time. And it started, Coreelec 22. I’m attaching the file below, and you can add it in future versions.
To be honest, I didn’t change anything on the fat32 disk except for DTB, in Coreelec 22.
But it doesn’t change the essence of the matter. It worked. Thank you, vpeter. Without you, the problem wouldn’t have been solved.
P.S. It might be worth adding this dtb to future versions of CE.
P.S.2. I changed the name in DTB to s905y4_g1.
I’m sorry, but I think I was too happy. None of the videos, either online or TV channels, are running.
I have no idea what to think about yet. I think I need to shift something from 2GB to 1GB (video memory or something like that)…
No problem, below are 2 files. “startdmesg.log” - Made immediately after starting coreelec. “videodmesg.log” - Made after 3 different attempts to play video. (1 - TV channel, 2 - Online video, 3 - Local video).
