<Bitweasil>
user_user, I'll suggest sticking around for a while. This is a pretty low traffic international channel.
<user_user>
Ok, I am not very used to irc's)
<user_user>
Wanted to find someone who can lend brains to discuss baremetal sdcard speed optimization
<user_user>
This is mostly Clever though) But maybe someone else also active here
<user_user>
So we have an mailbox interface. In my baremetal project, I ask clock rates to all peripherals. EMMC clock has ID==1, when I ask about this clock - i get a value of 200MHz. I want to change it with set_clock_rate API, for simplicity I first want to make it less and see the result by requesting get_clock_rate again. But I still see 200MHz.
<Bitweasil>
That's mostly a question for clever, yes. What gen Pi? The earlier ones suck, there's just nothing you can do about the interface being glacial.
<user_user>
I want to stick to 3B+ for just a little bit more time
<Bitweasil>
IMO, not worth the hassle, they don't really overclock the card well, they don't support the low voltage high speed modes, etc. Just let it run at whatever it can and call it good, cache stuff if you need.
<clever>
user_user: *waves*
<clever>
i would start by trying to probe the actual clock pin on the sd socket itself, and confirm if its running at 50mhz
<user_user>
I was thinking that too, but at this point I want at least the performance of stock linux kernel. currently I write to SD card at speed of 2.5Mbits per second , but! what makes me still try is that I have two classes of SDcards - v10 and v30, they have different speeds according to the classification, but in my code the writing speed is the same for both
<user_user>
I assume it is possible to hit the limit of writing speed on the SDcard itself and then to consider this a good result
<clever>
there are ~3 speeds to be aware of
<user_user>
Hi, clever
<Bitweasil>
The Pi3 SD interface, as I recall, can't run most of them anywhere near "competent or capable speeds."
<clever>
1st, is the speed of the SD bus, i believe the pi0-pi3 family top out at 50mhz 4bit SDR, so 200mbit
<user_user>
Probing the clock pin is a good advice..
<clever>
2nd is the clock speed of the sd/emmc peripheral, which is divided down to create that 50mhz
<clever>
and 3rd is the speed of the internal axi bus that the data flows over
<user_user>
I don't have an oscilloscope at this time though
<clever>
what about a logic analyzer?
<clever>
or an rp2040/pico
<user_user>
nothing, I am in the middle of relocation process. All stuff in storage
<user_user>
)
<clever>
ah
<user_user>
ok, what about rp2040 ?
<clever>
the rp2040 has a frequency counter in its PWM block
<clever>
so you could measure the frequency of the clk pin
<user_user>
is it running during communication or always?
<clever>
i'm not actually sure
<clever>
another thing, is how does emmc handle the clock divisor
<user_user>
So , do you think that emmc clock + the clock divisor set in one of emmc control registers actually form the 50MHz CLK signal on the sdcard pin?
<clever>
the SH_CDIV register sets the divisor, to go from i think core0 to the SD bus clock
<user_user>
Easiest is to check this part first. Because I already have a 64*512 bytes write outs to sdcard and I measure them. So if I change EMMC clock downwards, then without touching divisors - we could see that
<clever>
and this code decides what clock to use, based on the version the card claims to support
<user_user>
So in your code line 476 - does this mean that 200MHz are divided by 10 to receive 20MHz on sdcard pin?
<clever>
in linux, the sdhci core will write a 0 to the SDHCI_CLOCK_CONTROL register, compute the proper divisor, and then enable the clock
<clever>
and enabling the clock involves writing the internal clock enable flag, waiting for the internal clock to be stable, maybe writing to the PLL enable register (depending on which sdhci core you have), slapping the "clock card en" bit onto the divisor, and writing it to SDHCI_CLOCK_CONTROL
<user_user>
I observe very interesting thing now in parallel. As I've set divisor in EMMC_CONTROL register to 3 - the writing speed has increased but its not systematic. I would say some things are due to my scheduling, but it jumps from 14ms to 98ms