[U-Boot-Users] Heads up for ppl using the cpu/mpc8xx/spi.c
DavidHo at nanometrics.ca
Tue Jul 27 14:36:01 CEST 2004
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
> > dictates my time be best spent leaving 0.4.8 happily running and
> > 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
> > the SPI parameter RAM is, with respect to the start of the DPRAM, and
> > 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
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
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.
> > So with a small test, I replaced the statement with the default SPI
> > 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.
More information about the U-Boot