Re: 8xx parameter RAM clashes

Re: 8xx parameter RAM clashes

[Wolfgang Denk]

In message <3C2CAA01.6040801@embeddededge.com> you wrote:
>
> > it would be nice if the drivers would  register  the  locations  they
> > use,  and  actually  CHECK for collisions, instead of silently let us
> > run into strange and often hard to debug error conditions.
>
> So, add it then.

Does that mean that such a patch would be accepted?

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
I have often regretted my speech, never my silence.

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

Re: 8xx parameter RAM clashes

[Tom Rini]

On Wed, Nov 28, 2001 at 06:35:08PM +0100, Wolfgang Denk wrote:
>
> In message <3C2CAA01.6040801@embeddededge.com> you wrote:
> >
> > > it would be nice if the drivers would  register  the  locations  they
> > > use,  and  actually  CHECK for collisions, instead of silently let us
> > > run into strange and often hard to debug error conditions.
> >
> > So, add it then.
>
> Does that mean that such a patch would be accepted?

Yes.  And if you want to throw in more error checking/handling, please
do.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

Re: 8xx parameter RAM clashes

[Wolfgang Denk]

In message <3C2C99C0.1020502@embeddededge.com> Dan Malek wrote:
>
> Alex Zeffertt wrote:
>
> > I appreciate that there may not be anyone in a position to fix this problem - but I think it's worth
> > mentioning anyway so that future drivers don't make the problem worse.
>
> You need to load the appropriate CPM microcode patches that relocate the
> I2C, SPI, SMC space in the parameter ram and use the new addresses.
> Again, the infrastructure for all of this is in the PowerPC 2_4_devel
> kernels.

Right, Dan, but Alex has a valid point:

There is a lot of potential overlap in parameter RAM that  cannot  be
fixed  by microcode patches (at least I don't know of any uCode-patch
for the SMC1 = UART and SCC3 = ESAR collision mentioned by Alex), and
it would be nice if the drivers would  register  the  locations  they
use,  and  actually  CHECK for collisions, instead of silently let us
run into strange and often hard to debug error conditions.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"Where shall I begin, please your Majesty?" he asked. "Begin  at  the
beginning,"  the  King said, gravely, "and go on till you come to the
end: then stop."    - Alice's Adventures in Wonderland, Lewis Carroll

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