Open eeucalyptus opened 1 year ago
Another user reported this issue in the 0x64 discord, but it has not been root caused. In that case, the failure was board specific. So likely you didn't do anything wrong, but there is some bug that's causing sdhci init to be non-deterministic.
If you comfortably with a bit of kernel hacking please join us in the #ox64-nutcracker channel at pine64 (https://wiki.pine64.org/wiki/Main_Page#Chat_Platforms)
For anyone who wants to provide your own debug information from your example of this issue, if you flash these binaries with BLDevCube, and then use the normal SD card image, you'll find it starts spewing a whole ton of debug information regarding exactly what the SDHCI controller is doing at any given time, including errors and retries: MMC Debug Binaries.zip
This with a SanDisk Class 2 8GB microSD card and the Kernel 6.2-rc5 release of buildroot. I had similar issues with a 4GB card (can't find it to check the specs) but not with a PNY Elite-X 64GB card. ox64_mmc_debug.txt
I tried out my other boards and turns out I picked the only one of them which has issues with SDs. Here's the logs of all 5. 01 is the one with issues. I labelled the boards, so if you need to test something, just reach out and ask :) I'll look into possible assembly-issues soon, so if something is wrong with the soldering or alike, I will tell you. 2023-01-29_mmc_Ox64_01.log 2023-01-29_mmc_Ox64_02.log 2023-01-29_mmc_Ox64_03.log 2023-01-29_mmc_Ox64_04.log 2023-01-29_mmc_Ox64_05.log
Adding this datapoint. I have 3 boards, 1 has the problems described above. People have reported the SDK works fine on the bad boards getting back to software. I ran U-Boot on the bad board and got an error not seen on the good boards:
U-Boot 2023.04-rc1-g2c940eed61-dirty (Feb 10 2023 - 10:48:57 -0500)
DRAM: 64 MiB
Core: 33 devices, 16 uclasses, devicetree: separate
MMC: mmc@20060000: 0
Loading Environment from <NULL>... OK
In: serial
Out: serial
Err: serial
Net:
Warning: emac@20070000 (eth0) using random MAC address - ae:c1:88:31:99:4f
eth0: emac@20070000
=> mmc part
sdhci_send_command: Timeout for status update!
Which makes me think this is more hardware than software.
Annoyingly, the same U-Boot program only succeeds on 1 of the two boards that have been running buildroot. However the failing board recognizes the device but does nothing with any mmc operation. It does not report the error above.
Little more information. Was using one of my Ox64 boards this evening to test something completely unrelated, and it just stopped working. Was working one moment, removed the SD card to add some more files, reinserted and reset the board and it just started getting IO errors and timing out.
Rewrote my buildroot to the card from scratch, same issue. Tried the card in another board, worked fine.
I am also having this issue but only with one of my SD cards. I am using bl808-linux-pine64_ox64_full_defconfig.tar.gz
version 0.0.5
. The latest release at the time of writing this comment.
The SD card on the left is the problematic one. It was causing the exact same issue. I got that Netac SD card from the Enter 3D printer.
The problem has disappeared when I have put the OS into the Verbatim one. Same OS, same board, different SD card.
I am also having this issue but only with one of my SD cards. I am using
bl808-linux-pine64_ox64_full_defconfig.tar.gz
version0.0.5
. The latest release at the time of writing this comment.The SD card on the left is the problematic one. It was causing the exact same issue. I got that Netac SD card from the Enter 3D printer.
The problem has disappeared when I have put the OS into the Verbatim one. Same OS, same board, different SD card.
Thanks for the info! looks like it is basically impossible to specifically get that Netac card for me, only higher capacity Netac cards. All information like this is helpful though!
I am having a similar issue with a PNY 4GB microSD. Here is the output using the mmc debug binaries and 0.0.5 sdcard image: debug-output.txt
I am also getting these errors (Got data interrupt 0x00000002 even though no data operation was in progress
) on a m1s dock board running the latest release, combined with a 2GB Sandisk MicroSD. I get two of the messages below shortly after after another, repeated approximately every 6 seconds. It appears to be some regular command to retrieve the status form the card (MMC_SEND_STATUS) from what I am able to find.
[ 73.966826] mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
[ 73.967376] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[ 73.967770] mmc0: sdhci: Sys addr: 0x51341040 | Version: 0x00000000
[ 73.968169] mmc0: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000000
[ 73.968567] mmc0: sdhci: Argument: 0xb7db0000 | Trn mode: 0x00000023
[ 73.968965] mmc0: sdhci: Present: 0x01f70000 | Host ctl: 0x00000002
[ 73.969363] mmc0: sdhci: Power: 0x0000000f | Blk gap: 0x00000000
[ 73.969760] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x00000207
[ 73.970157] mmc0: sdhci: Timeout: 0x0000000e | Int stat: 0x00000000
[ 73.970555] mmc0: sdhci: Int enab: 0x02ff008b | Sig enab: 0x02ff008b
[ 73.970953] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[ 73.971350] mmc0: sdhci: Caps: 0x25fc0080 | Caps_1: 0x00002f77
[ 73.971748] mmc0: sdhci: Cmd: 0x00000d1a | Max curr: 0x00000000
[ 73.972145] mmc0: sdhci: Resp[0]: 0x00000e00 | Resp[1]: 0xc93efbcf
[ 73.972543] mmc0: sdhci: Resp[2]: 0x325f5a83 | Resp[3]: 0x00002600
[ 73.972941] mmc0: sdhci: Host ctl2: 0x00004000
[ 73.973218] mmc0: sdhci: ============================================
Hi everybody, had the very same issue a couple of weeks ago with an older 8GB no-name card. Then changed it to a SanDisk 32GB and everything worked fine. Seems to be some difference in older controllers. Using a more recent (still cheap) SD card seems to work around this issue. Tested with 4 boards and thought first it's due to a missing capacitor (C23, https://files.pine64.org/doc/ox64/PINE64_Ox64_PCB_Placement-Bottom-20221018.pdf) on one of these boards. But it was just the card. Best, CK
I have found the same. In my post above I used a very old 2gb card (Sandisk). A much more recent 32gb (Kingston Canvas Select) card works absolutely fine.
We are facing at least two separate problems here. Some have problems with specific SD-cards. Changing them will result in a working device. But others have problems with specific boards with all SD-cards. Changing the SD-card doesn't seem to help in those cases, changing the board does. I'm not saying that these are not related, but it might be good to differentiate between those. The workaround "Just use a different SD-Card" only applies to the former case...
I'm having similar issues, which manifest differently since the 1.0 build that loads the uBoot config and kernel from the SD card. I usually see a Card did not respond to voltage select! : -110
error. I've had the same issue with a new Samsung 64GB card, and with a no-name 16GB card. Repeated attempts to query mmc info/partitions from uBoot do eventually succeed, but I've yet to get the card reading on boot to the point where it can load the kernel.
Card did not respond to voltage select! : -110
error
I had the same error.
Left one does not work, right one works, both are reasonably quick ones.
Hi, I'm trying to run it on my Ox64. I flashed the low-load fw and the image, and dd'd the sdcard.img to two different sd-cards.The bootloader and the kernel start without a problem, but the rootfs doesn't get mounted and linux stops booting.
Here is my bootlog:
The SDHCI register dump continues several times afterwards.
This is the parted-output for one of the SD's:
Am I missing something, or is there something going on with the SDHCI?