Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'error -84 whilst initialising SD Card' when attempting to use SDHCI controller on microSD card slot on Raspberry Pi 4B #1896

Open
jeremysalwen opened this issue Jun 6, 2024 · 2 comments

Comments

@jeremysalwen
Copy link

jeremysalwen commented Jun 6, 2024

Describe the bug
The SDHCI controller gives the error "mmc3: error -84 whilst initialising SD card" when it is connected to the microSD Card slot (by using the 0xfe2000d0 bit1 mux). This is robust to changing a variety of other factors, such as the driver, and the microSD card.

To reproduce
The following is the simplest way to reproduce:

  1. Latest raspbian (6.6.31+rpt-rpi-v8)
  2. Modify raspberry-pi-4-b.dtb to set status of mmcnr@fe300000 to "disabled" and mmc@fe300000 to "okay"
  3. From inside initramfs, run devmem 0xfe2000d0 b 0x03

However, I have tested a wide variety of configurations, which I will detail below.

Expected behaviour
SD Card to be detected and appear in /dev/mmcblk*

Actual behaviour
dmesg periodically shows the error "mmc3: error -84 whilst initialising SD card"
Occasionally it will show "mmc3: error -110 whilst initialising SD card"

System
raspinfo: https://pastebin.com/6r7yZG5n

NOTE: the dmesg logs are from a boot where I did not use the mux at 0xfe2000d0, so the mmc3 error I believe is just from the removable mmc@fe300000 talking to the wifi module

Additional context
I have run a variety of experiment to determine if some other factor was causing the issue:

  1. I have tried four different SD cards, which all have the same error.
  2. I have tried both drivers (sdhci-iproc, and mmc-bcm2835), they both give the same error.
  3. I have booted into U-Boot and flipped the mux from inside U-Boot, using mw.b 0xfe2000d0 0x03, before booting linux. This gave the same error.
  4. From inside U-Boot I can read files successfully using SDHCI by running e.g. ls mmc 3:1.
  5. I have disabled the emmc2 node in the device tree this caused mmc3 to no longer be detected at all (??)
  6. I have disabled the GPIO ALT3 functions of pins GPIO34-43 (i.e. disconnecting the SDHCI controller from the wifi). I have also validated that GPIO22-27 and GPIO48-53 were also not connected to the SDHCI. This had no effect.
  7. I have booted linux fully and run busybox devmem 0xfe2000d0 b 0x03, which still generated the same error.
  8. I have tried unplugging/plugging the SD Card, before and after flipping the mux. While the card is unplugged the error stops being logged, but the errors continue when reinserted (error -110 seems more common at the moment of first insertion).
  9. I have tried switching the mux back and forth while an SD card is inserted. When I do so, mmc0 successfully recognizes the card when it is reconnected. I noticed that sometimes at the moment of switching the mux on, i.e. at the moment I connect the SDHCI, I will see in the log:
mmc3: new high speed SDHC card at address aaaa
mmcblk: mmc3:aaaa SU16G 14.8GiB
  mmcblk3: p1 p2
mmcblk3: mmc3:aaaa SU16G 14.8 GiB (quirks 0x00004000)
mmc0: Tuning failed, falling back to fixed sampling clock
mmc0: Tuning failed, falling back to fixed sampling clock
mmc0: Tuning failed, falling back to fixed sampling clock
mmc0: card aaaa removed
mmc3: card aaaa removed

Notice how both mmc0 and mmc3 (i.e. the emmc2 and the SDHCI) log the card being removed. This is the only situation in which I have seen SDHCI recognize the card.
10. I have added broken-cd to the mmc@fe300000 device tree node, which had no effect.
11. I have looked for prior examples of other people successfully using the mux to use the SDHCI controller on the microSD slot online. While I found examples of other people describing how you might do so or attempting to do so, I found no examples of someone successfully doing so. For example here here and here.

Previous related issues: #127 and raspberrypi/documentation#1209 (comment)

@pelwell
Copy link
Contributor

pelwell commented Jun 6, 2024

  1. You haven't said exactly what you have done, except in a vague overview. This makes it hard to spot what you've missed or got wrong.
  2. You haven't said why you want to do this.
  3. This mode of operation is not supported - we might be able to help you, but we are under no obligation to do so.

@jeremysalwen
Copy link
Author

jeremysalwen commented Jun 6, 2024

Specific commands:
I am not sure which area you feel is missing details, I would be happy to provide details on an any step if it is still not clear. I did not want to fill up the issue with the details of how I ran each experiment, since I expect most of them you would consider irrelevant.

  1. I installed the latest raspbian (sudo apt update; sudo apt upgrade)
  2. I decompiled /boot/bcm2711-rpi-4-b.dtb to a dts file, using dtc, edited the dts file to change the enabled/disabled status of the /soc/mmc@fe300000 to okay and /soc/mmcnr@fe300000 to disabled, and recompiled it back to `/boot/bcm2711-rpi-4-b.dtb. This is simply replacing the string "disabled" with "okay" and "okay" with "disabled". No other changes were made to the device tree.
  3. I booted into the busybox shell prompt of my initramfs (/boot/initramfs8, again stock from the latest raspbian). This can be forced a number of ways, e.g. changing the root=PARTUUID= in /boot/cmdline.txt to a different UUID (thus making it fail to find the root fs on boot).
  4. From inside that prompt I ran the command devmem 0xfe2000d0 b 0x03
  5. I observed the dmesg error message 'error -84 whilst initialising SD Card' start appearing, and no mmcblk device appearing in /dev.

Reason for wanting to do this:
The emmc2 driver causes significant EMI at 1200 and 1250 MHz, which causes interference with the L2 band of GPS. The SDHCI driver causes less interference in my tests. I have tried underclocking emmc2 with echo $CLOCK > /sys/kernel/debug/mmc0/clock but found that still did not reduce the EMI much.

Official Support
I understand you cannot debug my specific problem, but any help I could find would be appreciated. Especially any reference to a working example of using this functionality.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants