[U-Boot-Users] [PATCH][resubmit] MPC85xx, MPC83xx: Add/Fix UPM configuration support

Add support for UPM configuration on the 85xx platform. In addition, on the MPC83xx, remove MPC834x precompiler condition, in order to support all MPC83xx processors.
Signed-off-by: David Saada david.saada@ecitele.com
cpu/mpc83xx/cpu.c | 5 ---- cpu/mpc85xx/cpu.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ include/mpc85xx.h | 7 ++++- 3 files changed, 72 insertions(+), 6 deletions(-)
--- a/cpu/mpc83xx/cpu.c 2008-05-15 01:42:46.000000000 +0300 +++ b/cpu/mpc83xx/cpu.c 2008-05-18 11:22:34.503036000 +0300 @@ -147,7 +147,6 @@ int checkcpu(void) */ void upmconfig (uint upm, uint *table, uint size) { -#if defined(CONFIG_MPC834X) volatile immap_t *immap = (immap_t *) CFG_IMMR; volatile lbus83xx_t *lbus = &immap->lbus; volatile uchar *dummy = NULL; @@ -180,10 +179,6 @@ void upmconfig (uint upm, uint *table, u
/* Set the OP field in the MxMR to "normal" and the MAD field to 000000 */ *mxmr &= 0xCFFFFFC0; -#else - printf("Error: %s() not defined for this configuration.\n", __FUNCTION__); - hang(); -#endif }
--- a/cpu/mpc85xx/cpu.c 2008-05-15 01:42:46.000000000 +0300 +++ b/cpu/mpc85xx/cpu.c 2008-05-18 11:22:34.528046000 +0300 @@ -29,6 +29,7 @@ #include <watchdog.h> #include <command.h> #include <asm/cache.h> +#include "asm/immap_85xx.h"
DECLARE_GLOBAL_DATA_PTR;
@@ -274,3 +275,68 @@ int dma_xfer(void *dest, uint count, voi return dma_check(); } #endif + +/* + * Program a UPM with the code supplied in the table. + * + * The 'dummy' variable is used to increment the MAD. 'dummy' is + * supposed to be a pointer to the memory of the device being + * programmed by the UPM. The data in the MDR is written into + * memory and the MAD is incremented every time there's a read + * from 'dummy'. Unfortunately, the current prototype for this + * function doesn't allow for passing the address of this + * device, and changing the prototype will break a number lots + * of other code, so we need to use a round-about way of finding + * the value for 'dummy'. + * + * The value can be extracted from the base address bits of the + * Base Register (BR) associated with the specific UPM. To find + * that BR, we need to scan all BRs until we find the one that + * has its MSEL bits matching the UPM we want. Once we know the + * right BR, we can extract the base address bits from it. + * + * The MxMR and the BR and OR of the chosen bank should all be + * configured before calling this function. + * + * Parameters: + * upm: 0=UPMA, 1=UPMB, 2=UPMC + * table: Pointer to an array of values to program + * size: Number of elements in the array. Must be 64 or less. + */ +void upmconfig (uint upm, uint *table, uint size) +{ + volatile ccsr_lbc_t *lbc = (void *)(CFG_MPC85xx_LBC_ADDR); + volatile uchar *dummy = NULL; + const u32 msel = (upm + 4) << BRx_MS_SHIFT; /* What the MSEL field in BRn should be */ + volatile uint *mxmr = &lbc->mamr + upm; /* Pointer to mamr, mbmr, or mcmr */ + volatile uint *brx = &lbc->br0; /* Pointer to BRx */ + uint i; + + /* Scan all the banks to determine the base address of the device */ + for (i = 0; i < 8; i++) { + if ((*brx & BRx_MS_MSK) == msel) { + dummy = (uchar *) (*brx & BRx_BA_MSK); + break; + } + brx += 2; /* Skip to next BRx */ + } + + if (!dummy) { + printf("Error: %s() could not find matching BR\n", __FUNCTION__); + hang(); + } + + /* Set the OP field in the MxMR to "write" and the MAD field to 000000 */ + *mxmr = (*mxmr & 0xCFFFFFC0) | MxMR_OP_WARR; + + for (i = 0; i < size; i++) { + lbc->mdr = table[i]; + __asm__ __volatile__ ("sync"); + *dummy; /* Write the value to memory and increment MAD */ + __asm__ __volatile__ ("sync"); + } + + /* Set the OP field in the MxMR to "normal" and the MAD field to 000000 */ + *mxmr &= 0xCFFFFFC0; +} + --- a/include/mpc85xx.h 2008-05-15 01:42:46.000000000 +0300 +++ b/include/mpc85xx.h 2008-05-18 11:22:34.519035000 +0300 @@ -35,7 +35,10 @@ #define BRx_MS_UPMA 0x00000080 /* U.P.M.A Machine Select */ #define BRx_MS_UPMB 0x000000a0 /* U.P.M.B Machine Select */ #define BRx_MS_UPMC 0x000000c0 /* U.P.M.C Machine Select */ +#define BRx_MS_MSK 0x000000e0 /* Machine select mask */ +#define BRx_MS_SHIFT 5 /* Machine select shift */ #define BRx_PS_8 0x00000800 /* 8 bit port size */ +#define BRx_PS_16 0x00001000 /* 16 bit port size */ #define BRx_PS_32 0x00001800 /* 32 bit port size */ #define BRx_BA_MSK 0xffff8000 /* Base Address Mask */
@@ -53,8 +56,10 @@ #define ORxU_AM_MSK 0xffff8000 /* Address Mask Mask */
#define MxMR_OP_NORM 0x00000000 /* Normal Operation */ -#define MxMR_DSx_2_CYCL 0x00400000 /* 2 cycle Disable Period */ #define MxMR_OP_WARR 0x10000000 /* Write to Array */ +#define MxMR_DSx_2_CYCL 0x00400000 /* 2 cycle Disable Period */ +#define MxMR_DSx_3_CYCL 0x00800000 /* 3 cycle Disable Period */ +#define MxMR_GPL4_LPWT 0x00040000 /* LGPL4 Line in LUPWAIT mode */ #define MxMR_BSEL 0x80000000 /* Bus Select */
/* helpers to convert values into an OR address mask (GPCM mode) */

David Saada wrote:
Add support for UPM configuration on the 85xx platform. In addition, on the MPC83xx, remove MPC834x precompiler condition, in order to support all MPC83xx processors.
Signed-off-by: David Saada david.saada@ecitele.com
Bad news, David, I think I mislead you with my Option #1 - it looks sorta OK, but it still is full of bad stuff, including line wraps, when you look at the actual text of the email.
This is a snippet of the email source (text version, the HTML version is not even worth pasting in)
cpu/mpc83xx/cpu.c | 5 ---- cpu/mpc85xx/cpu.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++= ++++ include/mpc85xx.h | 7 ++++- 3 files changed, 72 insertions(+), 6 deletions(-)
--- a/cpu/mpc83xx/cpu.c 2008-05-15 01:42:46.000000000 +0300 +++ b/cpu/mpc83xx/cpu.c 2008-05-18 11:22:34.503036000 +0300 @@ -147,7 +147,6 @@ int checkcpu(void) */ void upmconfig (uint upm, uint *table, uint size) { -#if defined(CONFIG_MPC834X) volatile immap_t *immap =3D (immap_t *) CFG_IMMR; volatile lbus83xx_t *lbus =3D &immap->lbus; volatile uchar *dummy =3D NULL; @@ -180,10 +179,6 @@ void upmconfig (uint upm, uint *table, u
/* Set the OP field in the MxMR to "normal" and the MAD field to 00=
0000 */
Note the above is linewrapped with quoted printable "stuff" in it.
*mxmr &=3D 0xCFFFFFC0;
The =3D is more quoted printable "stuff."
-#else
printf("Error: %s() not defined for this configuration.\n", __FUNCT=
ION__);
More line wrapped q-p "stuff."
hang();
-#endif }
Sorry for getting your hopes up. Try finding an open port 25. :-/
Best regards, gvb

Bad news, David, I think I mislead you with my Option #1 - it looks sorta OK, but it still is full of bad stuff, including line wraps, when you look at the actual text of the email.
. . .
Sorry for getting your hopes up. Try finding an open port 25. :-/
That's pretty strange, as I managed to apply the patch after receiving my own mail. I also diffed it with my original patch file, and no difference was found (it wasn't so in the past). Also, in the past, when I had wrapping problems, I got the patch all wrapped up in the daily list mail, but here it was fine... Well, will try to look for that 25 port... Regards, David.

David Saada wrote:
Bad news, David, I think I mislead you with my Option #1 - it looks sorta OK, but it still is full of bad stuff, including line wraps, when you look at the actual text of the email.
. . .
Sorry for getting your hopes up. Try finding an open port 25. :-/
That's pretty strange, as I managed to apply the patch after receiving my own mail. I also diffed it with my original patch file, and no difference was found (it wasn't so in the past). Also, in the past, when I had wrapping problems, I got the patch all wrapped up in the daily list mail, but here it was fine… Well, will try to look for that 25 port… Regards, David.
OK, it is possible my end messed it up or that I'm just confused. Since nobody else hollared on the list, it is probably my bad. I did not check at home where I have a sane email stack. :-/
gvb

On Tue, 20 May 2008 08:44:09 -0400 Jerry Van Baren gerald.vanbaren@ge.com wrote:
David Saada wrote:
Bad news, David, I think I mislead you with my Option #1 - it looks sorta OK, but it still is full of bad stuff, including line wraps, when you look at the actual text of the email.
. . .
Sorry for getting your hopes up. Try finding an open port 25. :-/
That's pretty strange, as I managed to apply the patch after receiving my own mail. I also diffed it with my original patch file, and no difference was found (it wasn't so in the past). Also, in the past, when I had wrapping problems, I got the patch all wrapped up in the daily list mail, but here it was fine… Well, will try to look for that 25 port… Regards, David.
OK, it is possible my end messed it up or that I'm just confused. Since nobody else hollared on the list, it is probably my bad. I did not check at home where I have a sane email stack. :-/
nope, happens here too:
Applying MPC85xx, MPC83xx: Add/Fix UPM configuration support fatal: corrupt patch at line 14 Patch failed at 0001. When you have resolved this problem run "git-am --resolved". If you would prefer to skip this patch, instead run "git-am --skip".
...
ERROR: patch seems to be corrupt (line wrapped?) #105: FILE: cpu/mpc83xx/cpu.c:180: 0000 */
...
Kim

On Mon, 19 May 2008 19:05:04 +0300 David Saada David.Saada@ecitele.com wrote:
Add support for UPM configuration on the 85xx platform. In addition, on the MPC83xx, remove MPC834x precompiler condition, in order to support all MPC83xx processors.
Signed-off-by: David Saada david.saada@ecitele.com
cpu/mpc83xx/cpu.c | 5 ---- cpu/mpc85xx/cpu.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ include/mpc85xx.h | 7 ++++- 3 files changed, 72 insertions(+), 6 deletions(-)
Can we merge the register definition files and have a single upm_config for mpc8[356]xx instead of duplicating it as being done here?
Kim

Can we merge the register definition files and have a single upm_config for mpc8[356]xx instead of duplicating it as being done here?
Not sure that I'm the right person for this job, as I don't have an 86xx based board. Also, I'm not sure this would be a good idea: There are some differences between the registers in these 3 families, and the header file would look pretty ugly (many ifdefs). Even the UPM code won't be the same: for instance, the mpc85xx code scans the BR registers (which are adjacent) to determine the UPM machine, while in the 83xx we need to scan the lbus banks (and extract the BRs from there). This means that we will also have many ifdefs there as well. David.

On Tue, 20 May 2008 10:32:24 +0300 David Saada David.Saada@ecitele.com wrote:
Can we merge the register definition files and have a single upm_config for mpc8[356]xx instead of duplicating it as being done here?
Not sure that I'm the right person for this job, as I don't have an 86xx based board.
86xx can be tested by others; point here is to avoid code duplication.
Also, I'm not sure this would be a good idea: There are some differences between the registers in these 3 families, and the header file would look pretty ugly (many ifdefs). Even the UPM code won't be
the registers have a common base, and all the registers this patch uses are the same on all of them. I don't see why they can't be unified into a common include/asm-ppc/immap_8xxx.h file.
the same: for instance, the mpc85xx code scans the BR registers (which are adjacent) to determine the UPM machine, while in the 83xx we need to scan the lbus banks (and extract the BRs from there). This means that we will also have many ifdefs there as well.
afaict, the code this patch introduces for 85xx is functionally identical to that of 83xx:
* Program a UPM with the code supplied in the table. * * The 'dummy' variable is used to increment the MAD. 'dummy' is @@ -133,7 +13,7 @@ * * The value can be extracted from the base address bits of the * Base Register (BR) associated with the specific UPM. To find - * that BR, we need to scan all 8 BRs until we find the one that + * that BR, we need to scan all BRs until we find the one that * has its MSEL bits matching the UPM we want. Once we know the * right BR, we can extract the base address bits from it. * @@ -147,20 +27,20 @@ */ void upmconfig (uint upm, uint *table, uint size) { - volatile immap_t *immap = (immap_t *) CFG_IMMR; - volatile lbus83xx_t *lbus = &immap->lbus; + volatile ccsr_lbc_t *lbc = (void *)(CFG_MPC85xx_LBC_ADDR); volatile uchar *dummy = NULL; - const u32 msel = (upm + 4) << BR_MSEL_SHIFT; /* What the MSEL field in BRn should be */ - volatile u32 *mxmr = &lbus->mamr + upm; /* Pointer to mamr, mbmr, or mcmr */ + const u32 msel = (upm + 4) << BRx_MS_SHIFT; /* What the MSEL field in BRn should be */ + volatile uint *mxmr = &lbc->mamr + upm; /* Pointer to mamr, mbmr, or mcmr */ + volatile uint *brx = &lbc->br0; /* Pointer to BRx */ uint i;
/* Scan all the banks to determine the base address of the device */ for (i = 0; i < 8; i++) { - if ((lbus->bank[i].br & BR_MSEL) == msel) { - dummy = (uchar *) (lbus->bank[i].br & BR_BA); + if ((*brx & BRx_MS_MSK) == msel) { + dummy = (uchar *) (*brx & BRx_BA_MSK); break; } + brx += 2; /* Skip to next BRx */ }
if (!dummy) { @@ -169,10 +49,10 @@ }
/* Set the OP field in the MxMR to "write" and the MAD field to 000000 */ - *mxmr = (*mxmr & 0xCFFFFFC0) | 0x10000000; + *mxmr = (*mxmr & 0xCFFFFFC0) | MxMR_OP_WARR;
for (i = 0; i < size; i++) { - lbus->mdr = table[i]; + lbc->mdr = table[i]; __asm__ __volatile__ ("sync"); *dummy; /* Write the value to memory and increment MAD */ __asm__ __volatile__ ("sync");
btw, I don't see arch/powerpc/sysdev/fsl_lbc.c functionally differing among the families either.
am I missing something?
David.
Kim

On Mon, May 19, 2008 at 11:05 AM, David Saada David.Saada@ecitele.com wrote:
Add support for UPM configuration on the 85xx platform. In addition, on the MPC83xx, remove MPC834x precompiler condition, in order to support all MPC83xx processors.
Signed-off-by: David Saada david.saada@ecitele.com
David, I think this patch has been accomplished by some other patches which came in. Could you take a look at the recent patches to cpu/mpc85xx/cpu.c and see if those changes reflect everything you wanted? If not, please submit a patch on top of those changes.
Thanks, Andy

David, I think this patch has been accomplished by some other patches which came in. Could you take a look at the recent patches to cpu/mpc85xx/cpu.c and see if those changes reflect everything you wanted? If not, please submit a patch on top of those changes.
Andy - these patched seem to have the same functionality as mine, thus there's no need for my patch now. Regards, David.
participants (4)
-
Andy Fleming
-
David Saada
-
Jerry Van Baren
-
Kim Phillips