Stuck in MUOS logo after installing

Issues 2508 Goose
,
13

This has hopefully been fixed now that I finally managed to get my hands on a device that actually showed the problem. The solution is in place, but because it changes internal backend scripts, it will require a full re-flash once final testing is complete.

The good news is that this was never a bug in muOS itself (sort of) as it comes down to how the hardware queues the Wi-Fi device behind the SDIO controller.

Yes, you read that correctly…

Why it was happening?

  • The Wi-Fi chip (rtl8821cs) isn’t a simple PCIe or USB dedicated device. On these H700 boards it is exposed as an SDIO device on mmc2.
  • SDIO is bus-based, so the Wi-Fi chip has to wait in line with other SDIO transactions. If the system tries to probe it before storage and the SDIO host are fully settled, the chip just never shows up.
  • This explains why some units booted fine while others hung. It was pure timing and race conditions inside the SDIO up sequence.

Kernel information

The kernel logs thankfully backed this up. The MMC/SDIO host driver would repeatedly print messages like:

sunxi-mmc sdc1: Has wait r1 rdy ... (CMD53)

That line is the driver telling us that it’s waiting for the device to clear busy (r1 ready) before or during a CMD53 transfer. CMD53 being the SDIO multi-byte extended I/O command used for transactions and thus used by Wi-Fi traffic from what I can gather on the information superhighway…

Normally you might see a handful of these lines while the 8821cs firmware is loaded. But if it spams dmesg log output, it means the bus is being held busy or timing margins are too tight, which in turn stalls initialisation.

Technical notes

  • 8821cs init is super chatty… The chip seemingly hammers the bus with CMD52/53 reads/writes during firmware load, which easily triggers these waits.
  • Certain kernels often add explicit wait for R1 ready logic for SDIO, so these waits are expected… just not in bulk
  • It becomes a problem when you see hundreds of these per second, unexpected rising CPU usage, or additional messages like timeout waiting for hardware interrupt or data error, sending stop, then the controller and the Wi-Fi device are fighting.

Okay, cool, the fix?

To address this, I have done the following…

  • Split network module loading away from the general module initialisation.
  • Added an explicit SDIO wait before touching the Wi-Fi chip.
  • Delayed device specific modules until after storage mounts are complete.
  • Made module.sh load-network run exactly at network init and never earlier.

This ensures the SDIO bus has finished bringing up storage before we even look at Wi-Fi.

What this means for you

If you were unlucky and hit the first init, or general, boot hang this is hopefully the root cause. The fix is already in testing, but will require a re-flash of your device once finalised.

So yes… It technically wasn’t gremlins in MustardOS. It was the Wi-Fi chip sitting in a queue behind SDIO, waving its hand for attention and never getting it.

7 Likes