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 j...@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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
