OMAP3 Beagle Pin Mux initialization issue
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
Dear Bob Feretich,
Quoted 14 lines · In message <[email protected]> you wrote:
The BeagleBoard
beagle.cfile 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);
Quoted 5 lines
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
Quoted 6 lines
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
Signature · 7 lines
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''Comments inline...
Quoted 6 lines · Wolfgang Denk
Dear Bob Feretich,
Quoted 1 line · In message<[email protected]> 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.
Quoted 7 lines
Quoted 6 lines
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
Quoted 4 lines
Best regards,
Wolfgang Denk
Le 25/02/2011 22:44, Bob Feretich a ?crit :
Quoted 7 lines
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?
Quoted 3 lines
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.
Quoted 2 lines
Regards,
Bob Feretich
Amicalement,
Signature · 1 line
Albert.
(seems like I missed part of what I wanted to say)
Le 25/02/2011 23:23, Albert ARIBAUD a ?crit :
Quoted 2 lines
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,
Signature · 1 line
Albert.
Comments inline...
Quoted 10 lines · Albert ARIBAUD
Le 25/02/2011 22:44, Bob Feretich a ?crit :
Quoted 7 lines
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?
Quoted 9 lines
Quoted 3 lines
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
Quoted 3 lines
Quoted 2 lines
Regards,
Bob FeretichAmicalement,