TKS. no problem with usb? I have the AM9 Pro and usb cannot be used for CE
SK4 boots from USB perfectly
Thanks again. Will try.
Is there any difference between sk4 and sk4 pro in terms of codecs or hdr format support or I could buy the usual sk4 and itâll be fine?
Is there any chance you managed to look at my logs? If you could I would really appreciate it. Any pointers or ideas on how to fix would be amazing.
If you want to see any other logs, with the Homatics working etc just let me know.
Sorry for the lack of communication, I have been away on holiday. I just tried the latest nightly and have the same issues. Can anybody take a look at this problem as it doesnât look like it is going away? Happy to supply fresh logs if needed.
No idea what your original problem was, as the post appears to be deleted. Some issue with HDMI passthrough audio? All formats or just some?
The system crashes when playing HD audio files. It actually loses network connection which is odd, the old posts are still there from around a month ago. Initial responses were that it must be my set up as itâs working for other people, which I thought sounded right and just wanted some help tracking the issue down, but at this point I donât believe it is as I have tried:
ORIGINAL CABLES
Homatics CE NE21 > Soundbar > TV 
Homatics CE NE21 > TV > Soundbar
Homatics CE N022 > Soundbar > TV
Homatics CE N022 > TV > Soundbar
Homatics Android Kodi > Soundbar > TV
Homatics Android Kodi > TV > Soundbar
SK4 CE N022 > Soundbar > TV 
SK4 CE N022 > TV > Soundbar
SK4 Android Kodi > Soundbar > TV
SK4 Android Kodi > TV > Soundbar
Then the cables were said to be the problem and I bought 2 new sets, different brands, and ran the same set ups and got the same results. It is ONLY CE22 on the SK4 that has the problem so I am now convinced it is NOT a problem with my set up. I have posted multiple logs for various setups as per the above to demonstrate the issue and the other setups not having any problems.
Sometimes logs not show anything and only real test do.
I understand.
Is there anything more I can do then to assist you guys in being able to diagnose the problem? If not then I have a box here of zero use to me, so would happily post it to you if that would enable you to tinker and have a look yourself? I am happy to do whatever it takes to help.
Thanks for the response.
@vpeter did you see my message above? Can you let me know if there is anything more I can do please.
in case it helps anyone else, after buying and returning multiple other ethernet+hub options i finally got one that works (over usb-c, not testing it on the usb-a since itd be worse than wifi):
BENFEI USB-C to Gigabit Ethernet Adapter with 3-Port USB 3.0 Hub, RJ45 Network Adapter Compatible with MacBook Pro/Air, iPad Pro, iMac, Galaxy S23, XPS 17, Surface Book 3
amazon dot com/dp/B0DC75R8FV
ethtool and my router both list it as 1000Mb/s and i tested with my biggest (just 50gb) movie and no issues, wireless kb plugged into the hub part also works fine.
tested and didnât work were ones by ugreen and wavlink (both surprising and disappointing).
Iâve seen that USB-C support was added. So far Iâve been unable to boot from a USB-C drive, but looking at the commit, this support is only for storage drives added, and it canât boot the OS. Is that correct?
Cold boot hangs at U-Boot logo with a >2TB GPT USB drive attached (unrelated to eMMC install)
Wanted to document a separate issue in case it saves someone else the debugging time â this is not related to the eMMC-install topic I posted earlier (though I found it while my SK4 was moving media around post-install), and reproduces independent of that: happens with the stock USB-boot setup too, not just an eMMC-booted device.
Symptom: with a 3TB USB drive attached at power-on (formatted GPT + ext4), the box hangs at the U-Boot/Amlogic boot logo and never reaches Kodi. A 2TB USB drive attached at the same time causes no problem. Confirmed itâs not about which device provides the actual boot media â the hang happens even with a known-good CoreELEC boot USB stick also plugged in simultaneously, so itâs not a âwrong device selected for cfgloadâ issue, itâs something earlier in the boot-time USB enumeration itself.
Best working theory: bootcmd runs usb start / usb storage on every boot to sweep for boot media, regardless of where CoreELEC actually lives (SD, USB, or eMMC). That sweep appears to touch every attached deviceâs partition table to build its device list. 2^32 sectors times 512 bytes is about 2.2TB â the classic 32-bit LBA boundary. The 3TB drive was previously ExFAT (almost certainly MBR-partitioned, which canât even describe a partition past ~2TiB â so U-Boot never saw the true extent). Reformatting it GPT+ext4 exposed the driveâs real ~2.79TiB size via 64-bit LBA fields for the first time, and something in U-Bootâs storage-scanning code doesnât handle that cleanly. The 2TB drive stays under the boundary regardless of partition table type, so it was never going to trigger this.
I donât have serial/UART console access to confirm exactly where in U-Boot itâs stuck, so this is a strong hypothesis backed by the boot-order-doesnât-matter test, not a confirmed root cause. If anyone has a >2TB USB drive and can test whether reformatting it MBR (capped under 2TiB) vs GPT changes whether it hangs at boot, that would nail it down further.
Workaround: donât have the >2TB drive attached at power-on; hot-plug it once CoreELEC is up â Linuxâs own USB/GPT handling has no issue with it at runtime, only U-Bootâs boot-time scan does.
USB-C SuperSpeed never links up on SK4 â found the likely device-tree gap vs stock Android
Spent an evening chasing what looked like a hub/power/cable problem with a USB3 drive on the USB-C port, and it turned out to be neither. Documenting the methodology and the finding in case it helps whoever maintains the SK4 device tree.
Symptom: nothing ever links up as SuperSpeed on the USB-C port. Depending on the specific device and moment, it either fails to power up cleanly (host never even logs a connect event) or falls back and enumerates as USB2 âhigh-speedâ â never SuperSpeed. Ruled out hub-specific and device-specific causes by testing two different USB devices (a 3TB drive and a USB ethernet adapter) across two different hubs â failures tracked the SK4âs own port across every combination, not the hub or the downstream device.
Kernel log at boot has this, for both of the SoCâs USB3 PHY instances, before anything is even plugged in:
amlogic-crg-drd-usb3 fe358080.usbphy30: This phy has no usb port
amlogic-crg-drd-usb3 fe348080.usbphy31: This phy has no usb port
Pulled the stock Android device tree off this same unit (itâs still sitting untouched in the vendor_boot_a partition â ce-emmc-install.sh never touches it) and diffed the relevant node against CoreELECâs s7d_s905x5m_ugoos_sk4.dtb. The crgotg@fe358000 node â the controller for the USB-C combo port â differs like this:
Stock Android:
udc-name = â0xfe350000.crgudcâ;
dr_mode = âotgâ;
usb-role-switch;
role-switch-default-mode = âhostâ;
CoreELEC:
udc-name = â0xfe350000.crgudcâ;
controller-type = <0x01>;
dr_mode, usb-role-switch, and role-switch-default-mode = âhostâ are missing entirely in the CoreELEC tree, replaced with a controller-type property that isnât part of this binding. Those three properties are what tell the kernelâs USB role-switch framework to bring the port up in full dual-role/host mode â without them a limited fallback (USB2-only, or an incompletely-initialized SuperSpeed PHY) is consistent with everything observed. Everything else â the PHY node definitions themselves, the phandle wiring from the host controllers to their USB3 PHYs â is structurally identical between stock and CoreELEC, so this doesnât look like a hardware limitation.
This is a strong hypothesis backed by a concrete stock-vs-CoreELEC diff, not a confirmed fix â I havenât tried adding those properties back and testing, and Iâd flag some caution for whoever does: this same port is the USB-C OTG port used for Amlogic USB Burning Tool recovery, so changes to dr_mode/role-switch behavior are worth testing by someone with a way to recover if it goes sideways (I donât have serial/UART console access on this unit to debug a bad change).
coreelec doesnât support UAS in the kernel for the s905x5m the last time I was looking into this
quick reply to the UAS comment above - thatâs actually a different layer to what I found. UAS vs usb-storage is just the transport protocol once a device is connected, doesnât affect whether the PHY negotiates SuperSpeed vs USB2 in the first place. what Iâm describing below is upstream of that - the link never goes SuperSpeed at all regardless of storage protocol. still useful to know if thereâs other USB3 gaps on this chip though.
anyway, tried the actual fix. found the driver source (phy-aml-crg-drd-usb3.c in CoreELEC/common_drivers). portnum on usbphy30/usbphy31 gates a whole block in probe() - clocks, resets, PCIe-to-usb3 phy mux - behind âif (portnum > 0)â. both phys ship with portnum=0 in our tree, same in stock android and coreelec, so that block never runs and the phy stays disabled. thatâs the actual cause of the âno usb portâ log line.
found a real working reference in khadas VIM4âs board dts (same driver, T7 chip). they set portnum=1 on their working port, so that partâs confirmed correct. but they only enable ONE of their two combo ports - the other stays at portnum=0 on purpose, paired with a crg-host-drd-only controller. our board has the same split: usbphy30 pairs with crg-drd + the crgotg role-switch node (the real external port), usbphy31 pairs with crg-host-drd only. so only usbphy30 should need touching.
also found the phy-pcie-reg value the driver needs for the mux (0xfe02a000, size 0x2000) - missing from our tree entirely, but confirmed against this exact deviceâs own pcie node, and matches what T7 uses for the same register.
tested on a spare USB stick, not the eMMC:
- portnum=1 on both phys - boot loop
-
- portnum=1 + correct phy-pcie-reg on usbphy30 only, usbphy31 untouched - boot loop, same as before
- two different, reasoned attempts, same failure both times. at that point I donât think itâs a DT property problem anymore - looks more like the PCIe/usb3 phy mux this code path runs just doesnât have real hardware behind it on this board, even though the chip supports the concept in general. forcing it seems to hang hard enough to trip a watchdog reset, regardless of which values get fed in.
calling it here unless someoneâs got a serial console on one of these to see exactly where it hangs, or actual S7D bring-up docs. usb2 on the port works fine in the meantime.
Hello! Somewhere around August 10th, it started to freeze hard immediately after loading when connected Type ĐĄ USB-Ethernet Adapter.