SMP board : Bug in SID or configuration file ?

SMP board : Bug in SID or configuration file ?

[moris dong]

Hi,
I tried to set a simple configuration file for a two-processor SMP board 
(see below).
I use two loaders and two gloss (angel) instances, one per CPU.
I use a remapper (MMU?) so the addresses generated by the second processor 
will not conflict with the addresses generated by the first (I'm using a 
single memory bank, divided by the two CPUs).

The loading of the two "hello.arm" programs into my (single) 16MB memory is 
successful.
When I enable only one of the CPUs to run (connect-pin target-sched 0-event 
-> cpu1 step!  or connect-pin target-sched 1-event -> cpu2 step!) , the 
enabled CPU successfully executes the program.

But, when I enable the two CPUs (connect-pin target-sched 0-event -> cpu1 & 
connect-pin target-sched 1-event -> cpu2) I get a segmentation fault.

I would appreciate if you can answer the following questions:
1. What is wrong with my configuration file that is causing this core-dump ?

2. I want to see how each CPU affects the performance of the other (e.g., 
contention on bus and memory that causes delays and stalls). How can I 
monitor these parameters?

3. Although its an SMP board, in my configuration I'm not really running an 
SMP OS, since the two gloss (angel) instances are independent of each other, 
each using a different part of the memory.  How can I get two processes to 
run in a thread-like manner, sharing the memory, doing locks etc. What is 
the programing model (pthreads ?), how do I write such a program for SID and 
how do I start it ?

Thanks for you time :) !!!
Here is my conf file.
--------------------------------------------------------------
load libaudio.la audio_component_library
load libcache.la cache_component_library
load libcgencpu.la cgen_component_library
load libconsoles.la console_component_library
load libgdb.la gdb_component_library
load libgloss.la gloss_component_library
load libglue.la glue_component_library
load libhd44780u.la hd44780u_component_library
load libide.la ide_component_library
load libinterrupt.la interrupt_component_library
load libloader.la loader_component_library
load libmapper.la mapper_component_library
load libmemory.la mem_component_library
load libmmu.la mmu_component_library
load libparport.la parport_component_library
load libprof.la prof_component_library
load librtc.la rtc_component_library
load libsched.la sched_component_library
load libtimers.la timer_component_library
load libuart.la uart_component_library
load libx86.la x86_component_library
#MMU
load libmmu.la mmu_component_library

# first section
new hw-cpu-arm7t cpu1
new hw-cpu-arm7t cpu2
new hw-mapper-basic cpu-mapper
new hw-glue-sequence-8 init-sequence
new hw-glue-sequence-1 hw-reset-net
new hw-glue-sequence-8 deinit-sequence
new hw-glue-sequence-8 yield-net
new hw-glue-sequence-2 cache-flush-net
new sid-sched-host-accurate host-sched
new sid-sched-sim target-sched
# core tracing
new hw-glue-probe-bus bus-probe
# gloss
new sw-gloss-arm/angel gloss1
new sw-gloss-arm/angel gloss2

# gloss <-> stdio
new sid-io-stdio stdio
# cpu loader
new sw-load-elf cpu-loader1
new sw-load-elf cpu-loader2

# memory region 1 (0x00000000,0x01000000)
new hw-memory-ram/rom-basic mem1

# MMU
new hw-remap/pause-arm/ref remapper

# second section
# settings
set remapper num-relocations 1
set remapper 0-start 0
set remapper 0-end 8388607
set remapper 0-reloc-to 0x800000


set host-sched num-clients 10 # large enough?
set target-sched num-clients 10 # large enough?
# pin connections
connect-pin main perform-activity -> host-sched advance
connect-pin main perform-activity -> target-sched advance
connect-pin main starting -> init-sequence input
connect-pin main stopping -> deinit-sequence input
connect-pin init-sequence output-0 -> hw-reset-net input
connect-pin hw-reset-net output-0 -> cpu1 reset!
connect-pin hw-reset-net output-0 -> cpu2 reset!

connect-pin target-sched 0-event -> cpu1 step!
>>>>Uncomment the next line and get a core-dump
#connect-pin target-sched 1-event -> cpu2 step!

connect-pin target-sched 0-control <- cpu1 step-cycles
connect-pin target-sched time-query <- cpu1 time-query
connect-pin target-sched time-high -> cpu1 time-high
connect-pin target-sched time-low -> cpu1 time-low

connect-pin target-sched 1-control <- cpu2 step-cycles
connect-pin target-sched time-query <- cpu2 time-query
connect-pin target-sched time-high -> cpu2 time-high
connect-pin target-sched time-low -> cpu2 time-low


connect-pin yield-net output-0 -> cpu1 yield
connect-pin yield-net output-0 -> cpu2 yield
connect-pin yield-net output-0 -> host-sched yield

connect-bus cpu1 insn-memory bus-probe upstream
connect-bus cpu1 data-memory bus-probe upstream

connect-bus cpu2 insn-memory remapper access-port
connect-bus cpu2 data-memory remapper access-port
connect-bus remapper all bus-probe upstream

# core tracing
connect-bus bus-probe downstream cpu-mapper access-port

# gloss
relate gloss1 cpu cpu1
relate gloss2 cpu cpu2

connect-pin init-sequence output-3 -> gloss1 reset
connect-pin init-sequence output-4 -> gloss2 reset

connect-pin cpu1 trap <-> gloss1 trap
connect-pin cpu1 trap-code -> gloss1 trap-code

connect-pin cpu2 trap <-> gloss2 trap
connect-pin cpu2 trap-code -> gloss2 trap-code

connect-bus gloss1 target-memory bus-probe upstream
connect-bus gloss2 target-memory remapper access-port

# gloss <-> stdio
set host-sched 0-regular? 1
set host-sched 0-time 150 # apprx. human perception limit


connect-pin host-sched 0-event -> stdio poll
connect-pin gloss1 debug-tx -> stdio stdout
connect-pin gloss1 debug-rx <- stdio stdin

connect-pin gloss2 debug-tx -> stdio stdout
connect-pin gloss2 debug-rx <- stdio stdin

# gloss w/o gdb
connect-pin gloss1 process-signal -> main stop!
connect-pin gloss1 process-signal -> yield-net input

connect-pin gloss2 process-signal -> main stop!
connect-pin gloss2 process-signal -> yield-net input

set cpu1 engine-type pbb
set cpu2 engine-type pbb

# cpu loader
set cpu-loader1 file "hello.arm"
set cpu-loader2 file "hello.arm"

connect-bus cpu-loader1 load-accessor-data bus-probe upstream
connect-bus cpu-loader1 load-accessor-insn bus-probe upstream
# MMU
connect-bus cpu-loader2 load-accessor-data remapper access-port
connect-bus cpu-loader2 load-accessor-insn remapper access-port

connect-pin init-sequence output-5 -> cpu-loader1 load!
connect-pin init-sequence output-6 -> cpu-loader2 load!

connect-pin cpu-loader1 start-pc-set -> cpu1 start-pc-set!
connect-pin cpu-loader1 endian-set -> cpu1 endian-set!
connect-pin cpu-loader1 error -> main stop!

connect-pin cpu-loader2 start-pc-set -> cpu2 start-pc-set!
connect-pin cpu-loader2 endian-set -> cpu2 endian-set!
connect-pin cpu-loader2 error -> main stop!

# memory region 1 (0x00000000,0x01000000) configuration
set mem1 size 0x1000000 #16MB


#Trace all
set bus-probe trace? 1

connect-bus cpu-mapper mem1:[0,16777215] mem1 read-write-port

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

Re: SMP board : Bug in SID or configuration file ?

[Dave Brolley]

Hi! I can comment on your question 2) below....

moris dong wrote:

>
> 2. I want to see how each CPU affects the performance of the other 
> (e.g., contention on bus and memory that causes delays and stalls). 
> How can I monitor these parameters?
>
We have a port here which had the same requirements and, so we created 
some infrastructure in SID for this kind of thing. The port itself, 
unfortunately can not be contributed at this time, however, the 
infrastructure which allows for modelling of bus contention and stalls 
probably can. As usual, my problem is one of time. I'll see what I can 
do over the next week or so to get it approved and committed.

Dave

Re: SMP board : Bug in SID or configuration file ?

[Frank Ch. Eigler]

"moris dong" <moris_dong@hotmail.com> writes:

> I tried to set a simple configuration file for a two-processor SMP
> board (see below).  I use two loaders and two gloss (angel)
> instances, one per CPU.

Good.

> I use a remapper (MMU?) so the addresses generated by the second
> processor will not conflict with the addresses generated by the
> first [...]

You can also configure a hw-mapper-basic component to remap addresses
(see the "mapped_base" option).


> [...]  But, when I enable the two CPUs (connect-pin target-sched
> 0-event -> cpu1 & connect-pin target-sched 1-event -> cpu2) I get a
> segmentation fault.

That's a bug.  SID should not SEGV even on bad configuration.  Could
run SID under a debugger and report the backtrace at the point of
crash?

> 1. What is wrong with my configuration file that is causing this
> core-dump ?  [...]

Just glancing over it, nothing obvious is wrong.

> 3. [...]
> How can I get two processes to run in a thread-like manner, sharing
> the memory, doing locks etc. What is the programing model (pthreads
> ?), how do I write such a program for SID and how do I start it ?

Such functionality can only be layered above sid, within the OS you
would run on the simulator.  GLOSS is the only piece that emulates
some aspect of the software layer, and extending it to implementing
multithreading system calls would be a big job.

Think of SID as primarily modelling hardware, its components like the
integrated circuits; its configuration like the pattern of connections
etched into a printed circuit board.


- FChE

Re: SMP board : Bug in SID or configuration file ?

[moris dong]

Here is the GDB backtrace:
(gdb) file sid
Reading symbols from sid...done.
(gdb) set args hello.arm.send
(gdb) run
Starting program: /tmp/local/bin/sid hello.arm.send

Program received signal SIGSEGV, Segmentation fault.
0x402786da in arm7f::arm7f_cpu::arm_pbb_run() (this=0x80eb410) at 
arm-semsw.cxx:677
677       fragpc = vpc->execute.cgoto.frags;
(gdb) bt
#0  0x402786da in arm7f::arm7f_cpu::arm_pbb_run() (this=0x80eb410) at 
arm-semsw.cxx:677
#1  0x401f0675 in arm7f::arm7f_cpu::step_arm_pbb() (this=0x80eb410) at 
arm7f.cxx:571
#2  0x401ef711 in arm7f::arm7f_cpu::step_insns() (this=0x80eb410) at 
arm7f.cxx:209
#3  0x401da3a3 in sidutil::basic_cpu::step_pin_handler(unsigned) 
(this=0x80eb4d0) at sidcpuutil.h:278
#4  0x401de50c in 
sidutil::callback_pin<sidutil::basic_cpu>::driven(unsigned) (this=0x80eb410, 
v=0)
    at sidpinutil.h:507
#5  0x406887f5 in 
scheduler_component::generic_scheduler<scheduler_component::target_time_keeper>::advance_any() 
(
    this=0x81074d4) at sidpinutil.h:200
#6  0x40681ae2 in 
scheduler_component::scheduler_component<scheduler_component::generic_scheduler<scheduler_component::target_time_keeper> 
 >::advance(unsigned) (this=0x8107478) at compSched.cxx:773
#7  0x406972e4 in 
sidutil::callback_pin<scheduler_component::scheduler_component<scheduler_component::generic_scheduler<scheduler_component::target_time_keeper> 
 > >::driven(unsigned) (this=0x80eb410, v=1) at sidpinutil.h:507
#8  0x080a6737 in sidutil::output_pin::list_output::driven(unsigned) 
(this=0x80c4400, v=1) at stl_iterator.h:593
#9  0x0809a84a in cfgroot_component::run(unsigned) (this=0x80c4318) at 
sidpinutil.h:200
#10 0x080a9efb in sidutil::callback_pin<cfgroot_component>::driven(unsigned) 
(this=0x80eb410, v=0)
    at sidpinutil.h:507
#11 0x08060d91 in main (argc=2, argv=0xbfffed64) at mainDynamic.cxx:937
#12 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6

>From: fche@redhat.com (Frank Ch. Eigler)
>To: "moris dong" <moris_dong@hotmail.com>
>CC: sid@sources.redhat.com
>Subject: Re: SMP board : Bug in SID or configuration file ?
>Date: 30 Mar 2005 14:03:56 -0500
>
>
>"moris dong" <moris_dong@hotmail.com> writes:
>
> > I tried to set a simple configuration file for a two-processor SMP
> > board (see below).  I use two loaders and two gloss (angel)
> > instances, one per CPU.
>
>Good.
>
> > I use a remapper (MMU?) so the addresses generated by the second
> > processor will not conflict with the addresses generated by the
> > first [...]
>
>You can also configure a hw-mapper-basic component to remap addresses
>(see the "mapped_base" option).
>
>
> > [...]  But, when I enable the two CPUs (connect-pin target-sched
> > 0-event -> cpu1 & connect-pin target-sched 1-event -> cpu2) I get a
> > segmentation fault.
>
>That's a bug.  SID should not SEGV even on bad configuration.  Could
>run SID under a debugger and report the backtrace at the point of
>crash?
>
> > 1. What is wrong with my configuration file that is causing this
> > core-dump ?  [...]
>
>Just glancing over it, nothing obvious is wrong.
>
> > 3. [...]
> > How can I get two processes to run in a thread-like manner, sharing
> > the memory, doing locks etc. What is the programing model (pthreads
> > ?), how do I write such a program for SID and how do I start it ?
>
>Such functionality can only be layered above sid, within the OS you
>would run on the simulator.  GLOSS is the only piece that emulates
>some aspect of the software layer, and extending it to implementing
>multithreading system calls would be a big job.
>
>Think of SID as primarily modelling hardware, its components like the
>integrated circuits; its configuration like the pattern of connections
>etched into a printed circuit board.
>
>
>- FChE

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/