[ECOS] PPC852T port pin configuration questions

[ECOS] PPC852T port pin configuration questions

[Steve Strublic]

Hi,

I was investigating an issue with our product, that is using eCos and the PowerPC 852T.  I traced it
down to a specific area of code that configures ports A, B, and C.

The specific code is in hal/powerpc/mpx8xx/.../src/var_misc.c, and is specific to the 852T.

#if defined(CYGHWR_HAL_POWERPC_MPC8XX_852T) && !defined(CYG_HAL_STARTUP_RAM)
    // Only do this if we are not a RAM startup, otherwise we risk
    // disturbing settings made by RedBoot.
    // Special settings - according to manual errata
    eppc->pio_papar &= ~0xffffffff;   // PA manatory settings
    eppc->pio_padir |=  0xffffffff;

    eppc->pip_pbpar &= ~0x0003ff07;   // PB29..31 AS GPIO
    eppc->pip_pbdir |=  0x0003ff07;
    eppc->pip_pbdat  =  0x00010007;

    eppc->pio_pcpar &= ~0xffffffff;   // PC manatory settings
    eppc->pio_pcdir |=  0xffffffff;
#endif

Our specific issue is that these are interrupt-capable inputs in our product, and the hardware pulls
the pins to that state.  Forcing the pins as outputs without completely configuring the PCSO
register causes the pins to reach a state that is neither zero or one.

I looked through the errata for the 866/852T and I don't see the need to perform this operation.  I
saw no specific errata that stated the values of ports A/B/C/D were unknown at startup.

In fact, the configuration of port C as all outputs is a specific danger, as they default to inputs
at powerup.  Driving them as outputs may prevent them from being configured as spurious interrupt
sources, but in truth the PPC defaults them as general-purpose inputs with no interrupt capability.
And I don't understand the desire to force ports A and B to their configurations above... I could
not locate any references in any errata or manual.

Also, not everyone uses Redboot to boot their product... we aren't.  This causes a difficulty when
powering up a RAM-based image that does not use Redboot.

I appreciate any assistance in explaining the desire and logic behind the decisions which required
this implementation, and any offers of assistance to resolve the situation.

Thanks in advance,

Steve Strublic
sstrublic@hypercom.com

--------

"It only takes one person, one division, one group to change the whole company." --Phillip Crosby's
'Reflections on Quality', #248


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] PPC852T port pin configuration questions

[Gary Thomas]

On Thu, 2004-09-16 at 16:59, Steve Strublic wrote:
> 
> 
> Hi,
> 
> I was investigating an issue with our product, that is using eCos and the PowerPC 852T.  I traced it
> down to a specific area of code that configures ports A, B, and C.
> 
> The specific code is in hal/powerpc/mpx8xx/.../src/var_misc.c, and is specific to the 852T.
> 
> #if defined(CYGHWR_HAL_POWERPC_MPC8XX_852T) && !defined(CYG_HAL_STARTUP_RAM)
>     // Only do this if we are not a RAM startup, otherwise we risk
>     // disturbing settings made by RedBoot.
>     // Special settings - according to manual errata
>     eppc->pio_papar &= ~0xffffffff;   // PA manatory settings
>     eppc->pio_padir |=  0xffffffff;
> 
>     eppc->pip_pbpar &= ~0x0003ff07;   // PB29..31 AS GPIO
>     eppc->pip_pbdir |=  0x0003ff07;
>     eppc->pip_pbdat  =  0x00010007;
> 
>     eppc->pio_pcpar &= ~0xffffffff;   // PC manatory settings
>     eppc->pio_pcdir |=  0xffffffff;
> #endif
> 
> Our specific issue is that these are interrupt-capable inputs in our product, and the hardware pulls
> the pins to that state.  Forcing the pins as outputs without completely configuring the PCSO
> register causes the pins to reach a state that is neither zero or one.
> 
> I looked through the errata for the 866/852T and I don't see the need to perform this operation.  I
> saw no specific errata that stated the values of ports A/B/C/D were unknown at startup.
> 
> In fact, the configuration of port C as all outputs is a specific danger, as they default to inputs
> at powerup.  Driving them as outputs may prevent them from being configured as spurious interrupt
> sources, but in truth the PPC defaults them as general-purpose inputs with no interrupt capability.
> And I don't understand the desire to force ports A and B to their configurations above... I could
> not locate any references in any errata or manual.
> 
> Also, not everyone uses Redboot to boot their product... we aren't.  This causes a difficulty when
> powering up a RAM-based image that does not use Redboot.
> 
> I appreciate any assistance in explaining the desire and logic behind the decisions which required
> this implementation, and any offers of assistance to resolve the situation.

I don't recall right off why I did this, but it seems clear now that
it should go in platform code, not the variant code.  I'll move it
to the only public 852T (the A&M Adder)

That said, the current CVS doesn't match what you've quoted above.
What codebase are you working from?

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

re: [ECOS] PPC852T port pin configuration questions

[Steve Strublic]

Hi Gary,

Thanks for making the update.  It was a little perplexing.

This code snippet came from eCos 2.0.9.

Steve


On Thu, 2004-09-16 at 16:59, Steve Strublic wrote:
>
>
> Hi,
>
> I was investigating an issue with our product, that is using eCos and the PowerPC 852T.  I traced
it
> down to a specific area of code that configures ports A, B, and C.
>
> The specific code is in hal/powerpc/mpx8xx/.../src/var_misc.c, and is specific to the 852T.
>
> #if defined(CYGHWR_HAL_POWERPC_MPC8XX_852T) && !defined(CYG_HAL_STARTUP_RAM)
>     // Only do this if we are not a RAM startup, otherwise we risk
>     // disturbing settings made by RedBoot.
>     // Special settings - according to manual errata
>     eppc->pio_papar &= ~0xffffffff;   // PA manatory settings
>     eppc->pio_padir |=  0xffffffff;
>
>     eppc->pip_pbpar &= ~0x0003ff07;   // PB29..31 AS GPIO
>     eppc->pip_pbdir |=  0x0003ff07;
>     eppc->pip_pbdat  =  0x00010007;
>
>     eppc->pio_pcpar &= ~0xffffffff;   // PC manatory settings
>     eppc->pio_pcdir |=  0xffffffff;
> #endif
>
> Our specific issue is that these are interrupt-capable inputs in our product, and the hardware
pulls
> the pins to that state.  Forcing the pins as outputs without completely configuring the PCSO
> register causes the pins to reach a state that is neither zero or one.
>
> I looked through the errata for the 866/852T and I don't see the need to perform this operation.
I
> saw no specific errata that stated the values of ports A/B/C/D were unknown at startup.
>
> In fact, the configuration of port C as all outputs is a specific danger, as they default to
inputs
> at powerup.  Driving them as outputs may prevent them from being configured as spurious interrupt
> sources, but in truth the PPC defaults them as general-purpose inputs with no interrupt
capability.
> And I don't understand the desire to force ports A and B to their configurations above... I could
> not locate any references in any errata or manual.
>
> Also, not everyone uses Redboot to boot their product... we aren't.  This causes a difficulty when
> powering up a RAM-based image that does not use Redboot.
>
> I appreciate any assistance in explaining the desire and logic behind the decisions which required
> this implementation, and any offers of assistance to resolve the situation.

I don't recall right off why I did this, but it seems clear now that
it should go in platform code, not the variant code.  I'll move it
to the only public 852T (the A&M Adder)

That said, the current CVS doesn't match what you've quoted above.
What codebase are you working from?

--
Gary Thomas <gary@mlbassoc.com>
MLB Associates



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss