[U-Boot-Users] Microcode patches for mpc8xx
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
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.
- 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.
- 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.
- 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.
- 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
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.
- 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
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
On May 22, 2005, at 4:38 AM, Wolfgang Denk wrote:
In message 42901EE9.4090209@paulidav.org you wrote:
- 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
Dear Dan,
in message b612f49967c241b7139960e8a3144848@embeddededge.com you wrote:
- 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
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
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
participants (4)
-
Dan Malek -
Thomas Lange -
Vladimir A. Gurevich -
Wolfgang Denk