This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAPL-138 Pin Mux

Other Parts Discussed in Thread: OMAP-L138

Hi, I have doubts on pin multiplexing on OMAP-L138 processor.  

I want to use the MII interface and the pins conflict with the SPI0, also I want to use the two I2C channels that conflict whit the SPI1.  

My needs are to use a 64Mbit SPI memory on channel SPI1, and reconfigure the MUX registers to enable the I2C channels after the UBoot execution.

 My doubts are:  Does the UBboot loads all the program memory from the SPI Flash memory to the DDR memory during the boot?

 Is there any moment after loaded on DDR when the Uboot or Linux needs to access the SPI flash memory?

 I need to switch the SPI1 pins to work on the I2C channels after the boot.

Plese help.

Thank you all.

  • Rodrigo Herrera said:
    Does the UBboot loads all the program memory from the SPI Flash memory to the DDR memory during the boot?

    This is true, U-Boot does not fit in internal memory, and cannot execute out of the SPI flash, so the U-Boot image is loaded entirely into DDR before execution.

    Rodrigo Herrera said:
    Is there any moment after loaded on DDR when the Uboot or Linux needs to access the SPI flash memory?

    This depends on how you have things setup, you could have it such that the SPI is not used after booting. The first thing that comes to mind here is that U-Boot stores its environment variables within the SPI flash, as well as potentially the Linux kernel image, so U-Boot may need access to these over the SPI bus before you change the muxing. The kernel can be configured to not use the SPI flash, so that should not be an issue, it would only be using it as a generic storage device anyway, much like U-Boot the Linux kernel only runs out of DDR and does not have any hard requirement to use the SPI flash again after being loaded.