All of lore.kernel.org
 help / color / mirror / Atom feed
* Patch moving latest linux-galileo common & ev64260 code to 2_4_devel
@ 2002-12-24 16:34 Mark A. Greer
  2002-12-24 18:36 ` Mark A. Greer
  0 siblings, 1 reply; 5+ messages in thread
From: Mark A. Greer @ 2002-12-24 16:34 UTC (permalink / raw)
  To: linuxppc-dev


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/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Patch moving latest linux-galileo common & ev64260 code to 2_4_devel
  2002-12-24 16:34 Patch moving latest linux-galileo common & ev64260 code to 2_4_devel Mark A. Greer
@ 2002-12-24 18:36 ` Mark A. Greer
  2003-01-14 16:32   ` Tom Rini
  0 siblings, 1 reply; 5+ messages in thread
From: Mark A. Greer @ 2002-12-24 18:36 UTC (permalink / raw)
  To: Mark A. Greer; +Cc: linuxppc-dev


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/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Patch moving latest linux-galileo common & ev64260 code to 2_4_devel
  2002-12-24 18:36 ` Mark A. Greer
@ 2003-01-14 16:32   ` Tom Rini
  2003-01-14 23:47     ` Mark A. Greer
  0 siblings, 1 reply; 5+ messages in thread
From: Tom Rini @ 2003-01-14 16:32 UTC (permalink / raw)
  To: Mark A. Greer; +Cc: linuxppc-dev


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/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Patch moving latest linux-galileo common & ev64260 code to 2_4_devel
  2003-01-14 16:32   ` Tom Rini
@ 2003-01-14 23:47     ` Mark A. Greer
  2003-02-06 19:37       ` Tom Rini
  0 siblings, 1 reply; 5+ messages in thread
From: Mark A. Greer @ 2003-01-14 23:47 UTC (permalink / raw)
  To: Tom Rini; +Cc: linuxppc-dev

[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]

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

[-- Attachment #2: cfg.diff --]
[-- Type: text/plain, Size: 2090 bytes --]

===== arch/ppc/config.in 1.163 vs edited =====
--- 1.163/arch/ppc/config.in	Tue Jan 14 09:08:28 2003
+++ edited/arch/ppc/config.in	Tue Jan 14 16:08:59 2003
@@ -176,31 +176,27 @@
 fi

 if [ "$CONFIG_GT64260" = "y" ]; then
-   mainmenu_option next_comment
-   comment 'Marvell/Galileo GT64260 Options'
+  mainmenu_option next_comment
+  comment 'Marvell/Galileo GT64260 Options'

-   dep_bool 'PCI Bus 0 Snooping Disable (experimental)' \
-     CONFIG_GT64260_BUS_0_NOT_COHERENT $CONFIG_EXPERIMENTAL
-   dep_bool 'PCI Bus 1 Snooping Disable (experimental)' \
-     CONFIG_GT64260_BUS_1_NOT_COHERENT $CONFIG_EXPERIMENTAL
+  dep_bool 'PCI Bus 0 Snooping Disable (experimental)' \
+    CONFIG_GT64260_BUS_0_NOT_COHERENT $CONFIG_EXPERIMENTAL
+  dep_bool 'PCI Bus 1 Snooping Disable (experimental)' \
+    CONFIG_GT64260_BUS_1_NOT_COHERENT $CONFIG_EXPERIMENTAL

-   if [ "$CONFIG_GT64260_BUS_0_NOT_COHERENT" = "y" \
-     -o "$CONFIG_GT64260_BUS_1_NOT_COHERENT" = "y" ]; then
-       define_bool CONFIG_NOT_COHERENT_CACHE y
-   fi
+  if [ "$CONFIG_GT64260_BUS_0_NOT_COHERENT" = "y" \
+	-o "$CONFIG_GT64260_BUS_1_NOT_COHERENT" = "y" ]; then
+    define_bool CONFIG_NOT_COHERENT_CACHE y
+  fi

-   bool 'Board uses PPCBoot' CONFIG_USE_PPCBOOT
-   if [ "$CONFIG_USE_PPCBOOT" = "y" ]; then
-       hex 'Base Address assigned by Firmware' CONFIG_GT64260_ORIG_REG_BASE 0xf8000000
-   else
-       hex 'Base Address assigned by Firmware' CONFIG_GT64260_ORIG_REG_BASE 0x14000000
+  bool 'Board uses PPCBoot' CONFIG_USE_PPCBOOT
+  hex 'Base Address assigned by Firmware' CONFIG_GT64260_ORIG_REG_BASE 0x14000000

-       bool 'Change Base Address in Bootloader' CONFIG_GT64260_NEW_BASE
-       if [ "$CONFIG_GT64260_NEW_BASE" = "y" ]; then
-	 hex 'New Base Address' CONFIG_GT64260_NEW_REG_BASE 0x14000000
-       fi
-   fi
-   endmenu
+  bool 'Change Base Address in Linux/PPC Bootwrapper' CONFIG_GT64260_NEW_BASE
+  if [ "$CONFIG_GT64260_NEW_BASE" = "y" ]; then
+    hex 'New Base Address' CONFIG_GT64260_NEW_REG_BASE 0x14000000
+  fi
+  endmenu
 fi

 if [ "$CONFIG_FORCE" = "y" -o "$CONFIG_MENF1" = "y" \

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Patch moving latest linux-galileo common & ev64260 code to 2_4_devel
  2003-01-14 23:47     ` Mark A. Greer
@ 2003-02-06 19:37       ` Tom Rini
  0 siblings, 0 replies; 5+ messages in thread
From: Tom Rini @ 2003-02-06 19:37 UTC (permalink / raw)
  To: Mark A. Greer; +Cc: linuxppc-dev


On Tue, Jan 14, 2003 at 04:47:20PM -0700, Mark A. Greer wrote:
> Tom Rini wrote:
>
> >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/

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2003-02-06 19:37 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-24 16:34 Patch moving latest linux-galileo common & ev64260 code to 2_4_devel Mark A. Greer
2002-12-24 18:36 ` Mark A. Greer
2003-01-14 16:32   ` Tom Rini
2003-01-14 23:47     ` Mark A. Greer
2003-02-06 19:37       ` Tom Rini

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.