CPM2 early console

CPM2 early console

[Kalle Pokki]

Hello,

I'm trying to get vanilla 2.6.13.1 running on an EP8248 board without 
much success. I created my own platform files and have the kernel 
booting, but the execution is permanently stuck in the 
cpm_uart_console_write() function in the first while ((bdp->cbd_sc & 
BD_SC_READY) != 0) statement.

I don't have any COP debugger for this processor family, so the only 
debugging aid is the two leds onboard... It's clear that the buffer 
descriptor is not in sync with the CPM, but I have no clue what the 
address of the buffer descriptor is.

It seems this code is rather new, and I'm wondering if any of you have 
some patches that are not in the mainline kernel yet. Has anyone tested 
this with a 8248 processor? If so, could you please send your .config to 
me in case I made some errors in the platform definition.

RE: CPM2 early console

[Rune Torgersen]

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

There is a bug in the SMC init code, wher the base address for the SMC's
is not reinitialized by the kernel, so if the SMC is not initialized by
the bootloader, it will not work.

If that is the case, try this patch.

-----Original Message-----
From: Rune Torgersen 
Sent: Tuesday, August 23, 2005 15:19
To: linuxppc-embedded@ozlabs.org
Subject: [PATCH] ppc32: Fix baseaddress for SMC 1 and 2

Base addess register for SMC 1 and 2 are never initialized. 
This means that they will not work unless a bootloader already
configured them.
The DPRAM already have space reserved, this patch just makes sure 
the base addess register is updated correctly on initialization.

Signed-off-by: Rune Torgersen <runet@innovsys.com>


[-- Attachment #2: smc_baseparam.patch --]
[-- Type: application/octet-stream, Size: 1065 bytes --]

--- linux/drivers/serial/cpm_uart/cpm_uart_cpm2.c	2005-08-23 09:01:37.000000000 -0500
+++ linux-innsys/drivers/serial/cpm_uart/cpm_uart_cpm2.c	2005-08-23 15:11:14.000000000 -0500
@@ -257,6 +257,7 @@ int cpm_uart_init_portdesc(void)
 	cpm_uart_ports[UART_SMC1].smcp = (smc_t *) & cpm2_immr->im_smc[0];
 	cpm_uart_ports[UART_SMC1].smcup =
 	    (smc_uart_t *) & cpm2_immr->im_dprambase[PROFF_SMC1];
+	*(ushort *)(&cpm2_immr->im_dprambase[PROFF_SMC1_BASE]) = PROFF_SMC1;
 	cpm_uart_ports[UART_SMC1].port.mapbase =
 	    (unsigned long)&cpm2_immr->im_smc[0];
 	cpm_uart_ports[UART_SMC1].smcp->smc_smcm |= (SMCM_RX | SMCM_TX);
@@ -269,6 +270,7 @@ int cpm_uart_init_portdesc(void)
 	cpm_uart_ports[UART_SMC2].smcp = (smc_t *) & cpm2_immr->im_smc[1];
 	cpm_uart_ports[UART_SMC2].smcup =
 	    (smc_uart_t *) & cpm2_immr->im_dprambase[PROFF_SMC2];
+	*(ushort *)(&cpm2_immr->im_dprambase[PROFF_SMC2_BASE]) = PROFF_SMC2;
 	cpm_uart_ports[UART_SMC2].port.mapbase =
 	    (unsigned long)&cpm2_immr->im_smc[1];
 	cpm_uart_ports[UART_SMC2].smcp->smc_smcm |= (SMCM_RX | SMCM_TX);

Re: CPM2 early console

[Kumar Gala]

Rune's patch should be in 2.6.14-rc1 or greater.

- kumar

On Sep 22, 2005, at 11:02 AM, Rune Torgersen wrote:

> There is a bug in the SMC init code, wher the base address for the  
> SMC's
> is not reinitialized by the kernel, so if the SMC is not  
> initialized by
> the bootloader, it will not work.
>
> If that is the case, try this patch.
>
> -----Original Message-----
> From: Rune Torgersen
> Sent: Tuesday, August 23, 2005 15:19
> To: linuxppc-embedded@ozlabs.org
> Subject: [PATCH] ppc32: Fix baseaddress for SMC 1 and 2
>
> Base addess register for SMC 1 and 2 are never initialized.
> This means that they will not work unless a bootloader already
> configured them.
> The DPRAM already have space reserved, this patch just makes sure
> the base addess register is updated correctly on initialization.
>
> Signed-off-by: Rune Torgersen <runet@innovsys.com>
>
>
> <smc_baseparam.patch>
> <ATT296548.txt>
>

Re: CPM2 early console

[Kalle Pokki]

Rune Torgersen wrote:

>There is a bug in the SMC init code, wher the base address for the SMC's
>is not reinitialized by the kernel, so if the SMC is not initialized by
>the bootloader, it will not work.
>
>If that is the case, try this patch.
>  
>
The SMC was previously initialised, but I still upgraded to 2.6.14-rc2, 
which includes your patch. It still doesn't work, the buffer descriptor 
must be at a wrong address somehow since the board just hangs now in the 
same routine.

I did manage to decode the message coming to the console with the two 
leds onboard... it begun with "Linux ve", which at least looks like a 
good boot-up message :)

Re: CPM2 early console

[Kalle Pokki]

Is the alloc_bootmem() function in e.g. cpm_uart_allocbuf() supposed to 
give non-cached memory? In my 8248 board it seems not to. Only using 
DPRAM as buffer storage allows booting to proceed without hanging right 
in the beginning.

Any ideas what can set the bootmem memory as cached?

Re: CPM2 early console

[Dan Malek]

On Sep 27, 2005, at 10:11 AM, Kalle Pokki wrote:

> Is the alloc_bootmem() function in e.g. cpm_uart_allocbuf() supposed 
> to give non-cached memory? In my 8248 board it seems not to.

It provides cache coherent memory, whether it is cached or not
depends upon the capabilities of the cache controller and
peripherals.  On the 82xx, it is supposed to be cached.

>  Only using DPRAM as buffer storage allows booting to proceed without 
> hanging right in the beginning.

The only thing that would cause a problem is an
incorrect CPM configuration.

> Any ideas what can set the bootmem memory as cached?

All of memory is always cached on 82xx.  Which is fine
since the cache controller keeps the processor core
and peripherals coherent in hardware.

Thanks.

	-- Dan

Re: CPM2 early console

[Kalle Pokki]

Dan Malek wrote:

>
> On Sep 27, 2005, at 10:11 AM, Kalle Pokki wrote:
>
>> Any ideas what can set the bootmem memory as cached?
>
> All of memory is always cached on 82xx.  Which is fine
> since the cache controller keeps the processor core
> and peripherals coherent in hardware.

OK. Then the question really is why isn't the cache controller enforcing 
coherency between the G2_LE core and the CPM. While trying to debug the 
console driver I wrote a really simple SCC driver separated from the 
rest of the kernel in order to have a usable debug printf. And I 
couldn't get any buffers printed through the SCC until I started to use 
buffers in DPRAM. The CPM just didn't see anything I wrote to the 
buffers. The same thing seems to bother at least the console driver and 
the FCC ethernet driver (though they don't work at all for me at the 
moment..)

I think it is obvious I have misconfigured something, but at this point 
I am not even sure if it is something I should have initialised in the 
boot loader.

Re: CPM2 early console

[Dan Malek]

On Sep 27, 2005, at 4:35 PM, Kalle Pokki wrote:

> OK. Then the question really is why isn't the cache controller 
> enforcing coherency between the G2_LE core and the CPM.

Is the GBL and DTB set properly in the function code registers
of the SCC parameter ram?


	-- Dan

Re: CPM2 early console

[Kalle Pokki]

Dan Malek wrote:

> On Sep 27, 2005, at 4:35 PM, Kalle Pokki wrote:
>
>> OK. Then the question really is why isn't the cache controller 
>> enforcing coherency between the G2_LE core and the CPM.
>
> Is the GBL and DTB set properly in the function code registers
> of the SCC parameter ram?


The 60x bus is used, but snooping wasn't enabled before.

However, even after enabling snooping it still doesn't work right. If 
I'm just within my boot loader I still cannot use e.g. the SMC with WIMG 
bits 0010 and the GBL 1. If I set the write-through in WIMG bits as 
1010, it works. The core now sees the RX buffers from the CPM and, of 
course, my TX buffers since they are written to the memory.

I guess Linux remaps the RAM as copy-back. But snooping should work with 
copy-back caches, shouldn't it?

Re: CPM2 early console

[Kalle Pokki]

Kalle Pokki wrote:

> I guess Linux remaps the RAM as copy-back. But snooping should work 
> with copy-back caches, shouldn't it?

Oh, well. The kernel boots just fine if I add

flags |= _PAGE_WRITETHRU | _PAGE_COHERENT;

in setbat() in arch/ppc/mm/ppc_mmu.c. But this should not depend on this 
kind of a hack, should it?

Re: CPM2 early console

[Dan Malek]

On Sep 29, 2005, at 8:24 AM, Kalle Pokki wrote:

> flags |= _PAGE_WRITETHRU | _PAGE_COHERENT;
>
> in setbat() in arch/ppc/mm/ppc_mmu.c. But this should not depend on 
> this kind of a hack, should it?

This is clearly wrong since other 82xx processors work fine.  Something
is amiss with your boot rom or other setup of this processor.

Thanks.

	-- Dan

Re: CPM2 early console

[Alex Zeffertt]

On Thu, 29 Sep 2005 14:24:07 +0200
Kalle Pokki <kalle.pokki@iki.fi> wrote:

> Kalle Pokki wrote:
> 
> > I guess Linux remaps the RAM as copy-back. But snooping should
> > work with copy-back caches, shouldn't it?
> 
> Oh, well. The kernel boots just fine if I add
> 
> flags |= _PAGE_WRITETHRU | _PAGE_COHERENT;
> 
> in setbat() in arch/ppc/mm/ppc_mmu.c. But this should not depend on
> this kind of a hack, should it?
> 

I was experiencing a similar problem with the mpc8260sar ATM driver,
and Kalle's hack seems to fix the problem.

On the 8260 ATM SAR you can specify that the CPM asserts the GBL
signal whenever it accesses buffers, BDs, or interrupt queues. This
allows the cache to snoop accesses to these areas and invalidate cache
lines to keep the cache coherent.

However, there seems to be no way of telling the CPM to assert the GBL
signal when it is accessing External Connection Tables, or Second
Level lookup Tables - both of which are also accessed by the core.

Because of this the cache does not know when the CPM is accessing
these areas.

It seems to me that whilst the CPM was designed to be cache coherent
Freescale have overlooked some areas!

Till now I have worked around this problem by calling
dcache_invalidate_range() and dcache_flush_range() before and after
accesses to these areas.  I'm now considering changing to Kalle's way
of doing it.

Are there any drawbacks to this approach?

TIA,

Alex Zeffertt

Re: CPM2 early console

[Alex Zeffertt]

On Fri, 30 Sep 2005 14:22:18 +0100
Alex Zeffertt <ajz@cambridgebroadband.com> wrote:

> Till now I have worked around this problem by calling
> dcache_invalidate_range() and dcache_flush_range() before and after
> accesses to these areas.  I'm now considering changing to Kalle's
> way of doing it.
> 
> Are there any drawbacks to this approach?


To answer my own question: yes there is a drawback.

I've just done some performance tests on my driver.  In the first
test the driver uses invalidate/flush calls to keep the cache
coherent. In the second test I just use Kalle's mod to setbat().

In the second test the perfomance of the driver is roughly 1/3 of the
performance in the first test.

What I really want is a way of asserting GBL whenever the CPM accesses
ANY memory area other than DPRAM.  Hm.

Alex

Re: CPM2 early console

[Dan Malek]

On Sep 30, 2005, at 9:22 AM, Alex Zeffertt wrote:

> Are there any drawbacks to this approach?

The general system performance is going to suffer,
and if you really have a cache coherency problem
it only solves the write case and not the read case.


	-- Dan

Re: CPM2 early console

[Kalle Pokki]

Dan Malek wrote:

> On Sep 30, 2005, at 9:22 AM, Alex Zeffertt wrote:
>
>> Are there any drawbacks to this approach?
>
> The general system performance is going to suffer,
> and if you really have a cache coherency problem
> it only solves the write case and not the read case.

The read case seems to be solved by setting the appropriate GBL bits in 
the parameter ram areas, since the buffers work correctly in both 
directions by just setting cache write-through and coherent (coherent 
alone won't help). Still, there must be a correct way of doing this, but 
I think I have already tried modifying every register that sounds 
related. The errata doesn't list anything useful.

Another way of getting around the problem would be to place the buffers 
in a cache-inhibited memory area and have copy-back caches for other 
data. I successfully tried this in another application without Linux.

Re: CPM2 early console

[Kalle Pokki]

Alex Zeffertt wrote:

>>Are there any drawbacks to this approach?
>>    
>>
>
>
>To answer my own question: yes there is a drawback.
>  
>
Yes it's not so good for performance. I would be better no just 
cache-inhibit some specific memory areas.

Do you have more than one board to test this with? I only have one now, 
and this seems so odd I almost suspect a hardware flaw... but usually 
when I say this aloud it almost certainly turns out to be just a trivial 
software bug :)

Re: CPM2 early console

[Dan Malek]

On Sep 30, 2005, at 4:10 PM, Kalle Pokki wrote:

> ..... Still, there must be a correct way of doing this, but I think I 
> have already tried modifying every register that sounds related. The 
> errata doesn't list anything useful.

I just built an 8250. 8260, and 8270 from a very recent 2.6 tree today 
and they
all worked fine.  They all had different serial port configurations 
(SMC1, SCC1
and SCC2).  Two were u-boot and one was a proprietary boot rom.
So, the "problem" seems to be related to something unique with your 
system.

> .... I successfully tried this in another application without Linux.

This is code that has existed for many years in Linux and appears to 
continue
to work fine.  We need to identify what is causing the problem in your
environment, not look for some hack around it.

Thanks.

	-- Dan

Re: CPM2 early console

[Kalle Pokki]

Dan Malek wrote:

> I just built an 8250. 8260, and 8270 from a very recent 2.6 tree today 
> and they
> all worked fine.  They all had different serial port configurations 
> (SMC1, SCC1
> and SCC2).  Two were u-boot and one was a proprietary boot rom.
> So, the "problem" seems to be related to something unique with your 
> system.

Yes I'm sure the code in Linux is right. It may be missing some 
initialisation it depends on, but anyway.

My board is an Embedded Planet EP8248 that came with a pre-installed 
version of Linux 2.4. That version works ok, though I don't know what 
modifications were made to the kernel. The source wasn't included...

Currently I boot with PlanetCore, load my own boot loader (I'm going to 
use it exclusively when my own custom board based on 8247 comes out) via 
tftp, and start the most recent kernel.org kenel from it.

Re: CPM2 early console

[Roger Larsson]

On Saturday 01 October 2005 07.57, Kalle Pokki wrote:
> Dan Malek wrote:
> > I just built an 8250. 8260, and 8270 from a very recent 2.6 tree today
> > and they
> > all worked fine.  They all had different serial port configurations
> > (SMC1, SCC1
> > and SCC2).  Two were u-boot and one was a proprietary boot rom.
> > So, the "problem" seems to be related to something unique with your
> > system.
>
> Yes I'm sure the code in Linux is right. It may be missing some
> initialisation it depends on, but anyway.
>
> My board is an Embedded Planet EP8248 that came with a pre-installed
> version of Linux 2.4. That version works ok, though I don't know what
> modifications were made to the kernel. The source wasn't included...
>

That is a violation of the GPL license, developers could sue them for
copyright infringement.
(One other alternative is that you should have gotten info on how
to get the source)

/RogerL

Re: CPM2 early console

[Dan Malek]

On Oct 1, 2005, at 1:57 AM, Kalle Pokki wrote:

> Yes I'm sure the code in Linux is right. It may be missing some 
> initialisation it depends on, but anyway.

Did you mention in the past you have a custom boot loader?  Is this 
something
other than the PlanetCore boot rom?

> My board is an Embedded Planet EP8248 that came with a pre-installed 
> version of Linux 2.4. That version works ok, though I don't know what 
> modifications were made to the kernel. The source wasn't included...

I doubt they made any modifications to the generic driver.  The only 
thing
they may have done is added some board control register/GPIO to enable
the RS-232 transceiver.  If you don't have their board initialization 
functions,
though, this would be useful.

> Currently I boot with PlanetCore, load my own boot loader (I'm going 
> to use it exclusively when my own custom board based on 8247 comes 
> out) via tftp, and start the most recent kernel.org kenel from it.

What about just trying to boot the new kernel from PlanetCore boot rom?

Of course, if you are doing your own boot rom and have a board to bring 
up,
you should have invested in something like a BDI2000 long ago because 
it will
have paid for itself many times over by the time you are done :-)  It 
would have
also allowed you to debug this problem rather quickly.

You are going to have to investigate your processor state prior to 
calling
Linux (HIDx registers, cache and MMU state, SIU configuration, etc) to 
see
how it differs from what PlanetCore does.  There are lots and lots of 
options
on these processors, and one bit in one configuration register that is
incorrect can cause lots of grief.


	-- Dan

Re: CPM2 early console

[Kalle Pokki]

Dan Malek wrote:

> What about just trying to boot the new kernel from PlanetCore boot rom?


I do use PlanetCore to boot the system. Basically the only funtionality 
in my own custom boot loader with this board is to carry the image of 
the Linux kernel, decompress, and launch it. I have disabled all the 
initialisation code since it was previously written for another board, 
and PlanetCore does all the initialisations anyway. I didn't care to 
erase PlanetCore from the flash just yet, since I can just as well 
develop the real initialisations later with the custom board.

PlanetCore itself is not usable for booting any other Linux kernel than 
the pre-installed one. It just allows me to launch some launcher of the 
Linux kernel... Probably it's the launcher that does the tricks to make 
Linux run correctly.

> Of course, if you are doing your own boot rom and have a board to 
> bring up,
> you should have invested in something like a BDI2000 long ago because 
> it will
> have paid for itself many times over by the time you are done :-)  It 
> would have
> also allowed you to debug this problem rather quickly.
>
You are right, this would be a lot easier with a good debugger. I just 
have delayed purchasing it since I wasn't previously sure if we'd use 
the PowerQUICC II family or not. I already have Lauterbach for 8xx, but 
the Linux community seems to prefer the BDI2000. Do you know if it fits 
better in Linux development? At least it seems to be a lot less 
expensive than a new Lautherbach license for the 82xx family.

Re: CPM2 early console

[Kalle Pokki]

I found it. It's in the MPC8272 family errata. When setting pipeline 
depth to one everything works. Can you Alex confirm this works also for 
you? This errata should probably be included in the Linux kernel, since 
it really depends on it. Right now I set this from the boot loader, but 
perhaps head.S in the kernel would be the just as good.

Part I System Interface Unit (SIU) Errata
SIU18: ARTRY assertion when using pipeline depth of 0.
Devices:
MPC8272, MPC8271, MPC8248, MPC8247
Description:
Internal (60x) slave maintains a pipeline depth of zero by asserting 
AACK only after TA. When ARTRY is
asserted, the 60x bus access is terminated and TA is not asserted. The 
internal (60x) slave does not assert
AACK, since TA was not asserted.
Workaround:
Use a pipeline depth of one (BCR[PLDP]=0) for applications that require 
memory coherency.
Fix Plan:
No fix plan at this time.

Re: CPM2 early console

[Alex Zeffertt]

On Tue, 04 Oct 2005 10:13:10 +0200
Kalle Pokki <kalle.pokki@iki.fi> wrote:

> I found it. It's in the MPC8272 family errata. When setting pipeline
> depth to one everything works. Can you Alex confirm this works also
> for you? 

Hi Kalle,  I've just checked and it makes no difference to the ATM
driver.  In fact, on my platform (PM828+u-boot-1.1.3) the pipeline
depth was already set to 1.

You are probably right that the pipeline depth was the cause of your
problem- but my problem is something else.  I think that Freescale
simply overlooked the ATM external connection table case when
designing the cache coherency protocol - because they offered no way
to assert GBL when external connection tables are accessed.

Alex

Re: CPM2 early console

[Kalle Pokki]

Alex Zeffertt wrote:

>Hi Kalle,  I've just checked and it makes no difference to the ATM
>driver.  In fact, on my platform (PM828+u-boot-1.1.3) the pipeline
>depth was already set to 1.
>
>You are probably right that the pipeline depth was the cause of your
>problem- but my problem is something else.  I think that Freescale
>simply overlooked the ATM external connection table case when
>designing the cache coherency protocol - because they offered no way
>to assert GBL when external connection tables are accessed.
>  
>
The ATM in 8260 seems to have a huge errata list. Just quickly looking 
at those at least CPM71: CPM does not snoop MCC buffer descriptors 
sounds related, but it may be some other issue also. Do you already use 
the microcode patch provided by Freescale?

I'm confident my problem was fixed with the correct setting of the 
pipeline depth. I had trouble with everything related to cache 
coherency, not just a single communication protocol.

Re: CPM2 early console

[Dan Malek]

On Oct 4, 2005, at 1:13 AM, Kalle Pokki wrote:

> ...... This errata should probably be included in the Linux kernel, 
> since it really depends on it.

Everything depends on that, and it should be done in the boot rom as
part of the processor initialization after reset.

Thanks.

	-- Dan