* [U-Boot] OMAP3 Beagle Pin Mux initialization issue
@ 2011-02-22 1:51 Bob Feretich
2011-02-22 7:28 ` Wolfgang Denk
0 siblings, 1 reply; 6+ messages in thread
From: Bob Feretich @ 2011-02-22 1:51 UTC (permalink / raw)
To: u-boot
The BeagleBoard beagle.c file contains:
242 /* Configure GPIOs to output */
243 writel(~(GPIO23 | GPIO10 | GPIO8 | GPIO2 | GPIO1),
&gpio6_base->oe);
244 writel(~(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 |
245 GPIO15 | GPIO14 | GPIO13 | GPIO12), &gpio5_base->oe);
246
247 /* Set GPIOs */
248 writel(GPIO23 | GPIO10 | GPIO8 | GPIO2 | GPIO1,
249 &gpio6_base->setdataout);
250 writel(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 |
251 GPIO15 | GPIO14 | GPIO13 | GPIO12,
&gpio5_base->setdataout);
It first sets some pins as outputs and then initializes their values.
This can cause narrow glitches on the output pins.
To prevent the glitches the order should be reversed. First Set the
GPIOs, then Configure them as outputs.
Also, I have observed the discussion regarding moving Pin Mux control to
the kernel. This is fine except for pins that need to be configured ASAP
after power-on. (The system could sit at the u-boot command prompt
indefinitely, so the kernel pin mux configuration can be significantly
delayed.). Please leave the hook so that u-boot customizers can
configure their critical pins muxes.
Regards,
Bob Feretich
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] OMAP3 Beagle Pin Mux initialization issue
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
0 siblings, 1 reply; 6+ messages in thread
From: Wolfgang Denk @ 2011-02-22 7:28 UTC (permalink / raw)
To: u-boot
Dear Bob Feretich,
In message <4D6316A8.4090900@prodigy.net> you wrote:
> The BeagleBoard beagle.c file contains:
> 242 /* Configure GPIOs to output */
> 243 writel(~(GPIO23 | GPIO10 | GPIO8 | GPIO2 | GPIO1),
> &gpio6_base->oe);
> 244 writel(~(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 |
> 245 GPIO15 | GPIO14 | GPIO13 | GPIO12), &gpio5_base->oe);
> 246
> 247 /* Set GPIOs */
> 248 writel(GPIO23 | GPIO10 | GPIO8 | GPIO2 | GPIO1,
> 249 &gpio6_base->setdataout);
> 250 writel(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 |
> 251 GPIO15 | GPIO14 | GPIO13 | GPIO12,
> &gpio5_base->setdataout);
>
> It first sets some pins as outputs and then initializes their values.
> This can cause narrow glitches on the output pins.
>
> To prevent the glitches the order should be reversed. First Set the
> GPIOs, then Configure them as outputs.
You are right. Can you please submit a patch? For instructions
please see http://www.denx.de/wiki/U-Boot/Patches
> Also, I have observed the discussion regarding moving Pin Mux control to
> the kernel. This is fine except for pins that need to be configured ASAP
> after power-on. (The system could sit at the u-boot command prompt
> indefinitely, so the kernel pin mux configuration can be significantly
> delayed.). Please leave the hook so that u-boot customizers can
> configure their critical pins muxes.
Which pins would that be, for example?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
But the only way of discovering the limits of the possible is to
venture a little way past them into the impossible.
- _Profiles of the Future_ (1962; rev. 1973)
``Hazards of Prophecy: The Failure of Imagination''
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] OMAP3 Beagle Pin Mux initialization issue
2011-02-22 7:28 ` Wolfgang Denk
@ 2011-02-25 21:44 ` Bob Feretich
2011-02-25 22:23 ` Albert ARIBAUD
0 siblings, 1 reply; 6+ messages in thread
From: Bob Feretich @ 2011-02-25 21:44 UTC (permalink / raw)
To: u-boot
Comments inline...
On 2/21/2011 11:28 PM, Wolfgang Denk wrote:
> Dear Bob Feretich,
>
> In message<4D6316A8.4090900@prodigy.net> you wrote:
>> ... snipped...
> You are right. Can you please submit a patch? For instructions
> please see http://www.denx.de/wiki/U-Boot/Patches
The patch was submitted.
>> Also, I have observed the discussion regarding moving Pin Mux control to
>> the kernel. This is fine except for pins that need to be configured ASAP
>> after power-on. (The system could sit at the u-boot command prompt
>> indefinitely, so the kernel pin mux configuration can be significantly
>> delayed.). Please leave the hook so that u-boot customizers can
>> configure their critical pins muxes.
> Which pins would that be, for example?
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.)
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.
Regards,
Bob Feretich
> Best regards,
>
> Wolfgang Denk
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] OMAP3 Beagle Pin Mux initialization issue
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
0 siblings, 2 replies; 6+ messages in thread
From: Albert ARIBAUD @ 2011-02-25 22:23 UTC (permalink / raw)
To: u-boot
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?
> 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.
> Regards,
> Bob Feretich
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] OMAP3 Beagle Pin Mux initialization issue
2011-02-25 22:23 ` Albert ARIBAUD
@ 2011-02-25 22:24 ` Albert ARIBAUD
2011-02-26 6:25 ` Bob Feretich
1 sibling, 0 replies; 6+ messages in thread
From: Albert ARIBAUD @ 2011-02-25 22:24 UTC (permalink / raw)
To: u-boot
(seems like I missed part of what I wanted to say)
Le 25/02/2011 23:23, Albert ARIBAUD a ?crit :
> Can you not simply set this time high enough that the U-Boot script
> executes?
... and then from bootcmd issue the mux writes that you need?
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] OMAP3 Beagle Pin Mux initialization issue
2011-02-25 22:23 ` Albert ARIBAUD
2011-02-25 22:24 ` Albert ARIBAUD
@ 2011-02-26 6:25 ` Bob Feretich
1 sibling, 0 replies; 6+ messages in thread
From: Bob Feretich @ 2011-02-26 6:25 UTC (permalink / raw)
To: u-boot
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,
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-02-26 6:25 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox