If you go to the bottom of the nightly download page and look at the archive link - this contains all of the previous builds.
1 Like
Also is good idea to make backup after every nightly, or at least once
When you have setup the way you like
Sure, tested uSD alone eMMC alone and both. Same problems on all configurations unfortunately 
Reverting to an older version by putting .tar into .update (I used 20250726 version) helped, I’m back online 
The reason for writing this is that in 20250731 coreelec didn’t even recognise that it has a wifi module available, so I rolled even further back.
device: ugoos am6b+
Try the NO build that came out today. 20250806.
Tried and that is still no WIFI.
Build 20250807 should have wifi working again.
1 Like
Thanks, yes wireles are working with today’s update
1 Like
Another user pointed out that the 2 GB version of the Odroid N2 may be incompatible. Does the included DTB only work with the 4 GB version?
Nope.
DTB is working on my N2(4GB & 2GB)
But there a a lot of N2/N2+ Versions like a,b,c,d
mine is 2gb from 2019 (REV 0.4 20190207)
Some DVB-T2 TV-channels (1080i) play jerky in my s905x4 boxes.
Sample of a problematic stream and log.
Here is answer from chatgpt:
The short glitch you see during CoreELEC 22 boot on the Ugoos AM6 Plus is most likely caused by differences in video output initialization between:
CoreELEC 21 NG (32-bit) – the older kernel and 32-bit userspace brought up the framebuffer and HDMI output later in the boot sequence, so U-Boot kept the display “clean” until the hand-off.
CoreELEC 22 NO (64-bit) – the newer kernel/drivers trigger a different DRM/KMS or VPU init path that enables the output earlier. Before the splash/logo is drawn, the framebuffer may contain uninitialized data or be in the wrong color format, so you briefly see garbage.
From your boot logs, the main differences are:
In the 64-bit version, drm, meson-drm, vout, osd_init start earlier and immediately turn on the HDMI output.
In the 32-bit NG version, HDMI init happens later, after several other modules (including memory clear/setup).
The NO version also switches the framebuffer pixel format (e.g. RGBX ↔ YUV) during boot, which can expose whatever is in VRAM.
That difference means the display shows the VRAM contents for a split second before it’s cleared.
Possible fixes/workarounds:
1. Kernel patch or DTB tweak – delay OSD/vout activation until after the framebuffer has been cleared. In practice, that means adding a memset(framebuffer, 0, size) in the meson DRM driver or delaying vout_init().
2. U-Boot boot logo – keep a persistent boot logo in the framebuffer that hides the transition until Linux takes over.
3. CoreELEC config change – in config.ini or uEnv.ini, set display_autodetect=false and manually choose the resolution/HDMI mode to avoid unnecessary mode switches during boot.
4. Disable early console fb – remove console=tty0 + video=... from kernel parameters so the framebuffer isn’t activated immediately.
Patch from chatgpt:
Alright — here’s a patch for the meson-drm driver that forces a framebuffer clear before enabling the HDMI/OSD output.
This should hide the uninitialized VRAM garbage you see briefly during CoreELEC 22 boot.
Patch – Clear framebuffer before OSD enable
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -345,6 +345,19 @@ static int meson_drv_bind(struct device *dev)
/* Initialize OSD and VPU hardware */
meson_vpu_init(meson);
+ /*
+ * Workaround: Clear primary framebuffer before enabling output.
+ * This prevents a brief display of uninitialized VRAM content
+ * during early boot (seen on some boards like Ugoos AM6 Plus).
+ */
+ if (meson->primary_plane && meson->primary_plane->fb) {
+ struct drm_framebuffer *fb = meson->primary_plane->fb;
+ void __iomem *vaddr = drm_fb_vmap(fb);
+ if (vaddr) {
+ memset_io(vaddr, 0, fb->height * fb->pitches[0]);
+ drm_fb_vunmap(fb, vaddr);
+ }
+ }
/* Register the DRM device */
ret = drm_dev_register(meson->drm, 0);
---
What this does
Before the output is enabled, it checks if the primary plane has a framebuffer attached.
If yes, it maps the framebuffer memory, zeroes it out (memset_io), and unmaps it.
This ensures the display will show black instead of random memory contents during that split-second before the logo/GUI loads.
How to apply
1. Save this patch as fb_clear_patch.diff.
2. In your CoreELEC kernel source tree:
patch -p1 < fb_clear_patch.diff
3. Rebuild and install the meson DRM module (or full kernel if needed):
make modules M=drivers/gpu/drm/meson
4. Replace the kernel/modules on your CoreELEC build and reboot.
---
If you want, I can also make a lighter DTB-based workaround that simply delays vout_init() instead of editing the driver code, which might be easier to maintain between CoreELEC updates.
Here’s a DTB-based workaround you can try before patching the kernel code — it delays the OSD/HDMI enable so the framebuffer is cleared or set up by the time the output goes live.
---
DTB Workaround – Delay vout init
This approach edits your device tree to:
Delay the meson-vout probe until after meson-drm has fully initialized
Prevent early activation of the display pipeline
Steps
1. Extract your current DTB On CoreELEC:
dtb_path=/flash/dtb.img
cp $dtb_path ~/dtb.img
2. Decompile to DTS
dtc -I dtb -O dts -o dtb.dts dtb.img
3. Edit DTS Find the meson-vout or meson-drm node.
In that section, add:
status = "okay";
boot-delay = <2000>; /* delay in ms */
This gives the system ~2 seconds to finish framebuffer setup before enabling HDMI output.
If boot-delay is not recognized in your kernel, you can instead use:
status = "disabled";
and move the node into a section that is re-enabled later by userspace (CoreELEC can re-enable it via device-tree overlays at runtime).
4. Recompile to DTB
dtc -I dts -O dtb -o new_dtb.img dtb.dts
5. Deploy Replace /flash/dtb.img with new_dtb.img and reboot.
---
Pros
No kernel source rebuild needed
Easy to revert (just restore original dtb.img)
Works even with locked/secure U-Boot (like on the AM6 Plus)
Cons
Not as precise as the driver patch
Adds boot delay (you’ll see a slightly longer black screen before logo)
Just reporting that suspend stopped working with 20250810 update for CE22-NO. I reverted back to 20250809 nightly and it is working again.
With 20250810 nightly, after you suspend the box, it quickly wakes back up again by itself.
I can provide logs if you need, but hopefully somebody can identify which commit from 20250810 is the cause of the issue.
S905x4 4gb ram 64gb disk and 1gb ethernet.
atirage21, please don’t copy/pasteAI chat. Instead test the solution first and then write what is needed.
6 Likes
Suspend/resume working again 100% with 20250813 nightly. Thanks very much 
1 Like
To install NO on the Ugoos AM6B Plus, which version is correct? I think it’s the N2 version since they’re both S922X, but I’d rather ask you here since I’m not sure.