This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
re: PPC852T port pin configuration questions
- From: Steve Strublic <SStrublic at Hypercom dot com>
- To: ecos-discuss at sources dot redhat dot com
- Cc: gary at mlbassoc dot com
- Date: Fri, 17 Sep 2004 10:04:12 -0700
- Subject: re: [ECOS] PPC852T port pin configuration questions
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