Patch moving latest linux-galileo common & ev64260 code to 2_4_devel

Below is a link to a patch against the latest linuxppc_2_4_devel tree that brings
the Marvell/Galileo GT64260 and EV64260 code up to the latest version that's in the linux-galileo tree.

ftp://source.mvista.com/linuxppc/galileo_2_4_devel.diff

Comments welcome.

Mark


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

Okay, as requested, the big patch has been broken up into somewhat
logical pieces (although not perfect).  They are available here:

ftp://source.mvista.com/linuxppc/gal/

Mark
--


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

On Tue, Dec 24, 2002 at 11:36:46AM -0700, Mark A. Greer wrote:

Okay, as requested, the big patch has been broken up into somewhat
logical pieces (although not perfect).  They are available here:

ftp://source.mvista.com/linuxppc/gal/

I've applied all of this, in the interest of getting things back into
sync.

What I want to know 'tho, is why is there still the 'reg base' being
either here or there.  How hard would it be to always have it at the
'other' location?  Or, was it decided that it was best to allow this to
end up anywhere?

Also, I would really like to see the if/else of PPCBoot go away in favor
of something like parsing PPCBoot, if it exists, and if not setting up
things the 'other' way.  ie:
platform_init(...) {
  if (r3 == ppcboot)
    parse_ppcboot()
  else
    find_things_out()
  ...
}

find_things_out() {
  bd_t.memsize = gt64260_find_end_of_memory();
  ...
}

IOW, if we don't have PPCBoot and it's 'bd_t', fill it out.[1]

[1] And of course this brings us to bi_recs, which is another
flamewar^H^H^H^H^H^H^H^Hdiscussion.

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

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

Tom Rini wrote:

I've applied all of this, in the interest of getting things back into
sync.

Thanks.

What I want to know 'tho, is why is there still the 'reg base' being
either here or there.  How hard would it be to always have it at the
'other' location?  Or, was it decided that it was best to allow this to
end up anywhere?

There wasn't a decision per se but there were 2 versions of DINK and
different versions of PPCBoot that left the bridge at different
locations  so I made the "incoming" base address configurable to
anywhere (but with different default for PPCBoot vs. something else).
Also, people wanted the base moved to different locations for the kernel
so I made the "outgoing" base address configurable as well.

Note: The linuxppc bootwrapper is what takes the "incoming" base address
& moves it to the specified "outgoing" base address.

I sort of like having that flexibility but then I seem to like config
options more than others here so...  I can get rid of the different
defaults and have included a patch to do so.  Is that enough?

Also, I would really like to see the if/else of PPCBoot go away in favor
of something like parsing PPCBoot, if it exists, and if not setting up
things the 'other' way.  ie:
platform_init(...) {
 if (r3 == ppcboot)
   parse_ppcboot()
 else
   find_things_out()
 ...
}

find_things_out() {
 bd_t.memsize = gt64260_find_end_of_memory();
 ...
}

IOW, if we don't have PPCBoot and it's 'bd_t', fill it out.[1]

I suppose but there is code that can be ifdef'd out which makes the
executable smaller.  Isn't it worth keeping them for that reason?

[1] And of course this brings us to bi_recs, which is another
flamewar^H^H^H^H^H^H^H^Hdiscussion.

I've totally punted on this for the same reason...

Mark

On Tue, Jan 14, 2003 at 04:47:20PM -0700, Mark A. Greer wrote:

Tom Rini wrote:

quoted

Also, I would really like to see the if/else of PPCBoot go away in favor
of something like parsing PPCBoot, if it exists, and if not setting up
things the 'other' way.  ie:
platform_init(...) {
if (r3 == ppcboot)
  parse_ppcboot()
else
  find_things_out()
...
}

find_things_out() {
bd_t.memsize = gt64260_find_end_of_memory();
...
}

IOW, if we don't have PPCBoot and it's 'bd_t', fill it out.[1]

I suppose but there is code that can be ifdef'd out which makes the
executable smaller.  Isn't it worth keeping them for that reason?

That's the exact opposite of what I intended, actually.  I want
CONFIG_USE_PPCBOOT to go away.  For example, in
gt64260_eth.c::gt64260_eth_init yoou do:
#ifndef CONFIG_USE_PPCBOOT
 else {
   return -ENODEV;
 }
#else
  ... magic to find an enet addr from PPCBOOT
#endif

IMHO, this should all be:
  if (gt64260_info_struct.enet_addr)
    memcpy(..)
  else
    return -ENODEV

And so on.  Convert the bd_t into a 'generic' struct, fill it out with
what PPCBoot passes, or is gleaned from the cmdline, or bi_recs of stuff
gleaned from i2c, or whatever.

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

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