On a custom carrierboard for a verdin-imx8mp module, we ran into an issue with the SD-card not working in u-boot. This is very likely caused by the load switch for the SD-card VCC being a bit slower than the part used in the reference design. See this topic for details about the debugging that lead to this conclusion.
I expect this would be solvable by modifying the devicetree used by u-boot to tell u-boot about this startup time, so it waits a little longer after powering up the SD-card before starting communication.
Note that the MIC94073 load switch used in the reference design actually has a worst-case startup time of 2.5ms, the reason it works at all is because u-boot adds some additional delay (just over 2ms before the first relevant command starts, but there is also an apparently not relevant command - probably a reset command of sorts - going on before the regulator is enabled).
For the reference design, it thus seems good to increase this value to 2.5ms. To facilitate other designs (such as ours), I would suggest increasing this value to a bit more (maybe 5ms or 10ms). There should be no issue with a value that is too big, other than SD card detection being that much slower.
So my questions would be:
Is this something that Toradex would consider doing?
If yes, I will need to run with a modified u-boot to verify this actually solves the problem we are having. If someone at Toradex could produce a patched image (or just u-boot) that I could test, that would be awesome, but it also seems reasonable for me to build a modified image myself and then submit a patch for inclusion. I have built a custom image with Yocto before, so that is doable, but I have not done any u-boot modifications until now, so any pointers about where to look for this devicetree file and how to change it in a way that Yocto will pick it up would be welcome.
Thanks for creating the feature request and sharing the context around it.
After (quickly) going through your original thread and reading this one, I understand that you didn’t test the solution of changing the start-delay-us, right?
We can for sure analyze the possibility of having such change on our image by default. But, to be honest, it would be great if you could first test and validate the modification on your side, since you can reproduce the issue and compare the behaviors with and without the modification.
Correct! AFAIU I would need to recompile u-boot to make this change, and I have not investigated in detail what would be needed to do so (which is my second question).
I think u-boot would to be recompiled since AFAIU the devicetree it uses is embedded in the compiled binary. If there is a way to change just the devicetree (the one used by u-boot, not the one used by Linux) without rebuilding, that would be also be great, but I could not find it so far.
Yeah, that seems reasonable. I just kicked off a clean Yocto build, after it is done I’ll see if I can fudge in this change in a second build and compare them.
But to be honest it might be better to just build it using Yocto and patch what you need on your own .bbappend or even simply modifying something on Toradex recipe(s) to patch it for a quick and dirty test.
Yeah, but then it is not quite clear how to actually install the resulting u-boot binary (I went down the same path with a custom kernel earlier this year and then ended up doing a full Yocto build after all because then it was clear how to apply the resulting build ;-p).
For the kernel, I just did the patching inside the build directory where the kernel sources were downloaded, and then forced a recompile without unpacking the sources again with bitbake -C compile virtual/kernel (and a subsequent full build would then use the modified kernel binaries instead of rebuilding). I’ll see if that trick works here as well, otherwise I’ll throw in a patch into the Toradex recipe indeed.
Ok, that seemed to work. The procedure was a little different from modifying the kernel (because non-kernel packages have their source cleaned up after the build), but I found RM_WORK_EXCLUDE += "u-boot-toradex" which neatly sidesteps that (I’ll try and post some of my notes about how I did this to the forum for others soon).
Anyway, it seems I have an image with u-boot modified to do a 10ms delay. I am around the board again tomorrow, I will see if I can squeeze in some time to test this modification.
Here yellow is the load switch enable line, blue is the load switch output (3V3_SD) and purple is the SD clock line. You can see exactly 10ms delay between the load switch enable and the first clock activity.
For comparison, here is the same image with the original u-boot code, where you can see only 100us delay before the first clock activity (while the SD card is still unpowered):
The patch was made directly in the Index of /u-boot-toradex.git checkout. I’m not sure if that is the right place, or there should be a patch file in the u-boot-toradex yocto recipe. I assume you will know the best route and maybe have enough info to take up the rest from here? If you need anything else from me (a pull request somewhere, more testing, a signoff) let me know!
Thank you for doing these tests and sending us the results!
To answer your question on what the recommended approach is to apply this patch: The best way is to create your own custom layer and a recipe to add this patch.
Regarding your request on whether Toradex can merge this change into our u-boot sources: I am discussing this internally with our R&D team and I will let you know what they think about it.
I think you misunderstood my question, I was wondering how to best submit this patch for inclusion in the main build. But it sounds like that is ok for now and you’ll pick this up internally, so nothing else needed on our side now.
For our own images, we do not really need this feature on the short term (the SD-card slot is not user-reachable in our device for now), but we would like to know that it will become useful in a future update (and ideally without compiling our own u-boot, since then we need a more complex workflow for generating our images, since torizoncore-builder cannot make this change).
I had a discussion internally with our R&D team about this. Currently, we do not plan to make this change in our U-boot since this will require some thorough testing from our side. You mentioned early on in our discussion that you are not trying to boot from the SD card. Do you have a strong reason why you want the SD card to be detected in the Uboot? If you could share this use-case, it might help us re-consider our decision.
You are correct that we are not currently planning on using the SD-card for booting in our current product. However, this carrierboard we designed is intended to be used for future products as well, so we would like to ensure that all of the hardware that is on the board is actually usable (to prevent unexpected surprises later on). Also, we have not fully worked out our firmware recovery options for customers yet. We’ve verified that using an USB connection with the uuu tool and Tezi works and that seems to be the unbreakable fallback option, but (in cases where u-boot is still working) booting from SD-card or USB-stick for recovery is an option that is easier for end-users (just drop files on an SD-card or USB-stick instead of needing to install a tool and run commands). Making the bootloader work for this option work now allows us to actually implement it (i.e. generate the right files/images to actually do the recovery) in the future.
Does that clarify our need?
Also, I’d like to reiterate that the current u-boot configuration does not actually match the reference design hardware either and is only “accidentally” working:
