I’m experiencing an extremely stubborn infinite boot loop when trying to boot CoreELEC from a USB drive on my Homatics Box R 4K Plus after a recent OTA update to Android 14. I’ve exhausted all standard and advanced troubleshooting steps, so I’m hoping to get some insights from the community.
1. Environment & Core Symptoms
Device: Homatics Box R 4K Plus (Amlogic S905X4-K)
Current Android OS: Android 14 (Firmware Build: UKG3.241022.001)
(Note: Interestingly, in Android Recovery, the system fingerprint displays RockTek/SEI804RT/YYJ. I’m not sure if SEI Robotics merged the firmware branches recently.)
CoreELEC Versions Tested:Amlogic-ne 21.3-Omega (Stable) and the latest 21.3-Omega nightly.
DTB Configuration: Placed sc2_s905x4_sei_smb_280.dtb in the root directory and strictly renamed it to dtb.img.
The Issue: * Whenever the prepared USB drive is plugged in, triggering the boot process results in an infinite black screen boot loop.
If I unplug the USB drive between the reboot cycles, the box boots perfectly normal into the internal Android 14 OS.
It feels like a Kernel Panic triggering a hardware watchdog reset during the U-Boot to Linux kernel handoff.
2. Troubleshooting Steps Taken (All Failed)
Swapped Physical Media: Ruled out USB controller handshake timeouts. I tested both a high-speed SanDisk 3.2 Gen1 drive and a very old (2011) low-speed USB 2.0 drive (plugged into the USB 2.0 port). The exact same boot loop occurs on both.
Swapped Flashing Tools: Flashed the images using both BalenaEtcher and Rufus (forced “Write in DD Image mode” to ensure absolute physical sector mapping).
Boot Triggers Tested:
Toothpick Method (Reset Button): Seems to be disabled/remapped in this ATV14 firmware. Holding it during power-on just boots directly to Fastboot or Android Recovery, completely ignoring the USB.
ADB Injection: Enabled USB debugging in Android and ran adb reboot update from my PC terminal. The command executes successfully, the box reboots, but still falls into the infinite loop.
Kernel Parameters: Edited config.ini on the USB drive and injected rootdelay=10 into the coreelec= variable, hoping to give the USB bus more initialization time. No effect whatsoever.
3. My Questions
Has the Android 14 bootloader for this SEI board enabled strict AVB 2.0 validation, completely blocking third-party Linux kernel execution from USB/SDIO at the physical/bootloader level?
Aside from buying a male-to-male USB cable to use the Amlogic USB Burning Tool to force flash a downgrade back to Android 12 .img, is there ANY software-level workaround (or a custom recovery flashable zip bypass) to boot CE right now?
What size of USB stick are you using? Only max size of 32gb work dependably. On my similar Nokia 8010 CE 23.2 stable works great from a Sandisk 32GB USB 3.0 in USB 3.0 port on the box.
Image is flashed in standard mode with BalenaEtcher, and installation is initilized via “Reboot_to_CoreELEC_5.0.apk” in Android 14…
I was having the same issue a while ago. However, when I use(d) the boot to Coreelec app in Android 14, it was able to boot from the USB drive. It’s a Samsung 128GB drive, so the bigger ones work but the smaller ones are probably safer to try.
Hi, thanks a lot for the suggestion and sharing your Nokia 8010 setup!
To answer your question: I have tested both a 32GB SanDisk 3.2 Gen1 drive and a much older 16GB USB 2.0 drive specifically to rule out any capacity limits and USB 3.0 controller compatibility issues. Unfortunately, both drives resulted in the exact same infinite boot loop.
It’s really interesting that your Nokia 8010 (which is also a very similar SEI board) works perfectly on Android 14 with the Reboot_to_CoreELEC_5.0.apk. I actually used the same APK (and also tested the native adb reboot update command). The commands do successfully trigger the initial reboot, but the box still panics and loops during the handoff before CoreELEC can mount the filesystem.
Given that your Nokia works, I strongly suspect there might be a strict AVB or bootloader difference implemented specifically in the latest Homatics (or RockTek) Android 14 build (UKG3.241022.001) that isn’t present in the Nokia firmware.
I’m currently trying to get my hands on an Android 12 .img to flash it via the Amlogic USB Burning Tool to see if a bootloader downgrade is the only way out.
Hi, thanks for chiming in! It’s great to hear that a 128GB drive is working for you on Android 14, which definitely helps rule out the drive size as the main culprit.
Could I ask exactly which TV box model you are using?
I ask because I actually did use the “Boot to CoreELEC” app (and also tried the equivalent adb reboot update command via terminal) from within my Android 14 OS. While the app successfully triggers the reboot, my box still falls right into the infinite boot loop before CoreELEC can even start initializing.
It strongly feels like the bootloader on my specific Homatics/RockTek firmware build (UKG3.241022.001) has some strict AVB checks that physically block the handoff, even when triggered correctly by the app.
Would love to know your device model to see if it’s a brand-specific bootloader limitation!
Hi again, just an update: I installed the absolute latest v5.0 of the “Reboot to CoreELEC” app via ADB and hit the “FIRST REBOOT” button.
Unfortunately, the result is exactly the same: an infinite black screen boot loop.
This pretty much confirms our worst suspicion. While your Dune v1 (Android 14) firmware still allows the boot handoff, the specific Homatics/RockTek Android 14 branch (Build: UKG3.241022.001, with the SEI804RT fingerprint in recovery) has strictly locked down the bootloader and AVB. It’s a hard block at the hardware initialization level.
It looks like my only way out of this is to hunt down an Android 12 .img file and use a male-to-male USB cable with the Amlogic USB Burning Tool to physically downgrade the bootloader.
Thanks again for helping me rule out the app version variable! At least now we know for sure it’s an OEM firmware lock.
What is the exact build number of your ATV 14 firmware?
There are several different versions for these boxes, such as v14.8.4576, v14.8.6693 and v14.8.7403.
That last one cannot be found “in public” yet, but apparently has been submitted to Google for certification and is supposed to fix most bugs that were present in earlier builds.
Your Android build number doesn’t tell us all, because it only specifies the base ATV version the firmware is based on.
Hi everyone, I have finally solved the infinite boot loop issue!
I want to give a massive shoutout to a user named Wladislaw Lisowski over on the Russian 4PDA forum. I stumbled upon their conversation here: 4PDA Forum Thread (Post #13865), which provided the exact clues needed to crack this.
Based on that thread, I just did a series of rigorous A/B tests to isolate the root cause on this Android 14 firmware (Build: UKG3.241022.001). Here is the definitive conclusion:
1. The Architecture (ng vs ne) is the ONLY culprit. The Android 14 bootloader on this specific Homatics/RockTek board strictly blocks the ne (New Era) boot handoff, resulting in an immediate Kernel Panic and infinite boot loop. However, the ng (Next Generation) architecture bypasses this restriction perfectly. I flashed the ne image again on the exact same drive just to verify, and the boot loop immediately returned.
2. USB Drive Type DOES NOT matter. The 4PDA thread suggested using an older USB 2.0 drive, but my tests show this is a red herring. I successfully booted the ng build using my high-speed SanDisk 3.2 Gen1 drive. The success was entirely dependent on using the ng image, not the drive speed or capacity.
3. The “Toothpick” Timing (When to release). The most accurate visual cue to release the reset button is the screen itself. You just need to hold the reset button until the initial boot splash screen appears on your TV (indicating it has triggered the USB boot process), and release it immediately at that exact moment.
To anyone stuck in a boot loop with a Homatics/RockTek/Dune on Android 14: Stop trying to use the ne builds and stop trying to PC-flash a downgrade to ATV12. Just burn the CoreELEC-Amlogic-ng.arm-21.3-Omega-Generic.img.gz image, use your regular USB drive, and release the reset button the moment the USB boot screen appears.
CoreELEC is now running flawlessly on my box. Thanks to the community for the pointers!
Hi! Thank you for pointing that out. You are absolutely right about the build numbers.
I just checked my ro.build.fingerprint and my exact ATV 14 firmware build is indeed v14.8.4576.
What makes this incredibly interesting is the context from the Russian 4PDA forum I linked above. In that thread, the user who originally had the exact same infinite boot loop issue explicitly stated they were on build v14.8.6693.
Both of us (on 4576 and 6693) were completely hard-blocked when trying to boot the ne (aarch64) architecture, and both of us could only bypass it by switching to the ng (Next Generation) image.
This confirms that the strict bootloader/AVB restriction against the ne handoff isn’t just an isolated bug in one release, but is actively present across multiple ATV 14 builds for these SEI boards.
It will be very interesting to see if the upcoming v14.8.7403 build you mentioned quietly relaxes this bootloader restriction. But until then, using the ng build seems to be the definitive universal workaround! Thanks again for the technical insight!
Ah ok I missed the part where you said you were using NE. I think NE is kind of EOL anyway and NO is the way forward for Kodi 22 and beyond.
However, most people that run CE on the Homatics use the NG build anyway, because it’s the only one with the older 4.9 kernel that allows decoding of Dolby Vision P7 FEL material.
The issue with NE has nothing to do with bootloader. Seems no one noticed that NE stop working at some point. It is linux kernel or dts issue.
And normally you would use NG or NO anyway.