mx28 boot issues with SSP (SD card)

[RoboTech]

We made a custom board based on the IMX28EVK, but using the i.MX280, with DDR2 and boot from SSP0 (microSD card).

In our initial tests we found out that some SD cards couldn't boot on our board, but were successful on the EVK.

So I started looking for differences and ended up comparing the OTP flags. The EVK has only one OTP flag set, enabling 12mA drive on SSP0 pins. After burning that fuse, our board was able to boot with the problematic cards.

The boot message when the SD card fails, is just: 0x8020a014

The same card started working after we burned ENABLE_SSP_12MA_DRIVE bit in HW_OCOTP_ROM7 register of the same board.

Another board with OTP unchanged fails to boot the same card.

Now the question is: why is that flag necessary? is it a workaround for design issues of the EVK (and so in our board too) or is it required for proper boot with SD cards?

Can anyone shed a light on this matter?

Thank you,
Paolo

[PeterChan]

The SSPx_SCK pin requires a drive strength of 12mA to maintain a good signal integrity. You should blow this OTP bit so that the i.MX28 can boot from all SD cards.

FYI, Error 0x8020a014 is general error reported by the SD card driver.

[RoboTech]

Well, I've been researching this issue in the last days and finally came to a conclusion.

The SSP0 signal waveforms are really bad in our custom board and also on the EVK (that comes with 0ohm series resistors). We observed severe ringing on both boards, with undershoot and overshoot leading to a Vp-p of around 7V at worst.

To improve the signal and reduce ringing we tried series resistors in the range 33 - 100 ohm

However, that is not the main issue. Turned out that the ROM bootloader incorrectly setup the SSP clock with inverted polarity. Why this is allowed by the hardware peripheral is beyond me, since the SD specifications only support one clock polarity. It must be a SPI flag that is not ignored in SD mode.

This has been recently confirmed by Freescale in the chip errata and with a "patch" that you can load on an additional EEPROM memory, to fix the clock polarity and finally boot from the SD card.

Unfortunately this happened way after we designed our board.

From our measurements with a scope, the CMD line changes on the rising edge of the clock, which is the edge used by SD cards to sample the data and commands. So how can it work? Because the command is actually earlier than the clock by a few nanoseconds. With slow rising edges, some cards do not reply. But if you burn OTP flag to enable 12mA drive-strength, the edges are faster and it magically works. That of course with no guarantees at all or any safety margin.

Well, this is the end of the story. We investigated if we could just place a logic inverter on the clock line, but any SD card spec we saw had a max output delay time of 14ns from the rising edge of the clock. That means with a 50MHz clock, a period of 20ns, you have only 6ns to play with, minus 2.5ns for the setup time of SSP signals. Only 3.5ns left, and the fastest inverter (74LVC1G04) has a propagation delay of 3.3ns at 3.3V. Not accounting clock jitter.

Safest option is to boot from EEPROM, which fixes the clock polarity and continues to boot from SSP0. Freescale released the binary image to fix boot from SSP0 and SSP1 (even if they called them 1 and 2). We tested this solution and verified clock is good and boot is successful with the problematic SD cards we identified.

It works fine on a board we left with blank OTP. The fast edges are only really needed with a fast clock. Since the boot defaults are to use an SSP clock of 12MHz, the default drive strength is fine. After linux has been loaded and booted, its SD/MMC driver correctly programs the clock and increases the drive strength for 48MHz clock rate.

I hope this is useful to anybody that plans to boot from SD/MMC cards.

[stefanotappatà]

I'm also plannig to boot my board from EEPROM via spi in order to patch the mx28 sspolarity issue as described in

Linux patch to fix the boot problem when booting using the SD/eMMC on SSP0/1 (
mx28_ssppolarity_rompatch_up.zip downloaded from freescale site).

Which EEPROM did you have ? How did you burn the sb file to EEPROM?

Do I have to use an external programmer ?

Is it possible to use MFGTOOL for burning?

[RoboTech]

I used our custom board to program the EEPROM chip via I2C. I guess you could do the same with the EVK.

Oddly enough, I couldn't find a simple linux tool to program I2C EEPROM. I used sources of "i2c-tools" to build a modified version of "eeprom" in the "eepromer" directory. In particular, I had to add options to support EEPROM chips with 2-byte addressing and to insert delays between each page, to allow the device to come out from busy state.

Please note that you need a device >= 32kbits because the MX28 ROM code expects an I2C EEPROM with 2-byte addressing. I used a spare 24LC128 we had in our lab for testing.

Regarding the manufacturing tool, you can use it to execute any command in a linux environment. So I think you can build an image that contains the EEPROM programming tool and run it. Just like it does with SD/MMC cards or NAND flash.

Best,

Paolo

P.S. uploaded modified i2c-tools at: i2c-tools - Hack to program EEPROM I2C devices for MX28 boot

[Ramtry]

I hope by using the BitBurner we can able to  ENABLE_SSP_12MA_DRIVE bit in HW_OCOTP_ROM7 registe. But i havent tested it. The following link may be useful https://community.freescale.com/thread/308413

[MarekVasut]

Can you try raising the pullups on your SD data pins ?

[RoboTech]

Do you mean lowering the pull-up value or increasing it?

What would a suitable resistor value be like?

We don't have any external pull-up now.

Paolo