On Feb 3, 2005, at 10:02 AM, Per Hallsmark wrote:
> Yes, probably the 8260 code evolved from the 8xx code?
Yeah, sorta.
> Of course, there could be a reason why it is like it is
> and that's why I sent out the question...
It seems to be the personal preference of the last person that
make changes and checked in a patch.
Years ago, we used to always reset the cpm to eliminate
any microcode patches that may have been installed by the
boot rom. We never knew what may be there, so drivers
would fail.
Later, I added a bunch of kgdb/xmon support for early kernel
debugging. Due to this, we didn't want to reset the cpm because
we would rely on the boot rom initialization of the serial port
for communication. The early serial functions just track down
the BDs and use them, regardless of how they were set up.
Lots of kernel code is run prior to the Linux configuration of the
serial ports, and we wanted to debug before that.
Now, I see this microcode patch again. This is an old piece
of code, or perhaps a recent update to it.
So, the configuration issue is whether you want to run kdgb
or xmon for early kernel debugging. If so, you don't want to
reset the cpm. If there are microcode patches loaded by by
a boot rom, we probably want to reset the cpm. If you are
loading your own patches, you must reset the cpm. If you
want to run kgdb or xmon and load your own microcode
patches ... well, you have a challenge :-)
There may be some configuration logic that meets most
requirements, but it isn't going to be proper for everyone.
You may have to locally edit the files for your purpose,
which is true of several cpm related drivers. You have the
source, use it! ;-)
Thanks.
-- Dan
