[U-Boot-Users] [PATCH] Define upmconfig() for 834x systems

[U-Boot-Users] [PATCH] Define upmconfig() for 834x systems

[timur at freescale.com]

From: Timur Tabi <timur@freescale.com>

CHANGELOG:

* Define upmconfig() for 834x systems, and hang if called on non-834x systems.
  This function programs one of the UPMs with the code passed to it.  The
  BR and OR for the chosen bank (any bank will do) and the MxMR must all be
  programmed correctly before calling this function.

Signed-off-by: Timur Tabi <timur@freescale.com>
---
 cpu/mpc83xx/cpu.c |   65 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 64 insertions(+), 1 deletions(-)

diff --git a/cpu/mpc83xx/cpu.c b/cpu/mpc83xx/cpu.c
index 20bba6c..19c306c 100644
--- a/cpu/mpc83xx/cpu.c
+++ b/cpu/mpc83xx/cpu.c
@@ -69,9 +69,72 @@ int checkcpu(void)
 }
 
 
+/**
+ * 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 8 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)
 {
-	hang();		/* FIXME: upconfig() needed? */
+#if defined(CONFIG_MPC834X)
+	volatile immap_t *immap = (immap_t *) CFG_IMMRBAR;
+	volatile lbus8349_t *lbus = &immap->lbus;
+	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 */
+	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);
+			break;
+		}
+	}
+
+	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) | 0x10000000;
+	
+	for (i = 0; i < size; i++) {
+		lbus->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;
+#else
+	printf("Error: %s() not defined for this configuration.\n", __FUNCTION__);
+	hang();
+#endif
 }
 
 
-- 
1.4.2

[U-Boot-Users] [PATCH] Define upmconfig() for 834x systems

[Wolfgang Denk]

In message <11577520232114-git-send-email-timur@freescale.com> you wrote:
> 
> * Define upmconfig() for 834x systems, and hang if called on non-834x systems.
>   This function programs one of the UPMs with the code passed to it.  The
>   BR and OR for the chosen bank (any bank will do) and the MxMR must all be
>   programmed correctly before calling this function.

I don't see any users for this function. Please don't add dead code.

If you intend to use this with any future patches, then please submit
your patches in an order that makes some sense.

Also, please follow the Coding  Style  requirements  (trailing  white
space).

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Be careful what you wish for. You never know who will be listening.
                                      - Terry Pratchett, _Soul Music_

[U-Boot-Users] [PATCH] Define upmconfig() for 834x systems

[Timur Tabi]

Wolfgang Denk wrote:

> If you intend to use this with any future patches, then please submit
> your patches in an order that makes some sense.

Well, I have a dilemma then.

This upmconfig() patch is generic for all 834x systems.  It may not be currently used by the 8349EMDS, but it will be used by the upcoming 8349EMITX patch I'm working on.  Without the new upmconfig(), the ITX code won't compile.  And yet, the patch is not specific to the ITX.

That's why I sent it out today.

So you're saying I should send it out as part of my ITX patch, even though it's not ITX-specific?


> Also, please follow the Coding  Style  requirements  (trailing  white
> space).

Sorry, I keep thinking I've covered everything in the coding style, but something always slips through.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] [PATCH] Define upmconfig() for 834x systems

[Wolfgang Denk]

In message <4501F3A4.3060108@freescale.com> you wrote:
>
> Well, I have a dilemma then.

Not really.

> This upmconfig() patch is generic for all 834x systems. It may not
> be currently used by the 8349EMDS, but it will be used by the

It is also not used by other 834x systems.

> upcoming 8349EMITX patch I'm working on. Without the new upmconfig(),
> the ITX code won't compile. And yet, the patch is not specific to the
> ITX.

If this code is needed then, submit it then. Obviously no other boards
need or use it so far.

> That's why I sent it out today.

At the moment it's just dead, unused code which I will not add.

> So you're saying I should send it out as part of my ITX patch, even
> though it's not ITX-specific?

Technically it must be ITX-specific as no other board needs or uses
this (yet?).

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If there was anything that depressed him more than his own  cynicism,
it was that quite often it still wasn't as cynical as real life.
                                 - Terry Pratchett, _Guards! Guards!_

[U-Boot-Users] [PATCH] Define upmconfig() for 834x systems

[Ben Warren]

Wolfgang,

On Sat, 2006-09-09 at 01:05 +0200, Wolfgang Denk wrote:

> > This upmconfig() patch is generic for all 834x systems. It may not
> > be currently used by the 8349EMDS, but it will be used by the
> 
> It is also not used by other 834x systems.
> 
While neither of the two boards that are in the U-boot tree use this, my
custom board will make use of it, so I thank Timur for the submission.

I understand your reluctance to accept code that's not used by any of
the eval boards and SBCs that are part of the distribution.  There are
many reasons for taking this approach.

A crazy idea that I'm sure has been shot down before, but have you ever
considered making an 'unstable' branch available?  It could contain all
patches that pass the coding standards and perhaps a week of feedback.
If there was a big flashing sign that says "Use at your own risk", you
could offload the "RTFM" responses to others on the list, giving
yourself more time to move patches from unstable to stable.

Just a thought...

regards,
Ben

[U-Boot-Users] [PATCH] Define upmconfig() for 834x systems

[Timur Tabi]

Ben Warren wrote:

> I understand your reluctance to accept code that's not used by any of
> the eval boards and SBCs that are part of the distribution.  There are
> many reasons for taking this approach.

I'm working on a patch for the ITX that includes this change, as Wolfgang requested, so it's no big deal.

> A crazy idea that I'm sure has been shot down before, but have you ever
> considered making an 'unstable' branch available?  It could contain all
> patches that pass the coding standards and perhaps a week of feedback.
> If there was a big flashing sign that says "Use at your own risk", you
> could offload the "RTFM" responses to others on the list, giving
> yourself more time to move patches from unstable to stable.

I think that's just going to make more work for Wolfgang and not solve any real problems.  Patches aren't completely independent of each other - sooner or later he's going to get patches that apply to one tree but not the other.

Anyone who's really interested in unapplied patches can scan the mailing list archives.


-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] [PATCH] Define upmconfig() for 834x systems

[Wolfgang Denk]

Dear Ben,

in message <1157996270.5069.26.camel@saruman.qstreams.net> you wrote:
> 
> > It is also not used by other 834x systems.
> > 
> While neither of the two boards that are in the U-boot tree use this, my
> custom board will make use of it, so I thank Timur for the submission.

I thank him, too - I just reject the patch as is, i. e. out of
context.

> I understand your reluctance to accept code that's not used by any of
> the eval boards and SBCs that are part of the distribution.  There are
> many reasons for taking this approach.

Sorry, but the code will not go in until there is any other code that
uses it.

> A crazy idea that I'm sure has been shot down before, but have you ever
> considered making an 'unstable' branch available?  It could contain all

Yes. Actually not one, but several. It's planned.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The universe, they said, depended for its operation on the balance of
four forces which they identified as charm,  persuasion,  uncertainty
and bloody-mindedness.      -- Terry Pratchett, "The Light Fantastic"

[U-Boot-Users] [PATCH] Define upmconfig() for 834x systems

[Wolfgang Denk]

Dear Timur,

in message <4505A28B.9010909@freescale.com> you wrote:
> 
> I think that's just going to make more work for Wolfgang and not
> solve any real problems. Patches aren't completely independent of

Oh well, it does. Actually this  is  what  I'm  doing  all  the  time
internally. I just need to decide (a) if I want to make such branches
publickly available in general (versus in special cases as we already
do  with  the  USB  and  NAND  testing branches), (b) what's the most
efficient way for me is to deal with such a  configuration,  and  (c)
what could be done to get more feedback about test results from board
maintainers.

> each other - sooner or later he's going to get patches that apply to
> one tree but not the other.
> 
> Anyone who's really interested in unapplied patches can scan the mailing list archives.

Umm... I disagree. Having the patches available in a git  repo  where
you  can  pull  and/or  cherry-pick  from  is much more effcient than
having to deal with email messages, where patches come in a  plethora
of different formats, often in many parts and sub-parts, or combinbed
as patches plus tarballs, or whatever.

IN theory, our patch tracking system should jump in  here  and  allow
for  easy  scanning of open and applied patches, but again this takes
more time than planned.

I apologize for this.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
To know how another being, another creature feels -  that  is  impos-
sible.                  - Terry Pratchett, _The Dark Side of the Sun_

[U-Boot-Users] 86xx patches? (was [PATCH] Define upmconfig() for 834x systems)

[Jon Loeliger]

On Mon, 2006-09-11 at 13:52, Wolfgang Denk wrote:

> Umm... I disagree. Having the patches available in a git  repo  where
> you  can  pull  and/or  cherry-pick  from  is much more effcient than
> having to deal with email messages, where patches come in a  plethora
> of different formats, often in many parts and sub-parts, or combinbed
> as patches plus tarballs, or whatever.

Wolfgang,

Have you been able to pull and look at the
entire set of mpc86xx patches I published and
made available in a git tree as well yet?

> IN theory, our patch tracking system should jump in  here  and  allow
> for  easy  scanning of open and applied patches, but again this takes
> more time than planned.

For some reason my patches appear not to have
been picked up by the patch tracker.

Thanks,
jdl