Okay Wolfgang,
I really like to resolve this issue and let's put our heads together to iron this out.
I admit I jumped too early into conclusion, nothing is wrong, just that it is working for all the units you've run u-boot on, and it is failing on my unit.
dictates my time be best spent leaving 0.4.8 happily running and
working on
other issues.
...which will make it more and more difficult for you to catch up.
I already know this WD, you don't have to remind me. =)
In any case if spi->spi_rpbase is set, it tells the CPM where the start
of
the SPI parameter RAM is, with respect to the start of the DPRAM, and
by
default it ain't 0x0.
Ummm... what _exactly_ is the sort of problem you have with the current code?
Maybe I should expand on the problem...
I'm current using a MPC852T Part #: 0x08 Mask #: 0x00
The problem I have is the SPI transfer never starts, even in the POST SPI test.
In MPC860UM rev.1 there is no mention of the RPBASE register in the SPI P-RAM section or any indication that Ucode patch is possible.
In MPC860UM rev.2 section 18.6.3 Paramter RAM it gives a note:
Relocation requires the appropriate microcode patch, availabe on the web at www.motorola.com on the MPC860 Product Summary page. For I2C/SPI relocation, the patch file is MPC860MC04.zip. For SMC/I2C/SPI relocation, the patch file is MPC860MC05.zip.
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.
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.
I tried a number of experiments. One in which I don't touch the register at all in u-boot, and let it run the POST SPI test and stop it before it has a chance to boot the kernel. The value I read from RPBASE via BDI is 0x1D80, the default SPI P-RAM offset.
And as I told you before if I change all the statement that clears RPBASE to setting it 0x1D80, everything works fine.
David
So with a small test, I replaced the statement with the default SPI
offset
spi->spi_rpbase = 0x1D80;The CPM has a much happier time dealing with this than 0x0.
AFAICT the CPM has little to do with that; if my suspicions are correct, your problems only show up when using some other SPI drivers, like in Linux?
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.