[U-Boot-Users] Re: Patch: Support for PQ27e (8247/48/71/72) chips and MPC8272ADS board

[Yuli Barcohen]

>>>>> Dan Malek writes:

    Dan> Sorry to jump into this late, but since I do tons of PQ work I
    Dan> want to add my comments.

    Yuli> .... I personally don't like such
    Yuli> compile-time definitions because chip version can be easily
    Yuli> detected in run-time.

    Dan> No, it can't in all cases.  You can determine the core type and
    Dan> can sometimes find something about the CPM rom version, but
    Dan> tracking down and maintaining the permutations isn't trivial.

Well, you can't know if it's 8271 or 8272, for example, but you don't
need this info. You can detect the "family" (HiP4, HiP7, etc.) and this
is enough for the tasks which we are discussing.

    Dan> You have great inside information on this stuff,

No, I don't (and I won't disclose such information in GPL code if I
had).

    Dan> but it doesn't help the rest of us add or maintain this
    Dan> software.

    Wolfgang> The advantage of compile-time definitions is that they
    Wolfgang> result in smaller code.

    Dan> I agree.  We've been doing it this way in Linux for years, the
    Dan> compiler makes it pretty clear when you don't have something
    Dan> #defined.

And these #defines were one of the reasons that we developed completely
new Linux support for PQs. Now we've got one kernel image running on
MPC8260ADS, MPC8266ADS, PQ2FADS, and MPC8272ADS. You would have four
different images. Probably that images would be smaller by 2K, maybe 5K,
but if the price is maintaining four images instead of one, I vote for
one. The same is true for other board families (FADS, etc.) I agree that
this can be less important for boot loaders which in many cases contain
too much board-specific code to build one-for-all image.

    Dan> What's run-time code going to do when it can't determine the
    Dan> core or CPM type?  Assume some defaults and hope a message gets
    Dan> printed?

Maybe such a thing can happen but in many years of development for
Motorola controllers I personally never had a problem with run-time
detection of chip features.

-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli at arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================