IBM 440GX, Ocotea...

IBM 440GX, Ocotea...

[Wolfgang Grandegger]

Hello,

we are currently trying to understand which PPC Linux
kernel tree is best suited for the IBM 440GX on the
Ocotea eval board. We would like to support the 405GP
and 440GP as well.

The Ocotea 440GX board seems to be supported in the
"linuxppc_2_4_devel" tree. Is this board configuration
up-to-date and still maintained?

A more up-to-date implementation seems to be in the
"linuxppc-2.4" tree. Are there some open issues or known
problems? I realized that the L2 cache has been disabled
recently:

  $ cat arch/ppc/platforms/ocotea.c
  ...
  /* Disable L2-Cache due to hardware issues */
  ibm440gx_l2c_disable();

Does this mean that the L2 cache is unusable on current
revisions of the chip? [That's why we would like to use
this chip.]

Does this tree support the 405GP and 440GP as well? Could
anybody make some comments on the stability? We currently
use the "linuxppc_2_4_devel" tree for these processors
with little problems.

It would be nice if somebody could shed some light on
these issues.

TIA.

Wolfgang.


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

Re: IBM 440GX, Ocotea...

[Tolunay Orkun]

> The Ocotea 440GX board seems to be supported in the
> "linuxppc_2_4_devel" tree. Is this board configuration
> up-to-date and still maintained?
>
> A more up-to-date implementation seems to be in the
> "linuxppc-2.4" tree. Are there some open issues or known
> problems? I realized that the L2 cache has been disabled
> recently:

Regarding penguinppc.org BitKeeper trees, I was told that
linuxppc_2_4_devel tree is now dead and all commits are done against
linuxppc-2.4. Perhaps maintainers can clarify that in more detail. My
405GP snapshot is coming from linuxppc-2.4.

There is also another linuxppc_2_4_devel tree maintained by DENX. I don't
know the sync state between these two trees. It is my understanding that
DENX tree has some fixes that might not be in the BK trees.

IMHO, the community would be best served by single set of sources...

Best regards,
Tolunay Orkun

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

Re: IBM 440GX, Ocotea...

[Wolfgang Denk]

Dear Tolunay,

in message <12605.216.110.51.8.1080057816.squirrel@www.orkun.us> you wrote:
>
> > A more up-to-date implementation seems to be in the
> > "linuxppc-2.4" tree. Are there some open issues or known
> > problems? I realized that the L2 cache has been disabled
> > recently:
>
> Regarding penguinppc.org BitKeeper trees, I was told that
> linuxppc_2_4_devel tree is now dead and all commits are done against
> linuxppc-2.4. Perhaps maintainers can clarify that in more detail. My
> 405GP snapshot is coming from linuxppc-2.4.

Officially linuxppc-2.4 is the official tree ;-) But  then  it  seems
that  there  is  still a lot of difference between linuxppc_2_4_devel
and linuxppc-2.4, and I think you can find new features in both trees
that are not (yet?) present in the other tree.

> There is also another linuxppc_2_4_devel tree maintained by DENX. I don't

I guess Wolfgang Grandegger is aware of this. His other email address
is <wg@denx.de> :-)

But there are so many other trees. There is things like  the  ameslab
tree or the Linux-Tiny Tree or CELinux source tree or ...


> know the sync state between these two trees. It is my understanding that
> DENX tree has some fixes that might not be in the BK trees.

Our linuxppc_2_4_devel tree is in sync with the BK linuxppc_2_4_devel
tree. But there is lots of additional stuff in out  tree  that  never
made  it into the "official trees". So many of our contributions were
rejected or delayed or ignored that I finally gave up.

> IMHO, the community would be best served by single set of sources...

Indeed. But I think this is as likely as a world without war :-(

I would be perfectly happy if there was some plan or roadmap or  just
a  description of the current state which says which tree is in which
state, if it is maintained and by whom,  and  how  long  it  will  be
maintained, and when or why or by whom it might be declared as "dead"
(as  happened  with  the  linuxppc_2_4_devel  tree), or if anybody is
actually taking care of the known problems, and when, etc.


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
Inside every old person is a young person wondering what happened.
                              - Terry Pratchett, _Moving Pictures_

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

Re: IBM 440GX, Ocotea...

[Jaap-Jan Boor]

Wolfgang,

In addition to this nice tree discussion, I've a question:
from what 'official ppc' tree do patches eventually get into the
official linux kernel tree(s) at kernel.org?
only linuxppc-2.4? Or all?

thanks,

Jaap-Jan

On Tue, 2004-03-23 at 17:44, Wolfgang Denk wrote:
> Dear Tolunay,
>
> in message <12605.216.110.51.8.1080057816.squirrel@www.orkun.us> you wrote:
> >
> > > A more up-to-date implementation seems to be in the
> > > "linuxppc-2.4" tree. Are there some open issues or known
> > > problems? I realized that the L2 cache has been disabled
> > > recently:
> >
> > Regarding penguinppc.org BitKeeper trees, I was told that
> > linuxppc_2_4_devel tree is now dead and all commits are done against
> > linuxppc-2.4. Perhaps maintainers can clarify that in more detail. My
> > 405GP snapshot is coming from linuxppc-2.4.
>
> Officially linuxppc-2.4 is the official tree ;-) But  then  it  seems
> that  there  is  still a lot of difference between linuxppc_2_4_devel
> and linuxppc-2.4, and I think you can find new features in both trees
> that are not (yet?) present in the other tree.
>
> > There is also another linuxppc_2_4_devel tree maintained by DENX. I don't
>
> I guess Wolfgang Grandegger is aware of this. His other email address
> is <wg@denx.de> :-)
>
> But there are so many other trees. There is things like  the  ameslab
> tree or the Linux-Tiny Tree or CELinux source tree or ...
>
>
> > know the sync state between these two trees. It is my understanding that
> > DENX tree has some fixes that might not be in the BK trees.
>
> Our linuxppc_2_4_devel tree is in sync with the BK linuxppc_2_4_devel
> tree. But there is lots of additional stuff in out  tree  that  never
> made  it into the "official trees". So many of our contributions were
> rejected or delayed or ignored that I finally gave up.
>
> > IMHO, the community would be best served by single set of sources...
>
> Indeed. But I think this is as likely as a world without war :-(
>
> I would be perfectly happy if there was some plan or roadmap or  just
> a  description of the current state which says which tree is in which
> state, if it is maintained and by whom,  and  how  long  it  will  be
> maintained, and when or why or by whom it might be declared as "dead"
> (as  happened  with  the  linuxppc_2_4_devel  tree), or if anybody is
> actually taking care of the known problems, and when, etc.
>
>
> 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
> Inside every old person is a young person wondering what happened.
>                               - Terry Pratchett, _Moving Pictures_
>
--
J.G.J. Boor                       Anton Philipsweg 1
Software Engineer                 1223 KZ Hilversum
AimSys bv                         tel. +31 35 689 1941
Postbus 2194, 1200 CD Hilversum   mailto:jjboor@aimsys.nl


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

Re: IBM 440GX, Ocotea...

[Wolfgang Denk]

In message <1080061066.8019.70.camel@linpc003.aimsys.nl> you wrote:
> Wolfgang,
>
> In addition to this nice tree discussion, I've a question:
> from what 'official ppc' tree do patches eventually get into the
> official linux kernel tree(s) at kernel.org?
> only linuxppc-2.4? Or all?

Excellent question. But I do not know the answer.


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
"When people are least sure, they are often most dogmatic."
- John Kenneth Galbraith

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

Re: IBM 440GX, Ocotea...

[Dan Malek]

Jaap-Jan Boor wrote:

> from what 'official ppc' tree do patches eventually get into the
> official linux kernel tree(s) at kernel.org?
> only linuxppc-2.4? Or all?

It seems to be a circuitous route that I don't even understand
anymore.  Sometime stuff I check in gets there, sometimes not. :-)

http://penguinppc.org/dev/kernel.shtml tries to explain it.


	-- Dan


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

Re: IBM 440GX, Ocotea...

[Jaap-Jan Boor]

On Mar 23, 2004, at 19:24, Dan Malek wrote:

> Jaap-Jan Boor wrote:
>
>> from what 'official ppc' tree do patches eventually get into the
>> official linux kernel tree(s) at kernel.org?
>> only linuxppc-2.4? Or all?
>
> It seems to be a circuitous route that I don't even understand
> anymore.  Sometime stuff I check in gets there, sometimes not. :-)

and you have never found out the conditions when something
get's in (only when submitted at friday the 13th or something?)

>
> http://penguinppc.org/dev/kernel.shtml tries to explain it.
>

this states you should build/submit patches against kernel.org's
trees, which is quite different from linuxppc-2.[45], which is probably
Tom Rini's checkout of kernel.org's tree with all ppc patches.
Or is it?

thanks for your reply,

Jaap-Jan

>
> 	-- Dan
>
>


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

Re: IBM 440GX, Ocotea...

[Tom Rini]

On Wed, Mar 24, 2004 at 09:07:28AM +0100, Jaap-Jan Boor wrote:

> On Mar 23, 2004, at 19:24, Dan Malek wrote:
>
> >Jaap-Jan Boor wrote:
> >
> >>from what 'official ppc' tree do patches eventually get into the
> >>official linux kernel tree(s) at kernel.org?
> >>only linuxppc-2.4? Or all?
> >
> >It seems to be a circuitous route that I don't even understand
> >anymore.  Sometime stuff I check in gets there, sometimes not. :-)
>
> and you have never found out the conditions when something
> get's in (only when submitted at friday the 13th or something?)

Um, yeah.  I'm hoping 2.6 will be different from 2.4 in that regard. :)

> >http://penguinppc.org/dev/kernel.shtml tries to explain it.
>
>
> this states you should build/submit patches against kernel.org's
> trees, which is quite different from linuxppc-2.[45], which is probably
> Tom Rini's checkout of kernel.org's tree with all ppc patches.
> Or is it?

linuxppc-2.[45] are children of the linux-2.[45] trees, and contain
stuff that's not quite ready to go out, _but_will_be_soon_ or has been
put in a tree for Linus/Marcelo, but they haven't pulled yet.

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

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

Re: IBM 440GX, Ocotea...

[Jaap-Jan Boor]

On Mar 24, 2004, at 23:25, Tom Rini wrote:

>>> It seems to be a circuitous route that I don't even understand
>>> anymore.  Sometime stuff I check in gets there, sometimes not. :-)
>>
>> and you have never found out the conditions when something
>> get's in (only when submitted at friday the 13th or something?)
>
> Um, yeah.  I'm hoping 2.6 will be different from 2.4 in that regard. :)

ok!

> linuxppc-2.[45] are children of the linux-2.[45] trees, and contain
> stuff that's not quite ready to go out, _but_will_be_soon_ or has been
> put in a tree for Linus/Marcelo, but they haven't pulled yet.

ok thanks (and linuxppc-2.5 should be used to get something into 2.6?)

Jaap-Jan

>
> --
> Tom Rini
> http://gate.crashing.org/~trini/
>


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

Re: IBM 440GX, Ocotea...

[Tom Rini]

On Thu, Mar 25, 2004 at 08:57:47AM +0100, Jaap-Jan Boor wrote:

> On Mar 24, 2004, at 23:25, Tom Rini wrote:
>
> >>>It seems to be a circuitous route that I don't even understand
> >>>anymore.  Sometime stuff I check in gets there, sometimes not. :-)
> >>
> >>and you have never found out the conditions when something
> >>get's in (only when submitted at friday the 13th or something?)
> >
> >Um, yeah.  I'm hoping 2.6 will be different from 2.4 in that regard. :)
>
> ok!
>
> >linuxppc-2.[45] are children of the linux-2.[45] trees, and contain
> >stuff that's not quite ready to go out, _but_will_be_soon_ or has been
> >put in a tree for Linus/Marcelo, but they haven't pulled yet.
>
> ok thanks (and linuxppc-2.5 should be used to get something into 2.6?)

If it's something which isn't quite ready yet, it should go into
linuxppc-2.5.  Otherwise, it should go to linux-2.5, either via Andrew
Morton, or Paul or Ben sending it to Linus.

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

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

Re: IBM 440GX, Ocotea...

[Tolunay Orkun]

>> >linuxppc-2.[45] are children of the linux-2.[45] trees, and contain
>> >stuff that's not quite ready to go out, _but_will_be_soon_ or has been
>> >put in a tree for Linus/Marcelo, but they haven't pulled yet.
>>
>> ok thanks (and linuxppc-2.5 should be used to get something into 2.6?)
>
> If it's something which isn't quite ready yet, it should go into
> linuxppc-2.5.  Otherwise, it should go to linux-2.5, either via Andrew
> Morton, or Paul or Ben sending it to Linus.

If the chnage goes directly to linux-2.[56] tree directly is it also
applied to linuxppc-2.5 as well? How do you keep it in sync with
kernel.org tree?

My logic says that if the changes that goes to kernel.org 2.6 tree is not
incorporated to linuxppc 2.5 tree we have a major problem. It would be too
difficult to keep track of which tree has which.

I would rather like to think that kernel.org has a subset of ppc specific
chnages that goes to linuxppc but linuxppc has all the changes that goes
to kernel.org linux tree.

Best regards,
Tolunay Orkun


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

Re: IBM 440GX, Ocotea...

[Tom Rini]

On Thu, Mar 25, 2004 at 03:14:22PM -0600, Tolunay Orkun wrote:
> >> >linuxppc-2.[45] are children of the linux-2.[45] trees, and contain
> >> >stuff that's not quite ready to go out, _but_will_be_soon_ or has been
> >> >put in a tree for Linus/Marcelo, but they haven't pulled yet.
> >>
> >> ok thanks (and linuxppc-2.5 should be used to get something into 2.6?)
> >
> > If it's something which isn't quite ready yet, it should go into
> > linuxppc-2.5.  Otherwise, it should go to linux-2.5, either via Andrew
> > Morton, or Paul or Ben sending it to Linus.
>
> If the chnage goes directly to linux-2.[56] tree directly is it also
> applied to linuxppc-2.5 as well? How do you keep it in sync with
> kernel.org tree?

The linuxppc-2.5 tree is a child of the linux-2.5 tree.  Once a change
gets into the linux-2.5 tree, we can pull it into the linuxppc-2.5 tree.
So it becomes just another change we get.

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

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

Re: IBM 440GX, Ocotea...

[Tolunay Orkun]

>> If the chnage goes directly to linux-2.[56] tree directly is it also
>> applied to linuxppc-2.5 as well? How do you keep it in sync with
>> kernel.org tree?
>
> The linuxppc-2.5 tree is a child of the linux-2.5 tree.  Once a change
> gets into the linux-2.5 tree, we can pull it into the linuxppc-2.5 tree.
> So it becomes just another change we get.

OK. I was alarmed for no reason then.

Regards,
Tolunay Orkun


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

Re: IBM 440GX, Ocotea...

[Paul Mackerras]

Jaap-Jan Boor writes:

> In addition to this nice tree discussion, I've a question:
> from what 'official ppc' tree do patches eventually get into the
> official linux kernel tree(s) at kernel.org?
> only linuxppc-2.4? Or all?

Well, the thing to understand is that there is no automatic,
effortless way that code goes into the kernel.org trees.  Every change
that goes in involves somebody putting together a patch against the
current state of the official kernel.org trees, together with a
description of what is being changed and why it is being changed, and
sending that to Marcelo Tosatti, Andrew Morton or Linus Torvalds.

BitKeeper can help to some extent with this, mainly by providing a way
for us to send Marcelo/Andrew/Linus a bunch of changes in one go.  It
doesn't, however, provide any automatic way for changes to get from
the linuxppc-2.4 or linuxppc-2.5 trees into their trees.  The reason
is that with BK, if you pull the changes from one tree into another
tree, you have to take all the changes in the first tree that aren't
in the second.  You can't pick and choose which changesets get
transferred.  Therefore, we don't ask Marcelo/Andrew/Linus to pull
from linuxppc-2.[45] into their trees.  There is too much stuff in
there that isn't ready, or that I don't agree with, or that I just
don't understand.

I have taken on the role of ppc32 maintainer, part of which involves
sending changes to Marcelo/Andrew/Linus.  However, doing that involves
work on my part to identify which changes in linuxppc-2.[45] are ready
to send, which changes logically go together, and I have to be able to
explain the change.

When it comes to things like the 8xx/82xx/85xx support, I rely on the
maintainers for that area -- Tom Rini and Dan Malek -- to do that work
of identifying sets of related changes that are suitable for inclusion
in the official trees, and packaging them up with an explanation so
that they can be sent upstream.  (That can be done either with patches
or BK changesets; the amount of work required is pretty much the same
either way.)

Similarly, for the boot code I look to Tom and for the powermac
support I look to Ben Herrenschmidt.  For the 4xx stuff there isn't
really a maintainer at the moment, unfortunately, except that Matt
Porter is looking after the 44x boards.  I look after the classic
PowerPC core support -- exception handling, memory management, etc.,
and to some extent the 4xx core support, and the CHRP port.

What this boils down to is that for changes in these areas I expect
the maintainers for those areas to be packaging up the changes with
explanations, ready to go upstream.  Anyone is of course welcome to
put together a patch + explanation and propose that it go upstream.
In such cases I would ask the maintainer for that area for his
opinion, or if there isn't a maintainer, I would ask the submitter if
they will commit to maintaining that area of the code.  If they won't,
I would tend to drop the patch unless it is a simple, obviously
correct bugfix.

One problem we have at present is that there are a number of board
ports which don't appear to have a maintainer.  Sometimes there are
people using those ports but noone taking responsibility for updating
it and keeping it working as things change elsewhere in the kernel.
Having a maintainer is a prerequisite for the board port to be sent
upstream.

I hope this clarifies things.  If you want the kernel.org trees to
support your platform, then I suggest you put together the changes you
want to see as patches and send them to me and the maintainer for the
subarea.  Make sure that the patch comes with a good explanation of
the change, and if you think the patch should go upstream, say so.  If
possible make sure that the patch isn't too large.  If it is large,
see if you can split it up into smaller patches, each of which
contains a logically related set of changes.

Regards,
Paul.

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

Re: IBM 440GX, Ocotea...

[Jaap-Jan Boor]

Paul,

Much thanks for your explanation, it clarifies a lot.

Jaap-Jan

On Thu, 25 Mar 2004, Paul Mackerras wrote:

>
> Jaap-Jan Boor writes:
>
> > In addition to this nice tree discussion, I've a question:
> > from what 'official ppc' tree do patches eventually get into the
> > official linux kernel tree(s) at kernel.org?
> > only linuxppc-2.4? Or all?
>
> Well, the thing to understand is that there is no automatic,
> effortless way that code goes into the kernel.org trees.  Every change
> that goes in involves somebody putting together a patch against the
> current state of the official kernel.org trees, together with a
> description of what is being changed and why it is being changed, and
> sending that to Marcelo Tosatti, Andrew Morton or Linus Torvalds.
>
> BitKeeper can help to some extent with this, mainly by providing a way
> for us to send Marcelo/Andrew/Linus a bunch of changes in one go.  It
> doesn't, however, provide any automatic way for changes to get from
> the linuxppc-2.4 or linuxppc-2.5 trees into their trees.  The reason
> is that with BK, if you pull the changes from one tree into another
> tree, you have to take all the changes in the first tree that aren't
> in the second.  You can't pick and choose which changesets get
> transferred.  Therefore, we don't ask Marcelo/Andrew/Linus to pull
> from linuxppc-2.[45] into their trees.  There is too much stuff in
> there that isn't ready, or that I don't agree with, or that I just
> don't understand.
>
> I have taken on the role of ppc32 maintainer, part of which involves
> sending changes to Marcelo/Andrew/Linus.  However, doing that involves
> work on my part to identify which changes in linuxppc-2.[45] are ready
> to send, which changes logically go together, and I have to be able to
> explain the change.
>
> When it comes to things like the 8xx/82xx/85xx support, I rely on the
> maintainers for that area -- Tom Rini and Dan Malek -- to do that work
> of identifying sets of related changes that are suitable for inclusion
> in the official trees, and packaging them up with an explanation so
> that they can be sent upstream.  (That can be done either with patches
> or BK changesets; the amount of work required is pretty much the same
> either way.)
>
> Similarly, for the boot code I look to Tom and for the powermac
> support I look to Ben Herrenschmidt.  For the 4xx stuff there isn't
> really a maintainer at the moment, unfortunately, except that Matt
> Porter is looking after the 44x boards.  I look after the classic
> PowerPC core support -- exception handling, memory management, etc.,
> and to some extent the 4xx core support, and the CHRP port.
>
> What this boils down to is that for changes in these areas I expect
> the maintainers for those areas to be packaging up the changes with
> explanations, ready to go upstream.  Anyone is of course welcome to
> put together a patch + explanation and propose that it go upstream.
> In such cases I would ask the maintainer for that area for his
> opinion, or if there isn't a maintainer, I would ask the submitter if
> they will commit to maintaining that area of the code.  If they won't,
> I would tend to drop the patch unless it is a simple, obviously
> correct bugfix.
>
> One problem we have at present is that there are a number of board
> ports which don't appear to have a maintainer.  Sometimes there are
> people using those ports but noone taking responsibility for updating
> it and keeping it working as things change elsewhere in the kernel.
> Having a maintainer is a prerequisite for the board port to be sent
> upstream.
>
> I hope this clarifies things.  If you want the kernel.org trees to
> support your platform, then I suggest you put together the changes you
> want to see as patches and send them to me and the maintainer for the
> subarea.  Make sure that the patch comes with a good explanation of
> the change, and if you think the patch should go upstream, say so.  If
> possible make sure that the patch isn't too large.  If it is large,
> see if you can split it up into smaller patches, each of which
> contains a logically related set of changes.
>
> Regards,
> Paul.
>
>

--
J.G.J. Boor			  Anton Philipsweg 1
Software Engineer		  1223 KZ Hilversum
AimSys bv              		  tel. +31 35 689 1941
Postbus 2194, 1200 CD Hilversum   mailto:jjboor@aimsys.nl


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

Re: IBM 440GX, Ocotea...

[Eugene Surovegin]

On Tue, Mar 23, 2004 at 12:02:31PM +0100, Wolfgang Grandegger wrote:
>
> we are currently trying to understand which PPC Linux
> kernel tree is best suited for the IBM 440GX on the
> Ocotea eval board. We would like to support the 405GP
> and 440GP as well.

linuxppc-2.4

>
> The Ocotea 440GX board seems to be supported in the
> "linuxppc_2_4_devel" tree. Is this board configuration
> up-to-date and still maintained?

unlikely. linuxpp_2_4_devel is officialy "dead" tree :).

> A more up-to-date implementation seems to be in the
> "linuxppc-2.4" tree. Are there some open issues or known
> problems?

New UIC mode isn't supported yet.
Work on GigE support is still not finished yet.

> I realized that the L2 cache has been disabled
> recently:
>
>   $ cat arch/ppc/platforms/ocotea.c
>   ...
>   /* Disable L2-Cache due to hardware issues */
>   ibm440gx_l2c_disable();
>
> Does this mean that the L2 cache is unusable on current
> revisions of the chip? [That's why we would like to use
> this chip.]

Yes, we found problems with current chip revisions (A & B).
Ask your IBM contact for more information.

> Does this tree support the 405GP and 440GP as well?

Yes.

> Could
> anybody make some comments on the stability? We currently
> use the "linuxppc_2_4_devel" tree for these processors
> with little problems.

I'm using linuxppc-2.4 as of 2.4.21 in production for 440GP,
440GX, 405GPr, 405EP based hardware.

Eugene.

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

Re: IBM 440GX, Ocotea...

[Wolfgang Grandegger]

>-- Original Message --
>Date: Tue, 23 Mar 2004 10:31:22 -0800
>From: Eugene Surovegin <ebs@ebshome.net>
>To: Wolfgang Grandegger <wolfgang.grandegger@bluewin.ch>
>Cc: linuxppc-embedded@lists.linuxppc.org
>Subject: Re: IBM 440GX, Ocotea...
>
>
>
>On Tue, Mar 23, 2004 at 12:02:31PM +0100, Wolfgang Grandegger wrote:
>>
>> we are currently trying to understand which PPC Linux
>> kernel tree is best suited for the IBM 440GX on the
>> Ocotea eval board. We would like to support the 405GP
>> and 440GP as well.
>
>linuxppc-2.4
>
>>
>> The Ocotea 440GX board seems to be supported in the
>> "linuxppc_2_4_devel" tree. Is this board configuration
>> up-to-date and still maintained?
>
>unlikely. linuxpp_2_4_devel is officialy "dead" tree :).
>
>> A more up-to-date implementation seems to be in the
>> "linuxppc-2.4" tree. Are there some open issues or known
>> problems?
>
>New UIC mode isn't supported yet.
>Work on GigE support is still not finished yet.
>
>> I realized that the L2 cache has been disabled
>> recently:
>>
>>   $ cat arch/ppc/platforms/ocotea.c
>>   ...
>>   /* Disable L2-Cache due to hardware issues */
>>   ibm440gx_l2c_disable();
>>
>> Does this mean that the L2 cache is unusable on current
>> revisions of the chip? [That's why we would like to use
>> this chip.]
>
>Yes, we found problems with current chip revisions (A & B).
>Ask your IBM contact for more information.
>
>> Does this tree support the 405GP and 440GP as well?
>
>Yes.
>
>> Could
>> anybody make some comments on the stability? We currently
>> use the "linuxppc_2_4_devel" tree for these processors
>> with little problems.
>
>I'm using linuxppc-2.4 as of 2.4.21 in production for 440GP,
>440GX, 405GPr, 405EP based hardware.

Great, thanks a lot for the clearification. Unfortunately there
is some confusion and disappointment on what board is well
supported in what tree.

Wolfgang.


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

IBM 440GX performance (was Re: IBM 440GX, Ocotea...)

[Wolfgang Grandegger]

>-- Original Message --
>Date: Tue, 23 Mar 2004 10:31:22 -0800
>From: Eugene Surovegin <ebs@ebshome.net>
>To: Wolfgang Grandegger <wolfgang.grandegger@bluewin.ch>
>Cc: linuxppc-embedded@lists.linuxppc.org
>Subject: Re: IBM 440GX, Ocotea...
[...deletions...]
>> Could
>> anybody make some comments on the stability? We currently
>> use the "linuxppc_2_4_devel" tree for these processors
>> with little problems.
>
>I'm using linuxppc-2.4 as of 2.4.21 in production for 440GP,
>440GX, 405GPr, 405EP based hardware.

BTW, do you or somebody else have some performance figures
(LMbench?) for the GX compared to the other processor.

Thanks.

Wolfgang.


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

USB problem on 2.4.20

[song sam]

Hi,

When trying to make USB HOST mode kernel on 2.4.20
from MVL PRO 3.1 for RPXlite DW board,I found that USB
keyboard didn't work but it did work on 2.4.18 from
MVL PRO 3.0.Does anyone have success experience in
similar case?Also,the reseaon why I try to make USB
work on 2.4.20 is that I noticed the newer kernle tree
with the same configuration could get smaller and
faster kernel.Is this ture for most
case?Anyway,smaller and faster is attractive to all of
us.

Any comment and advice is welcome.

Thanks in advance!

Sam

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

Re: IBM 440GX performance (was Re: IBM 440GX, Ocotea...)

[Gerhard Jaeger]

Hi Eugene,

thanks for the benchmarks, but I was somewhat surprised to find results with
enabled L2 cache. Does this mean, that there is some existing revision
with working L2 cache, or is it only enabled to demonstrate how fast it could
be if this thing is working correctly?

Ciao,
  Gerhard


On Thursday 25 March 2004 00:40, Eugene Surovegin wrote:
> On Wed, Mar 24, 2004 at 09:59:56AM +0100, Wolfgang Grandegger wrote:
> > BTW, do you or somebody else have some performance figures
> > (LMbench?) for the GX compared to the other processor.
>
> I did some testing on our custom 440GP/GX hardware.
>
> Each system has 512M of RAM, SCSI disk was used for disk and FS testing (in
> RAID-1 configuration but without a mirror drive).
>
> I used NFS root, host - P4 1.6GHz, SuSE 8.0, 100Mbit switch connection.
>
> 440GP system was running at 400MHz/133MHz, 440GX - 500MHz/166MHz. For 440GX
> I did testing with L2C disabled and enabled.
>[SNIPSNAP]


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

Re: IBM 440GX performance (was Re: IBM 440GX, Ocotea...)

[Eugene Surovegin]

On Wed, Mar 24, 2004 at 03:40:25PM -0800, Eugene Surovegin wrote:
> All systems were running identical highly patched 2.4.21 based kernel (preempt,
> low-lat, aa-VM).

... + O(1), HZ=1000

Eugene

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

RE: IBM 440GX, Ocotea...

[Neil Wilson]

> > Does this mean that the L2 cache is unusable on current
> revisions of
> > the chip? [That's why we would like to use this chip.]
>
> Yes, we found problems with current chip revisions (A & B).
> Ask your IBM contact for more information.
>

Can you elaborate a bit on this please ?, we are considering using this
processor but would need the cache.
I have had a quick look at the 2 errata docs  I found on the IBM web
site but must be missing the bit this relate to.
Thanks.

Neil

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

Re: IBM 440GX, Ocotea...

[Matt Porter]

On Wed, Mar 24, 2004 at 02:21:38PM -0000, Neil Wilson wrote:
>
> > > Does this mean that the L2 cache is unusable on current
> > revisions of
> > > the chip? [That's why we would like to use this chip.]
> >
> > Yes, we found problems with current chip revisions (A & B).
> > Ask your IBM contact for more information.
> >
>
> Can you elaborate a bit on this please ?, we are considering using this
> processor but would need the cache.
> I have had a quick look at the 2 errata docs  I found on the IBM web
> site but must be missing the bit this relate to.

I know if I elaborated the "issue" it would violate the NDA that
we (my employer) are covered under. I assume Eugene is in a similar
position. You really should talk to IBM, that's what mvista is forced
to tell its 440GX customers. :)

-Matt

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