0B ReadSector - Stable clock troubleshooting
manncr opened this issue · 8 comments
Hello! I apologize if this isn't the right place to ask this, but....
I'm working through ReadSector and trying to get it to work, but I keep getting the error for "failed to get stable clock". Is there a way to troubleshoot this? I've tried different SD cards in my rpi3, turning everything off and back on again, tried different frequencies, but can't seem to find the solution to this error. Do you guys have any ideas on how to get around this issue I'm having? Thanks in advance.
Hi,
I keep getting the error for "failed to get stable clock". Is there a way to troubleshoot this?
Try printing MMIO registers around sd.c:240. Also try to increase the cnt value, maybe it's just too slow, and needs more time to settle?
I've tried different SD cards in my rpi3
Do they work with Rasbian? If not, then you'll need other SD cards. Not all are supported by the hardware, has to be at least HC Class 10.
tried different frequencies
Not a good idea. Some commands are only accepted at specific frequencies, the controller needs one freq, and the cards need another (what's more, that latter depends on card's class too, hence the Class 10 requirement in hw).
This happens in sd.c:282 (controller freq), then the card's freq is set at sd.c:322.
Do you guys have any ideas on how to get around this issue I'm having? Thanks in advance.
I can only give you tips. Read the eMMC SD specification, and try to get some other valid freqs from there. But TBH this works for everybody, you're the first reporting this error.
One last question, you have an RPi3, and not an RPi4 by any chance, right? RPi4 uses a different controller, this driver I've implemented is known not to work with that.
Hope this helps,
bzt
Thanks for the quick response, bzt!
Try printing MMIO registers around sd.c:240. Also try to increase the cnt value, maybe it's just too slow, and needs more time to settle?
Increasing the count didn't change it so I know it's not that. Any MMIO registers in particular I should check? EEMC_CONTROL1 is at zero, didn't check any others yet.
Do they work with Rasbian? If not, then you'll need other SD cards. Not all are supported by the hardware, has to be at least HC Class 10.
It's most likely that I'm not using a Class 10, I guess I missed that prereq. This Class 4 one worked for the previous tutorials weirdly enough.
Not a good idea.
Haha yeah was trying anything to see if it would stick, but thanks for the explanation.
One last question, you have an RPi3, and not an RPi4 by any chance, right? RPi4 uses a different controller, this driver I've implemented is known not to work with that.
Yes its's an RPi3 thankfully.
Thank you again for the response,
manncr
Thanks for the quick response, bzt!
You're welcome!
It's most likely that I'm not using a Class 10, I guess I missed that prereq.
Pi hardware sadly is (and always were) very picky about SD cards. Here's a list that might help: https://elinux.org/RPi_SD_cards The Class 10 is not officially a requirement, but note that 99.999% of the cards on that list which have "Pi 3" in their description are Class 10 cards.
This Class 4 one worked for the previous tutorials weirdly enough.
On the same Pi hardware? If so then it's not a hardware + card combination issue.
Any MMIO registers in particular I should check? EEMC_CONTROL1 is at zero, didn't check any others yet.
That would be my first pick too. Being zero isn't good, that means the SD clock isn't enabled and isn't programmable, and freq being infinity (divider=0), something that shouldn't happen.
I've tried to look up the spec for you, but I've realized all the materials I've used to write this driver are gone. I could only find a BCM2835 spec (which is for RPi2, but the eMMC peripheral is the same, so should be ok).
https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
Check the page 74-75, and also try to dump the EMMC_STATUS register's bits. That should tell you what's going on. But if the status register also returns zero, then you have some other more fundamental issues (bad MMIO address maybe? Or something like that, you're not reading the actual registers rather some arbitrary memory values).
Oh, and make sure there's no config.txt on your boot card. It can instruct start.elf to configure the peripherals in some unexpected state. But I think you already aware of this.
Hope this helps,
bzt
Check the page 74-75, and also try to dump the EMMC_STATUS register's bits
The EMMC_STATUS register came back as 3f500024, which if I'm understanding correctly from the link you gave, is saying that a data line is active, and it can't read or write new data.
Oh, and make sure there's no config.txt on your boot card.
Yeahh that's the thing. I'm using an FT232H JTAG chip(not 100% on the nomenclature) with OpenOCD to debug this, and from my understanding you need the config.txt to enable it. Sounds like I'll need to figure out how to get around the start.elf instruction issues? I'm still pretty new to all this bare metal stuff.
Edit: There is a chance I'm misremembering and I wasn't actually able to run all the previous tutorials
The EMMC_STATUS register came back as 3f500024, which if I'm understanding correctly from the link you gave, is saying that a data line is active, and it can't read or write new data.
Check the other registers as well, maybe you'll figure out from the bits why. (Unfortunately I can't tell you exactly to check this or that, all the advice I can give, keep dumping registers, see if something doesn't seem right.)
I'm using an FT232H JTAG chip(not 100% on the nomenclature) with OpenOCD to debug this
I would recommend an USB serial cable instead, because that does not need anything special on the Pi's side (no special hw, no special sw, no special config etc.) It's as simple as it gets, so it is unlikely to go wrong. On the PC's side you can use minicom (if you're on Linux) or PuTTY (if you're on Windows) to display the messages sent by the tutorial code running on the Pi. (HINT: you could then also use the mini debugger tutorial and dump the MMIO registers on-the-fly using the x command)
from my understanding you need the config.txt to enable it.
Having a config.txt isn't necessarily a bad thing; just make sure it does not influence the peripherals you're interested in. For example it could change some memory mappings, or it could map an entirely different device at the same address. If you're using a config.txt, make sure that's not happening with the devices you're using (which are, UART, eMMC in your case).
There is a chance I'm misremembering and I wasn't actually able to run all the previous tutorials
You should try to get a SDHC Class 10 card. My driver was specifically written for those. Frankly it was years ago, so I don't remember if I considered Class 4 cards or not, but all my cards are Class 10, so even if i did, I couldn't test the driver with those for sure. There's a chance that a particular Class 4 card is actually working with the hw, but my quick'n'dirty sd driver still can't handle it (all I can say for sure is, haven't been tested with any Class 4 cards, and all of my Class 10 cards are working fine).
I don't know what more I could say about this issue, so I'm closing it. But I'll keep reading it, so feel free to ask, I'll try to answer if I can. In a nutshell, first try to get a Class 10 card, second, do what you're doing, keep printing MMIO registers and match their bitfields with the spec maybe you'll figure out the reason.
Cheers,
bzt
Just an update. Got the new SD card. 128GB wasn't working, but the 32GB did. Both Class 10 cards. I still get the same exact errors about the clock being unstable/not enabled. EMMC_CONTROL1 still zeroed out, as is EMMC_CONTROL0 but I don't think anything in that one affects what I'm trying to do.
As for the config.txt, doesn't seem like anything that is active in it is messing with UART or EMMC thankfully.
More info on my setup. I am using a serial cable and using CoolTerm to read the output instead of Putty. I've been using a JTAG board to debug a bare metal program that is using your EMMC driver. So all of this is running off a GDB server that it creates. So my only theory is that because I'm running the code off the GDB server it isn't getting the right kind of access to the EMMC reader or something like that. We're still working on getting it to compile into a binary that we can turn into a .img file for the pi to run, so I don't have a way to test that completely yet.
I'm trying to find if there is a way to enable/disable the SD's clock but that's not easy to find.
EDIT: I remember seeing an "undervoltage detected" warning when I was first messing with the pi and loading up the RaspbianOS on it. I just read on some random thread that an underpowered board could have issues with the SD card or something. This is something I'll test when I can, but another possible reason why it isn't working. Could be the microUSB isn't providing enough juice or somehow the JTAG board is causing it too.
EDIT2: Turns out I'm an idiot and was printing out the EMMC_STATUS, not *EMMC_STATUS, which is zero as well. I'll look into if the MMIO_BASE is correct or not I guess. Seems like it should be 0x3F000000, not 0x3F200000 (which it for some reason got set to somehow)? CONTROL1 is still at zero, but STATUS is at 1fff0000
Last reply on this. Turns out just fixing the base address fixed everything. A bit of a waste of an issue, but thanks for your help either way, bzt. Made me much more knowledgeable on all this bare metal stuff.
Take care,
manncr
You're welcome, and I'm glad you managed to get it working!
Cheers,
bzt