f_ changed the topic of ##raspberrypi-internals to: The inner workings of the Raspberry Pi (Low level VPU/HW) -- for general queries please visit #raspberrypi -- open firmware: https://librerpi.github.io/ -- VC4 VPU Programmers Manual: https://github.com/hermanhermitage/videocoreiv/wiki -- chat logs: https://libera.irclog.whitequark.org/~h~raspberrypi-internals -- bridged to matrix and discord
<f_ridge> <x​2x6_/D> Don't know what to do actually. Think I need some extra rig to be able to sniff data and clock pins, and also a logic analyzer to proceed
<f_ridge> <c​lever___/D> yeah, i ran into similar issues when using a really old 2gig card
<f_ridge> <x​2x6_/D> I can not say these cards that I have are old.
<f_ridge> <x​2x6_/D> they are both sdxc - 64 and 128gb
<f_ridge> <x​2x6_/D> BAD SCR: 0205848701006432
<f_ridge> <x​2x6_/D> GOOD SCR: 0285808300000000
<f_ridge> <x​2x6_/D> I am going to check their SCR register and probably compare some other registers as well
<f_ridge> <c​lever___/D> yeah, its less age, and more that different age from what your code expects
<f_ridge> <x​2x6_/D> what do you mean?
<f_ridge> <c​lever___/D> they keep changing the sd protocol, and your code expects the card to behave a certain way
<f_ridge> <c​lever___/D> and as soon as the card stops behaving that way, bad things happen
<f_ridge> <x​2x6_/D> So my idea for future is to actuallly read out all the sdcard registers and dump / parse them into more meaningful logs, now I only dump SCR to some degree of detalization
<f_ridge> <c​lever___/D> yeah, thats kind of what you need to do, to work with all cards
<f_ridge> <x​2x6_/D> But this becomes a bit of race with time, it's too hard for me to put so much time for this)) Its ridiculusly complex)
<f_ridge> <c​lever___/D> ah, found it: https://archive.goughlui.com/static/csdecode2.htm
<f_ridge> <c​lever___/D> if you paste in the CSD value, this will decode it
<f_ridge> <x​2x6_/D> thanks
<f_ridge> <c​lever___/D> ```c
<f_ridge> <c​lever___/D> #define MMC_SEND_CSD 9 /* R2 */
<f_ridge> <c​lever___/D> /* get card specific data */
<f_ridge> <c​lever___/D> send_136_resp(MMC_SEND_CSD, MMC_ARG_RCA(rca));
<f_ridge> <c​lever___/D> if (!wait_and_get_response())
<f_ridge> <c​lever___/D> return false;
<f_ridge> <c​lever___/D> copy_136_to(csd);
<f_ridge> <c​lever___/D> ```
<f_ridge> <c​lever___/D> and it looks like thats CMD9 with a 136 bit reply
<f_ridge> <c​lever___/D> so the reply comes back on the CMD pin, not the DAT pins
<f_ridge> <c​lever___/D> `CSD: 0x0a400027ae077f80db790003400e0032`
<f_ridge> <c​lever___/D> not sure if i printed it right, but this is what i found in my existing `csd` variable
<f_ridge> <c​lever___/D> yeah, thats totally scrambled
<f_ridge> <c​lever___/D> `CSD: 0x400e0032db790003ae077f800a400027`
<f_ridge> <c​lever___/D> if i swap it around, i get this
<f_ridge> <c​lever___/D> thats much better, now it says version 2.0 SDHC
<f_ridge> <c​lever___/D> 1ms read time
<f_ridge> <c​lever___/D> 25mhz max clock!
<f_ridge> <c​lever___/D> erase block size, 128 sectors
<f_ridge> <c​lever___/D> write is 4x slower then read
<f_ridge> <c​lever___/D> `printf("CSD: 0x%08x%08x%08x%08x\n", csd[3], csd[2], csd[1], csd[0]);`
<f_ridge> <c​lever___/D> thats how i had printed it
Stromeko has quit [Quit: Going… gone.]
Stromeko has joined ##raspberrypi-internals
jcea has quit [Ping timeout: 268 seconds]
f_ridge has quit [Remote host closed the connection]
f_ridge has joined ##raspberrypi-internals
jcea has joined ##raspberrypi-internals
Stromeko has quit [Quit: Going… gone.]
Stromeko has joined ##raspberrypi-internals
srk- has joined ##raspberrypi-internals
srk has quit [Ping timeout: 256 seconds]
srk- is now known as srk
jcea has quit [Ping timeout: 264 seconds]
vriska has quit [Read error: Connection reset by peer]
vriska has joined ##raspberrypi-internals