Nick Garnett
Thu, 02 Mar 2006 06:29:04 -0800
Andrew Lunn <[EMAIL PROTECTED]> 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