[U-Boot-Users] Microcode patches for mpc8xx

[U-Boot-Users] Microcode patches for mpc8xx

[Vladimir A. Gurevich]

Hello,

I have a couple of questions about RAM microcode patches for MPC8xx CPUs:

   1. What is EXACTLY the patch in cpu/mpc8xx/upatch.c. Specifically,
      which CPU(s) it is applicable to? I looked at a couple of recent
      patches available at Freescale website and none of them resembles
      the stuff in upatch.c
   2. My impression is that different CPUs need different patches. I can
      at least see patches for MPC823, MPC850, MPC860 and MPC862. That
      means that we probably need to check not only CFG_*_UCODE_PATCH,
      but also the corresponding CONFIG_ variable for the CPU. I am
      about to add the appropriate patch for my board, and thus I have
      to #ifdef the older one and I'd better do it right.
   3. I noticed that there is special handling for SPI and I2C, but how
      about SMC? I use SCC3 in the ethernet mode and SMC1 as a console
      and definitely have a problem. (A simple change to scc.c seems to
      have fixed the problem for now, but I'd like to have a cleaner
      solution).
   4. Finally, what is the assumption about Linux. Is it supposed to
      reset the CP and reload the patches?

Thanks,
Vladimir

[U-Boot-Users] Microcode patches for mpc8xx

[Wolfgang Denk]

In message <42901EE9.4090209@paulidav.org> you wrote:
> 
> I have a couple of questions about RAM microcode patches for MPC8xx CPUs:

This is a neglected area  in  U-Boot;  usually  U-Boot  needs  little
resources  and  uCode patches are needed at all. actually none of the
existing configurations seems to use the code.

>    1. What is EXACTLY the patch in cpu/mpc8xx/upatch.c. Specifically,
>       which CPU(s) it is applicable to? I looked at a couple of recent
>       patches available at Freescale website and none of them resembles
>       the stuff in upatch.c

The existing code was added to PPCBoot  as  part  of  the  GTH  board
support  on 2001/09/11, and never changed since. Interesting ewnough,
the GTH board does not use the code - nor does any other  board.  The
README  says  what  it is intended to do. The uCode itself is probaly
obsolete by now as it is at least as old as the code in the CVS.

>    2. My impression is that different CPUs need different patches. I can
>       at least see patches for MPC823, MPC850, MPC860 and MPC862. That
>       means that we probably need to check not only CFG_*_UCODE_PATCH,
>       but also the corresponding CONFIG_ variable for the CPU. I am
>       about to add the appropriate patch for my board, and thus I have
>       to #ifdef the older one and I'd better do it right.

You are right. See how it's implemented in our Linux tree.

>    3. I noticed that there is special handling for SPI and I2C, but how
>       about SMC? I use SCC3 in the ethernet mode and SMC1 as a console
>       and definitely have a problem. (A simple change to scc.c seems to
>       have fixed the problem for now, but I'd like to have a cleaner
>       solution).

I guess that was not available at the time this code was written.

>    4. Finally, what is the assumption about Linux. Is it supposed to
>       reset the CP and reload the patches?

This is what it's doing at the moment. One can ague if this is a good
idea or not.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I haven't lost my mind - it's backed up on tape somewhere."

[U-Boot-Users] Microcode patches for mpc8xx

[Thomas Lange]

Wolfgang Denk wrote:

>In message <42901EE9.4090209@paulidav.org> you wrote:
>  
>
>>I have a couple of questions about RAM microcode patches for MPC8xx CPUs:
>>    
>>
>
>This is a neglected area  in  U-Boot;  usually  U-Boot  needs  little
>resources  and  uCode patches are needed at all. actually none of the
>existing configurations seems to use the code.
>
>  
>
>>   1. What is EXACTLY the patch in cpu/mpc8xx/upatch.c. Specifically,
>>      which CPU(s) it is applicable to? I looked at a couple of recent
>>      patches available at Freescale website and none of them resembles
>>      the stuff in upatch.c
>>    
>>
>
>The existing code was added to PPCBoot  as  part  of  the  GTH  board
>support  on 2001/09/11, and never changed since. Interesting ewnough,
>the GTH board does not use the code - nor does any other  board.  The
>README  says  what  it is intended to do. The uCode itself is probaly
>obsolete by now as it is at least as old as the code in the CVS.
>  
>
I checked the patch I sent for the GTH board.
upatch.c was not included.
You probably just happened to add upatch.c from somewhere
else at the same time.
We have never used microcode patches for GTH.
CVS log:
--------------------------------------------------------------------------

Add cpu/mpc8xx/upatch.c which I forgot to check in.

Major modification for GTH board;
added CONFIG_RESET_TO_RETRY configuration option

--------------------------------------------------------------------------
Regards,
/Thomas

[U-Boot-Users] Microcode patches for mpc8xx

[Wolfgang Denk]

Dear Thomas,

in message <4290BDE8.8020102@corelatus.se> you wrote:
> 
> I checked the patch I sent for the GTH board.
> upatch.c was not included.

You are right, I didn't check carefully enough. It seems I  forgot  a
"cvs add" for the previous patchset, which reads:

...
Date: 2001/09/11 00:00:30
Log:
* Add I2C and SPI microcode relocation patches (MPC8xx)
  Based on a patch by Joakim Tjernlund, 23 Aug 2001
...

> You probably just happened to add upatch.c from somewhere
> else at the same time.

You are right. Sorry for the confusion.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A day without sunshine is like night.

[U-Boot-Users] Microcode patches for mpc8xx

[Dan Malek]

On May 22, 2005, at 4:38 AM, Wolfgang Denk wrote:

> In message <42901EE9.4090209@paulidav.org> you wrote:
>>    4. Finally, what is the assumption about Linux. Is it supposed to
>>       reset the CP and reload the patches?
>
> This is what it's doing at the moment. One can ague if this is a good
> idea or not.

We kind of have to do it again in Linux because we don't know what
was loaded or if it will match the drivers we have.   There are boards
that load CPM microcode patches, aren't running U-Boot, and would
often fail because we couldn't keep the Linux configuration or driver
modifications in sync with the board boot roms.

Thanks.


	-- Dan

[U-Boot-Users] Microcode patches for mpc8xx

[Wolfgang Denk]

Dear Dan,

in message <b612f49967c241b7139960e8a3144848@embeddededge.com> you wrote:
> 
> >>    4. Finally, what is the assumption about Linux. Is it supposed to
> >>       reset the CP and reload the patches?
> > This is what it's doing at the moment. One can ague if this is a good
> > idea or not.
> 
> We kind of have to do it again in Linux because we don't know what
> was loaded or if it will match the drivers we have.   There are boards
> that load CPM microcode patches, aren't running U-Boot, and would
> often fail because we couldn't keep the Linux configuration or driver
> modifications in sync with the board boot roms.

Yes, this is the major argument pro doing it in Linux, too.

Of course, for highly optimized systems where you  have  squeeze  the
memory  footprint  as  far as possible this is one of the areas where
one can save a few bytes.

Normally I too think that Linux should not make too many  assumptions
about the previous state of the hardware.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I program, therefore I am.

[U-Boot-Users] Microcode patches for mpc8xx

[Vladimir A. Gurevich]

Hello Wolfgang,

Wolfgang Denk wrote:

>This is a neglected area  in  U-Boot;  usually  U-Boot  needs  little
>resources  and  uCode patches are needed at all. actually none of the
>existing configurations seems to use the code.
>  
>
Yes, I noticed that too and was a little suprised. At least SMC1/SCC3 or 
SPI/SCC2 combinations should not be that uncommon...

Does that mean it's OK to mess up cpu/mpc8xx/upatch.c? How would you 
like to ifdef the original code?

I think that CFG_{SPI,I2C}_UCODE_PATCH config variables  make little 
sense. Instead, we should rely on CFG_{I2C,SPI}_DPMEM_OFFSET (and add 
another one for SMC) as well as the CPU type to decide whether a patch 
is needed and if yes, which one. Also, the code in the corresponding 
drivers will be changed to use RPBASE based not on the  fact that patch 
is there, but on whether the feature is supported. This will take care 
of MPC852T, that doesn't need a patch for SPI/I2C, but still needs one 
for SMC1. Is that OK?

>You are right. See how it's implemented in our Linux tree.
>  
>
I should've probably asked that on linuxppc-embedded, but since we are 
on this topic here: look like SMC relocation is explicitly not supported 
and I can't see the SPI driver as well (unless it reuses 8260 driver). 
So, while the ucode support seems to be more elaborate, I am not sure I 
understand how it is used. I am talking about linuxppc_2_4_devel tree 
here. Am I missing something?

>This is what it's doing at the moment. One can ague if this is a good idea or not.
>  
>
That's probably the safest way, though probably not the most efficient 
or elegant one.

Thanks,
Vladimir

[U-Boot-Users] Microcode patches for mpc8xx

[Wolfgang Denk]

Dear Vladimir,

in message <429182DA.4090207@paulidav.org> you wrote:
> 
> Yes, I noticed that too and was a little suprised. At least SMC1/SCC3 or 
> SPI/SCC2 combinations should not be that uncommon...

They are pretty uncommon.

> Does that mean it's OK to mess up cpu/mpc8xx/upatch.c? How would you 
> like to ifdef the original code?

No, it's NEVER ok to mess up any U-Boot code. But please feel free to
clean this up (you can probably use the Linux implementation  in  our
CVS tree as starting point).

> I think that CFG_{SPI,I2C}_UCODE_PATCH config variables  make little 
> sense. Instead, we should rely on CFG_{I2C,SPI}_DPMEM_OFFSET (and add 
> another one for SMC) as well as the CPU type to decide whether a patch 

Be careful. The requirements for ucode support have changed with  the
more recent versions of 8xx processors.

> is needed and if yes, which one. Also, the code in the corresponding 
> drivers will be changed to use RPBASE based not on the  fact that patch 
> is there, but on whether the feature is supported. This will take care 
> of MPC852T, that doesn't need a patch for SPI/I2C, but still needs one 
> for SMC1. Is that OK?

Probably. Let's see how it works...

> I should've probably asked that on linuxppc-embedded, but since we are 
> on this topic here: look like SMC relocation is explicitly not supported 
> and I can't see the SPI driver as well (unless it reuses 8260 driver). 

In our CVS tree? See the old linux-2.4 tree. We don't see  many  uses
of 8xx systems recently with ucode requirements.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
How long does it take a  DEC  field  service  engineer  to  change  a
lightbulb?       It depends on how many bad ones he brought with him.

Re: Microcode patches for mpc8xx

[Vladimir A. Gurevich]

Dear Wolfgang,

Wolfgang Denk wrote:

>>since we are on this topic here: look like SMC relocation is explicitly not supported and I can't see the SPI driver as well (unless it reuses 8260 driver). 
>>    
>>
>In our CVS tree? See the old linux-2.4 tree. We don't see  many  uses of 8xx systems recently with ucode requirements.
>  
>
I am completely puzzled now.  It looks like your stable, but old 
linux-2.4 tree has a much better selection of 8xx drivers compared to 
the linuxppc_2_4_devel. Why is that? What do you recommend for a new 
MPC852T-based development? Can the drivers be dropped into the newer 
tree or more serious backporting effort is needed?

Thanks,
Vladimir

Re: Microcode patches for mpc8xx

[Wolfgang Denk]

Dear Vladimir,

in message <4291DEAF.1080705@paulidav.org> you wrote:
> 
> >In our CVS tree? See the old linux-2.4 tree. We don't see  many  uses of 8xx systems recently with ucode requirements.
> >  
> >
> I am completely puzzled now.  It looks like your stable, but old 
> linux-2.4 tree has a much better selection of 8xx drivers compared to 
> the linuxppc_2_4_devel. Why is that? What do you recommend for a new 

This is because we  have  limited  resources,  and  do  those  things
(first)  where a customer is waiting (and paying) for. Not all of the
work that went into the old 2.4.4 tree was adapted  for  more  recent
versions  of  2.4  yet;  and  most  of  the 2.4 stuff got lost in 2.6
anyway.

> MPC852T-based development? Can the drivers be dropped into the newer 
> tree or more serious backporting effort is needed?

It depends. Most should work fine with minimal changes, but obviously
some effort for a code review and especially testing will be needed.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
core error - bus dumped