thoughts and questions on 8xx patches
wd at denx.de
Tue Sep 21 21:49:51 EST 2004
In message <Pine.LNX.4.60.0409210644150.9187 at dell.enoriver.com> you wrote:
> > In message <Pine.LNX.4.60.0409210605090.9033 at dell.enoriver.com> you wrote:
> >> rather than get into more detailed discussion on microcode patches,
> >> here's a (partial) patch that represents what i'd really, really,
> what i was showing was just an example, it didn't need to represent
> *exactly* the set of choices that would be in the final menu. if the
Ummm. To me "partial patch" means that this is an excerpt of exactly
the patch you want to see applied. Please write "example" if this is
what you mean.
> above is the case, that's fine. but there's still then, at the very
> least, the list of possible patches that are in *your* 2.4 kernel
> source tree. i wasn't submitting a final list of patches, just a
Please forget our tree for this discussionhere, it is not relevant.
Also, I wrote you before that the uCode stuff was only tested in a
small number of specific configurations, and that it is KNOWN TO BE
BROKEN for many configurations, including most newer 8xx processors.
> suggested *format* for selection, that's all. don't get ahead of me
It looked like a ready-to-sumbit patch, and you announced it as such.
> >> it adds a simple choice entry to the MPC8xx menu, from which you can
> >> select the appropriate patch -- it's as easy as that.
> > No, it is not that easy.
> yes, it is.
OK. I give up here. I've explained the complexity (like processor
variants, like incompatible changes of the relocation base address
pointer between versions, etc.) several times before. You seem to
> > Indeed. And AFAICT there is no way to get the processor version from
> > any other CONFIG option that the board name, so this would become an
> > awfully long list.
> in what way? the denx 2.4 kernel source tree defines all of 5
> patches. i don't see that as an overly long list, and given that the
> default selection would be "None", people who don't even know what a
> patch is would never have to make that decision.
It was _you_ who asked for a "simple" configuration where you just
enable a uCode patch, and where the kernel config tool does not even
offer selections that don;t apply to a specific board. It was _you_
who posted a "(partial) patch" which did not mention that you will
violate your own requirements.
> at the moment, your denx tree supports a number of patches that
> require users to edit source files and manually define constants. in
> what way is this a better idea than picking from a drop down choice
It is not better. Nobody ever claimed that. See above.
> (and i never suggested that the config process automatically detect
> the 850 or non-850-ness of the processor. that would be a manual
Yes, you did. Quote Robert P. J. Day (22 Jul 2004 08:00:01 -0400):
perhaps overly ambitious, but it would be *really* cool if the
patches presented to the developer were tied to the underlying
processor. that is, once you've selected, say, RPXlite, the only
patches displayed in the menu should be those relevant to the rpxlite.
> me: "um ... ok, what about a patch like this?"
> reply: "no."
Just look at this discussion today: you post a "(partial) patch", and
when I point out problems with it you say, "umm, that's not the real
patch, it's just an example, but it needs to be fixed and extended
and actually you goot make it working first." I claim that it's more
complex than this, you deny this, and then add that of course more
manual selections need to be added.
I have to admit that I don't understand what _exactly_ you suggest.
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
It is easier to write an incorrect program than understand a correct
More information about the Linuxppc-dev