Default uboot config for Colibri SoM i.MX6ULL

Hello,

Following the “Colibri Carrier Board Design Guide”, the section 2.8 SD/MMC/SDIO, states:

2.8.2 Reference Schematics

[...] There is no dedicated card detect signal available. Any free GPIO capable signal could be used, but we recommend using the signal on Pin 43 (CTRL_WAKE_0) whenever possible.      [...]

Our custom carrier board does not use the PIN43 for the SD card detection. The u-boot shipped with the SoM for i.MX6ULL (shipped “as-is” from Toradex) force the detection on this pin, hence the SD card is inaccessible from u-boot.

The solution is to custom-configure u-boot for our carrier, but we’ve found that we cannot update the default burned u-boot on NAND with ours, because the default u-boot doesn’t detect the SD card and refuse to load the updated binaries (USB&ETH interfaces also requires configuration changes).

The question: Is there any way (workaround in software) to change/override/configure the SD detection line in the current shipped u-boot ?

Our current understanding is that we can flash the NAND in several ways (recovery, etc.), but that requires flashing each module one by one because we can’t use our custom carrier board right now “as-is” to do so without using exactly the same pinout layout as Toradex carrier board for Colibri modules. Our last resource would be a pull-up for pin 43 to force the detection and be able to update NAND shipped u-boot with ours in the first boot.

P.S. We’ve also noticed that with the current mask of OTP fuses used on Colibri i.MX6ULL SoM’s, you cannot find any combination with BOOT_MODE0 and BOOT_MODE1 pins that allow you to boot from a SD interface, and this could be very helpful to boot a custom u-boot from an external device and flashing the NAND later on.

Thank you,
A.

You can use one of the Toradex carrier board to flash your module and then insert them in your carrier board.
You can also use a USB or Ethernet to update U-Boot and OS using Toradex Easy Installer.

True, but we want to avoid flashing +100 SoM like this in the future.

So maybe, Toradex can provide a better way to do it (like shipping the flashed u-boot which allow you to change the parameters on-the-fly without a full flash procedure for a custom uboot? like some environment parameter on the u-boot), it is not ideal, because you are force to stop the u-boot on the first boot (serial port/debug console), but you can setup u-boot to run configurations and commands that allows you to run an external script from a SD-card (or any other external filesystem supported)

Or just patching the u-boot to ignore the SD_Detection_line from the current u-boot till you specifically configure in the u-boot environment to use it.

This could solve a lot of problems with SD card initializacion without forcing to use the pin43 for those tasks.

Anyways, the fuse issue is the stopper right now, because we can configure our custom board to try to boot the SD first always (avoiding the NAND u-boot), flashing the correct one and restore the boot0/boot1 pins to boot from NAND per default, but current fuses burned in the SoM avoid this.

The main question is why we can’t use a custom pinout for a widely used interface like SD when the documentation states that we can use any GPIO to carry the CD detection, but we’re limited somehow to the Toradex u-boot configuration without “simple” way to avoid but to use the exactly same mapping for the pinouts.

Thanks, and best regards,
A.

All Colibri iMX6Ull modules shipped preflashed with Toradex Easy Installer. And it’s a default way to flash an any Toradex provided image or you custom image. It can also be used to flash a bootloader only. Please see details here.

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 possible.

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 code modification.

All Colibri modules are fused at factory to boot from an internal flash memory.

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
possible.

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
code modification.

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)

Thank you,
A.

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,

I can create a ticket for our developers to add mentioned feature. If it will be approved you can expect to it to be included in a release during 4-5 month. However even if it will be released you will need to flash it. It means you will need to do the same operation as if you flash U_Boot modified by yourself. A I said all modules shipped with Toradex Easy Installer. It’s based on Linux but it’s not intended to be used in final product. Its sole purpose is to flash required bootloader and OS by Ethernet, USB or SD card. You can’t expect that U_boot provided with the Toradex Easy Installer will be the same as in Toradex provided full featured Linux or other OS.

Would be it possible for toradex to provide non-fused SOMs so we can do it ourselves ?

You can negotiate manufacturing of special butch unfused modules however it should be at least 5K units.

I can create a ticket for our
developers to add mentioned feature.
If it will be approved you can expect
to it to be included in a release
during 4-5 month. However even if it
will be released you will need to
flash it. It means you will need to do
the same operation as if you flash
U_Boot modified by yourself.

Yeah, I understand that we’re locked with what we have, but if the futures modules bring this feature in their preflashed u-boot, it would be extremely helpful.

Thank you for everything.

Best regards,
A.