Boundary SABRE Lite i.MX6: is my SPI Flash broken or is U-Boot?

[louiskoziarz]

Hi all,

I was hoping someone out there has some experience with the SPI Flash EEPROM on the new Boundary SABRE Lite board.

In the process of practicing with U-boot and the loader I've apparently messed up the SPI Flash on the board.  No big deal, so I'm rebooting in USB OTG mode and running U-Boot out of RAM.  When I try to run the 6q_upgrade script off of SD to reflash the board, it fails. 

It seems that spi_flash.c isn't getting the manufacturer code back from the Flash at the correct time.  I've recompiled with DEBUG and If I run the probe alone, I get the manufacturer code:

U-Boot > sf probe

SF: Got idcodes

00000000: bf 25 41 bf 25    .%A.%

SF: Detected SST25VF016B with page size 4 KiB, total 2 MiB

But if I run "sf probe 1" as the 6q_upgrade script likes to do, I get this:

U-Boot > sf probe 1

SF: Got idcodes

00000000: 00 00 00 00 00    .....

SF: Unsupported manufacturer 00

Failed to initialize SPI flash at 0:1

and just for kicks...

U-Boot > sf probe 0

SF: Got idcodes

00000000: 00 00 00 00 00    .....

SF: Unsupported manufacturer 00

Failed to initialize SPI flash at 0:0

Anyone have any ideas?

Thanks,

Louis Koziarz

[luisgarcia]

Hi Louis,

Reading your post, I have seen that you could add debugging options to u-boot. As a consequently, you get some messages about SPI FLASH memory (identifier, manufacturer, size). In my R+D group, I am working with a based-OMAPL137 custom board but it is almost similar to EVM board. At the booting, I have problems with the SPI recognition, because the SPI FLASH at the custom board is slightly different than the EVM SPI FLASH, I mean, I can see the uboot prompt, and type commands like printenv, setenv and so on but when I save these changes by means saveenv, following mesages are printed:

Failed to initialize SPI flash at 0:0

In order to solve that problem, I select the SPI FLASH 0 interface by means sf probe 0, but the result is the same...

For that reason, it would be very interesting know to compile the uboot with debugging options! I could see the same messages than you and fix mistakes!

Thanks in advance!

Regards

Luis

[louiskoziarz]

Luis,

I added my own printk calls inside of the SPI flash driver to get the information I wanted, then recompiled u-boot.  It's the only way to get the code to do what you want.

Good luck,

Louis

[EricNelson]

Hi Luis,

This issue is fixed. Louis, please confirm.

We haven't seen any issues with SPI NOR on any boards since production began a long while ago.

The issue Louis was seeing stemmed from an incompatibility between different versions of U-Boot

Old (2009.08 version) had this syntax:

     U-Boot > sf probe 1

The new (2013 and later) has this syntax:

     U-Boot > sf probe

[louiskoziarz]

Eric,

Yes, the 2013 u-boot is working just fine with SPI flash now.  My problem stemmed from a newer bootloader with an older script.

- Louis

[luisgarcia]

Thanks Eric for your quick answer! I am going to try this procedure next monday. Respect to the debugging option at the uboot, any suggestion? Thanks in advance

Regards

Luis

[louiskoziarz]

Just to follow up some more, I've dug into the command/cmd_sf.c for the Boundary branch of U-Boot and I'm noticing that "sf probe" works correctly with no parameters because Chip Select (cs) is being set tot the default of CONFIG_SF_DEFAULT_CS (which is set in include/configs/nitrogen6x.h as it should be).

It's when the 0/1 parameter gets added to "sf probe" that cs gets set to 0 or 1 and the probe fails.  How is this working for others in the field?

[EricNelson · Accepted solution]

Hi Louis,

Our latest, main-line based U-Boot introduced an incompatibility with respect to sf probe as discussed in this blog post.

Sorry I didn't catch this query. I'm not sure how I can subscribe to notifications of *SABRE Lite*|Nitrogen.