All Colibri modules are fused at factory to boot from an internal flash memory.
Would be it possible for toradex to provide non-fused SOMs so we can do it ourselves ? The default i.MX6ULL fuses from NXP comes with a combination that allow us to boot the SD first just with a pin change (pins exported on the SOM, so we can select from one to another with some hardware-magic for the first boot and solve this nightmare of plugging thousands of modules on a SDK before shipping to clients).
About the rest of you comment, some hints, if Toradex wants to consider another approach for a software solution that could fix the SD issue for ALL hardware configurations:
As about SD card CD signals. From a HW
point of view you can use any GPIO
line as CD line. But changing it will
require changes in a software, that’s
why “Colibri Carrier Board Design
Guide” recommends using the signal on
Pin 43 (CTRL_WAKE_0) whenever is
There are thou thousands of allowed HW
alteration and it’s not possible to
adopt them by U_Boot environment
variables. But you can do a source
Using Pin 43 won’t ensure the correct operation with the current u-boot, because even the guidelines doesn’t establish the polarity of this pin for detection (some SD card close the switch on insertion, others open it), so you need to implement the exactly pull-up/pull-down according to your own switch to make it work exactly as Toradex carrier boards.
It is true that it’s not possible to adapt u-boot to all combinations of hardware, but going back to our SD case u-boot provides you with a way to make this painless for this specific case with the SD interface.
This function “u-boot-toradex.git => board/toradex/colibri-imx6ull/colibri_imx6ull.c”
int board_mmc_getcd(struct mmc *mmc)
Could have three return states following u-boot documentation:
board_mmc_getcd() returns -1 to
indicate that no card-detection
mechanism is implemented; 0 indicates
that no card is present and 1 is
returned if it was detected that a
card is present.
Please consider adding an environment variable, so we can choose between force detection, just polarity changes or just disable the CD detection until the u-boot is properly configured, this open the door to almost any combination of SD card interfaces out there with a simple config line.
As matter of fact, currently the CD gpio could be force within u-boot with gpio command on pin43, changing from intput to output, this make u-boot to fallback to a timeout sequence where it would try to comunicate with the SD for a number of retries and mark the card as “correct” if this success (this would happen if or when “board_mmc_getcd” return -1, as “no card-detection mechanism is implemented”). The current i.MX6ULL interface doesn’t require SD line to interface with the SD lines, it is just u-boot software preventing the read because the detection return a 0 always even if the card is connected correctly.
So even, if you can’t, want or add a enviroment variable to configure the detecting for SD insertion, you can always try to execute a command on the MMC/SD interface even when the detection line is telling you that “nothing is there”. That work wonders on some boards and it is very common -workaround- in another platforms to support this type of behaviour, because it is an widespread (and known) problem with the undocumented CD line polarities and all possible configurations (usually CPU doesn’t care about the CD line on the CD MMC interface, they fallback this work to software, as long as everything is setup, you can read an SD card just fine regardless of the CD line)
The example could be the #mmc rescan command on u-boot, currenctly failing because “board_mmc_getcd” just return “no card present”, when actually there is one and you can force the mmc system to read it correctly when you change this input state to an output and the function return a “detection” even when the card is unplugged (and gives your an error message about not be able to communicate with the MMC after 3 unsuccessful tries)