Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips/mips




On Nov 10, 2009, at 5:02 AM, Simon Burge wrote:

Cliff Neighbors wrote:

Module Name:    src
Committed By:   cliff
Date:           Mon Nov  9 10:00:02 UTC 2009

Modified Files:

        src/sys/arch/mips/mips [matt-nb5-mips64]: db_interface.c

Log Message:

arch/mips/mips/db_interface.c
- add MIPS64_SHOW32() and MIPS64_SHOW64()  macros
 to show MIPS64 specific cp0 regs

Is the use of ".set mips64" safe in MIPS64_SHOW32 without the ".set
push"/".set pop" dance?

you're right, I found that too.


- add EIRR, EIMR, EBASE, CONFIG[0,1,7] to show regs
these switched by runtime vairable  is_rmi_xls
       is there a better variable to use ???
       cpu_arch == 64 ??

Querying cpu_id in db_interface.c is definitely wrong - maybe we should
add a new field to cputab in mips_machdep.c to say which CP0 regs are
available on each CPU.  You should KNF the "is_rmi_xls=0" as well.

I agree cputab[] should be useful for this problem.
Both cputab[] and mycpu could to be more visible
(they're currently static), and more broadly used
for runtime check of implementation specific attributes.

a registers available field in struct pridtab would work,
I assume you would only track regs that are not common?

there are other implementation-specific "quirks" besides CP0 registers,
like RMI instructions mfcr, mtcr.  these seem to exist on all the RMI
implementations, and could be switched by cpu_cid.

another need that I have is to identify (at runtime)
what family of chip we're on.  In specific RMI case, knowing
XLR vs. XLS vs. XLP will be needed.  I propose that such
classification could be flagged in a company-specific flags field,
e.g. call it cpu_cidflags.


- add mach mtcr, mfcr MD ddb commande
these are not runtime switched based on cpu arch,
     they are just 'there'
     if you use them on the wrong CPU, it's your problem!

Do these even link for a non-RMI config? You're unconditionally calling
rmi functions from "MI" MIPS code.

the RMI functions would only be called if the 'operator'
running ddb does so intentionally.  the call could be avoided
by an appropriate runtime switch, such as looking at 'mycpu'
attributes as mentioned above.
anyway, it did seem wrong, hence my comment.

you're right there is a linking problem for non-RMI kernel here.
It would be simple to #ifdef MIPS64_XLS if that is appropriate.
I understand there is a desire to avoid ifdefing, in order to
assist (eventual) movement towards implementation-agnostic kernel.

one non-ifdef alternative for db_mfcr_cmd() and db_mfcr_cmd()
is to simply asm() the instruction needed, avoiding the
need to link to RMI "MD" MIPS code in a non-RMI config.
it doesn't solve the general problem of linking to "MD" MIPS
(impl-dependent) features in ddb, but it does avoid it
for now.



In general, I'm a tad concerned about the chip-specific code that is
getting added here.

Thanks Simon, I appreciate your comments and input.  This is my
first foray into arch/mips, and I'm bumping into the walls a bit.
Additional discussion is helpful and welcome.

   -cliff-




Home | Main Index | Thread Index | Old Index