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