[U-Boot] OMAP3 Beagle Pin Mux initialization issue

[Bob Feretich]

Comments inline...

On 2/25/2011 2:23 PM, Albert ARIBAUD wrote:
> Le 25/02/2011 22:44, Bob Feretich a écrit :
>> For the BeagleBoard, the pins of interest are the ones routed to the
>> Expansion, J4, and J5 connectors. I am working with a local university.
>> Students are building projects that interface to these connectors.
>> Usually, the Linux boot delay is not a concern, but depending on the
>> project, sometimes the pins need to be initialized before a "set time
>> interval after power-on" expires (We can set the power-on reset delay to
>> several hundreds milliseconds, but the time must be bounded.)
> Can you not simply set this time high enough that the U-Boot script
> executes?
Yes, that would be ideal. But how can I set set pin mux controls, 
initialize output pin state, and set the pin direction from an 
automatically executed u-boot script?

>> By having the spot (beagle.c&   beagle.h) in u-boot, where we can add our
>> I/O Pin Mux initialization code, we can satisfy the needs of a bounded
>> I/O initialization time.
> Out of sheer curiosity (I've done some lab teaching in assembly language
> and device control in a previous life), what are those IOs that have
> such a bounded set-up time relative to power-on in a university project?
> If you are willing to answer but find that's really not related to
> U-Boot, we can discuss this in private.
>
In the past we have had problems using the McSPI 3 and 4 interfaces on 
the BeagleBoard Expansion connector. The GPIO pins initialize as 0s 
which activate the SPI chip selects and the SCLKs (for SPI CPOL=1 
devices). Later, when the pin mux is set to select the SPI controller, 
the SCLK assumes its inactive state (logic 1). Now the SPI devices have 
observed a 0 to 1 transition of the SCLK and are one bit out of sync 
with the controller.

Activation of a power-good signal can be delayed for a fixed time to 
prevent the devices from interpreting the SPI bus until it has properly 
initialized, but the delay should be kept to less than a second.

Regards,
Bob Feretich
>> Regards,
>> Bob Feretich
> Amicalement,