Stuck in MUOS logo after installing

Issues 2508 Goose
,
1

I try to install goose on my rg40xx v, however after installing it. its stuck on muos logo. I already try flash it into 2 different sdcard (16gb & 64gb). Then I already try flash using (raspberry pi imager and rufus) and redownload the image from mega and gofile. Any idea what should I try to fix this issue? I try to flash pixie just in case something wrong with my device or sdcard and its install and run correctly.

1 Like
2

Hi,

Just tested on a rg35xx-PLUS: it’s stuck on the MuOS logo as well.
Tried to flash twice.

Thank you for you help!

3

I had the same issue had to eject SD2 from my RG40XXV to get it to install. Tested twice to confirm wont install if I had the SD2 card in the console.

4

I can install it but freeze after reboot

5

Having issues booting the 34XX H and SP images for Goose on my 34XX SP, it doesn’t even go into the initial set-up process and just stays in the boot logo.

Weird part is that Pixie for the 34XX H does work perfectly fine on my 34XX SP, so I’m wondering if there’s anything at all different between the Pixie and Goose images in terms of how MuOS handles booting onto devices?

6

Hi everyone, I have the same problem. After install I got the stuck boot logo multiple times. Just rebooting with reset button several times it can boot normally. Even extracting and inserting sd card helps sometimes to not get stuck in booting logo. With pixie the boot process worked fine. For a moment I thought my sd card was corrupted but its not just me

7

RG35XXH, same issue. I’ve tried the Reset button (below the power button) more times than I remember by now.

8

Yep also having this on my RG35XXSP. Installed fine but then get stuck on the boot up this morning and had to do a hard reset.

9

RG35XXH here, can report the same issue, installed fine but it sometimes get stuck on the muos logo upon waking it up, have to use the reset button a lot of times until it managed to boot.

10

Same issue here on the RG-Cube-xx. Got it to boot once and then nothing. I like the logo and all, but I would like to actually play some games.

11

Same issue on rg35xx plus. Back to Pixie using image backup of sd card. I will wait for fix! Thank you for amazing os.

1 Like
12

Same here with my RG40XX-H. Stuck in logo for an hour during installation and had to reset 4-5 times until it started actually installing. Once installed, it gets stuck on boot logo until I reset it 2-3 times. Will have to wait for fix :slight_smile:

Thank you for the amazing OS! Cheers!

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
14

Glad to read that :slight_smile: very interesting stuff indeed, how unexpected behaviors can cause such issues.

Will wait for the fix to be released; thank you very much for the thorough explanation!

15

Awesome to find that issue so quick. I’ll prob wait for update to do my 40V. It will have a new version number once tested and released ?

16

This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.