This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Anyone run on Intel Xeon processor?


<kevin_lemay@agilent.com> writes:

> I was trying to get a board driver running using eCos using a Intel
> Xeon target.
> 
> If I do not enable SMP support, then the interrupts are never
> cleared. Reviewing the code, it only supports the advanced interrupt
> controller found on the Xeon if SMP is enabled.
> 
> I rebuilt my application enabling SMP support and now it hangs
> before the initial breakpoint.
> 
> Following the boot sequence for i386... It calls:
>   cyg_hal_smp_init_apic      - returns OK
>   cyg_hal_smp_init_ioapic    - returns OK
>   cyg_hal_invoke_contructors - returns - OK
>   hal_init_istack            - unknown (It was assembler, I couldn't just add diag_print)
>   cyg_hal_smp_cpu_start_all  - never reached.
> 
> I tried rebuilding redboot with SMP support and it will no longer
> boot.
> 
> Has anyone tried this? It does run fine on a Pentium 3. It will also
> run fine on the Xeon if I put my driver in a polling loop. It has
> something to do with the Xeon.

The SMP support has only been run on a small number of actual
systems. I suppose there could easily be a problem dealing with
different variations of the Xeon/APIC/IOAPIC. It is also doubtful that
this code has been exercised much since I wrote it, it may have
suffered a little bitrot.

Unfortunately my dual proceesor machine is currently without its power
supply, so I cannot test anything on real hardware. I have tried out
both RedBoot and the smp kernel test on a dual processor configuration
of Bochs. RedBoot seems to run OK, but since it doesn't start the
additional CPUs, that is not a surprise. The SMP test gets as far as
printing its first message and then goes quiet. A bit of investigation
suggests that the second CPU is not running. It is not clear why and
might just as easily be a problem with Bochs as with eCos.

I don't really have time to investigate this further, unfortunately.
So, it is probably up to you to debug this. One of debug techniques I
used when developing this code was to write things to the PC screen --
its memory mapped, so easy to access and has minimal impact on
timing. There are some C macros in pcmb_io.h to help with this. In asm
code, just incrementing a byte on screen is a really useful way to see
whether a piece of code is being executed.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]