Jeremie FRANCOIS

Forum Replies Created

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • in reply to: SPI NOR not recognized by u-boot on the OSD3358-SM-RED #6713
    Jeremie FRANCOISJeremie FRANCOIS
    Participant

      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!//

      in reply to: SPI NOR not recognized by u-boot on the OSD3358-SM-RED #6692
      Jeremie FRANCOISJeremie FRANCOIS
      Participant

        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!

      Viewing 2 posts - 1 through 2 (of 2 total)