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!//
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!
Octavo Systems LLC all rights reserved
OCTAVO is registered in the U.S. Patent and Trademark Office. OSD, C-SiP, and the Octavo Logo are trademarks of Octavo Systems LLC.
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields