Re: [Linux-galileo] Re: EV-64260-BP & GT64260 bi_recs

Re: [Linux-galileo] Re: EV-64260-BP & GT64260 bi_recs

[Michael Sokolov]

Nye Liu <nyet@zumanetworks.com> wrote:

> _devel does not work on our custom board due
> to ethernet bugs,

Not encountered any so far.

> mpsc problems, and no 750cx support.
                     ^^^^^^^^^^^^^^^^

What are talking about? Adirondack, IBM's reference board for 750CXe built for
them by SBS, has been supported (rock solid) in 2_4_devel since last summer. (I
know firsthand as I wrote all firmware and Linux code for the Adirondack and
significantly participated in the hardware design.) Also the EV-64260A I had at
SBS on which I did my first GT-64260 work had a 750CXe CPU module (SBS was
fully committed to 750CXe or 750FX for all designs by then) and ran fine.

> _devel does also
> not work 100% with ppcboot since it does not support bd_info afaik.

I'm very very glad that 2_4_devel doesn't use the bd_info crap and uses bi_recs
instead. If PPCBoot can't handle that, it's PPCBoot's problem. There is more to
the world than PPCBoot. StarMON rules!

> We do have an Abatron.

Ahh, JTAG Heisenberg debuggers. Another thing I can't stand. Real programmers
don't need no stinking JTAG debuggers. StarMON's debug capabilities are better
than any JTAG debugger and don't have the Heisenberg effects of the latter.

--
Michael Sokolov					786 E MISSION AVE APT F
Programletarian Freedom Fighter			ESCONDIDO CA 92025-2154 USA
International Free Computing Task Force		Phone: +1-760-480-4575
						msokolov@ivan.Harhan.ORG (ARPA)
Let the Source be with you
Programletarians of the world, unite!

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

Re: [Linux-galileo] Re: EV-64260-BP & GT64260 bi_recs

[Murray Jensen]

On Sun, 24 Mar 02 20:31:55 PST, msokolov@ivan.Harhan.ORG (Michael Sokolov) writes:
>I'm very very glad that 2_4_devel doesn't use the bd_info crap and uses bi_recs
>instead. If PPCBoot can't handle that, it's PPCBoot's problem. There is more to
>the world than PPCBoot. StarMON rules!

2_4_devel does "use the bd_info crap". It is my impression that bi_recs support
in 2_4_devel is very limited and only used by certain platforms, so you could
safely say that it doesn't use bi_recs (correct me if this is wrong - I don't
know all the other platforms intimately). The whole huge discussion on this very
list recently (with exactly this same subject line) has been to determine how
best to get rid of "the bd_info crap" and only use bi_recs. I'm sure as soon as
this is ironed out, ppcboot will easily support bi_recs (there you go Wolfgang -
I saved you having to respond to this :-). Cheers!
								Murray...
--
Murray Jensen, CSIRO Manufacturing Sci & Tech,         Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen@csiro.au

Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/


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

Re: [Linux-galileo] Re: EV-64260-BP & GT64260 bi_recs

[Michael Sokolov]

Murray Jensen <Murray.Jensen@cmst.csiro.au> wrote:

> 2_4_devel does "use the bd_info crap".

Thankfully not for EV-64260 or any other almost-non-embedded 6xx/7xx/74xx
systems, only for 4xx/8xx/82xx stuff that's completely off my radar screen for
now and probably for the foreseeable future.

> It is my impression that bi_recs support
> in 2_4_devel is very limited and only used by certain platforms, so you could
> safely say that it doesn't use bi_recs (correct me if this is wrong - I don't
> know all the other platforms intimately).

It is wrong. Every platform in 2_4_devel my hacky hands have touched uses
bi_recs exclusively. bi_recs work very well for me as they are right now.

> The whole huge discussion on this very
> list recently (with exactly this same subject line) has been to determine how
> best to get rid of "the bd_info crap" and only use bi_recs. I'm sure as soon as
> this is ironed out, [...]

For me it has been ironed out perfectly a long time ago, which is why I haven't
participated much in that "discussion".

MS

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

Re: [Linux-galileo] Re: EV-64260-BP & GT64260 bi_recs

[Murray Jensen]

On Sun, 24 Mar 02 22:47:19 PST, msokolov@ivan.Harhan.ORG (Michael Sokolov) writes:
>It is wrong. Every platform in 2_4_devel my hacky hands have touched uses
>bi_recs exclusively. bi_recs work very well for me as they are right now.

Which part of "very limited and only used by certain platforms" is wrong? OK,
maybe its half-and-half then (half the platforms use them, half don't) - that's
a long way from all platforms. The proposal is that 2.5 use bi_recs exclusively
for all platforms (something I agree with, by the way). The discussion is in the
detail of the implementation.

>For me it has been ironed out perfectly a long time ago, which is why I haven't
>participated much in that "discussion".

Well, you'd better get involved then - because the proposal is to change them
(or maybe "extend slightly in a backwards compatible way", would better describe
it) so if they're perfect for you now, you wouldn't want this :-) I think they
are too limited at the moment, but could be very useful if implemented properly.
benh's current proposal appears to give me all that I want (except for some
formal definition of "dimension"), so I support it. Cheers!
								Murray...
--
Murray Jensen, CSIRO Manufacturing Sci & Tech,         Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen@csiro.au

Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/


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

Re: [Linux-galileo] Re: EV-64260-BP & GT64260 bi_recs

[Michael Sokolov]

Nye Liu <nyet@zumanetworks.com> wrote:

> Mike S: I would also be VERY interested in any work you may have already
> done in the mpsc or eth drivers; especially with regards to SMP and
> cache coherency.

I already wrote about this in my long posting.

> i would
> still like other GT EVB users lurking here to stress test the _galileo
> tree as best they can, since right now, I seem to be the only active
> developer with an EVB contributing to _gal.

Well, EV-64260 is completely broken in the 2_4_galileo tree, and has been so
from the moment I first looked at it through now inclusive. Since 2_4_devel
works so much better for me and is closer to my goal of stable support in 2.4
release tarballs on kernel.org, I really have no incentive to mess with the
2_4_galileo crap.

Just to tell everyone honestly how I really feel, IMHO 2_4_galileo is Nye's
play tree and I strongly recommend against anyone other than Nye using it.

MS

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

Re: [Linux-galileo] Re: EV-64260-BP & GT64260 bi_recs

[Nye Liu]

On Sun, Mar 24, 2002 at 08:19:58PM -0800, Michael Sokolov wrote:
> Nye Liu <nyet@zumanetworks.com> wrote:
>
> Just to tell everyone honestly how I really feel, IMHO 2_4_galileo is Nye's
> play tree and I strongly recommend against anyone other than Nye using it.
>

Thanks for your constructive criticism. I find your demeanor and helpful
attitude quite refreshing! :)

Have a great day!

--
Nye Liu
nyet@zumanetworks.com

"Who would be stupid enough to quote a fictitious character?"
	-- Don Quixote

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

Re: EV-64260-BP & GT64260 bi_recs

[Michael Sokolov]

Tom Rini <trini@kernel.crashing.org> wrote:

> Sure there is, for it to be accepted.

Wait a minute, why am I even talking to you? Mark said he is the responsible
maintainer and promised to push my patch in a few days if there is no consensus
by then, and I think I'll just wait a few days and then ask him to stick to his
word. (I'm willing to bet $50 that in the next few days there will be no
consensus nor will anyone else offer a counterpatch.)

> And would you please make it
> versus the _galileo tree

Sorry, no, that would be a step backward and we need to move forward.

MS

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

Re: EV-64260-BP & GT64260 bi_recs

[Troy Benjegerdes]

On Wed, Mar 20, 2002 at 09:04:35AM -0800, Michael Sokolov wrote:
>
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> > Sure there is, for it to be accepted.
>
> Wait a minute, why am I even talking to you? Mark said he is the responsible
> maintainer and promised to push my patch in a few days if there is no consensus
> by then, and I think I'll just wait a few days and then ask him to stick to his
> word. (I'm willing to bet $50 that in the next few days there will be no
> consensus nor will anyone else offer a counterpatch.)

Well, If I remember right, Mark doesn't even have a galileo board anymore
(someone else got it). So I could probably make an argument I'm the
maintainer now.

>
> > And would you please make it
> > versus the _galileo tree
>
> Sorry, no, that would be a step backward and we need to move forward.

I strongly suggest you submit me (or the -galileo) list patches, otherwise
when I start merging the _galileo tree code to _devel, I'm likely to blow
your changes away because I can't test them.

And PLEASE give me a different eth driver ;)

The one in the tree right now works for single cpus, but
a) is ugly
b) blows up very nicely with SMP.


The _galileo tree was created to keep us from thrashing in _devel with a
bunch of crappy (but working) code.

FYI, I am about ready to merge Zuma's gt64260_mpsc driver to 2_4_devel
since it seems to work reasonably well, and the code is mostly sane. If
you have another mpsc driver, speak now or forever hold your peace.

--
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's
why I draw cartoons. It's my life." -- Charles Schulz

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

Re: EV-64260-BP & GT64260 bi_recs

[Mark A. Greer]

Troy Benjegerdes wrote:

> Well, If I remember right, Mark doesn't even have a galileo board anymore
> (someone else got it). So I could probably make an argument I'm the
> maintainer now.

Mine broke.  I'm supposed to get one yesterday/today/tomorrow.  No FedEx guy so far
today...


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

Re: EV-64260-BP & GT64260 bi_recs

[Jim Potter]

Now that things are settling down a bit -- who's got which tree running on which
platform and in what condition?  Basically, what's the conditon of the 2_4_galileo and
2_4_devel tree's on EVB, MVP, (etc) -- SMP y/n, PCI cards (scsi, ide, etc) y/n,
running solid y/n, and under which boot environment (dink, ppcboot, starmon, etc)?


> Troy Benjegerdes wrote:
>
> > Well, If I remember right, Mark doesn't even have a galileo board anymore
> > (someone else got it). So I could probably make an argument I'm the
> > maintainer now.
>
> Mine broke.  I'm supposed to get one yesterday/today/tomorrow.  No FedEx guy so far
> today...

--
Sincerely,

Jim Potter
45th Parallel Processing


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

Re: [Linux-galileo] Re: EV-64260-BP & GT64260 bi_recs

[Nye Liu]

On Thu, Mar 21, 2002 at 01:36:48PM -0800, Jim Potter wrote:
> Now that things are settling down a bit -- who's got which tree running on which
> platform and in what condition?  Basically, what's the conditon of the 2_4_galileo and
> 2_4_devel tree's on EVB, MVP, (etc) -- SMP y/n, PCI cards (scsi, ide, etc) y/n,
> running solid y/n, and under which boot environment (dink, ppcboot, starmon, etc)?

I have _gal and _devel running on the EVB and _gal running our custom
board with ppcboot. Both are stable; the _gal has a bunch of other stuff
and random bug fixes in it. _devel does not work on our custom board due
to ethernet bugs, mpsc problems, and no 750cx support. _devel does also
not work 100% with ppcboot since it does not support bd_info afaik.

We are using the 750cx(e). We do not use DINK. We do have an Abatron.

Note that our evb is showing signs of breaking (the cpu module slot seems
to be a real weak point), so we may end up just like Mark any second now.

--
Nye Liu
nyet@zumanetworks.com

"Who would be stupid enough to quote a fictitious character?"
	-- Don Quixote

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

Re: [Linux-galileo] Re: EV-64260-BP & GT64260 bi_recs

[Mark A. Greer]

Nye Liu wrote:

> Note that our evb is showing signs of breaking (the cpu module slot seems
> to be a real weak point), so we may end up just like Mark any second now.

Yep, mine broke when switching cpu's.  Was supporting it underneath & everything but I
guess I did it one too many times...


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

Re: EV-64260-BP & GT64260 bi_recs

[Michael Sokolov]

Mark A. Greer <mgreer@mvista.com> wrote:

> Man, can I ever turn a quiet email day into a hurricane!!  :)

Ever heard the term filibuster? That's what I think happening here: lots of
talk, no work. Also note that so far I'm the only one who has posted a patch,
the rest is verbiage.

> Point well taken and you're right, perhaps the cmd_line is a better way to
> pass in hdx/fdx & speed, phy addr & is_rmii.

The PHY address and MII vs. RMII are things fixed by board circuitry and would
normally be hard-coded. The only reason I added them to BI_GT64260_ETH_CFG was
because I imagined the #ifdef maze that would otherwise eventually grow in the
gt64260_eth driver as people add ports to different boards with these things
wired differently.

As for speed, etc. no other driver I know of requires the bootloader to pass
this info. It's normally set by ethconfig, miitool, etc. Please don't add that
in there, I have no slightest idea what to put in those fields if they were in
the bi_rec.

MS

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

Re: [Linux-galileo] Re: EV-64260-BP & GT64260 bi_recs

[Troy Benjegerdes]

> > Point well taken and you're right, perhaps the cmd_line is a better way to
> > pass in hdx/fdx & speed, phy addr & is_rmii.
>
> The PHY address and MII vs. RMII are things fixed by board circuitry and would
> normally be hard-coded. The only reason I added them to BI_GT64260_ETH_CFG was
> because I imagined the #ifdef maze that would otherwise eventually grow in the
> gt64260_eth driver as people add ports to different boards with these things
> wired differently.

If we get an #ifdef maze, this is an indication we need to re-think how
gt64260 is done. My suggestion is a struct that the platform/*_setup.c
file can give to the eth driver somehow that specifies all this stuff.

I would really like the gt64260 eth and serial drivers to be useable on
mips also.. so we need to find someone with a mips 64240 board..

FYI, the gt eth driver is completely busticated for SMP. I managed to get
zuma's mpsc driver working on SMP by turning on snooping. (this may be the
'wrong' thing to do , but it works for now)

> As for speed, etc. no other driver I know of requires the bootloader to pass
> this info. It's normally set by ethconfig, miitool, etc. Please don't add that
> in there, I have no slightest idea what to put in those fields if they were in
> the bi_rec.

I agree 100% on this.

The only thing we *HAVE* to find out from the firmware is the MAC address.



--
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's
why I draw cartoons. It's my life." -- Charles Schulz

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

Re: [Linux-galileo] Re: EV-64260-BP & GT64260 bi_recs

[Mark A. Greer]

Troy Benjegerdes wrote:

> FYI, the gt eth driver is completely busticated for SMP. I managed to get
> zuma's mpsc driver working on SMP by turning on snooping. (this may be the
> 'wrong' thing to do , but it works for now)

I haven't looked at the zuma version of the drivers but the ones inherited from
marvell need to be dumped and completely rewritten...and made SMP-safe.  Its been
on my list but I haven't gotten around to do that.  If/when I do, I'll look at what
Nye, et. al. has done first.  They may have all the issues settled already.

Mark


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

Re: [Linux-galileo] Re: EV-64260-BP & GT64260 bi_recs

[Nye Liu]

On Thu, Mar 21, 2002 at 02:10:18PM -0500, Mark A. Greer wrote:
> Troy Benjegerdes wrote:
>
> > FYI, the gt eth driver is completely busticated for SMP. I managed to get
> > zuma's mpsc driver working on SMP by turning on snooping. (this may be the
> > 'wrong' thing to do , but it works for now)
>
> I haven't looked at the zuma version of the drivers but the ones inherited from
> marvell need to be dumped and completely rewritten...and made SMP-safe.  Its been
> on my list but I haven't gotten around to do that.  If/when I do, I'll look at what
> Nye, et. al. has done first.  They may have all the issues settled already.

Mark: myself, Troy, and rex will be working on this. The serial driver
is fine in SMP (although it depends on snooping, which, according to
Galileo, is broken for SDMA *and* ETHDMA).

The GT's ethernet snooping is DEFINITELY broken; not sure where we will
go from here for smp. I will let people smarter than me handle that..

The good news is that PCI snooping seems to be rock solid.

Troy: the question in my mind is whether the SDMA snooping is always
safe or not. We will torture test the SDMA some here; but keep in mind
when we first did this, the SDMA snooping seems to cause problems
under severe stress testing, which is why by default the driver does
explicit cache flushes. Maybe things have changed since then; it needs
testing.

What I dont get is that in BOTH (SDMA and ETHDMA) situations (with
CPU snooping on), if DMA snooping is off, invalidates were still
required. Perhaps somebody more knowledgeable can explain why this is.

Mike S: I would also be VERY interested in any work you may have already
done in the mpsc or eth drivers; especially with regards to SMP and
cache coherency.

Finally, my EVB board is growing increasingly less stable by the day (i
think my cpu module is very loose; if i touch the cpu, the board bombs
out), so testing on that platform is becoming increasingly difficult.

The good news is that our custom board is pretty stable, but i would
still like other GT EVB users lurking here to stress test the _galileo
tree as best they can, since right now, I seem to be the only active
developer with an EVB contributing to _gal.

--
Nye Liu
nyet@zumanetworks.com

"Who would be stupid enough to quote a fictitious character?"
	-- Don Quixote

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