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" \
next prev parent 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$(echo .)com \
--cc=linuxppc-dev@lists$(echo .)linuxppc.org \
--cc=trini@kernel$(echo .)crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox