[U-Boot-Users] Heads up for ppl using the cpu/mpc8xx/spi.c

[David Ho]

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.
>