SPI NOR not recognized by u-boot on the OSD3358-SM-RED

[Jeremie FRANCOIS]

Hello

I am failing at trying to talk to the embedded SPANSION SPI NOR from the u-boot command prompt. We have a design that mimics the OSD3358-SM-RED, but we experience the problem upfront with your board as well.

Actually, within the u-boot prompt, sf probe 0 systematically returns SF: unrecognized JEDEC id bytes: 00, 00, 00

I tried the official Linux image that you provide for the OSD3358-SM-RED but the u-boot seems to be a regular BeagleBone one.
I also tried to build a lot of variants of u-boot, including some based on am335x_evm_spiboot_defconfig (with the added "CONFIG_SPI_FLASH_SPANSION=y" instead of the default support for a Windbond NOR). But I was not able to talk to the SPI NOR.

Weirdly, one month ago I was able to build an u-boot that made it possible for me to flash the SPI NOR (…with a corrupted MLO which is another story). But I have lost the configuration, and I am since completely unable to get it working again.

I wish Octavo provided something like am335x_evm_osd3358_defconfig but I was not able to find it.

Is there any resource out there that tells me how to configure u-boot for this board and talk to the SPI NOR ?

[Neeraj Dantu]

Hey JF,

 

Did you populate J11 to complete the electrical connections between the SPI NOR and the AM335x SPI interface? The first step would be to verify the electrical connectivity and monitor whether the communication signals are reaching the NOR flash. Once you have verified the connectivity, verifying the communication between the AM335x and the NOR flash via for example, spidev on Linux would be the next thing to do. Scoping the interface pins including for whether the chip select pin is going low, the clock is being exercised and the data is being transferred via D0 and D1 would also narrow down where the issue is.

The OSD335x integrates and exposes all the peripheral functions of the AM335x processor (Except for internal DDR). So, all the defconfigs that work with the AM335x processor should also work for OSD335x.

[Jeremie FRANCOIS]

Thanks Neeraj for your reply & fast support!

Yes, I did populate J11 as required. I also think the hardware is OK: when I boot the Linux image provided by Octavo on an SD and into the u-boot prompt, sf probe 0 outputs the SF: unrecognized JEDEC id bytes: 01, 20, 18. So u-boot does see the SPI NOR chip, but it will not talk to it, most probably because this Octavo Linux image was built with the default u-boot support for Windbond chips instead of the required CONFIG_SPI_FLASH_SPANSION=y (the chip which is specifically on the SM RED).

I do need an early support for the SPI NOR, either in the SPL or in u-boot, so as to implement a secure boot via a TPM chip.
And the SM RED is a good testbed that we also purchased for this reason 😉

=> I really wish I had official data for u-boot (e.g. an am335x_evm_osd3358_sm_red_defconfig, or .config, or patch, or documentation), which would enable a full support of the Spansion SPI NOR present on the SM RED directly within u-boot. It would give us a solid ground for enabling secure boot and handling our own board. The official Octavo Linux image & clients would also benefit from it IMHO.

To provide more context, on our own hardware, the Octavo Linux image will not let us go this far: no prompt is given at all. I think that our few available SYSBOOT options conflict with the MLO of your image.
Still, I believe our hardware is OK I **once** was able to flash the SPI with a hand-made u-boot (a customized u-boot that did support the Spansion chip). Actually, on this prototype, the CPU **still boots straight into the MLO which is in the SPI NOR**! I know… because it then fails with a particular error message due to me flashing an improper MLO at the time! So I am confident both our schematics, routing, SYSBOOT and chips are all OK to support the SPI NOR, and it probably boils down to the build configuration of u-boot.

Unfortunately, I lost the respective MLO/u-boot I was able to flash with, and more annoyingly, I am just unable to re-create one! I mean, even one that would be able to flash the NOR of the OSD3358-SM-RED in the first place.

With an official and customized u-boot for the SM RED, we could make sure at least that the problem comes from u-boot build configuration!

• This reply was modified 5 years, 12 months ago by Jeremie FRANCOIS.

[Neeraj Dantu]

Hey JF,

First addressing the custom board boot, do you have your EEPROM programmed with a Beagle compatible ID? Check: https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/

There is an am335x_evm_norboot_defconfig (https://github.com/u-boot/u-boot/blob/master/configs/am335x_evm_norboot_defconfig) which has CONFIG_SPI_FLASH_WINBOND=y.

Try changing to CONFIG_SPI_FLASH_SPANSION=y and rebuild. The procedure to rebuild and replace the existing u-boot with the new u-boot is provided step-by-step here: https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black. Specifically, you will need sections ‘ARM Cross Compiler: GCC’, ‘Bootloader: U-Boot’ and first 3 steps of ‘Set up MicroSD card’

 

[Jeremie FRANCOIS]

Hi Neeraj.

Yes, we did have proper EEPROM values. I tried various sets of ID, including a regular Beagle Bone Black in addition to the OS (actually, I wrote a special version of board/ti/common/board_detect.c because our own board does not have any EEPROM to store the beagle signature at all — so this emulates the content of the EEPROM and immediately higher TI structures).

Thanks you for telling about the am335x_evm_norboot_defconfig, but as we already knew about it and about the required CONFIG_SPI_FLASH_SPANSION=y (see above).

However… we were able to trace our problem thanks to a weird behavior: when flashed on an SD, u-boot was able to detect the SPI JEDEC bytes. But when booted from the UART, all the bytes were zero.

So we eventually were able to trace the issue to a partially defined pinmux, which probably left the SPI0 CS either floating or badly assigned. This made it depend on the context… And even more bizarre: booting the CPU straight in the SPI did work, but the u-boot prompt then failed to handle the flash.

Whatever our attempts to get a proper u-boot .config (via makemenuconfig or manually), we never were able to get a correct pinmux for a complete, stable SPI support (like only half of the SPI0 signals were defined)

=> so we ended up adding an explicit call to configure_module_pin_mux(spi0_pin_mux); in board/ti/am335x/mux.c. And this solved everything! We now have complete and stable support for the SPI NOR flash at u-boot prompt, whichever way we boot!

Anyhow, thanks for your support! Looks like an additional patch for a single line was our solution 🙂

//you can edit the title to mark it “solved” — I was not able to see how to do it and now I really need to move forward!//

• This reply was modified 5 years, 11 months ago by Jeremie FRANCOIS.

[willisNGC_39]

SPI0 or SPI1 is not initialized from an unedited version of the OSD Debian 9.1 (or any debian OS) used. You have to set it up in the device tree overlay or cape overlay (Cape overlays still work in 9.1 but the Debian OS designers are designing it out, I suggest getting familiar with creating or editing the device tree overlay).

There’s a nice little quirk I found. If you use the adafruit_BBIO library for SPI (comes with the debian arm OS) in a python script to access SPI, it will auto attach the spi cape overlay to an open and empty attached cape overlay. 4 are initialized when it boots up to add capes when it’s already on.

[Author]

Posts