00:01 <clever> ah, ACMD41 switches to 1.8v mode

00:02 <clever> and i think that should be followed by CMD11?

00:02 <clever> and then it defaults to SDR12, a 25mhz 1.8v mode

00:03 <clever> and CMD6? is involved in raising the clock further?

00:26 <clever> whacked an SD sniffer and scope onto my rpi1

00:26 <clever> with no SD card present, it repeats some command several times at 125khz, then gives up

00:27 <clever> with a build of little-kernel on the card, it does a quick burst at some higher frequency, and i cant measure it easily

00:28 <f_ridge> <c​lever___/D> https://cdn.discordapp.com/attachments/1196514625370472570/1250607706465763350/20240612_212259.jpg?ex=666b8eb0&is=666a3d30&hm=11d9fcc1470079b8170282ebf71424d0c8138d10025fcbcb6cc981aa927d2546&

00:28 <clever> that would be the 125khz command the rom repeats during a failed boot

00:56 <clever> and with some more probing, ive confirmed that the other controller (sdhost) seems to run from PLLC_CORE0 or VPU, it was clocked at 250mhz in my test case

00:56 <clever> and the source assumed a 41mhz input clock, so it setup the divisors wrong for the initial 125khz mode

00:57 <clever> but even at 125khz, i just get a timeout error, and cant read the card in the sniffer

22:20 <user_user> Hi all

22:30 <user_user> So, clever, as I wanted to test for EMMC clock divider in the Control register - putting 2 to divisor, which according to datasheet means divide EMMC base clock by 4 - does not work, because the very next command to SDcard comes with error intterupt (CRC error)

22:51 <user_user> No, actually divisor value 2 is ok, it was just a bug

22:56 <clever> user_user: i did some of my own tests on the sdhost controller, and confirmed that its clocked at 250mhz, and my "safe" divisor gave 700khz, not 125khz!

22:56 <clever> but i cant get my sd card to identify with the sniffer in place, and only with my own driver

22:56 <clever> its weird

23:00 <user_user> Yes, I've read, but I did not understand)

23:01 <clever> https://www.sparkfun.com/products/11468

23:01 <clever> i used one of these to connect a full size SD card to my pi1

23:01 <clever> and then i hooked my scope up to CLK and CMD

23:01 <user_user> So, I've found a huge bug in my code. I used control1 = read_reg32(EMMC_CONTROL1); control1 |= div << 8 code. Without clearing previous value

23:01 <clever> ah yeah, that will cause issues

23:01 <clever> many

23:01 <user_user> and then after I've started clearing it I had all kinds of problems when trying to access SD card - it has turned out I had a value 0x40 and then added 2 or 4 to that.

23:02 <clever> the clock divisor is in bits 8-15

23:02 <user_user> so my sd card worked on value 0x42

23:02 <clever> ah but you have the <<8, thats good

23:02 <user_user> yes, I was doing OR to previous 0x40

23:03 <clever> yeah, you need to do the usual &0xffff00ff dance

23:03 <user_user> the speed has not changed drastically

23:03 <clever> https://github.com/librerpi/rpi-open-firmware/blob/master/common/broadcom/bcm2708_chip/emmc.h#L321-L325

23:03 <clever> thats part of why the official headers have all of those bit patterns

23:04 <clever> the CLR pattern lets you clear FREQ8 and nothing else

23:04 <user_user> Without this bug divisor starting from 8 work fine

23:04 <user_user> I mean register value 8

23:04 <clever> 200mhz/8 is 25mhz i believe

23:05 <user_user> i think 200mhz / 16

23:05 <user_user> if looking at the datasheet

23:08 <clever> ah yes, 8 means /16

23:08 <clever> so 12.5mhz

23:08 <clever> the part i'm still confused on, is which speeds need special commands

23:08 <user_user> yep.

23:09 <clever> in my case, i have a pi1 booting a custom bootcode.bin, via the SD sniffer i linked from sparkfun

23:09 <user_user> Ok, at least some progress... Anyways I am going to test sd card perf without distraction from the videocore ISP stuff

23:09 <clever> my custom bootcode.bin then tries to mount the SD card, and it immediately fails

23:10 <user_user> Ok.

23:10 <user_user> Maybe put retries?

23:10 <clever> i could try, that would also help with probing it via the scope

23:10 <clever> but developing on the pi1 is anoying, because you have to swap the SD card on every test

23:10 <user_user> By the way, I've stopped trusting my time measuring function. Because it's based on scheduler time slices and system clock peripheral.

23:11 <user_user> Maybe I should use some other clock.

23:11 <clever> if you want to measure time, just read ST_CLO before and after

23:11 <user_user> On 3b+ is the same, no?

23:11 <clever> and the difference, is how many uSec it took

23:11 <user_user> I can not because ST_CLO is used for scheduling

23:11 <clever> the ST_CLO register is readable on every pi model, even the pi5

23:12 <clever> but ST_C0, the compare/irq stuff, cant generate core-local IRQ's

23:12 <clever> so its not scheduler friendly on a multi-core arm

23:12 <user_user> I set a certain amount of milliseconds into ST_CLO everytime - or count up to that number and then reset and collect ticks

23:12 <clever> ST_CLO should be read-only

23:13 <user_user> I need to have a look

23:13 <clever> basically, ST_CLO and ST_CHI form a 64bit counter, it starts at 0 when the pi is reset, and it just counts at 1mhz

23:13 <clever> ST_C0 thru ST_C3 form 4 compare channels, that can each generate a different irq, when ST_CLO matches

23:14 <user_user> ok, yes

23:14 <clever> but the firmware is using one, and they cant interrupt a specific arm core, so they are useless on the pi2 and above

23:14 <user_user> I can use raw ST_CLO, thanks)

23:14 <clever> yep