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

(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.

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).
participants (2)
-
Stefan Roese
-
Tolunay Orkun