Dear David,
in message OF5D5CE5D0.A860DE7D-ON85256EDE.0042486D-85256EDE.00453798@nanometrics.ca you wrote:
I'm current using a MPC852T Part #: 0x08 Mask #: 0x00
Gotcha.
The problem I have is the SPI transfer never starts, even in the POST SPI test.
I bet this code has never been tried on such a processor before, and I have to admit that I have no idea if the uCode mechanism is still the same or even compatible to some extend.
In MPC866UM rev1.1 section 18.7.3 Parameter RAM it states:
The SPI and I2C parameter RAM areas can be relocated to other 32-byte aligned parameter areas in dual-port RAM by programming their 16-bit base offsets, shown in Table 18-11.The note from the MPC860UM rev.2 has been removed, an indication that relocation of SPI can take place without the uCode patch.
I remember to have seen this, too. But never tried it out before.
There is no other mention of what value you should initialize it to at any time. So I don't understand where u-boot or any driver that relies on the testing RPBASE is 0 to indicate uCode patch application.
It may easily be possible that this methoid does not work any more on the new processors.
And as I told you before if I change all the statement that clears RPBASE to setting it 0x1D80, everything works fine.
...which is an indication that the processors are different enough to require different code.
But now I finally understand why you see so different results - it would have been really a good idea to mention earlier that you are on a 866...
Normally, Linux driver code will look like this:
... /* Check for and use a microcode relocation patch. */ if (spi->spi_rpbase) spi = (spi_t *)&cpmp->cp_dpmem[spi->spi_rpbase]; printk("cpm_spi: using microcode patch (spi_rpbase=0x%p)\n", spi); ...
Note that this code requires that spi_rpbase is initialized to 0 when no uCode patch is applied. And it seems to work fine on allour systems that use SPI.
... this will then fail, too.
Best regards,
Wolfgang Denk