thoughts and questions on 8xx patches
wd at denx.de
Tue Sep 21 22:45:58 EST 2004
In message <Pine.LNX.4.60.0409210741150.9337 at dell.enoriver.com> you wrote:
> > These things have nothing to do with each other.
> ok, i was definitely unclear about the point i was trying to make,
> so let me rephrase. i understand that the patch itself is independent
> from the code to copy/install it -- your point is well taken, and i
> accept that the ucode patch itself works just fine. but, in this
> context, it's premature to say that it clearly "obsoletes" the older
> patch given that micropatch.c could never have installed it
I repeat: these things have nothing to do with each other.
The uCode patch may even be used in a completely different OS where
there is no such thing like micropatch.c. and still the I2C/SPI/SMC1
obsoletes the older I2C/SPI patch. Your terms "presumptuous" and
"premature" are inappropriate.
> been tested in the current situation. that's all i meant. anyone who
> took your advice and moved up to the newer patch and installed it
> would have been in for a rude awakening.
We were discussiong a NEW implementation for 2.6, right? Of course
you will have to fix the known problems. Anybody who is trying the
old code on - say - a MPC859 will experience much severe problems.
> and, besides, who's to say that the new I2C/SPI/SMC1 patch
> "obsoletes" the older I2C/SPI patch? what if someone *wants* just the
> older relocation and has no need to move SMC1? the older patch works.
What does it hurt?
> observation. i've been told, more than once, that my suggestions
> regarding applying microcode patches are not viable -- that it's "not
> that easy". but no one seems prepared to explain exactly why.
Arg... You must have bad memory. For example:
> Subject: Re: more questions about 8xx microcode patches
> From: Wolfgang Denk <wd at denx.de>
> Date: Wed, 28 Jul 2004 00:30:28 +0200
> To: "Robert P. J. Day" <rpjday at mindspring.com>
> Cc: Embedded Linux PPC list <linuxppc-embedded at lists.linuxppc.org>
> Just to add to the complexity: are you aware that the parameter RAM
> relocation may be different between 8xx processors? For example it
> seems that on the 866 family you can relocate PRAM even without
> loading any uCode by just writing the correct offset to (for example)
> the spi_rpbase register.
I also explained to you that the assumption that *_rpbase == 0 means
that no uCode patch is installed is wrong, and that code which writes
0 into this register will crash on such processors.
And so on. You received similar explanations why selecting a specific
processor model is complicated.
> i've proposed a simple, *workable* solution for selecting ucode
> patches from a short, established list. if you don't think it will
> work, by all means, explain why, without resorting to "it's not that
> easy" or "it's just magic, don't ask."
It will not work, because in the example you showed it does not take
into account the complexity of this issue. It's not magic, but there
exisit many differenc combinations which you did not deal with. Just
two examples: (1) differenrt versions of the uCode patch are required
for MPC850 vs. other processors, and (2) you may need to relocate
your parameter RAM on systems which actually don't use any microcode
for this (like MPC866 and other processors of this family).
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
"The POP3 server service depends on the SMTP server service, which
failed to start because of the following error: The operation comple-
ted successfully." -- Windows NT Server v3.51
More information about the Linuxppc-dev