more questions about 8xx microcode patches

more questions about 8xx microcode patches

[Robert P. J. Day]

   after poring over the header and source files, and the MOT docs, a
few questions about possible microcode patches, based on the following
layout of the parameter RAM memory map of the MCP850 family,
reproduced from the user's manual (and, just remember, i'm not
*trying* to be pedantic or annoying, i am merely succeeding :-):

   the DPRAM memory map:

     Offset from DPRAM base   Controller

 	0x1C00-0x1C7F		USB
 	0x1C80-0x1CAF		I2C
 	0x1CB0-0x1CBF		Misc.
 	0x1CC0-0x1CCF		IDMA1 (whatever that is)
 	0x1D00-0x1D7F		SCC2
 	0x1D80-0x1DAF		SPI
 	0x1DB0-0x1DBF		RISC timer table
 	0x1DC0-0x1DFF		IDMA2
 	0x1E00-0x1E7F		SCC3
 	0x1E80-0x1EBF		SMC1
 	0x1EC0-0x1EFF		(Reserved)
 	0x1F00-0x1F7F		(Reserved)
 	0x1F80-0x1FBF		SMC2
 	0x1FC0-0x1FFF		(Reserved)

so, barring any typoes in the above ...


1)
   i recall that, while the manual lists the first controller above as
USB, SCC1 is also a possibility for other 8xx processors, yes?  (i'm
sure i saw this somewhere; it's not an issue for us, i just wanted to
be complete.)


2)
   given the size of the scc_enet structure in commproc.h, the whole
reason to relocate SMC1 is to let ethernet on SCC3 spill over into the
normally-reserved SMC1 memory.  i would assume the same situation
would hold if you were trying to use SCC2 for ethernet -- you'd need
to relocate SPI, right?


3)
   speaking of I2C and SPI, what's the rationale for pretty much every
single piece of information insisting that these two controllers are
relocated as a pair?  micropatch.c provides a patch which relocates
them both, a motorola doc i have has a table entitled "I2C/SPI
Parameter RAM" as if these things are absolutely inseparable.  but
they clearly initially live in different locations, and commproc.h has
two distinct structs -- "iic" and "spi".  so why historically are
these two so inextricably linked, especially in terms of a relocation
patch?  can't you relocate one and leave the other where it is?
certainly, if i wanted to put ethernet on SCC2, SPI would have to move
but not I2C.  rationale?

(if address 0x1C00 was in fact being used for SCC1, then ethernet on
SCC1 would require I2C to move.  you get the idea.)


4)
   the current micropatch.c file appears to limit one to applying a
single patch.  the first patch (written to DPRAM address 0) appears to
relocate both I2C/SPI (there's that linkage again).

further down, there's a test for USE_SMC_PATCH (*clearly* not
compatible with the first patch since they both write to DPRAM address
0) which represents the SMC/I2C/SPI patch.  (actually, it reads
"SMC2", which i assume is a typo.)  i'm assuming that this patch
relocates *all* of SMC1, I2C and SPI.  this suggests that there's
currently no patch for just relocating SMC1, which seems somewhat
restrictive.  is there no reason why someone might want to relocate
just SMC1?  or does that patch just not exist?

5)
   in general, what patches should exist?  taking into account that
applying some patches may make others impossible to use, what should
be in the list of possible microcode patches in the MPC8xx CPM
submenu?  right now, it seems that that list could contain two
entries:

   I2C/SPI
   SMC1/I2C/SPI

which would be mutually exclusive.  should there be others?  SMC1 by
itself?  SMC2?

6)
   should the USB SOF patch listed in micropatch.c be an option?
despite the fact that, as some have pointed out, USB is kind of borked
in the 850 Rev B board?


   it seems that creating a menu of 8xx microcode patches would be
fairly easy:

   1) collect the current patches, assign them symbolic names [*]
   2) decide which are mutually exclusive and code that into Kconfig
   3) using the denx 2.4.25 tree as a model, put each patch into a
 	separate source file and just include the appropriate file,
 	making the appropriate changes to source files like
 	cpm_uart_cpm1.c where necessary

thoughts?

rday

[*] definitely need some decent Kconfig names for possible ucode
patches if there's going to be a list.  the current "UCODE_PATCH"
would clearly have to go. :-)

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: more questions about 8xx microcode patches

[Mark Chambers]

Robert,

I know I've never had a need to use a microcode patch.  Maybe a quick
survey - has anybody ever had a need to use two patches at once?  I'm
suspecting you may be putting a lot of effort into something that's rarely
needed.  Also, as Motorola updates their silicon the patches will likely
become less relevant (less likely that new users will need the patches).

Mark Chambers


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Looking for GT64260 MPSC serial console driver

[Jeff Domogala]

Hello folks.

I am looking for a MPSC serial console driver for the Marvell GT-64260.  I
have one from an old 2.4 development tree but it looks like it never made it
into the linuxppc-2.5 tree.  I would also entertain anyone who could point
me in the direction of what needs to be done to port a serial console driver
from a 2.4 kernel to the current 2.6 kernel in the linuxppc-2.5 tree.

Thanks,

Jeff Domogala


-----Original Message-----
From: owner-linuxppc-embedded@lists.linuxppc.org
[mailto:owner-linuxppc-embedded@lists.linuxppc.org]On Behalf Of Mark
Chambers
Sent: Tuesday, July 27, 2004 5:07 PM
To: Robert P. J. Day; Embedded Linux PPC list
Subject: Re: more questions about 8xx microcode patches



Robert,

I know I've never had a need to use a microcode patch.  Maybe a quick
survey - has anybody ever had a need to use two patches at once?  I'm
suspecting you may be putting a lot of effort into something that's rarely
needed.  Also, as Motorola updates their silicon the patches will likely
become less relevant (less likely that new users will need the patches).

Mark Chambers


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Looking for GT64260 MPSC serial console driver

[Mark A. Greer]

Jeff Domogala wrote:

>Hello folks.
>
>I am looking for a MPSC serial console driver for the Marvell GT-64260.  I
>have one from an old 2.4 development tree but it looks like it never made it
>into the linuxppc-2.5 tree.  I would also entertain anyone who could point
>me in the direction of what needs to be done to port a serial console driver
>from a 2.4 kernel to the current 2.6 kernel in the linuxppc-2.5 tree.
>

Mail archives are your friend...
http://lists.linuxppc.org/linuxppc-embedded/200407/msg00332.html

I should add that I am currently having problems with that driver on a
64360 base board.  I hope to have it working "soon".

Mark


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Looking for GT64260 MPSC serial console driver

[Mark A. Greer]

Mark A. Greer wrote:

> I should add that I am currently having problems with that driver on a
> 64360 base board.  I hope to have it working "soon".


Scratch that.  I had a bug in my platform code.  The mpsc *port 0* seems
to work fine on the 64360.

Mark


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: more questions about 8xx microcode patches

[Robert P. J. Day]

On Tue, 27 Jul 2004, Mark Chambers wrote:

> Robert,
>
> I know I've never had a need to use a microcode patch.  Maybe a quick
> survey - has anybody ever had a need to use two patches at once?  I'm
> suspecting you may be putting a lot of effort into something that's rarely
> needed.  Also, as Motorola updates their silicon the patches will likely
> become less relevant (less likely that new users will need the patches).

on my project alone, we've needed two different selections of those
patches.  so while it's not an earth-shattering modification, it
doesn't hurt and it sometimes helps.  and it makes the addition of any
future patches really trivial, if that ever happens.

rday

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: more questions about 8xx microcode patches

[Dan Malek]

On Jul 27, 2004, at 4:23 PM, Robert P. J. Day wrote:

> 1)
>   i recall that, while the manual lists the first controller above as
> USB, SCC1 is also a possibility for other 8xx processors, yes?

Yes.  On the 823/850 the SCC1 controller is dedicated to USB.

> 2)
>   given the size of the scc_enet structure in commproc.h, the whole
> reason to relocate SMC1 is to let ethernet on SCC3 spill over into the
> normally-reserved SMC1 memory.  i would assume the same situation
> would hold if you were trying to use SCC2 for ethernet -- you'd need
> to relocate SPI, right?

Yes.

>   speaking of I2C and SPI, what's the rationale for pretty much every
> single piece of information insisting that these two controllers are
> relocated as a pair?

There were (are?) various microcode patches that became available
as people needed the relocation.  In the end, I think there was only
one patch the relocated everything.

> 4)
>   the current micropatch.c file appears to limit one to applying a
> single patch.  the first patch (written to DPRAM address 0) appears to
> relocate both I2C/SPI (there's that linkage again).

Unless it has changed recently, all microcode patches have to be
loaded into location 0 of the DPRAM.  You can only load one patch
at a time, hence the need for a single patch to contain the relocation
of multiple devices.

> further down, there's a test for USE_SMC_PATCH (*clearly* not
> compatible with the first patch since they both write to DPRAM address
> 0) which represents the SMC/I2C/SPI patch.

Yep.

>   (actually, it reads
> "SMC2", which i assume is a typo.)

Nope, it's to relocate SMC2 so you could run Ethernet/ATM on SCC4.

>  i'm assuming that this patch
> relocates *all* of SMC1, I2C and SPI.

Don't assume anything.  There are lots of different patches.  Carefully
read all of the documentation with all of the patches to see what they
do, how they are supposed to be loaded, and they match the
CPM microcode ROM that is present in your processor.

>   in general, what patches should exist?

You will have to investigate.  At one time I knew of no less than six
different patches, for various relocation or feature additions.

>   should the USB SOF patch listed in micropatch.c be an option?
> despite the fact that, as some have pointed out, USB is kind of borked
> in the 850 Rev B board?

....and I have pointed out that when used properly it works just fine.
It's up to you.

>   it seems that creating a menu of 8xx microcode patches would be
> fairly easy:


Hahahahaha!!!!  You don't know how big of a hole you are digging :-)


>   1) collect the current patches, assign them symbolic names [*]
>   2) decide which are mutually exclusive and code that into Kconfig

As far as I know, they are all mutually exclusive, unless they have
been changed recently.

>   3) using the denx 2.4.25 tree as a model, put each patch into a
> 	separate source file and just include the appropriate file,
> 	making the appropriate changes to source files like
> 	cpm_uart_cpm1.c where necessary

I have not looked at what Wolfgang has done, but the patches
I have seen are all S-record files that were supposed to be downloaded
through a debugger.  In addition to writing the microcode to
the DPRAM, they also modified various parameter and control
registers in the CPM.  The point is, you just can't download
code, you also have to perform some initialization steps in
the drivers, which of course are usually different depending
upon the patch that is loaded.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: more questions about 8xx microcode patches

[Robert P. J. Day]

On Tue, 27 Jul 2004, Dan Malek wrote:

> On Jul 27, 2004, at 4:23 PM, Robert P. J. Day wrote:

>>   it seems that creating a menu of 8xx microcode patches would be
>> fairly easy:
>
>
> Hahahahaha!!!!  You don't know how big of a hole you are digging :-)

oh, fer shure.  :-)  but given that there are three clear and
identifiable patches that exist at the moment, i'll put together a
patch that turns them into a submenu and submit it, and you can decide
what to do with it.  i'll make sure that the submission doesn't change
any of the current functionality, just makes it easier to pick what
you want.

(specifically, it's inconvenient to be able to select one patch via
Kconfig, and the other only by editing micropatch.c.  but give me a
bit, and i'll post something based on those other two small patches i
submitted.)

rday

p.s.  should patches be submitted as main body in postings, or as
attachments?  or do you care?

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: more questions about 8xx microcode patches

[Wolfgang Denk]

In message <Pine.LNX.4.60.0407271733200.7504@localhost.localdomain> you wrote:
>
> > Hahahahaha!!!!  You don't know how big of a hole you are digging :-)
>
> oh, fer shure.  :-)  but given that there are three clear and
> identifiable patches that exist at the moment, i'll put together a
> patch that turns them into a submenu and submit it, and you can decide
> what to do with it.  i'll make sure that the submission doesn't change
> any of the current functionality, just makes it easier to pick what
> you want.

Just to add to the complexity: are you aware that the  parameter  RAM
relocation  may  be  different between 8xx processors? For example it
seems that on the 866 family  you  can  relocate  PRAM  even  without
loading any uCode by just writing the correct offset to (for example)
the spi_rpbase register.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Substitute "damn" every time you're inclined to write "very"; your
editor will delete it and the writing will be just as it should be.
                - Mark Twain

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: more questions about 8xx microcode patches

[David Ho]

owner-linuxppc-embedded@lists.linuxppc.org wrote on 07/27/2004 06:30:28 PM:

>
> Just to add to the complexity: are you aware that the  parameter  RAM
> relocation  may  be  different between 8xx processors? For example it
> seems that on the 866 family  you  can  relocate  PRAM  even  without
> loading any uCode by just writing the correct offset to (for example)
> the spi_rpbase register.
>

I just had a conversation with Wolfgang on the 866 uCode patch situation.
It appears that the I2C/SPI patch is already incorporated in this silicon
rev.  Please look at the follow post for detail of my findings.

http://sourceforge.net/mailarchive/message.php?msg_id=9072298

Hope this help you along the way.  Or it might not.

Regards,

David Ho
Nanometrics Inc.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: more questions about 8xx microcode patches

[Robert P. J. Day]

On Tue, 27 Jul 2004, Dan Malek wrote:

> On Jul 27, 2004, at 4:23 PM, Robert P. J. Day wrote:

>>   it seems that creating a menu of 8xx microcode patches would be
>> fairly easy:

> Hahahahaha!!!!  You don't know how big of a hole you are digging :-)

   "Now, Ward, don't just tell the Beav he shouldn't do it.  It's
always better when they learn these things on their own."

rday

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: more questions about 8xx microcode patches

[Wells, Charles]

I was working with Motorola about a year ago on USB on the MPC850.  At that
time, we were already using the I2C/SPI relocation patch.  The word from the
factory was that you couldn't use more than one microcode patch at a time on
an '850.  I doubt this has changed since then.  There was a first attempt at
a single patch for I2C/SPI relocation combined with USB.  I don't know if it
was ever released.

Regards,
Charlie

-----Original Message-----
From: Mark Chambers [mailto:markc@mail.com]
Sent: Tuesday, July 27, 2004 5:07 PM
To: Robert P. J. Day; Embedded Linux PPC list
Subject: Re: more questions about 8xx microcode patches



Robert,

I know I've never had a need to use a microcode patch.  Maybe a quick
survey - has anybody ever had a need to use two patches at once?  I'm
suspecting you may be putting a lot of effort into something that's rarely
needed.  Also, as Motorola updates their silicon the patches will likely
become less relevant (less likely that new users will need the patches).

Mark Chambers


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/