I just wanted to post a thanks to the developers here, my X96 X10 is running like a champ!
It plays basically everything I throw at it, and I do throw a lot at it!
And it’s actually fast, pretty impressive for a tiny box that only uses ~5W.
1 Like
Sorry about thread off topic
Has anyone on Team tested/using this on the X96X10 PRO S928X-J?
I’d like to utilize the 8 gigs if Ram, have the 8/64 version.
This box is allready Blazing Fast read speed
Boot time will not change, just wondering how much advantage it would be ?
Hey 
Tried this many times,just can’t seem to get it.Of course iam very weak in terminal/command, so could just be human error.
Here are return / mount point does not exist
/var/media/data mount point does not exist
Fuse expat 1.2.8
Error: exFAT file system is not found
After searching a bunch, I arrived at your post. Is it possible to use a script in CE to change DV settings based on what display CE Box is connected? I need two separate CE setting for playback of DV/HDR content based on if TV or Projector is used. I use Home Assistant for control in my room.
Hi, has anyone faced such issue when developing for s928x-j (x96 x10): after flashing some android roms device stuck in state rebooting on early boot stage after lines
NOTICE: BL31: S5 normal boot!
NOTICE: BL31: BL32 decompress pass
NOTICE: BL31: BL33 decompress pass
E/TC:0 00 INFO: BL3-2: ATOS-V3.18.0-7564de6c1 (gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36))) #1 Tue May 23 08:53:20 UTC 2023 aarch64
S5:BL:e5b833;ID:8096601107010306;FEAT:30F:10010000:9002F:19;POC:FF;RCY:0;OVD:0;DFU:0;eMMC:0;RD-1:0;CHK:0;SCS:0;CC:0;U:0;C:0;D:1;
already tried everything: flashed over usb from windows and linux adnl, it reboots same before actual firmware starts to flash, tried to make bootable usb and tf card. Does it mean dead memory? Actually got device from store, uased it about a day on stock firmware and tried to flash custom rom.
Wrong forum
1 Like
Perhaps you can use the Kodi JSON-RPC API within Home Assistant to change the settings of KODI
Got a brand new Ugoos SK1 which came with Android 14 out of the box. Since cemmc does not support Android 14, I tried downgrading it to Android 11 firmware with the USB burn tool. After that Android 11 boots successfully, but attempts to boot CoreELEC from a USB drive hang on the Amlogic bootlogo. Upgraded back to Android 14, CoreELEC booted successfully too.
Is there anything I could try to make it work with Android 11 firmware, other than disassemble and attach to UART to figure out what’s wrong?
The UART output ends with “Bl2_early_platform_setup”, which, I guess, won’t surprise anyone.
Looks like I’m stuck with running from a USB stick. If anyone has an older Android 11 firmware image that supports booting from USB, please let me know (1.3.6/1.3.8/1.4.0 did not work for me). Or, if anyone could at least roughly outline the procedure for manual eMMC installation, that would be very helpful as well. I suppose ceemmc sources would be a good source of information 
I don’t need much, just want to single-boot CoreELEC from eMMC.
Tried experimenting a bit further: flashed 2.0.5 firmware (Android 14), then flashed entire 1.4.0 (Android 11), except for the bootloader partition. USB boot starts working, but ceemmc fails the same way as with Android 14. Any tips in the right direction are appreciated.
I don’t think installing to eMMC works anymore with latest devices and SoCs .
I’ve seen people on this forum confirming that single-boot installation worked on the same SK1. I wonder what’s different about my box…
Did you try to flash the slimbox firmware onto your SK1? It is Android 11.
I did, unfortunately could not boot from USB with that firmware as well.
So for current system correlec is ugoos am6(b)plus as best device ?
System without vulkan for newers socs dont know acces to framebuffer as “object”?
In graphics programming, a framebuffer is still the essential destination where pixels are stored before they hit your screen. However, Vulkan treats it very differently compared to older APIs like OpenGL.
1. The Framebuffer as an Explicit Object
In older APIs, you often had a “default framebuffer” provided by the system. In Vulkan, a VkFramebuffer is an explicit object you must create yourself.
-
It acts as a link between your Images (the actual memory buffers) and the Render Pass (the instructions on how to draw).
-
You usually create a separate framebuffer for every image in your swapchain.
2. The Swapchain: The Real Shift
What often feels like a “replacement” in Vulkan is the Swapchain.
-
In OpenGL: The driver handled the switching between the “front buffer” (what you see) and the “back buffer” (what is being drawn) automatically.
-
In Vulkan: You must manually manage the Swapchain. The Swapchain is essentially a collection of framebuffers that take turns being presented to the monitor.
3. Separation of Concerns
Vulkan splits the concept of “where we draw” into three distinct parts:
-
VkImage: The actual raw memory holding the pixels.
-
VkImageView: A wrapper that describes how to look at that memory (e.g., as a 2D texture).
-
VkFramebuffer: The object that binds these views together so the GPU knows which attachments (Color, Depth, Stencil) to use during a specific drawing operation.
What exactly has this post above to do with this SoC? There is no Vulcan for Kodi(CE).
Looks like ChatGPT to me.
Yes, is it chatgpt output. I asked on changes of acces ti framebuffer between opengl snd vulcan. Somebody wrote about slower gui in kodi due to missing a support of framebuffer for s928x and newers SOCs. Maybe newer SOCs are designed primary for using of vulcan.
The issue is with vsync and screen tearing, not a slow gui. I’ve been looking into this and looking at Kodi’s source code here:-
Kodi should write to the log with information on weather or not vsync is enabled, however these lines never appear in the log leading me to believe Kodi never attempts to set vsync enabled.
True, this is the case with FBDEV. Not sure why not with GBM.
The problem looks like this change: AML Windowing: add support of GBM mali interface · CoreELEC/xbmc@374b4b2 · GitHub
The override of PresentRender was implemented so CRenderSystemGLES::PresentRender what do include SetVSync(true) is not called anymore.
so this might solve the issue?
diff --git a/xbmc/windowing/amlogic/WinSystemAmlogicGLESContext.cpp b/xbmc/windowing/amlogic/WinSystemAmlogicGLESContext.cpp
index 27c7895fdb..a87e1248c4 100644
--- a/xbmc/windowing/amlogic/WinSystemAmlogicGLESContext.cpp
+++ b/xbmc/windowing/amlogic/WinSystemAmlogicGLESContext.cpp
@@ -260,6 +260,7 @@ void CWinSystemAmlogicGLESContext::SetVSyncImpl(bool enable)
void CWinSystemAmlogicGLESContext::PresentRender(bool rendered, bool videoLayer)
{
+ SetVSync(true);
if (rendered || (videoLayer && m_amlGBMUtils))
{
#if defined(EGL_ANDROID_native_fence_sync) && defined(EGL_KHR_fence_sync)
0001-WinSystemAmlogicGLESContext-fix-missing-VSYNC-enable.patch (932 Bytes)
1 Like