SIS MP success

[Sebastian Huber]

On 12/12/2018 17:20, Jiri Gaisler wrote:
> On 12/12/18 10:26 AM, Sebastian Huber wrote:
>> ----- Am 12. Dez 2018 um 10:01 schrieb Jiri Gaisler jiri at gaisler.se:
>>
>>> After implementing the interrupt broadcast function, and stop telling
>>> the software that there are 5 cores in the system when there really only
>>> are 4, all tests run fine ..:-)
>> This sounds great.
>>
>>> I can run all SMP tests with a time slot
>>> of 50 clocks except smpclock01.exe, which fails with:
>>>
>>> *** BEGIN OF TEST SMPCLOCK 1 ***
>>> *** TEST VERSION: 5.0.0.b7a1f9efadd928cda0f56123a1b6245b30b076fc-modified
>>> *** TEST STATE: EXPECTED-PASS
>>> *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP
>>> *** TEST TOOLS: 7.4.0 20181206 (RTEMS 5, RSB
>>> b4e80fb8e29c47fa970b5cdb815c26f1af4fd173, Newlib
>>> 2ab57ad59bc35dafffa69cd4da5e228971de069f)
>>> ../../../../../../rtems/c/src/../../testsuites/smptests/smpclock01/init.c:
>>> 117 cpu_self->Watchdog.ticks == ticks + 1
>>> IU in error mode (128)
>>>   12095340  40012200  91d02000  ta  0
>>> sis> q
>> There could be an issue with the interrupt delivery after an interrupt enable. In the test source we have:
>>
>>    // At this point the clock interrupt is pending
>>    rtems_interrupt_local_enable(level);
>>
>>    // Here the clock interrupt should be already processed, incrementing the tick
>>    rtems_test_assert(cpu_self->Watchdog.ticks == ticks + 1);
> I checked for interrupts only once per time slice, which broke the
> program. I changed to check for interrupts on every instruction and
> smpclock01 now works with any slice time.

This is really nice. Your simulator is the first on which all SMP tests 
pass. Qemu doesn't work well.

>
>
>>> Lowering the time slot to 15 clocks fixes this error and the test passes.
>>>
>>> I will clean up my sources, and work a bit on improving breakpoint
>>> handling and tracing. The MP function broke erc32 and leon2 support, so
>>> I will fix that too. After that I can post a patch if anyone is
>>> interested. Threaded simulation could come after that ...
>> Nice, do you plan to submit this to the upstream GDB? Sounds like a lot of work to do this.
> I have been thinking to abandon the old sis which is under sim/erc32 in
> gdb, and create a new simulator under sim/sis or sim/sparc. The old name
> (erc32) is a bit misleading anyway since we now emulate leon2 and leon3
> also. I will offer the gdb maintainers a patch for this move and an
> upgrade to mp. If they don't like it then I will maintain sis-mp outside
> the gdb tree and provide a patch for RSB. It is easier to maintain the
> whole directory, than incremental patches to existing code.
>
> Note that the whole work on MP support is actually driven by RISC-V (!).
> I have a RISC-V version of sis that I use with an RTEMS bsp for a
> GRLIB/AMBA SOC with a RISC-V core. I want to move to RISC-V SMP so I
> need a simulator to test the software. Being more familiar with SPARC, I
> decided to first get MP simulation to work with LEON3, and then just
> port the RISC-V emulation. I also thought that a LEON3 sis-mp could be
> useful for the RTEMS community, which was an other reason to start with
> SPARC and then move to RISC-V.

I use the SIS every day for RTEMS development and test suite runs. The 
SMP support would be a very valuable for RTEMS development. If we can 
get also code coverage from it, then it would be perfect.

I will try to move the grlib from bsps/sparc/shared/* to 
bsps/shared/grlib before the RTEMS 5 release so that it can be used from 
SPARC and RISC-V BSPs.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.