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

[Mark A. Greer]

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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cfg.diff
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20030114/43f35112/attachment.txt>