Skip to contentSkip to conversation

Question about cpm reset on 8xx

DISCUSSION Per Hallsmark 2 participants 2 messages Feb 3, 2005

lore
Share & tools
lore

Per Hallsmark

author
#0 lore raw

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...

Quoted 58 lines

===== Original Message From Jaap-Jan Boor <[email protected]> =====

Quoted 32 lines · 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
     .......
Quoted 3 lines

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

Quoted 11 lines

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
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

#1 lore raw
Quoted 1 line · Per Hallsmark

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

Yeah, sorta.

Quoted 2 lines

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