sdmon does not work with new Apacer card

[joel-bourquard]

I purchased a new 32GB SLC Apacer card, expecting sdmon would work with it:
https://www.digikey.ch/en/products/detail/apacer-memory-america/AK6-848HSA-00101/17877877

However it does not work. This is with latest arm64 build (October 4th 2023 at 11:09).

Run #1

# ./sdmon /dev/mmcblk0
{
"version": "v0.5.0-5 (6111224) arm64",
"date": "2023-10-30T22:39:59.000Z",
"device":"/dev/mmcblk0",
"addTime": "false",
"signature":"0x0 0x4",
"manufactureYYMMDD": "",
"healthStatusPercentUsed": 27,
"featureRevision": "0x4",
"generationIdentifier": 4,
"productString": "P�P�",
"success":true
}

Run #2

# ./sdmon /dev/mmcblk0
{
"version": "v0.5.0-5 (6111224) arm64",
"date": "2023-10-30T22:40:35.000Z",
"device":"/dev/mmcblk0",
"addTime": "false",
"signature":"0xa4 0x81",
"manufactureYYMMDD": "",
"healthStatusPercentUsed": 199,
"featureRevision": "0x63",
"generationIdentifier": 73,
"productString": "",
"success":true
}

My platform is a Raspberry Pi 4 with very standard, up-to-date 64-bit setup.

# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

# uname -a
Linux rpi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023 aarch64 GNU/Linux

I also tried sdmon 0.3.2, 0.4.2 and 0.5.0 with similar results.

[Ognian]

Hello Joel,
thanks for the info. My tests were with a recent 5.x kernel and yours are with a new 6.x , so I suspect that this is the problem.
My first thought was that only an actual build environment would be needed, but looking into the github action logs I realized that due to using alpine:latest the headers are already on a 6.x version, so it seems that there are some major changes in the kernel driver causing this behavior.
Could you try with an 5.10.x kernel?
Thanks
Ognian

[joel-bourquard]

Hi Ognian,
Yes I will definitely try a 5.10.x kernel and report back.

In the meantime, still on kernel 6.1.21, I tried building latest master (dba7898) from source, simply running "make" in the src/ directory and running sdmon, but problem persists.

[joel-bourquard]

Hi Ognian,

As a first try, I downgraded kernel to latest 5.x which is 5.15.92:
Linux rpi 5.15.92-v8+ #1627 SMP PREEMPT Mon Feb 6 12:35:20 GMT 2023 aarch64 GNU/Linux

Same issue (I tried all versions of sdmon listed above).

Was sdmon tested with 5.15.x? Should I really do down to 5.10.x?
Thanks :)

[krypton-x]

I'm not sure the kernel version causes the problem. With my raspberrypi 4, Kernel 6.1.21-v8+ #1642 SMP it works without a problem using the Kingston SDCIT2 sd card:

# sudo ./sdmon /dev/mmcblk0
{
"version": "v0.6.0 (dba7898) arm64",
"date": "2023-11-01T19:02:51.000Z",
"device":"/dev/mmcblk0",
"addTime": "false",
"read_via_cmd56_arg_1":"read successful but signature 0xff 0xff",
"idata.response[]":"0x900 0x00 0x00 0x00",
"flashId": ["0x98","0x3e","0x98","0xb3","0x76","0xe3","0x08","0x16","0x00"],
"icVersion": ["0x1f","0xc3"],
"fwVersion": [38,240],
"ceNumber": "0x01",
"spareBlockCount": 14,
"initialBadBlockCount": 14,
"goodBlockRatePercent": 99.64,
"totalEraseCount": 216707,
"enduranceRemainLifePercent": 99.63,
"avgEraseCount": 111,
"minEraseCount": 2,
"maxEraseCount": 258,
"powerUpCount": 48,
"abnormalPowerOffCount": 0,
"totalRefreshCount": 0,
"productMarker": ["0x70","0x53","0x4c","0x43","0x00","0x00","0x00","0x00"],
"laterBadBlockCount": 0,
"success":true
}

[Ognian]

Hmm,
Thanks @krypton-x for testing with a 6.x kernel. I searched in the 6.x kernel release notes too and did not found any significant changes to the driver, so it looks like the kernel is not the reason for the above behavior.
@joel-bourquard I don't think that you need to test with a lower 5.x version (I've tested with a 5.14.21 version without any problems on the apacer card).

But I have one more idea to test:
@joel-bourquard could you remove (comment out) in sdmon.c everything from line 197
to line 255
and try again?
apacer cards used not to answer on this command and I used it as a test to distinguish the different card types...
But it looks like your card is answering on this command so maybe this changed and we need to search for an other way of doing this...

[joel-bourquard]

Hi @Ognian ,
I've applied this patch on latest sdmon master to remove the lines:
sdmon-patch-1.txt

And now I get pretty much all zeroes except in idata.response[] (kernel 6.1.58):

# ./sdmon /dev/mmcblk0 
{
"version": "",
"date": "2023-11-02T15:16:03.000Z",
"device":"/dev/mmcblk0",
"addTime": "false",
"idata.response[]":"0x900 0x00 0x00 0x00",
"flashId": ["0x00","0x00","0x00","0x00","0x00","0x00","0x00","0x00","0x00"],
"icVersion": ["0x00","0x00"],
"fwVersion": [00,00],
"ceNumber": "0x00",
"spareBlockCount": 0,
"initialBadBlockCount": 0,
"goodBlockRatePercent": 0.00,
"totalEraseCount": 0,
"enduranceRemainLifePercent": 0.00,
"avgEraseCount": 0,
"minEraseCount": 0,
"maxEraseCount": 0,
"powerUpCount": 0,
"abnormalPowerOffCount": 0,
"totalRefreshCount": 0,
"productMarker": ["0x00","0x00","0x00","0x00","0x00","0x00","0x00","0x00"],
"laterBadBlockCount": 0,
"success":true
}

Tried adding the "-a" flag and got the additional delay, but same output.

[Ognian]

Unfortunately this means that this new Apacer Card does not provide the health info the same way, like it did before (via cmd56_arg = 0x00000010; prepare and cmd56_arg = 0x00000021;read).
Looks like they are also switching to provide the health info via the cmd56_arg = 0x00000001; command too. Actually there was a proposal for a well known "read health" command but I never found some free available specification about this and I was told that the different members of the sdcard association could not agree on this years ago...
Now I see 2 opportunities:

• the output of the cmd56_arg = 0x00000001; command is not stable when called, at least the signature should be constant; but on subsequent calls it changes
• I could not found any public available data sheet about this card (containing some real info and not only marketing...)