I am trying out the SMP code for a PC x386 build. When a
gets encountered the system crashes. I tried using a spinlock around
cyg_thread_delay() but it makes no difference. I have an older version
eCos about 3 years old. Any suggestions would be helpful.
I have found that pcmb_smp.c finds only 1 entry for a CPU in the ACPI
I assume this is the starting CPU. How do I get the MB to report all
I am using the DG35EC MB with a Core 2 dual CPU.
I did some work and submit some patch about that in the past (you can
look the list archives for david.fernandez). If you are using a
version 3 yeras old is quite likely that you haven't got the right
code.(assuming it made it into the ecos mainline)
The existing code did not have into account that the processor number
could not be sequential, nor the MP has to be the number one. There
were other issues with the ACPI table parsing.
After I submit the patch I kept working on it and I find out that
there was no proper PCI interrupt parsing either, that could cause big
problems if you try to use a kernel with hardware devices that could
At the moment I have a pretty reliable interrupt parsing, just I found
that not all the BIOSes generate a proper ACPI interrupt table if you
have multiple PCI bridges, which means that you will have to scan
thoroughly your PCI bus first and keep a static interrupt table if the
BIOS does not do it properly (remember that the PCI interrupt lines 4
or 8 sometimes, rotate over each bridge. but sometimes the bridge
itself has a funny interrupt line wiring and you have to probe for
In addition, some chipsets have two, and sometimes three IOAPICs, I
started to do some general IOAPIC architecture in ecos before I
May be in a few weeks I could prepare the mods to eCos HAL to take
into account the general BIOS in most systems, but you will have to do
a little research on your box to prepare your platform variant HAL.
Another missing thing for the PC world is a set of chipset platform
HAL files. I ported into three of them, but those are Intel NDA
protected, so I can't tell you anything about them. Anyway, linux guys
use to do a lot of reverse engineering on them, and most of the time
they have better information than the one provided by Intel.
As a starting point google for the intel multiprocessor specification.
I think it is public. Make sure you get the latest one, it used to be
buggy, I submitt a few erratas to intel, I suppose they have them
incorporated in the latest one.