[U-Boot-Users] ppc4xx: gpio setup broken for ppc405ep

[Stefan Roese]

On Monday 31 March 2008, Markus Brunner wrote:
> > > Even worse you can't even
> > > have one which only takes care of the ppc440ep.
> >
> > ppc405ep?
>
> no typo, I ment ppc440ep

OK.

> > > Maybe I misunderstood the datasheet of the ppc440ep, so please correct
> > > me if I'm wrong.
> > > According to Table 29-6 on page 687 which lists the registers for the
> > > alternate1 function the tsrl bits for gpio 12 have to be 01, but for
> > > gpio 13 they have to be 00. Both are inputs and both are alt1, so I
> > > don't see how to find a rule to decide what value has to be set.
> >
> > I'm pretty sure that this is a documentation fault. Please contact AMCC
> > support on this.
>
> This could explain a lot. I'm already waiting for response from amcc - I
> let you know. If this is an error in the 440ep manual, then there are some
> in the 405ep manual, too.

Please keep me informed on this. Thanks.

<snip>

> > > This bugs probably could have been avoided if the addresses of the
> > > registers would have been defined with #else #error, at least we would
> > > have a scapegoat now, who defined the wrong addresses.
> > > So why not add this rule to the coding style?
> >
> > Not sure what you mean with this.
>
> Let the compiler fail with an error if an address wasn't defined explicitly
> for this CPU. But I'm going to write a separate email dedicated to this
> subject, so it gets enough attraction.

OK.

> > > Because no 405ep board uses config_gpio and only taihu uses
> > > gpio_set_chip_configuration, I think it would be best to undef this
> > > error prone functions and registers for 405ep.
> >
> > I don't think so.
>
> If the values for the registers follow a simple rule as described in the
> detailed register description and not as randomly as in the alternate
> function table I agree with you and it should get fixed.
>
> > > The registers defined
> > > in ppc405.h are correct,
> >
> > No, I don't think they are correct. These are the defines for 405EP (and
> > 405GP btw) in ppc405.h (I know this file is hell):
> >
> > #define GPIO_BASE  0xEF600700
> > #define GPIO0_OR               (GPIO_BASE+0x0)
> > #define GPIO0_TCR              (GPIO_BASE+0x4)
> > #define GPIO0_OSRH             (GPIO_BASE+0x8)
> > #define GPIO0_OSRL             (GPIO_BASE+0xC)
> > #define GPIO0_TSRH             (GPIO_BASE+0x10)
> > #define GPIO0_TSRL             (GPIO_BASE+0x14)
> > #define GPIO0_ODR              (GPIO_BASE+0x18)
> > #define GPIO0_IR               (GPIO_BASE+0x1C)
> > #define GPIO0_RR1              (GPIO_BASE+0x20)
> > #define GPIO0_RR2              (GPIO_BASE+0x24)
> > #define GPIO0_ISR1H            (GPIO_BASE+0x30)
> > #define GPIO0_ISR1L            (GPIO_BASE+0x34)
> > #define GPIO0_ISR2H            (GPIO_BASE+0x38)
> > #define GPIO0_ISR2L            (GPIO_BASE+0x3C)
> >
> >
> > And as you pointed out above, this is incorrect. High and low is swapped
> > here.
>
> ppc405ep doesn't have GPIO0_RR2, GPIO0_ISR2H and GPIO0_ISR2L, but the rest
> conforms with the datasheet, doesn't it?.

No. High and low *are* swapped. I just re-checked with users manual rev 1.08. 
GPIO0_OSRH has offset 0x0C and GPIO0_OSRL has offset 0x08. So this matches 
the offsets of all other 4xx GPIO registers I have seen so far.

> I think you got me wrong here.
> Here is a example. The numbers in brackets are the offsets for the OSR.
> The datasheet of 405ep says the address of the high register (0x08) is 4
> bytes lower than the low register (0x0C) and the high register is
> responsible for the pins 0-15.
> So if gpio_config, with the "broken" code tries to set something for gpio
> pin 0, it will try to access a low register (0x0C), because on the other
> cpus the low register is responsible for the pins 0-15. But on 405EP the
> high register is responsible for pins 0-15. So this is wrong.

Right. The 405EP documentation clearly states that the H register is 
responsible for pins 0-15 while on other 4xx PPC's the H register is 
responsible for pins 16-31.

I'm not really sure if this is true though since  Taihu is using  
gpio_set_chip_configuration() without known problems. Could you please 
re-check with AMCC support, if this statement for 405EP is correct? If this 
pin assignment of the 405EP GPIO block is incompatible with other GPIO cores, 
like the one on 440EP or 405EX.

I think we should first be totally sure about the register offsets and pin 
assignments before thinking about restructuring the code.

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================