[U-Boot-Users] Heads up for ppl using the cpu/mpc8xx/spi.c
Hi all,
For those who are using an old u-boot version 0.4.8 like me please be warned that the code somehow is setting a register (spi->spi_rpbase) for which there is no defined behaviour (good or bad) when the spi ucode patch is _not_ applied.
Apparently I hit on the bad behaviour where it just wouldn't work when spi_rpbase is set.
void spi_init_f (void) {
...
#ifdef CFG_SPI_UCODE_PATCH spi = (spi_t *)&cp->cp_dpmem[spi->spi_rpbase]; #else spi = (spi_t *)&cp->cp_dparam[PROFF_SPI]; /* Disable relocation */ #if THIS_IS_GIVING_ME_GRIEF spi->spi_rpbase = 0; #endif #endif
I hope most of you would agree this is causing more harm then good.
Regard, David Ho Nanometrics Inc.
In message OFFBF98B13.2D8DB2ED-ON85256EDD.00553965-85256EDD.0055DB25@nanometrics.ca you wrote:
For those who are using an old u-boot version 0.4.8 like me please be
Question 1: why are you using this old version?
Question 2: is your observation still relevant to current code?
warned that the code somehow is setting a register (spi->spi_rpbase) for which there is no defined behaviour (good or bad) when the spi ucode patch is _not_ applied.
What makes you think so?
#ifdef CFG_SPI_UCODE_PATCH spi = (spi_t *)&cp->cp_dpmem[spi->spi_rpbase]; #else spi = (spi_t *)&cp->cp_dparam[PROFF_SPI]; /* Disable relocation */ #if THIS_IS_GIVING_ME_GRIEF spi->spi_rpbase = 0; #endif #endif
I hope most of you would agree this is causing more harm then good.
As the comment explains, this code is intended to disable parameter RAM relocation in case the uCode patch is not used.
What exactly is your problem?
Best regards,
Wolfgang Denk
For those who are using an old u-boot version 0.4.8 like me please be
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 dictates my time be best spent leaving 0.4.8 happily running and working on other issues.
Question 2: is your observation still relevant to current code?
Good point, but that's way down in my priority list.
warned that the code somehow is setting a register (spi->spi_rpbase)
for
which there is no defined behaviour (good or bad) when the spi ucode
patch
is _not_ applied.
What makes you think so?
I was reading an old manual that ends at offset 0x24 TxTMP... will be more careful next time.
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.
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.
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.
David
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
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.
Dear David,
in message OF5D5CE5D0.A860DE7D-ON85256EDE.0042486D-85256EDE.00453798@nanometrics.ca you wrote:
I'm current using a MPC852T Part #: 0x08 Mask #: 0x00
Gotcha.
The problem I have is the SPI transfer never starts, even in the POST SPI test.
I bet this code has never been tried on such a processor before, and I have to admit that I have no idea if the uCode mechanism is still the same or even compatible to some extend.
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.
I remember to have seen this, too. But never tried it out before.
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.
It may easily be possible that this methoid does not work any more on the new processors.
And as I told you before if I change all the statement that clears RPBASE to setting it 0x1D80, everything works fine.
...which is an indication that the processors are different enough to require different code.
But now I finally understand why you see so different results - it would have been really a good idea to mention earlier that you are on a 866...
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.
... this will then fail, too.
Best regards,
Wolfgang Denk
participants (2)
-
David Ho -
Wolfgang Denk