Booting Beaglebone Black from SPI Flash (N25Q256)

In the last line I meant to say - However this does not seem to have any effect

Hi Eugene,

As you probably know SPI0 boot uses the following pins:

CS     spi0_cs0

MISO spi0_d0

MOSI spi0_d1

CLK   spi0_sclk

These pins are already pinmuxed for SPI by the ROM code. Why are you pinmuxing them again in the SPL?

Another thing that you may check is whether the MCSPI_CH0CONF doesn't get modified somewhere in the code. I seem to remember that there was a discrepancy between the default MISO/MOSI channels and the ones in the u-boot code. Check bits IS, DPE0 and DPE1 in MCSPI_CH0CONF. They should be IS=0, DPE0=1, DPE1=0.

Hi Biser

The problem is that after SPL takes over, it appears to change pinmux from the one set by ROM code to the one set according to SPL/U-boot code and/or config options. When I monitor the level of SPI0 CS signal (Pin 17 at expansion header 9 of BBB) with the oscilloscope, this level goes high immediately after powering up BBB, then goes low when SPL takes over. This happens with any SPL/U-boot boot I tried - either EMMC or SPI.

With EMMC boot I could enable SPI communication in U-boot by setting SPI0 pinmux with mm commands - I placed 30 to 0x44E10950, 30 to 0x44E10954, 10 to 0x44E10958 and 10 to 0x44E1095C. The original SPL values were from memory (I am not at work now): 37, 37, 62 and 62. Following mm commands, the level of SPI0 CS signal went high again and I could access SPI flash with sspi and sf U-boot commands

However during SPI boot, the boot simply could not proceed following the the first read of SPL image from SPI flash, as(if my understanding is correct) SPL set its own pinmux which disabled SPI and stopped U-boot from loading. That is why I was trying to modify /board/ti/am335x/mux.c to enable SPI0, as described in my original post, and rebuild SPL/U-boot, but that did not have any effect - every time the level of SPI0 CS signal went low following loading of SPL from SPI flash.

I hope that there is a way to build SPL/U-boot with any pinmux settings we need so look forward to your advice

Regards

Eugene

I will ask the SW team to help on this.

Hi Eugene, 

Eugene Zilberg said:

That is why I was trying to modify /board/ti/am335x/mux.c to enable SPI0, as described in my original post, and rebuild SPL/U-boot, but that did not have any effect - every time the level of SPI0 CS signal went low following loading of SPL from SPI flash

Have you cleaned the settings of SPI0 CS pad from the other pinmux structures, i.e.: 
  static struct module_pin_mux uart3_pin_mux[] = {

    {OFFSET(spi0_cs1), (MODE(1) | PULLUP_EN | RXACTIVE)}

  static struct module_pin_mux mmc0_pin_mux[] = { 

       ................

       {OFFSET(spi0_cs1), (MODE(5) | RXACTIVE | PULLUP_EN)}, /* MMC0_CD */

If you don't do that the configure_module_pin_mux(spi0_pin_mux) could be overwritten a couple of lines later where mmc0 pin mux is done: 
    configure_module_pin_mux(mmc0_pin_mux); 

Also when flashing the board you use the MLO.byteswap & u-boot.img built with am335x_evm_spiboot_config, right? 

Best Regards, 

Yordan

Yes when flashing the board I used the MLO.byteswap & u-boot.img built with am335x_evm_spiboot_config. As for my changes in mux.c I will review that tomorrow (when I have access to the code) to make sure SPI0 pinmux is not overwritten later in the code.

So if mux.c is modified correctly, are you suggesting that I was using the correct method to enable SPI0 in SPL/U-boot?

Regards

Eugene

Hello,

Please check that the "Hold" pin of the SPI flash is connected to VDD_3V3B with a pull-up (e.g 100k)

Regards,

Thank you - I made a few more modifications in mux.c (my main problem was that originally I did not realise that I had to use Beaglebone LT pinmux) and everything works now

Regards
Eugene