From: Bob Feretich <bob.feretich@rafresearch.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] OMAP3 Beagle Pin Mux initialization issue
Date: Fri, 25 Feb 2011 22:25:20 -0800 [thread overview]
Message-ID: <4D689CD0.8020105@rafresearch.com> (raw)
In-Reply-To: <4D682BE6.2060805@free.fr>
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,
prev parent reply other threads:[~2011-02-26 6:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-22 1:51 [U-Boot] OMAP3 Beagle Pin Mux initialization issue Bob Feretich
2011-02-22 7:28 ` Wolfgang Denk
2011-02-25 21:44 ` Bob Feretich
2011-02-25 22:23 ` Albert ARIBAUD
2011-02-25 22:24 ` Albert ARIBAUD
2011-02-26 6:25 ` Bob Feretich [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D689CD0.8020105@rafresearch.com \
--to=bob.feretich@rafresearch.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox