* [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