[U-Boot-Users] Heads up for ppl using the cpu/mpc8xx/spi.c
wd at denx.de
Mon Jul 26 23:46:17 CEST 2004
In message <OF860C514F.59EEA3B3-ON85256EDD.005E8AF9-85256EDD.005F7807 at nanometrics.ca> you wrote:
> > Question 1: why are you using this old version?
> I would love to go with a newer version but after patching in my changes to
> 1.0.2 u-boot doesn't boot, so I'm left with a business decision that
Well, U-Boot 1.0.2 is out of date, too.
> 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.
> 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
> 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. */
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.
> My original post is simply to warn people who are still using version
> 0.4.8. If someone has the time to check out the latest version of the code
> please feel free to do so.
This part of the code has not changed. Yet I don't see the problem.
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
"355/113 -- Not the famous irrational number PI, but an incredible
More information about the U-Boot