[U-Boot-Users] ppc4xx: Initializing GPIO0_OR and GPIO0_ODR

[U-Boot-Users] ppc4xx: Initializing GPIO0_OR and GPIO0_ODR

[Tolunay Orkun]

(Note: This is specific to PPC405EP but it might be applicable to other 
4xx cpus)

On a PPC405EP based boards, U-Boot is initializing below registers to 
select between primary and alternate functions of the GPIO pins (e.g. 
GPIO10 vs CS1) using the CFG_CPIO0_... macros defined in the board 
config file.

GPIO0_TCR, GPIO0_OSRH, GPIO0_OSRL, GPIO0_TSRH, GPIO0_TSRL, GPIO0_ISR1H, 
GPIO0_ ISR1L

This much is sufficient for alternate function programming. However, if 
a the GPIO pin is actually used as GPIO output pin, the initial signal 
level presented happens to be "0" which may not be appropriate for some 
implementations.

I propose to introduce CFG_GPIO0_OR and CFG_CPIO0_ODR macros that could 
be defined in the appropriate board config file and initialize GPIO0_OR 
and GPIO0_ODR before GPIO0_TCR. If these macros are undefined the 
existing code behavior could be maintained so the additional macros 
would not break any existing board or add any additional code.

I will be introducing a patch to take care of this but I wanted to get 
feedback first.

FYI: For our board, we have a GPIO line connected to an active low reset 
line of a custom ASIC chip. There is a pull-up so during the time while 
this pin is tri-state/input we should not reset the ASIC automatically 
while management processor is booting. Our ASIC can operate 
independently while the management processor is booting.

[U-Boot-Users] ppc4xx: Initializing GPIO0_OR and GPIO0_ODR

[Stefan Roese]

Hi Tolunay,

On Friday, 7. April 2006 01:00, Tolunay Orkun wrote:
> On a PPC405EP based boards, U-Boot is initializing below registers to
> select between primary and alternate functions of the GPIO pins (e.g.
> GPIO10 vs CS1) using the CFG_CPIO0_... macros defined in the board
> config file.
>
> GPIO0_TCR, GPIO0_OSRH, GPIO0_OSRL, GPIO0_TSRH, GPIO0_TSRL, GPIO0_ISR1H,
> GPIO0_ ISR1L
>
> This much is sufficient for alternate function programming. However, if
> a the GPIO pin is actually used as GPIO output pin, the initial signal
> level presented happens to be "0" which may not be appropriate for some
> implementations.
>
> I propose to introduce CFG_GPIO0_OR and CFG_CPIO0_ODR macros that could
> be defined in the appropriate board config file and initialize GPIO0_OR
> and GPIO0_ODR before GPIO0_TCR. If these macros are undefined the
> existing code behavior could be maintained so the additional macros
> would not break any existing board or add any additional code.

Sounds good to me.

> I will be introducing a patch to take care of this but I wanted to get
> feedback first.

Please send your patch.

Best regards,
Stefan

PS: Did you happen to take a look at the recent changes I made to the 
cfi_flash driver? Now the Intel "legacy lock/unlocking" is supported. Please 
let me know if you see any problems with these changes (I could only test on 
J3 FLASH's with legacy unlocking).