In message [off-list ref] you wrote:
from list discussions some time back, i already gave up on the idea of
the configuration being able to detect the exact processor and taking
that into account. we've already established that, and i'm happy with
that.
OK.
all i'm suggesting now is a drop down choice menu of known patches
relevant to that architecture, that's all. in some cases, there would
be two choices, as in:
[ ] I2C/SPI for 850
[ ] I2C/SPI for 8xx (non-850)
Plus there is also the case of "need to relocate parameter RAM on a
MPC852/859/866/... processor". In this case no microcode patch i
sneeded, and the current code will crash the system.
More cases may be necessary.
i can't imagine that this list would get overly long. from what i can
see, the denx tree supports the following list of patches:
Please forget this. I asked you several times NOT to use this old
code for reference. It is known to be broken in several configu-
rations.
and, unless i'm reading this badly, that's the entire list. all of
No, it's not. It will not work on most of the newer MPC8xx
processors.
so ... why is this such an objectionable thing?
Because it is (1) incomplete and (2) broken.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
There are two ways to write error-free programs. Only the third one
works.
On Tue, 21 Sep 2004, Wolfgang Denk wrote:
In message [off-list ref] you wrote:
quoted
from list discussions some time back, i already gave up on the idea of
the configuration being able to detect the exact processor and taking
that into account. we've already established that, and i'm happy with
that.
OK.
quoted
all i'm suggesting now is a drop down choice menu of known patches
relevant to that architecture, that's all. in some cases, there would
be two choices, as in:
[ ] I2C/SPI for 850
[ ] I2C/SPI for 8xx (non-850)
Plus there is also the case of "need to relocate parameter RAM on a
MPC852/859/866/... processor". In this case no microcode patch i
sneeded, and the current code will crash the system.
More cases may be necessary.
...
quoted
and, unless i'm reading this badly, that's the entire list. all of
No, it's not. It will not work on most of the newer MPC8xx
processors.
quoted
so ... why is this such an objectionable thing?
Because it is (1) incomplete and (2) broken.
ok, so i'll back off and ask one more question. even without a *current* list of microcode patches, is there any value to even building in the infrastructure for such a thing in the config menu, so that patches can be added quickly and (relatively) painlessly as they come up? and old ones tossed out as they become obsolete? if there's no value to this at all, i'll just let it drop and move on.
rday
On Sep 21, 2004, at 8:56 AM, Robert P. J. Day wrote:
ok, so i'll back off and ask one more question.
Create and test the patch that works for you. Don't be creating
options and code for things you can't test and verify. Those
of us that have lived through the generations of microcode
patches and processor variants know you can't guess what
the future will bring. If someone else has a need to extend
the work you have done, they will do that to meet their
requirements.
If you make the options available and write the code to
match, people are going to believe it works. If you can't
test it, they will struggle with it and we will have these
"... this is obviously broken ..." discussions all over again.
Thanks.
-- Dan