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