Homatics Box R 4K Plus

Help & Support Hardware
6391

Stick with whatever build serves your purposes best, if that’s NG21.3 use that. But remember that NG development has ended and there won’t be any further updates, fixes or official support for problems you might encounter. All efforts are on CE-NO22. It’s just not possible maintain multiple branches and support for +50 devices by 2 or 3 people working for free.

6392

I’ve tried it, same result as before.

Reset button method:
Fast Recovery Screen > USB Burning > Recovery options screen > Reboot straight to ATV.

Using the APK First Boot option:
Reboots to the first load screen (homatics logo > animation > androidtv logo/loading > ATV).

Normal boot goes straight to the Recovery options screen.

I’ve noticed that in all previous and this new image, the files changes asap I plug my usb on the box. It gets populated with the standard ATV folders (Android, DCIM, etc) + the files that was already there.

File list right after Rufus flashing:
device_tree
aml_autoscript
cfgload
cfgload_env
config.ini
dtb.img (copied from device tree)
kernel.img
kernel.img.md5
recovery.img
SYSTEM
SYSTEM.md5

Thanks again for trying to help me.

6393

Other SD card? Pendrive?
USB2 or USB3 port?

6394

I only have this one usb drive.
Does not work on box USB3.0, only 2.0 recognizes it.

I have an SD and USB adapter, should I try it?

6395

Yes. I have an other box, it is working well with a µSD card and a Ugreen adapter

6396

I think the issue might be my pendrive.

With the microSD card (2gb only) it booted using the Boot to CoreELEC apk.

It runned a few commands, restarted and seems to be stuck on the CoreELEC logo screen.

:confused:

6397

I completely understand and respect that, sir. In the end, I’m sticking with nightly 22; despite the occasional kernel panic, it works great and handles large DV FEL 7 remuxes more smoothly. Since the restarts don’t happen every day, there’s no reason to go back to an older version. Thank you for your work.

6398

Intermittent USB 3.0/UAS I/O failure and read-only storage on Homatics R 4K Plus with CoreELEC 22 nightly

Hello again,

I am experiencing an intermittent USB 3.0 storage/boot failure on a Dune/Homatics Box R 4K Plus running CoreELEC 22.

System information:

  • CoreELEC 22.0-Piers nightly 20260730 (Amlogic-no.aarch64)

  • Linux kernel 5.15.196

  • Device: Dune/Homatics R 4K Plus

  • CoreELEC dt-id: sc2_s905x4_sei_smb_280_id5

  • Amlogic dt-id: sc2_s905x4_ah212-id5

  • Storage: Verbatim Portable SSD Slim 256 GB

  • USB VID:PID: 18a5:0468

  • The SSD is connected directly to the blue USB 3.0 port of the Homatics. No external USB hub is being used.

Symptoms:

After a longer period between starts, CoreELEC occasionally takes much longer to boot. On one occurrence, I saw a large console/filesystem-check-like screen containing many read/write messages.

On a later failed boot, the Homatics logo did not repeat. Only the CoreELEC logo kept flashing/looping and Kodi did not start properly.

The SSD was initially detected normally as a SuperSpeed USB device using UAS:

  • scsi host0: uas

  • Both sda1 and sda2 were detected

  • /storage was initially mounted as EXT4

  • The initial filesystem check reported the storage as clean

At approximately 8.9 seconds, multiple commands started failing with:

  • hostbyte=DID_ERROR

  • Sense Key: Aborted Command

  • Data phase error

  • blk_update_request: I/O error

There were errors on both partitions:

  • SQUASHFS read errors on the CoreELEC system partition

  • EXT4/JBD2 and Buffer I/O errors on /storage

At approximately 42 seconds, the kernel attempted a UAS device reset:

  • uas_eh_device_reset_handler start

  • reset SuperSpeed USB device number 2 using xhci-hcd-meson

  • uas_eh_device_reset_handler success

After that, /storage was remounted read-only and the EXT4 journal was reported as aborted.

Anonymized failed-boot log:

https://paste.coreelec.org/AirheadBarbie

I then completely disconnected the Homatics from power and connected it again. I did not change the SSD or USB port. CoreELEC booted immediately and normally from the same USB 3.0 port, without the read/write screen.

After this successful boot:

  • /storage was mounted as rw,noatime

  • EXT4 recovered the journal left by the failed boot

  • No USB resets, UAS errors or I/O errors appeared

Anonymized successful-boot log after the power cycle:

https://paste.coreelec.org/QumarGotcha

The 1a40:0101 USB2.0 HUB visible in the complete USB topology is not an external hub. It appears to be an internal part of the Homatics USB topology. The SSD itself is enumerated separately and directly as usb 2-1 on the SuperSpeed root port.

I did not observe this kind of USB 3.0/UAS failure when using CoreELEC NG 21.3. The problem appeared with CoreELEC NO 22. I have also encountered USB 3.0 boot/detection instability with more than one SSD on this Homatics, although one older Verbatim Vx500 may have a separate hardware/overheating problem.

Could this be a regression or compatibility issue involving UAS, xhci-hcd-meson, power management or the Homatics USB 3.0 controller in CoreELEC NO 22?

I can test an UAS blacklist/USB-storage quirk, another nightly build or additional diagnostic commands if required. Please let me know which additional anonymized logs would be useful.

Thank you.

6399

My first guess is that the SSD isn’t stable because of insufficient power. SSD/USB flash drive read/write rates are potentially much faster in CE-NO compared to CE-NG. I’ve gotten 100-150MB/s read speeds in CE-NG, compared to ~300MB/s in CE-NO with the same media. That higher throughput requires more power and stability.

Use a powered USB hub that supports USB3 and can output 0.9A (4.5W). Also try a couple different high-quality USB cables. Try a secondary powered USB hub if you need. Are there less crashes/bootup issues with a powered USB hub than when plugging directly into the 4K Plus port?

6400

I too get nothing but Fast Recovery Screen > USB Burning > Recovery options screen … over and over using this (latest nightly): CoreELEC-Amlogic-no.aarch64-22.0-Piers_nightly_20260806-Generic.img

Should it? I haven’t tried CoreElec on a Homatics in over a year, but the USB drives that used to work no longer work.

The Homatics was updated in January (security wise at least), is it possible that the update has caused problems? Am I using the correct image?

INFO:

Images tried:

CoreELEC-Amlogic-ng.arm-21.3-Omega-Generic.img

CoreELEC-Amlogic-no.aarch64-22.0-Piers_nightly_20260806-Generic.img

Homatics info:

Android TV OS security patch level: January 5, 2026

KV: 5.15.170-android14-11

ATV: UKG3.250803.001.7475

Box R 4K Plus SW Version: v14.8.7475

Result is nothing but Fast Recovery Screen > USB Burning > Recovery options screen … over and over. I do see the indicator led on USB drives flash for ~3 seconds when it states USB burning, so it seemingly is looking at it for a few seconds. Considering the 21.x branch used to work I’m thinking it is a Homatics problem, so is there a way to boot this image from the recovery menu that is somehow different than holding down the reset button?

6401

Thank you. That could explain why the issue occurs with CE-NO but never occurred with CE-NG: the higher transfer speed in NO may expose marginal USB power stability.

The failed log I posted was captured with the Verbatim SSD connected directly to the blue USB 3.0 port of the Homatics, without any external hub.

I already own an AXAGON HUE-S2BP powered USB 3.0 hub with a supplied 5 V / 2 A power adapter. I tested it previously, but it did not clearly improve reliability. CoreELEC sometimes failed to boot through the hub, although it did boot successfully on at least one attempt.

More importantly, this hub appears to back-feed power into the Homatics through its upstream USB connection. If the hub power supply remains connected and I unplug the Homatics power adapter, a USB fan connected to the Homatics continues spinning. Because of this, I stopped using the powered hub.

Therefore, I cannot say that I experienced fewer crashes or boot problems with the powered hub than with a direct connection. Direct USB 3.0 operation was stable for me on CE-NG 21.3, while the intermittent failures appeared with CE-NO 22. However, your explanation about the considerably higher SSD throughput in NO could account for that difference.

I have already tested multiple different USB 3.0 cables, including good-quality cables, and the behavior remained the same. Therefore, the cable itself is very unlikely to be the cause.

Would you consider my existing hub unsuitable because of the back-feeding? Should I test a different powered USB 3.0 hub with proper upstream power isolation, or would disabling UAS and forcing “usb-storage” be a useful diagnostic test to distinguish a power issue from a UAS/xHCI problem?

I can provide additional anonymized logs or perform other diagnostic tests if needed.

6402

Update: failure reproduced with a complete pstore kernel panic log

I reproduced the problem again, this time on:

- CoreELEC 22.0-Piers nightly 20260806

- Linux 5.15.196

- Dune/Homatics R 4K Plus

- Verbatim Portable SSD Slim 256 GB

- SSD connected directly to the Homatics USB 3.0 port

- UAS active at 5000M

- No external USB hub

I have already tested different USB cables and the behaviour remained unchanged.

During this boot, the animated CoreELEC logo kept spinning and SSH never became available. A console screen containing a kernel panic then appeared, the device rebooted automatically, and CoreELEC successfully started on the next attempt.

The pstore log shows the following sequence:

- At 3.979 seconds, the EXT4 storage partition was mounted.

- At 4.148 seconds, many parallel UAS commands failed simultaneously with:

  • “hostbyte=DID_ERROR”

  • “Sense Key: Aborted Command”

  • “Data phase error”

  • “blk_update_request: I/O error”

- SQUASHFS reads from the CoreELEC system partition then started failing.

- Starting at approximately 37 seconds, multiple UAS commands remained stuck.

- The kernel repeatedly performed “uas_eh_device_reset_handler” and SuperSpeed USB resets at roughly 30-second intervals.

- The resets were reported as successful, but subsequent reads continued to fail.

- At approximately 249 seconds, further SQUASHFS and EXT4 read errors occurred.

- Because the system image could no longer be read, PID 1 (“busybox init”) exited.

- At 250.333 seconds, the kernel panicked with:

“Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100”

The panic therefore appears to be a consequence of losing access to the boot SSD, rather than an independent kernel crash.

Anonymized full pstore dmesg:

https://paste.coreelec.org/BoozeOught

Anonymized console ramoops containing the panic trace:

https://paste.coreelec.org/StinkingSheldon

For comparison, the previous occurrence showed the same type of UAS “Data phase error” and I/O failures:

https://paste.coreelec.org/AirheadBarbie

The subsequent successful boot after fully removing power was:

https://paste.coreelec.org/QumarGotcha

After the automatic reboot from the latest panic, the same SSD mounted successfully as “rw,noatime” and is again detected as:

“Driver=uas, 5000M”

There are no “Medium Error” or “Unrecovered read error” messages indicating a permanent NAND/media failure. The failures occur across multiple unrelated sectors and both partitions simultaneously.

Could insufficient USB power still produce this exact pattern without a USB disconnect, enumeration failure, or errors such as “-71”/“-110”? Or does the simultaneous failure of many queued UAS commands and the repeated UAS resets point more strongly to a UAS/xHCI compatibility problem or regression?

Would it be appropriate to test this SSD with UAS disabled using the following per-device quirk?

“usb-storage.quirks=18a5:0468:u”

If so, could you please confirm where this kernel parameter should be added for CoreELEC NO on the Homatics R 4K Plus?

Until this is clarified, I will avoid booting this SSD through USB 3.0/UAS and use USB 2.0 instead.

6403

Title: Homatics R 4K Plus: CE-NO 22 UAS I/O failures and kernel panic; the same SSD is stable on CE-NG 21.3 using usb-storage

Hi,

I would like to add a direct comparison between CoreELEC-NO 22 and CoreELEC-NG 21.3 using the same Homatics box, SSD and USB 3.0 port.

Test setup

  • Device: Dune/Homatics R 4K Plus

  • SSD: Verbatim Portable SSD Slim 256 GB

  • USB VID:PID: 18a5:0468

  • SSD connected directly to the blue USB 3.0 port

  • No external USB hub

  • Multiple cables have been tested, with no change in behaviour

  • Same Homatics power supply and USB port were used

  • SSD temperature was approximately 43°C even after several formatting operations, so there is no current indication of SSD overheating

Direct comparison

CoreELEC-NG 21.3 CoreELEC-NO 22
Version 21.3-Omega official 22.0-Piers nightly 20260806
Kernel 4.9.269 5.15.196
USB host driver xhci-hcd xhci-hcd-meson
Storage driver usb-storage uas
USB link speed 5000M 5000M
Result Stable Repeated I/O failures and kernel panic

CoreELEC-NO 22 behaviour

With NO 22, the SSD is bound to UAS:

scsi host0: uas
new SuperSpeed USB device using xhci-hcd-meson

During the latest failed boot:

  1. The SSD was detected and /storage was mounted normally.

  2. At approximately 4.15 seconds, many concurrent read commands started failing with:

hostbyte=DID_ERROR
Sense Key: Aborted Command
Data phase error
blk_update_request: I/O error
  1. The errors affected both partitions simultaneously:

  • SQUASHFS errors on the CoreELEC system partition

  • EXT4 errors on /storage

  1. UAS repeatedly attempted to abort commands and reset the SSD:
uas_eh_abort_handler
uas_eh_device_reset_handler start
reset SuperSpeed USB device using xhci-hcd-meson
uas_eh_device_reset_handler success

Although the resets were reported as successful, the failures continued.

  1. After approximately 250 seconds, PID 1 could no longer read the system files and the system ended with:
Kernel panic - not syncing: Attempted to kill init!

Sanitised latest failure and panic timeline:

NO 22 recurring UAS failure and kernel panic

Sanitised console panic trace:

NO 22 console-ramoops panic trace

This was not the first occurrence. An earlier NO 22 nightly also produced DID_ERROR, Data phase error, SQUASHFS errors, EXT4/JBD2 failures and a UAS device reset. /storage was subsequently remounted read-only.

Earlier NO 22 failed boot

After completely disconnecting the Homatics from power, the same SSD sometimes boots normally through the same USB 3.0 port and UAS. During one such successful boot, EXT4 recovered the interrupted journal and no new I/O or UAS errors appeared.

Successful NO 22 boot after a complete power cycle

The problem is therefore intermittent, but it has now occurred repeatedly on NO 22.

CoreELEC-NG 21.3 behaviour

I then tested CoreELEC-NG 21.3 with the same SSD connected directly to the same USB 3.0 port.

NG 21.3 binds the SSD to the traditional usb-storage Bulk-Only Transport driver instead of UAS:

Class=Mass Storage, Driver=usb-storage, 5000M

/storage was mounted normally as read/write:

/dev/sda2 on /storage type ext4 (rw,noatime,data=ordered)

NG 21.3 system, USB topology and storage log

The following tests were then completed without any storage errors:

After these tests, the filtered kernel log contained no DID_ERROR, Data phase error, I/O error, EXT4/JBD2 error, UAS reset or SuperSpeed reset. The only matching line is the normal SQUASHFS driver version message.

NG 21.3 post-test error check

As an additional network sanity check, downloads reached approximately 337 and 311 Mb/s:

NG 21.3 network test

I also tried booting from the black USB 2.0 port, including a full power disconnection and a freshly written installation, but this SSD did not boot from that port. Therefore, USB 2.0 is not a usable workaround on this box. NG 21.3 already demonstrates stable usb-storage operation at USB 3.0 SuperSpeed.

Interpretation

This comparison appears to make defective NAND or an ordinary filesystem problem unlikely:

  • The same physical SSD completes sustained reads and writes on NG 21.3 without a single transport error.

  • NO 22 failures begin during early boot, before Kodi starts.

  • Multiple unrelated sectors and both partitions fail simultaneously.

  • The reported errors are Data phase error, DID_ERROR and UAS command/reset failures, rather than persistent Medium Error or Unrecovered read error.

  • The most important transport difference is that NG 21.3 uses usb-storage, while NO 22 uses UAS.

A general power problem cannot be excluded with absolute certainty because UAS can queue several commands simultaneously, while Bulk-Only Transport serialises them. Nevertheless, the stable high-throughput NG results and the version-dependent driver change make a NO 22 UAS/xHCI compatibility problem, power-management regression or missing device quirk much more likely than a defective SSD or cable.

Could you please check:

  1. Should USB device 18a5:0468 have an IGNORE_UAS quirk on Amlogic-NO?

  2. Is it expected that NG 21.3 binds this device to usb-storage, while NO 22 binds it to uas?

  3. Could this be a regression involving UAS, xhci-hcd-meson, command queue handling or USB power management on the S905X4 Homatics?

  4. Would you like me to test NO 22 with an equivalent of:

usb-storage.quirks=18a5:0468:u

If so, please provide the recommended CoreELEC method or a test image, because I do not want to apply the parameter incorrectly.

All linked logs have been sanitised and checked for serial numbers, MAC addresses, IP addresses, UUIDs, androidboot values and the kernel command line.

Thank you.

6404

Your analysis seems reasonable, perhaps that SSD USB bridge doesn’t play well with the UAS driver. Try adding the USB quirk to the kernel cmdline to ignore UAS for that device.

To do this edit config.ini on the CoreELEC partition (aka /flash). At the bottom of config.ini modify the line

# coreelec='quiet'

to

coreelec='debugging ignore_loglevel=1 usb-storage.quirks=18a5:0468:u'

When CE boots, verify that usb-storage.quirks=18a5:0468:u appears in the kernel cmdline at the beginning of dmesg.

6405

Thank you, sir. I added the suggested quirk to config.ini on CoreELEC 22 nightly 20260806:

coreelec='debugging ignore_loglevel=1 usb-storage.quirks=18a5:0468:u'

After booting, I verified that the parameter is present in the active kernel command line:

usb-storage.quirks=18a5:0468:u

lsusb -t now reports:

Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd-meson/1p, 5000M
    |__ Port 001: Dev 002, If 0, Class=Mass Storage, Driver=usb-storage, 5000M

Therefore, the same Verbatim SSD is still connected directly to the Homatics USB 3.0 SuperSpeed port at 5000M, but it is now using usb-storage instead of UAS.

The first boot completed normally. The following check currently returns no errors:

dmesg | grep -Ei "DID_ERROR|Data phase|I/O error|Buffer I/O|SQUASHFS|EXT4-fs error|JBD2|uas_eh|reset SuperSpeed"

This now matches the behaviour under CoreELEC NG 21.3, where the same SSD also used usb-storage at 5000M and did not experience these errors.

I will test several normal reboots, cold boots and longer operation and report back if the I/O errors or kernel panic return. So far, the workaround looks promising.

Thank you for the help.