In message OF860C514F.59EEA3B3-ON85256EDD.005E8AF9-85256EDD.005F7807@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 current code?
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.
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.
Best regards,
Wolfgang Denk