RE: Question about cpm reset on 8xx

RE: Question about cpm reset on 8xx

[Per Hallsmark]

Thanks for replying,

Yes, probably the 8260 code evolved from the 8xx code?
Personally I like to code so logic is reset'd to a known base
even if that means we have to go through some setup steps again.

Of course, there could be a reason why it is like it is
and that's why I sent out the question...

We have a problem where hdlc sometimes seems to lookup, when the ppc
reboots it doesn't helps but after a while it is reseted by harder
means (pulling the resetline) which helps. Testing the change right now,
but it can take long time before it happens...

>===== Original Message From Jaap-Jan Boor <jjboor@aimsys.nl> =====
>On Thu, 2005-02-03 at 15:29, Per Hallsmark wrote:
>> Hi all,
>>
>> Working with a board using hdlc over SCC channel (852T) and kernel 2.4.21,
>> in the cpm reset code in arch/ppc/8xx_io/commproc.c it's like:
>>
>> void
>> m8xx_cpm_reset()
>> {
>>         volatile immap_t         *imp;
>>         volatile cpm8xx_t       *commproc;
>>         pte_t                   *pte;
>>
>>
>>         imp = (immap_t *)IMAP_ADDR;
>>         commproc = (cpm8xx_t *)&imp->im_cpm;
>>
>>
>> #ifdef CONFIG_UCODE_PATCH
>>         /* Perform a reset.
>>         */
>>         commproc->cp_cpcr = (CPM_CR_RST | CPM_CR_FLG);
>>
>>
>>         /* Wait for it.
>>         */
>>         while (commproc->cp_cpcr & CPM_CR_FLG);
>>
>>
>>         cpm_load_patch(imp);
>> #endif
>>      .......
>>
>> In our case, CONFIG_UCODE_PATCH is not defined so the commproc is never
>> reseted during reboot. Could it be that the #ifdef CONFIG_UCODE_PATCH
>> should just be around the cpm_load_patch command?
>
>It seems the author wants to reset the cpm only when microcode
>patches are needed.
>
>m8260_cpm_reset() does also not reset the cpm.
>
>I don't know why (e.g. the console is setup after this)
>
>Jaap-Jan
>
>> The CONFIG_UCODE_PATCH seems to point this to be i2c/spi patch, but
>> shouldn't a reset go to cpm in anycase?
>>
>> /Per
>>
>>
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Question about cpm reset on 8xx

[Dan Malek]

On Feb 3, 2005, at 10:02 AM, Per Hallsmark wrote:

> Yes, probably the 8260 code evolved from the 8xx code?

Yeah, sorta.

> Of course, there could be a reason why it is like it is
> and that's why I sent out the question...

It seems to be the personal preference of the last person that
make changes and checked in a patch.

Years ago, we used to always reset the cpm to eliminate
any microcode patches that may have been installed by the
boot rom.  We never knew what may be there, so drivers
would fail.

Later, I added a bunch of kgdb/xmon support for early kernel
debugging.  Due to this, we didn't want to reset the cpm because
we would rely on the boot rom initialization of the serial port
for communication.  The early serial functions just track down
the BDs and use them, regardless of how they were set up.
Lots of kernel code is run prior to the Linux configuration of the
serial ports, and we wanted to debug before that.

Now, I see this microcode patch again.  This is an old piece
of code, or perhaps a recent update to it.

So, the configuration issue is whether you want to run kdgb
or xmon for early kernel debugging.  If so, you don't want to
reset the cpm.  If there are microcode patches loaded by by
a boot rom, we probably want to reset the cpm.  If you are
loading your own patches, you must reset the cpm.  If you
want to run kgdb or xmon and load your own microcode
patches ... well, you have a challenge :-)

There may be some configuration logic that meets most
requirements, but it isn't going to be proper for everyone.
You may have to locally edit the files for your purpose,
which is true of several cpm related drivers.  You have the
source, use it! ;-)

Thanks.

	-- Dan

Question about cpm reset on 8xx

[Per Hallsmark]

Hi all,

Working with a board using hdlc over SCC channel (852T) and kernel 2.4.21,
in the cpm reset code in arch/ppc/8xx_io/commproc.c it's like:

void
m8xx_cpm_reset()
{
        volatile immap_t         *imp;
        volatile cpm8xx_t       *commproc;
        pte_t                   *pte;


        imp = (immap_t *)IMAP_ADDR;
        commproc = (cpm8xx_t *)&imp->im_cpm;

 
#ifdef CONFIG_UCODE_PATCH
        /* Perform a reset.
        */
        commproc->cp_cpcr = (CPM_CR_RST | CPM_CR_FLG);


        /* Wait for it.
        */
        while (commproc->cp_cpcr & CPM_CR_FLG);


        cpm_load_patch(imp);
#endif
     .......

In our case, CONFIG_UCODE_PATCH is not defined so the commproc is never
reseted during reboot. Could it be that the #ifdef CONFIG_UCODE_PATCH
should just be around the cpm_load_patch command?
The CONFIG_UCODE_PATCH seems to point this to be i2c/spi patch, but
shouldn't a reset go to cpm in anycase?

/Per

Re: Question about cpm reset on 8xx

[Jaap-Jan Boor]

On Thu, 2005-02-03 at 15:29, Per Hallsmark wrote:
> Hi all,
> 
> Working with a board using hdlc over SCC channel (852T) and kernel 2.4.21,
> in the cpm reset code in arch/ppc/8xx_io/commproc.c it's like:
> 
> void
> m8xx_cpm_reset()
> {
>         volatile immap_t         *imp;
>         volatile cpm8xx_t       *commproc;
>         pte_t                   *pte;
> 
> 
>         imp = (immap_t *)IMAP_ADDR;
>         commproc = (cpm8xx_t *)&imp->im_cpm;
> 
>  
> #ifdef CONFIG_UCODE_PATCH
>         /* Perform a reset.
>         */
>         commproc->cp_cpcr = (CPM_CR_RST | CPM_CR_FLG);
> 
> 
>         /* Wait for it.
>         */
>         while (commproc->cp_cpcr & CPM_CR_FLG);
> 
> 
>         cpm_load_patch(imp);
> #endif
>      .......
> 
> In our case, CONFIG_UCODE_PATCH is not defined so the commproc is never
> reseted during reboot. Could it be that the #ifdef CONFIG_UCODE_PATCH
> should just be around the cpm_load_patch command?

It seems the author wants to reset the cpm only when microcode 
patches are needed. 

m8260_cpm_reset() does also not reset the cpm.

I don't know why (e.g. the console is setup after this)

Jaap-Jan

> The CONFIG_UCODE_PATCH seems to point this to be i2c/spi patch, but
> shouldn't a reset go to cpm in anycase?
> 
> /Per
> 
> 
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded