All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mark A. Greer" <mgreer@mvista.com>
To: Tom Rini <trini@kernel.crashing.org>
Cc: linuxppc-dev <linuxppc-dev@lists.linuxppc.org>
Subject: Re: Patch moving latest linux-galileo common & ev64260 code to 2_4_devel
Date: Tue, 14 Jan 2003 16:47:20 -0700	[thread overview]
Message-ID: <3E24A188.6050802@mvista.com> (raw)
In-Reply-To: <20030114163239.GD791@opus.bloom.county>

[-- 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" \

  reply	other threads:[~2003-01-14 23:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2003-02-06 19:37       ` Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E24A188.6050802@mvista.com \
    --to=mgreer@mvista.com \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=trini@kernel.crashing.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.