Re: [ECOS] Debugging pc platform

[Nick Garnett <nickg at ecoscentric dot com>]

Andrew Lunn <andrew@lunn.ch> writes:

> On Thu, Mar 02, 2006 at 01:38:36PM +0000, David Fernandez wrote:
> > 
> > 	Andrew,
> > 
> > 	Looking further into pcmb_smp.c, seems that there is a real mess with
> > the ordinal cpu count numbers and the cpu ids.
> > 
> > 	According to Intel SMP specification, what is regarded in pcmb_smp.c as
> > cpu id, is really the apic id, that should be unique but not need to be
> > consecutive. As most commercial boards could have them consecutive, its
> > not likely to be aware of the problem, but looking into the code, for
> > example the cpu flags are read and stored according to the cpu id, but
> > then are checked according to the cpu ordinal number; and there are
> > several other things like that.
> > 
> > 	I would like to know what do you think is the best way to change that;
> > we could have another table indexed by ordinal cpu number giving the cpu
> > ids, or we could just index everything by ordinal cpu number.
> > 
> > 	Anyway, seems that all the code there should be revised... So tell me
> > if it is going to be some high priority thing in there, and I wait for
> > it, or if you think it's okay for me to do it and submit the changes...
> 
> I beleave Nick did the SMP support. He can give you the definitive
> answer. I don't know of anybody else working on SMP at the moment, so
> i think it would be best if you attempted to fix the problem and
> submit a patch.

The SMP stuff was done quite a while ago now. It is quite likely that
subsequent changes to other parts of the i386/PC HAL may have broken
it. It doesn't get used much so some bitrot may have set in.

Even when it was working, the testing was done using stand-alone eCos
applications with no RedBoot involved. From memory, I don't think I
ever successfully resolved all the issues regarding RedBoot. Things
like: should RedBoot start all the CPUs, or should that wait for the
application; what happens to the other CPUs when one CPU hits an
exception that goes into GDB; what happens when a CPU calls into
RedBoot via the virtual vectors.

I ran out of time before I could get it all working fully. It was a
speculative project within Red Hat and I had to move on to other
(revenue generating) things. It was all checked in pending time to
come back later. That never happened and it eventually made its way
into anoncvs in its current state.


As for the CPU ID problem. As far as I recall, there are no explicit
CPU IDs the only thing we have to distinguish the CPUs is the ID read
from the APIC. All the dual machines I tried it on used APIC IDs of 0
or 1, although it seemed to vary which CPU booted first. So, mapping
the APIC IDs to CPU IDs seemed to be a sensible thing to do at the
time.

If the APIC IDs are indeed not sequential then we need a way to map
the APIC IDs back to simple CPU numbers. The simplest approach is
probably to add a mapping table as suggested, indexed by APIC ID,
yielding a CPU number. The entries in this table will need to be
installed as each CPU boots and discovers its APIC ID.

There probably needs to be a table going the other way too since
inter-processor interrupts are addressed by APIC number.


David, I don't think anybody else is working on this code, so you have
free reign to make whatever changes you think necessary. Once you are
done, post your improvements to the patches list and I'll take a look
at them and, providing they look OK, check them in. If your changes
are extensive, you may need to sign an assigment form.


-- 
Nick Garnett                                 eCos Kernel Architect
http://www.ecoscentric.com            The eCos and RedBoot experts
Visit us at ESC Silicon Valley, April 4-6 2006.         Booth 1448
San Jose McEnery Convention Center  http://www.embedded.com/esc/sv


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss