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

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