Trouble with SCC UART ports when moving from ppc to powerpc

Trouble with SCC UART ports when moving from ppc to powerpc

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]

Hi everybody,

I'm trying to move from ARCH=ppc to ARCH=powerpc on an MPC8272 based board.

I updated my bootloader (U-Boot) to get FDT support, wrote a device tree and 
compiled a powerpc kernel with CONFIG_PPC_CPM_NEW_BINDING set. No problem so 
far (well, no problem I haven't been able to solve).

I then tried to get the serial console on SCC1 to work. The serial port was 
silent, and the kernel hanged in cpm_uart_console_write while waiting for the 
CPM to clear the ready bit in tx buffer descriptors.

After checking the SCC1 configuration registers, parameter RAM and buffer 
descriptors, I found out that something was overwriting the buffer 
descriptors were stored in the DPRAM at offset 0.

Right after initializing the rx buffer descriptors, dumping the rx bds dpram 
with the BDI2000 gave me

90000088 003518e0 90000008 00351900
90000000 00351911 b5400000 2dace564

while I was expecting

90000088 003518e0 90000008 00351900
90000000 00351920 b0000000 00351940

Some data was clearly being overwritten by something.

The CPM dual port ram was defined in the device tree as follows (copied from 
the MPC8272ADS board device tree).

        muram@0 {
                #address-cells = <1>;
                #size-cells = <1>;
                ranges = <0 0 10000>;

                data@0 {
                        compatible = "fsl,cpm-muram-data";
                        reg = <0 2000 9800 800>;
                };
        };

Changing the reg property to

reg = <80 1f80 9800 800>;

fixed my problem.

Does anyone have any clue regarding what could write to the dpram ? I thought 
about some CPM peripheral set up by the boot loader, but my board 
initialization code calls cpm2_reset() long before initializing SCC1.

Best regards,

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Trouble with SCC UART ports when moving from ppc to powerpc

[Timur Tabi]

Laurent Pinchart wrote:

> Does anyone have any clue regarding what could write to the dpram ? I thought 
> about some CPM peripheral set up by the boot loader, but my board 
> initialization code calls cpm2_reset() long before initializing SCC1.

I'm not familar with the CPM, but in cpm_common.c are a bunch of functions to
manage memory allocated of the DPRAM.  You might want to see who's using those
functions, and how.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: Trouble with SCC UART ports when moving from ppc to powerpc

[Scott Wood]

On Fri, Mar 07, 2008 at 03:20:55PM +0100, Laurent Pinchart wrote:
> The CPM dual port ram was defined in the device tree as follows (copied from 
> the MPC8272ADS board device tree).
> 
>         muram@0 {
>                 #address-cells = <1>;
>                 #size-cells = <1>;
>                 ranges = <0 0 10000>;
> 
>                 data@0 {
>                         compatible = "fsl,cpm-muram-data";
>                         reg = <0 2000 9800 800>;
>                 };
>         };
> 
> Changing the reg property to
> 
> reg = <80 1f80 9800 800>;
> 
> fixed my problem.

Perhaps there's an SMC1 running with its parameter RAM at offset zero? 

> Does anyone have any clue regarding what could write to the dpram ? I thought 
> about some CPM peripheral set up by the boot loader, but my board 
> initialization code calls cpm2_reset() long before initializing SCC1.

cpm2_reset() doesn't currently actually reset the CPM, for some reason
(unlike cpm1).  This should probably be fixed, though then we'd have to
deal with assigning SMC parameter RAM addresses ourselves.

For now, the above fix should be done on any board with an active SMC
device (assuming SMC parameter RAM at zero, as u-boot sets it; other
bootloaders may need to exempt a different region).

-Scott

Re: Trouble with SCC UART ports when moving from ppc to powerpc

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]

On Friday 07 March 2008 17:21, Scott Wood wrote:
> On Fri, Mar 07, 2008 at 03:20:55PM +0100, Laurent Pinchart wrote:
> > The CPM dual port ram was defined in the device tree as follows (copied
> > from the MPC8272ADS board device tree).
> >
> >         muram@0 {
> >                 #address-cells = <1>;
> >                 #size-cells = <1>;
> >                 ranges = <0 0 10000>;
> >
> >                 data@0 {
> >                         compatible = "fsl,cpm-muram-data";
> >                         reg = <0 2000 9800 800>;
> >                 };
> >         };
> >
> > Changing the reg property to
> >
> > reg = <80 1f80 9800 800>;
> >
> > fixed my problem.
>
> Perhaps there's an SMC1 running with its parameter RAM at offset zero?

Good guess. U-Boot configured SMC1 with its parameter RAM at offset 0.

> > Does anyone have any clue regarding what could write to the dpram ? I
> > thought about some CPM peripheral set up by the boot loader, but my board
> > initialization code calls cpm2_reset() long before initializing SCC1.
>
> cpm2_reset() doesn't currently actually reset the CPM, for some reason
> (unlike cpm1).  This should probably be fixed, though then we'd have to
> deal with assigning SMC parameter RAM addresses ourselves.

I had overlooked that. Resetting the CPM in cpm2_reset() helps. Is there any 
reason not to rset the CPM in cpm2_reset() ?

How should SMC parameter RAM assignment be handled ? I'm not very familiar 
with the CPM1, but for CPM2 the cpm_uart driver could easily cpm_dpalloc() 
parameter RAM.

> For now, the above fix should be done on any board with an active SMC
> device (assuming SMC parameter RAM at zero, as u-boot sets it; other
> bootloaders may need to exempt a different region).

Thanks for your help.

Best regards,

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Trouble with SCC UART ports when moving from ppc to powerpc

[Scott Wood]

On Mon, Mar 10, 2008 at 01:17:01PM +0100, Laurent Pinchart wrote:
> On Friday 07 March 2008 17:21, Scott Wood wrote:
> > cpm2_reset() doesn't currently actually reset the CPM, for some reason
> > (unlike cpm1).  This should probably be fixed, though then we'd have to
> > deal with assigning SMC parameter RAM addresses ourselves.
> 
> I had overlooked that. Resetting the CPM in cpm2_reset() helps. Is there any 
> reason not to rset the CPM in cpm2_reset() ?

The only issue I'm aware of other than the SMC parameter RAM relocation is
that the reset can't happen if the early udbg printk is being used.

> How should SMC parameter RAM assignment be handled ? I'm not very familiar 
> with the CPM1, 

CPM1 has hardcoded SMC parameter RAM addresses, so it's not relevant here.

> but for CPM2 the cpm_uart driver could easily cpm_dpalloc() parameter RAM.

It can, yes.  Patches welcome. :-)

-Scott

Re: Trouble with SCC UART ports when moving from ppc to powerpc

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]

Hi Scott,

On Monday 17 March 2008 16:33, Scott Wood wrote:
> On Mon, Mar 10, 2008 at 01:17:01PM +0100, Laurent Pinchart wrote:
> > On Friday 07 March 2008 17:21, Scott Wood wrote:
> > > cpm2_reset() doesn't currently actually reset the CPM, for some reason
> > > (unlike cpm1).  This should probably be fixed, though then we'd have to
> > > deal with assigning SMC parameter RAM addresses ourselves.
> >
> > I had overlooked that. Resetting the CPM in cpm2_reset() helps. Is there
> > any reason not to rset the CPM in cpm2_reset() ?
>
> The only issue I'm aware of other than the SMC parameter RAM relocation is
> that the reset can't happen if the early udbg printk is being used.
>
> > How should SMC parameter RAM assignment be handled ? I'm not very
> > familiar with the CPM1,
>
> CPM1 has hardcoded SMC parameter RAM addresses, so it's not relevant here.
>
> > but for CPM2 the cpm_uart driver could easily cpm_dpalloc() parameter
> > RAM.
>
> It can, yes.  Patches welcome. :-)

I'm working on a patch. I'm not sure how to handle the early udbg printk 
problem, so the first version will just ignore it.

Best regards,

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Trouble with SCC UART ports when moving from ppc to powerpc

[Scott Wood]

On Thu, Mar 20, 2008 at 02:39:56PM +0100, Laurent Pinchart wrote:
> I'm working on a patch. I'm not sure how to handle the early udbg printk 
> problem, so the first version will just ignore it.

udbg printk is extremely useful... I'd not be fond of it breaking.

Perhaps we should stick more initialization into the cpm udbg code, so it
isn't so dependent on the bootloader setup... though we'd have push the
CPM reset and SMC allocation earlier in such a case.

-Scott

Re: Trouble with SCC UART ports when moving from ppc to powerpc

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 1376 bytes --]

On Thursday 20 March 2008 16:08, Scott Wood wrote:
> On Thu, Mar 20, 2008 at 02:39:56PM +0100, Laurent Pinchart wrote:
> > I'm working on a patch. I'm not sure how to handle the early udbg printk
> > problem, so the first version will just ignore it.
>
> udbg printk is extremely useful... I'd not be fond of it breaking.

I don't want to kill it either. What I meant is that my first patch will not 
care about udbg so that I can get feedback about the CPM serial driver part. 
I'll then see how to make udbg fit into that.

> Perhaps we should stick more initialization into the cpm udbg code, so it
> isn't so dependent on the bootloader setup... though we'd have push the
> CPM reset and SMC allocation earlier in such a case.

When SMC1 is used as a serial console, SMC1 is the first CPM dpram allocation 
user. This means the CPM dpram allocator will allocate a buffer at the 
beginning of the dpram. As he SMC controller will already be using the 64 
first bytes of the dpram, it will not see any difference when being 
reinitialized.

This of course depends on the boot loader allocating parameter ram at the 
beginning of the dpram for SMC1, but we already depend on that if I'm not 
mistaken.

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Trouble with SCC UART ports when moving from ppc to powerpc

[Scott Wood]

On Thu, Mar 20, 2008 at 04:18:26PM +0100, Laurent Pinchart wrote:
> I don't want to kill it either. What I meant is that my first patch will not 
> care about udbg so that I can get feedback about the CPM serial driver part. 
> I'll then see how to make udbg fit into that.

OK.

> > Perhaps we should stick more initialization into the cpm udbg code, so it
> > isn't so dependent on the bootloader setup... though we'd have push the
> > CPM reset and SMC allocation earlier in such a case.
> 
> When SMC1 is used as a serial console, SMC1 is the first CPM dpram
> allocation user.

Typically yes, but I wouldn't want to depend on that...

> This means the CPM dpram allocator will allocate a buffer at the beginning
> of the dpram. As he SMC controller will already be using the 64 first
> bytes of the dpram, it will not see any difference when being
> reinitialized.

Not always.  Planetcore, for example, puts SMC parameter RAM at 0x1100
rather than zero.

> This of course depends on the boot loader allocating parameter ram at the 
> beginning of the dpram for SMC1, but we already depend on that if I'm not 
> mistaken.

We don't depend on it -- it's specified in the smc node's reg property, and
in the absence of said regions in the muram node.

-Scott