Re: [tools] tester: Remove hard coded time limits for SIS

[Jiri Gaisler]

On 7/5/22 12:45, Sebastian Huber wrote:



On 05/07/2022 12:31, Chris Johns wrote:



On 5 Jul 2022, at 6:23 pm, Sebastian Huber  
wrote:

On 05/07/2022 10:21, Chris Johns wrote:

On 5/7/2022 4:29 pm, Sebastian Huber wrote:
On 05/07/2022 08:23, Chris Johns wrote:

On 5/7/2022 4:02 pm, Sebastian Huber wrote:

On 05/07/2022 07:14, Chris Johns wrote:

On 5/7/2022 2:58 pm, Sebastian Huber wrote:

On 05/07/2022 03:08, Chris Johns wrote:

On 5/7/2022 9:44 am, Joel Sherrill wrote:

The limit removed in sis and tsim is the simulated cpu time used. If not
using
that, the behavior of the tester is to let the simulator run for so much
real
processor time.

Replacing these with a command line argument is probably good but just
removing
these mean these simulators will just run much longer before being killed.

How best to capture the distinction between target run time and host run
time?

Thank you for the explanation. I was not sure how the option effected things
and
yes it does matter we have this set correctly.

Options can be set in the $HOME/.rtemstesterrc is via the --user-config
option.
Maybe this can be used to control the time out for specific user tests?

I would not make this more complicated than necessary. We have a --timeout
command line option and the default timeout value can be set by *.ini
files. The
simulator speed is just a detail similar to running a target at 100MHz or
1GHz.

It is actually simpler to have this option and to measure time against the cpu
time. The work loads on SMP hosts with qemu shows simulation timeouts are
difficult to get right.

I don't know what is wrong with the patch. Overruling command line options is
just bad.

It does not work that way. When simulating the timeout in the tester is a catch
all. It may triggered if the simulator locks up. With real hardware it is the
timeout but that is a different use case. A simulator timeout is preferred when
available.

Ok, good. Who will fix this?

I am sorry I am not following. The tests have valid times for the default
optimisation. What is broken?

What is broken is that the --timeout command line option doesn't work with SIS 
because it uses hard coded values.

The timeout option is correct and your understanding of it’s purpose is wrong. 
Joining them as you would like would break it.


It would be nice if someone could offer me a way to run tests which exceed the 
hard coded SIS timeout values?


sis accepts several -tlim options. The last one will be the active one. So 
rtems-test could add an extra -tlim option at the end of the sis parameters 
which would override the default one.


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [tools] tester: Remove hard coded time limits for SIS

[Jiri Gaisler]

On 7/5/22 12:31, Chris Johns wrote:



On 5 Jul 2022, at 6:23 pm, Sebastian Huber  
wrote:

On 05/07/2022 10:21, Chris Johns wrote:

On 5/7/2022 4:29 pm, Sebastian Huber wrote:
On 05/07/2022 08:23, Chris Johns wrote:

On 5/7/2022 4:02 pm, Sebastian Huber wrote:

On 05/07/2022 07:14, Chris Johns wrote:

On 5/7/2022 2:58 pm, Sebastian Huber wrote:

On 05/07/2022 03:08, Chris Johns wrote:

On 5/7/2022 9:44 am, Joel Sherrill wrote:

The limit removed in sis and tsim is the simulated cpu time used. If not
using
that, the behavior of the tester is to let the simulator run for so much
real
processor time.

Replacing these with a command line argument is probably good but just
removing
these mean these simulators will just run much longer before being killed.

How best to capture the distinction between target run time and host run
time?

Thank you for the explanation. I was not sure how the option effected things
and
yes it does matter we have this set correctly.

Options can be set in the $HOME/.rtemstesterrc is via the --user-config
option.
Maybe this can be used to control the time out for specific user tests?

I would not make this more complicated than necessary. We have a --timeout
command line option and the default timeout value can be set by *.ini
files. The
simulator speed is just a detail similar to running a target at 100MHz or
1GHz.

It is actually simpler to have this option and to measure time against the cpu
time. The work loads on SMP hosts with qemu shows simulation timeouts are
difficult to get right.

I don't know what is wrong with the patch. Overruling command line options is
just bad.

It does not work that way. When simulating the timeout in the tester is a catch
all. It may triggered if the simulator locks up. With real hardware it is the
timeout but that is a different use case. A simulator timeout is preferred when
available.

Ok, good. Who will fix this?

I am sorry I am not following. The tests have valid times for the default
optimisation. What is broken?

What is broken is that the --timeout command line option doesn't work with SIS 
because it uses hard coded values.

The timeout option is correct and your understanding of it’s purpose is wrong. 
Joining them as you would like would break it.


I think that Sebastian has a point, a hard-coded value in the sis script 
prevents changing the time-out value from rtems-test.

The timeout value in sis is in simulated CPU time, not host time. I am not sure 
how it works on the other simulators. If you would prefer host time time-outs, 
let me know and I will modify sis for this.

Jiri.


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Running SPARC/LEON3 in TSIM-LEON3 simulator

[Jiri Gaisler]

On 6/11/21 12:37 PM, Đức Anh wrote:

Hi Sebastian,

Thank you. I didn't notice that.

I recompile with SMP enabled, and the application doesn't run successfully in 
the TSIM-LEON3 simulator. Below is the error message:

Initializing and starting from 0x4000

  CPU 0 in error mode (tt=0x80, trap instruction)
  (In trap table for tt=0x02, illegal instruction)
      70150  4020  91d02000   ta        0        start + 0x20


The thing is, the same code will work if I compile with SMP disabled. When the 
SMP is enabled, the simulator will crash like above, even with the simple hello 
world application.

Have anyone here run into a similar issue? Or do you know any other leon3 (or 
sparc) simulator that I can try?



You can try with sis:

sparc-rtem6-sis -leon3 -m 4 hello.exe

Should work without problems. For SMP, you need the '-m 4' switch to enable 4 
cores ...

Jiri.




Best regards,
Duc Anh

On Wed, 9 Jun 2021 at 18:46, Sebastian Huber mailto:sebastian.hu...@embedded-brains.de>> wrote:

On 09/06/2021 18:39, Đức Anh wrote:
> - Is there a way to enable SMP for SPARC/LEON3 in RTEMS 6?

Just set "RTEMS_SMP = True" in your config.ini:


https://docs.rtems.org/branches/master/user/bld/index.html#migration-from-autoconf-automake
 


-- 
embedded brains GmbH

Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de 

phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/ 



___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 5/5] bsps/sparc: Simplify memory initialization

[Jiri Gaisler]

On 6/8/21 4:14 PM, Sebastian Huber wrote:

On 08/06/2021 16:03, Gedare Bloom wrote:

I guess at
some time, loading initialized data from the ROM was needed, but now
it is not?


I asked about this some time ago. I think these days the RTEMS application is 
always loaded by a boot loader (GRMON). If the data copy is really necessary, 
then an application can still add this step as a very early system 
initialization step, since boot_card() and the system initialization loop 
doesn't use global data (only read-only and BSS data). However, the SMP startup 
would still not work in this case. A boot loader is a better place to load the 
sections.


The code is an artifact from the old erc32 days, when we would boot and execute 
from ROM and the .data had to be copied over to RAM. With leon1/2/3, this is 
not used anymore as a boot loader is made from the RAM image using a custom 
tool (mkprom).

Jiri.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Fwd: How to debug on leon3 with sis and gdb

[Jiri Gaisler]

Forgot copy the list.

On 5/21/21 7:02 AM, Richi Dubey wrote:

Hi,

A test fails at the assert(sc==RTEMS_SUCCESSFUL) after a call to 
rtems_task_set_affinity.

So, following the docs <https://devel.rtems.org/wiki/Debugging/sis>, I figured 
out where the break point should be set:

---

$ ~/quick-start/rtems/6/bin/sparc-rtems6-sis -leon3 -m 4 
~/sis-quick-start/src/rtems/build/sparc/leon3/testsuites/smptests/smpschedstrongapa01.exe

 SIS - SPARC/RISCV instruction simulator 2.26,  copyright Jiri Gaisler 2020
 Bug-reports to j...@gaisler.se <mailto:j...@gaisler.se>

 LEON3 emulation enabled, 4 cpus online, delta 50 clocks

 Loaded 
/home/richi/sis-quick-start/src/rtems/build/sparc/leon3/testsuites/smptests/smpschedstrongapa01.exe,
 entry 0x4000
cpu0> hi 10
trace history length = 10
cpu0> run
Waking CPU 1
Waking CPU 2
Waking CPU 3
assertion "sc == RTEMS_SUCCESSFUL" failed: file 
"../../../testsuites/smptests/smpschedstrongapa01/init.c", line 264, function: Init
cpu 0 in error mode (tt = 0x80)
   423950  4000f9e0:  91d02000   ta  0x0
cpu0> hi
   423922  40019d40:  90100018   mov  %i0, %o0
   423923  4000f9e4:  82102001   mov  1, %g1
   423924  4000f9e8:  8418   mov  %o0, %g2
   423925  4000f9ec:  8619   mov  %o1, %g3
   423926  4000f9f0:  91d02000   ta  0x0
   423928  4800:  a148   mov  %psr, %l0
   423929  4804:  2910003e   sethi  %hi(0x4000f800), %l4
   423930  4808:  81c521e0   jmp  %l4 + 0x1e0
   423932  480c:  a6102080   mov  128, %l3
   423933  4000f9e0:  91d02000   ta  0x0
cpu0> reg

 INS       LOCALS      OUTS     GLOBALS
   0:  0007   F3001FC6   0007   
   1:  4002F008   4000F9F0      0001
   2:  40029CF8   4000F9F4   4002F008   0007
   3:  000A   0080   40020400   4002F008
   4:  0073   4000F800   000E   
   5:  40029C00      0004   
   6:  4002EEE0   4002A250   4002EE78   4002CD00
   7:  40019D3C   4002CD00   4000EC80   

 psr: F3001FC6   wim: 0008   tbr: 4800   y: 

  pc: 4000F9E0 = 91D02000     ta  0x0
 npc: 4000F9E4 = 82102001     mov  1, %g1
 IU in error mode

cpu0> quit
---
So the breakpoint has to be set at the second last instruction at address 
0x480c


This is the wrong assumption. The program does not halt where the assertion 
fails, it prints the error message and exits the normal way. To stop execution 
right where the assertion is made, you should add a breakpoint at the line 
number:

bre init.c:264

Also, make sure you compile RTEMS without optimization, or single-stepping and 
debugging will be hard. I usually do this by removing all optimization flags in 
the OPTIMIZATION_FLAGS variable in the bsp .ini file before configuring with 
waf.




But when I try to debug this with gdb keeping the sis as remote target, it does 
not work:

-
$ ~/quick-start/rtems/6/bin/sparc-rtems6-gdb 
~/sis-quick-start/src/rtems/build/sparc/leon3/testsuites/smptests/smpschedstrongapa01.exe
GNU gdb (GDB) 10.1.90.20210409-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html 
<http://gnu.org/licenses/gpl.html>>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=sparc-rtems6".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/ 
<https://www.gnu.org/software/gdb/bugs/>>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/ 
<http://www.gnu.org/software/gdb/documentation/>>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from 
/home/richi/sis-quick-start/src/rtems/build/sparc/leon3/testsuites/smptests/smpschedstrongapa01.exe...
(gdb) tar sim -leon3
Undefined target command: "sim -leon3".  Try "help target".
(gdb) target extended-remote localhost:1234
Remote debugging using localhost:1234
0x in ?? ()
(gdb) load
Loading section .text, size 0x218f0 lma 0x4000
Loading section .rtemsroset, size 0x90 lma 0x400218f0
Loading section .data, size 0x530 lma 0x40029980
Start address 0x4000, load size 138928
Transfer rate: 3083 KB/sec, 271 bytes/write.
(gdb) bre 0x480c


To break at a hex address in gdb, you need a pointer:

bre *0x480c



Function "0x480c" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (0x480c) pending.
(gdb) run
The program being debugg

[PATCH v3] smpfatal08: halt secondary processors if necessary

[Jiri Gaisler]

Just one nit, I think we still want to keep
-  (void) cpu_self;
because the variable is unused. This suppresses unused variable warnings.

I never understood why it was there, but now I know ... :-)

smpfatal08 fails on systems where all cpus are started by the 
boot-loader and thereby clobber the test output. This patch stops the 
secondary cpus with a call to _CPU_Thread_Idle_body(). Tested on RISC-V 
and SPARC.


>From 666fcbdb1fe8ef7d7988279d4da673de3cdd5d95 Mon Sep 17 00:00:00 2001
From: Jiri Gaisler 
Date: Sun, 11 Apr 2021 21:15:13 +0200
Subject: [PATCH] smpfatal08: block secondary processors

	* On some SMP platforms, all cpus are started by the
	  boot-loader. We need to block the secondary cpus or they
	  will clobber the test output.
---
 testsuites/smptests/smpfatal08/init.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/testsuites/smptests/smpfatal08/init.c b/testsuites/smptests/smpfatal08/init.c
index 47ea91b29d..bcfb3b72be 100644
--- a/testsuites/smptests/smpfatal08/init.c
+++ b/testsuites/smptests/smpfatal08/init.c
@@ -38,6 +38,8 @@ void bsp_start_on_secondary_processor(struct Per_CPU_Control *cpu_self)
 {
   /* Provided to avoid multiple definitions of the CPU SMP support functions */
   (void) cpu_self;
+  /* Block secondary cpus if they are running to avoid clobbering output */
+  (void) _CPU_Thread_Idle_body( 0 );
 }
 
 #if QORIQ_THREAD_COUNT > 1
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2] smpfatal08: halt secondary processors if necessary

[Jiri Gaisler]

smpfatal08 fails on systems where all cpus are started by the boot-loader and 
thereby clobber the test output. This patch stops the secondary cpus with a 
call to _CPU_Thread_Idle_body(). Tested on RISC-V and SPARC.

From 4429fd6b391e3feebd72a0e7d403cc4745e35a3a Mon Sep 17 00:00:00 2001
From: Jiri Gaisler 
Date: Sun, 11 Apr 2021 21:15:13 +0200
Subject: [PATCH] smpfatal08: block secondary processors

	* On some SMP platforms, all cpus are started by the
	  boot-loader. We need to block the secondary cpus or they
	  will clobber the test output.
---
 testsuites/smptests/smpfatal08/init.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/testsuites/smptests/smpfatal08/init.c b/testsuites/smptests/smpfatal08/init.c
index 47ea91b29d..bfdfda9437 100644
--- a/testsuites/smptests/smpfatal08/init.c
+++ b/testsuites/smptests/smpfatal08/init.c
@@ -37,7 +37,8 @@ const char rtems_test_name[] = "SMPFATAL 8";
 void bsp_start_on_secondary_processor(struct Per_CPU_Control *cpu_self)
 {
   /* Provided to avoid multiple definitions of the CPU SMP support functions */
-  (void) cpu_self;
+  /* Block secondary cpus if they are running to avoid clobbering output */
+  (void) _CPU_Thread_Idle_body( 0 );
 }
 
 #if QORIQ_THREAD_COUNT > 1
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] smpfatal08: halt secondary RISC-V processors

[Jiri Gaisler]

On 4/13/21 7:44 AM, Sebastian Huber wrote:

On 12/04/2021 21:40, Jiri Gaisler wrote:



I just realized that I can change the patch from an assembly WFI to a simple busy loop instead. This would work on any architecture without assembly. Should I provide a new patch with this cleaner solution? 


You can use

(void) _CPU_Thread_Idle_body( 0 );

for an idle loop which my use architecture/BSP-specific optimizations, e.g. wfi.


Elegant solution! I will post a patch with this fix.

Jiri.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] smpfatal08: halt secondary RISC-V processors

[Jiri Gaisler]

On 4/12/21 8:44 PM, Gedare Bloom wrote:

Hi Jiri,

How much do you think this is a RISC-V specific problem, or one that
may affect other SMP processors? Should we add an RTEMS API for this
capability instead of shimming some Asm into a test case?


It's bound to happen on any architecture/loader that starts all processor cores 
before jumping to RTEMS. Leon3 and Griscv only start on core so the test 
passes, while 'regular' RISCV will fail as all cores are started by the loader. 
I do not now how the other SMP architectures (x86, PowerPC, ARM) work during 
start-up. Note that this specific test bypasses most of the normal SMP 
start-up, that's why the problem occurs. I really don't think we need a special 
API for this.

I just realized that I can change the patch from an assembly WFI to a simple 
busy loop instead. This would work on any architecture without assembly. Should 
I provide a new patch with this cleaner solution?

Jiri.



On Sun, Apr 11, 2021 at 1:30 PM Jiri Gaisler  wrote:

smpfatal08 fails on SMP RISC-V systems because all cpus are started by the 
boot-loader and clobber the test output. This patch stops the secondary cpus 
with a WFI (wait-for-interrupt). Harmless if only one cpu is started by the 
loader, as in the griscv bsp.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] smpfatal08: halt secondary RISC-V processors

[Jiri Gaisler]

smpfatal08 fails on SMP RISC-V systems because all cpus are started by the 
boot-loader and clobber the test output. This patch stops the secondary cpus 
with a WFI (wait-for-interrupt). Harmless if only one cpu is started by the 
loader, as in the griscv bsp.

From 722f8363fe131801ebb9f733f836d0bf6cd82c7a Mon Sep 17 00:00:00 2001
From: Jiri Gaisler 
Date: Sun, 11 Apr 2021 21:15:13 +0200
Subject: [PATCH] smpfatal08: halt secondary RISC-V processors

	* On most RISC-V platforms, all cpus are started by the
	  boot-loader. We need to stop the secondary cpus or they
	  will clobber the test output.
---
 testsuites/smptests/smpfatal08/init.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/testsuites/smptests/smpfatal08/init.c b/testsuites/smptests/smpfatal08/init.c
index 47ea91b29d..d0c9fe276a 100644
--- a/testsuites/smptests/smpfatal08/init.c
+++ b/testsuites/smptests/smpfatal08/init.c
@@ -37,6 +37,9 @@ const char rtems_test_name[] = "SMPFATAL 8";
 void bsp_start_on_secondary_processor(struct Per_CPU_Control *cpu_self)
 {
   /* Provided to avoid multiple definitions of the CPU SMP support functions */
+#if defined(__riscv)
+   asm("wfi");
+#endif
   (void) cpu_self;
 }
 
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Open firmware: restore FDT in ofw01 to avoid test timeout

[Jiri Gaisler]

The ofw01 test will hang on RISC-V unless the real FDT is restored at the end 
of the test. This will allow the Sifive test module be found by 
_CPU_Fatal_halt() and avoid an infinite loop.


From 7d285bb7b9d648bef2eb6bd39c5530c56beff287 Mon Sep 17 00:00:00 2001
From: Jiri Gaisler 
Date: Sun, 28 Mar 2021 14:51:25 +0200
Subject: [PATCH] Restore FDT in ofw01 to avoid test timeout on RISCV

---
 testsuites/libtests/ofw01/init.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/testsuites/libtests/ofw01/init.c b/testsuites/libtests/ofw01/init.c
index 39bc30774a..6006121cc7 100644
--- a/testsuites/libtests/ofw01/init.c
+++ b/testsuites/libtests/ofw01/init.c
@@ -184,6 +184,7 @@ static void Init(rtems_task_argument arg)
   rtems_test_assert(rv == true);
 
   TEST_END();
+  test_bin = NULL;
   rtems_test_exit(0);
 }
 
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Fwd: [rtems-source-builder commit] devel/sis: Update to 2.26

[Jiri Gaisler]

This commit updates sis to 2.26 which has support for the RISCV32 bsps. There 
are a few fails, but thess are probably bsp issues. sis can detect if the 
binary is for the rv32 or griscv bsps, so the same griscv-sis.ini file can be 
used in rtems-test:

rtems-test --rtems-bsp=griscv-sis --rtems-tools=/opt/rtems/6 
build/riscv/rv32imafd/testsuites

Passed:    601
Failed:  3
User Input:  5
Expected Fail:   0
Indeterminate:   0
Benchmark:   3
Timeout: 3
Test too long:   0
Invalid: 1
Wrong Version:   0
Wrong Build: 0
Wrong Tools: 0
--
Total: 616
Failures:
 spconsole01.exe
User Input:
 monitor.exe
 termios.exe
 top.exe
 capture.exe
 fileio.exe
Benchmark:
 linpack.exe
 dhrystone.exe
 whetstone.exe
Timeouts:
 crypt01.exe
 smpclock01.exe
 smpschededf03.exe
Invalid:
 smpfatal08.exe
Average test time: 0:00:00.468645
Testing time : 0:04:48.685363

 Forwarded Message 
Subject:[rtems-source-builder commit] devel/sis: Update to 2.26
Date:   Sun, 20 Dec 2020 20:29:46 +
From:   Jiri Gaisler 
Reply-To:   v...@rtems.org
To: v...@rtems.org



Module: rtems-source-builder
Branch: master
Commit: 649beb430b6fc97bcefd4324db451db11e4e84fd
Changeset: 
http://git.rtems.org/rtems-source-builder/commit/?id=649beb430b6fc97bcefd4324db451db11e4e84fd

Author: Jiri Gaisler 
Date: Fri Dec 18 22:57:31 2020 +0100

devel/sis: Update to 2.26

---

bare/config/devel/sis-2-1.cfg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bare/config/devel/sis-2-1.cfg b/bare/config/devel/sis-2-1.cfg
index 4f4a0f5..c4b5f9e 100644
--- a/bare/config/devel/sis-2-1.cfg
+++ b/bare/config/devel/sis-2-1.cfg
@@ -8,8 +8,8 @@
%include %{_configdir}/base.cfg
-%define sis_version 2.25
-%hash sha512 sis-%{sis_version}.tar.bz2 
e0523a3907403da37c8c3e506f7e1c7a62c66c75a1a61373af03d1ebeb307dc991ca54f15c35f468d216ccf58bd65ee7a0eab74a1f291d4df858ed205acd62df
+%define sis_version 2.26
+%hash sha512 sis-%{sis_version}.tar.bz2 
91c5699ae71113ea405300f4b19e072a9cdf334fe3b1d399ec497fe45ea9522076a310c05560676a960018497a062d7c573e27cc68716f07d2a12ba80881eb2a
#
# The SIS build instructions.

___
vc mailing list
v...@rtems.org
http://lists.rtems.org/mailman/listinfo/vc
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: MSYS2 build: header file missing

[Jiri Gaisler]

On 12/18/20 5:15 PM, Robin Müller wrote:
> Hi Jiri,
>
> Okay, I commented out that header on my Windows 10 machine (Version 20H2, 
> 19042.685) and it compiled.
>
> That error was on a different Linux machine when cross compiling the cross 
> toolchain for Windows (i686 rtems6-arm worked now, so that's nice). Maybe 
> this #define is also derived from the current OS?
> I could try to supply it manually..

I have updated sis git with the windows fixes. To test it, apply the attached 
patch to your RSB tree and build sis standalone with

../source-builder/sb-set-builder --prefix=/opt/rtems/6 devel/sis

Let me know if it builds OK for you and I will push the patch to the RSB tree...

Jiri.

>
> Kind Regards
> Robin
>
>
>
> On Fri, 18 Dec 2020 at 16:35, Jiri Gaisler  <mailto:j...@gaisler.se>> wrote:
>
>
> On 12/18/20 2:10 PM, Robin Müller wrote:
>> In case you're interested, this is the fail report for the SIS Cxc build 
>> on Linux (failed both for i686 and x86_64).
>>
>> I think it fails because _WIN32_WINNT (windows version) is not defined, 
>> causing winsock2.h to exclude requires sections.
>>
>> Build command was:
>>  ../source-builder/sb-set-builder 
>> --prefix=/c/Users/Robin/RTEMS/rtems-tools/rtems/6 --no-install 
>> --bset-tar-file --host=i686-w64-mingw32 6/rtems-sparc
>>
> I had a quick look at this. The first problem with missing arpa/inet.h 
> can be fixed by commenting out the include file, as it is not needed:
>
> i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I.    -DFAST_UART -O2 -g -pipe 
> -I/home/rmueller/Documents/RTEMS/rtems-tools/src/rsb/rtems/build/tmp/sb-1000/6/rtems-sparc/c/Users/Robin/RTEMS/rtems-tools/rtems/6/include
>   -MT greth.o -MD -MP -MF .deps/greth.Tpo -c -o greth.o greth.c
> greth.c:31:10: fatal error: arpa/inet.h: No such file or directory
>    31 | #include 
>
>
> The second problem with winsock2.h is not obvious to me. On my old 
> windows7/qemu system, remote.c compiles fine and winsock2.h provides the 
> necessary defines. Which windows version are you using where it fails?
>
> I am about to release a new sis version with more RISCV support, so I 
> could add fixes for MSYS2 if necessary ...
>
> Regards, Jiri.
>
>
>> Kind Regards
>> Robin
>>
>> On Fri, 18 Dec 2020 at 12:49, Robin Müller > <mailto:robin.muelle...@gmail.com>> wrote:
>>
>> If I understand correctly, the BSPs can be installed with waf only 
>> if the tool suite for the given architecture has been installed.
>> Problem is, the RSB build will fail even if a tiny component is 
>> problematic. 
>> I thought the tool suite itself is installed using the build 
>> commands required by the sources (make, automake, etc).
>> Is it possible to also build these sources with waf?
>>
>> I have tried this cross compiling on linux for windows (I used 
>> x86_64 instead of i686) because everything was working on Linux, but there 
>> are issues with the SIS tool for sparc-rtems6..
>> But SIS is now also problematic on the Windows machine where I 
>> almost managed to build everything.
>>
>> Everything except SIS was built by the RSB and I copied the 
>> installed files manually to install them and tried to build a BSP (is there 
>> actually some script like do-install which will perform this step?)
>> But now some RTEMS tool is missing (rtems-bin2c):
>>
>> $ ./waf configure --prefix=$RTEMS_TOOLS --rtems-bsp=sparc/erc32
>> Setting top to                           : 
>> C:/Users/Robin/Documents/RTEMS/rtems-tools/src/rtems
>> Setting out to                           : 
>> C:/Users/Robin/Documents/RTEMS/rtems-tools/src/rtems/build
>> Configure board support package (BSP)    : sparc/erc32
>> Checking for program 'sparc-rtems6-gcc'  : 
>> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-gcc.exe
>> Checking for program 'sparc-rtems6-g++'  : 
>> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-g++.exe
>> Checking for program 'sparc-rtems6-ar'   : 
>> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ar.exe
>> Checking for program 'sparc-rtems6-ld'   : 
>> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ld.exe
>> Checking for program 'ar'                : 
>> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ar.exe
>> Checking for

Re: MSYS2 build: header file missing

[Jiri Gaisler]

On 12/18/20 2:10 PM, Robin Müller wrote:
> In case you're interested, this is the fail report for the SIS Cxc build on 
> Linux (failed both for i686 and x86_64).
>
> I think it fails because _WIN32_WINNT (windows version) is not defined, 
> causing winsock2.h to exclude requires sections.
>
> Build command was:
>  ../source-builder/sb-set-builder 
> --prefix=/c/Users/Robin/RTEMS/rtems-tools/rtems/6 --no-install 
> --bset-tar-file --host=i686-w64-mingw32 6/rtems-sparc
>
I had a quick look at this. The first problem with missing arpa/inet.h can be 
fixed by commenting out the include file, as it is not needed:

i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I.    -DFAST_UART -O2 -g -pipe 
-I/home/rmueller/Documents/RTEMS/rtems-tools/src/rsb/rtems/build/tmp/sb-1000/6/rtems-sparc/c/Users/Robin/RTEMS/rtems-tools/rtems/6/include
  -MT greth.o -MD -MP -MF .deps/greth.Tpo -c -o greth.o greth.c
greth.c:31:10: fatal error: arpa/inet.h: No such file or directory
   31 | #include 


The second problem with winsock2.h is not obvious to me. On my old 
windows7/qemu system, remote.c compiles fine and winsock2.h provides the 
necessary defines. Which windows version are you using where it fails?

I am about to release a new sis version with more RISCV support, so I could add 
fixes for MSYS2 if necessary ...

Regards, Jiri.


> Kind Regards
> Robin
>
> On Fri, 18 Dec 2020 at 12:49, Robin Müller  > wrote:
>
> If I understand correctly, the BSPs can be installed with waf only if the 
> tool suite for the given architecture has been installed.
> Problem is, the RSB build will fail even if a tiny component is 
> problematic. 
> I thought the tool suite itself is installed using the build commands 
> required by the sources (make, automake, etc).
> Is it possible to also build these sources with waf?
>
> I have tried this cross compiling on linux for windows (I used x86_64 
> instead of i686) because everything was working on Linux, but there are 
> issues with the SIS tool for sparc-rtems6..
> But SIS is now also problematic on the Windows machine where I almost 
> managed to build everything.
>
> Everything except SIS was built by the RSB and I copied the installed 
> files manually to install them and tried to build a BSP (is there actually 
> some script like do-install which will perform this step?)
> But now some RTEMS tool is missing (rtems-bin2c):
>
> $ ./waf configure --prefix=$RTEMS_TOOLS --rtems-bsp=sparc/erc32
> Setting top to                           : 
> C:/Users/Robin/Documents/RTEMS/rtems-tools/src/rtems
> Setting out to                           : 
> C:/Users/Robin/Documents/RTEMS/rtems-tools/src/rtems/build
> Configure board support package (BSP)    : sparc/erc32
> Checking for program 'sparc-rtems6-gcc'  : 
> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-gcc.exe
> Checking for program 'sparc-rtems6-g++'  : 
> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-g++.exe
> Checking for program 'sparc-rtems6-ar'   : 
> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ar.exe
> Checking for program 'sparc-rtems6-ld'   : 
> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ld.exe
> Checking for program 'ar'                : 
> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ar.exe
> Checking for program 'g++, c++'          : 
> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-g++.exe
> Checking for program 'ar'                : 
> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ar.exe
> Checking for program 'gas, gcc'          : 
> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-gcc.exe
> Checking for program 'ar'                : 
> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ar.exe
> Checking for program 'gcc, cc'           : 
> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-gcc.exe
> Checking for program 'ar'                : 
> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ar.exe
> Checking for program 'rtems-bin2c'       : not found
> Could not find the program ['rtems-bin2c']
> (complete log in 
> C:/Users/Robin/Documents/RTEMS/rtems-tools/src/rtems/build/config.log)
>
> In general the build process on Windows seems to be more "brittle" than 
> on Linux, so maybe installers would be a good idea? I generally installed 
> cross-compilers (e.g. arm-none-eabi-gcc) on Windows
> using installers (for example https://xpack.github.io/arm-none-eabi-gcc/) 
> and have made very good experience with that.
>
> Kind Regards
> Robin
>
> On Fri, 18 Dec 2020 at 12:24, Sebastian Huber 
>  > wrote:
>
> On 18/12/2020 11:35, Chris Johns wrote:
>
> >> Since all parts of RTEMS build now with waf I think it i

Re: [PATCH v3 0/2] Add networking support for griscv bsp

[Jiri Gaisler]

Does anyone object to this patch? Otherwise I will go ahead and commit it...

Jiri.

On 11/1/20 4:46 PM, Jiri Gaisler wrote:
> Third attempt. Needed to fix the waf build and add correct link address
> for the griscv bsp. Tested with rtems-netdemos.
>
> Jiri Gaisler (2):
>   Add networking support for griscv bsp
>   Add correct link address for griscv waf build
>
>  bsps/riscv/griscv/console/console.c  |  2 +-
>  bsps/riscv/griscv/include/bsp.h  | 14 +
>  bsps/riscv/griscv/net/griscv_greth.c | 59 
>  bsps/shared/grlib/net/greth.c| 24 
>  bsps/shared/net/greth2.c |  6 +-
>  c/src/lib/libbsp/riscv/griscv/Makefile.am|  6 ++
>  spec/build/bsps/riscv/griscv/grp.yml |  2 +
>  spec/build/bsps/riscv/griscv/objnetnosmp.yml | 18 ++
>  spec/build/bsps/riscv/optrambegin.yml|  3 +
>  spec/build/bsps/riscv/optramsize.yml |  3 +
>  10 files changed, 123 insertions(+), 14 deletions(-)
>  create mode 100644 bsps/riscv/griscv/net/griscv_greth.c
>  create mode 100644 spec/build/bsps/riscv/griscv/objnetnosmp.yml
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Problems compiling rtems-libbsd

[Jiri Gaisler]

  
  


On 11/2/20 1:37 AM, Sebastian Huber
  wrote:

Hello
  Jiri,
  
  
  it builds for me. I guess you installed the BSP before with
  RTEMS_NETWORKING == True and then again with RTEMS_NETWORKING ==
  False. Please remove the BSP installation and start from scratch.
  
  

Thanks, that helped and it now compiles and runs on sis. One
  final question:
Do I need to port the RTEMS GRETH driver into the libbsd tree to
  get networking going, or is there some other trick? So far I can
  only get the lo0 device to come up ...


$ sudo ./sis -leon3 -bridge lxcbr0
~/ibm/src/rtems/rtems-libbsd/build/sparc-rtems6-leon3-default/ping01.exe
  
   Loaded
/home/jiri/ibm/src/rtems/rtems-libbsd/build/sparc-rtems6-leon3-default/ping01.exe,
entry 0x4000
  sis> run
  
  *** BEGIN OF TEST LIBBSD PING 1 ***
  *** TEST VERSION:
6.0.0.e303ca4384fb97a9aa870b07b3d442aff562646b
  *** TEST STATE: EXPECTED_PASS
  *** TEST BUILD: RTEMS_POSIX_API
  *** TEST TOOLS: 10.2.1 20200904 (RTEMS 6, RSB
31f936a7b74d60bda609a9960c6e1a705ba54974, Newlib a0d7982)
  nexus0: 
  [zone: unpcb] kern.ipc.maxsockets limit reached
  info: lo0: link state changed to UP
  ifconfig: interface gr_eth1 does not exist
  assertion "exit_code == EX_OK" failed: file
"../../testsuite/include/rtems/bsd/test/default-network-init.h",
line 97, function: default_network_ifconfig_hwif0
  cpu 0 in error mode (tt = 0x80)
  

  


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Problems compiling rtems-libbsd

[Jiri Gaisler]

  
  


On 11/1/20 2:29 PM, Joel Sherrill
  wrote:


  
  Are you on the master instead of 6-freebsd12?


Libbsd is different from our other repos since
  you need to be on a branch that matches RTEMS and FreeBSD
  version
  

I am a bit confused here - I was on RTEMS master and rtems-libbsd
  master which seems to be OK according to README.md. I switched to
  6-freebsd12 for rtems-libbsd but the same errors occurred



  
On Sun, Nov 1, 2020, 10:54 AM
  Jiri Gaisler <j...@gaisler.se> wrote:

I am trying
  to build the rtems-libbsd package to test the new network
  stack. Configuration works fine, but compiling fails quickly.
  Log below,
  any ideas ...?
  
  jiri@carbon:~/ibm/src/rtems/rtems-libbsd$ python3 ./waf
  configure
  --rtems-bsps=sparc/leon3 --prefix=/opt/rtems/6
  --buildset=buildset/default.ini
  Setting top to   :
  /home/jiri/ibm/src/rtems/rtems-libbsd
  Setting out to   :
  /home/jiri/ibm/src/rtems/rtems-libbsd/build
  RTEMS Version    : 6
  Architectures    : riscv-rtems6,
  sparc-rtems6
  Board Support Package (BSP)  : sparc-rtems6-leon3
  Show commands    : no
  Long commands    : no
  Checking for program 'sparc-rtems6-gcc'  :
  /opt/rtems/6/bin/sparc-rtems6-gcc
  Checking for program 'sparc-rtems6-g++'  :
  /opt/rtems/6/bin/sparc-rtems6-g++
  Checking for program 'sparc-rtems6-gcc'  :
  /opt/rtems/6/bin/sparc-rtems6-gcc
  Checking for program 'sparc-rtems6-ld'   :
  /opt/rtems/6/bin/sparc-rtems6-ld
  Checking for program 'sparc-rtems6-ar'   :
  /opt/rtems/6/bin/sparc-rtems6-ar
  Checking for program 'sparc-rtems6-nm'   :
  /opt/rtems/6/bin/sparc-rtems6-nm
  Checking for program 'sparc-rtems6-objdump' :
  /opt/rtems/6/bin/sparc-rtems6-objdump
  Checking for program 'sparc-rtems6-objcopy' :
  /opt/rtems/6/bin/sparc-rtems6-objcopy
  Checking for program 'sparc-rtems6-readelf' :
  /opt/rtems/6/bin/sparc-rtems6-readelf
  Checking for program 'sparc-rtems6-strip'   :
  /opt/rtems/6/bin/sparc-rtems6-strip
  Checking for program 'sparc-rtems6-ranlib'  :
  /opt/rtems/6/bin/sparc-rtems6-ranlib
  Checking for program 'rtems-ld' :
  /opt/rtems/6/bin/rtems-ld
  Checking for program 'rtems-tld'    :
  /opt/rtems/6/bin/rtems-tld
  Checking for program 'rtems-syms'   :
  /opt/rtems/6/bin/rtems-syms
  Checking for program 'rtems-bin2c'  :
  /opt/rtems/6/bin/rtems-bin2c
  Checking for program 'tar'  : /bin/tar
  Checking for program 'gcc, cc'  :
  /opt/rtems/6/bin/sparc-rtems6-gcc
  Checking for program 'ar'   :
  /opt/rtems/6/bin/sparc-rtems6-ar
  Checking for program 'g++, c++' :
  /opt/rtems/6/bin/sparc-rtems6-g++
  Checking for program 'ar'   :
  /opt/rtems/6/bin/sparc-rtems6-ar
  Checking for program 'gas, gcc' :
  /opt/rtems/6/bin/sparc-rtems6-gcc
  Checking for program 'ar'   :
  /opt/rtems/6/bin/sparc-rtems6-ar
  Checking for c flags '-MMD' : yes
  Checking for cxx flags '-MMD'   : yes
  Compiler version (sparc-rtems6-gcc) : 10.2.1 20200904
  (RTEMS 6,
  RSB 31f936a7b74d60bda609a9960c6e1a705ba54974, Newlib a0d7982)
  Checking for a valid RTEMS BSP installation : yes
  Checking for RTEMS_DEBUG    : no
  Checking for RTEMS_MULTIPROCESSING  : no
  Checking for RTEMS_NEWLIB   : yes
  Checking for RTEMS_POSIX_API    : yes
  Checking for RTEMS_SMP  : no
  Checking for RTEMS_NETWORKING   : no
  Checking for header dlfcn.h : yes
  Checking for header rtems/pci.h : yes
  Configure variant:  :
  sparc-rtems6-leon3-default
  Checking for library debugger   : yes
  'configure' finished successfully (0.871s)
   

Problems compiling rtems-libbsd

[Jiri Gaisler]

I am trying to build the rtems-libbsd package to test the new network
stack. Configuration works fine, but compiling fails quickly. Log below,
any ideas ...?

jiri@carbon:~/ibm/src/rtems/rtems-libbsd$ python3 ./waf configure
--rtems-bsps=sparc/leon3 --prefix=/opt/rtems/6
--buildset=buildset/default.ini
Setting top to   :
/home/jiri/ibm/src/rtems/rtems-libbsd
Setting out to   :
/home/jiri/ibm/src/rtems/rtems-libbsd/build
RTEMS Version    : 6
Architectures    : riscv-rtems6, sparc-rtems6
Board Support Package (BSP)  : sparc-rtems6-leon3
Show commands    : no
Long commands    : no
Checking for program 'sparc-rtems6-gcc'  :
/opt/rtems/6/bin/sparc-rtems6-gcc
Checking for program 'sparc-rtems6-g++'  :
/opt/rtems/6/bin/sparc-rtems6-g++
Checking for program 'sparc-rtems6-gcc'  :
/opt/rtems/6/bin/sparc-rtems6-gcc
Checking for program 'sparc-rtems6-ld'   : /opt/rtems/6/bin/sparc-rtems6-ld
Checking for program 'sparc-rtems6-ar'   : /opt/rtems/6/bin/sparc-rtems6-ar
Checking for program 'sparc-rtems6-nm'   : /opt/rtems/6/bin/sparc-rtems6-nm
Checking for program 'sparc-rtems6-objdump' :
/opt/rtems/6/bin/sparc-rtems6-objdump
Checking for program 'sparc-rtems6-objcopy' :
/opt/rtems/6/bin/sparc-rtems6-objcopy
Checking for program 'sparc-rtems6-readelf' :
/opt/rtems/6/bin/sparc-rtems6-readelf
Checking for program 'sparc-rtems6-strip'   :
/opt/rtems/6/bin/sparc-rtems6-strip
Checking for program 'sparc-rtems6-ranlib'  :
/opt/rtems/6/bin/sparc-rtems6-ranlib
Checking for program 'rtems-ld' : /opt/rtems/6/bin/rtems-ld
Checking for program 'rtems-tld'    : /opt/rtems/6/bin/rtems-tld
Checking for program 'rtems-syms'   : /opt/rtems/6/bin/rtems-syms
Checking for program 'rtems-bin2c'  : /opt/rtems/6/bin/rtems-bin2c
Checking for program 'tar'  : /bin/tar
Checking for program 'gcc, cc'  :
/opt/rtems/6/bin/sparc-rtems6-gcc
Checking for program 'ar'   :
/opt/rtems/6/bin/sparc-rtems6-ar
Checking for program 'g++, c++' :
/opt/rtems/6/bin/sparc-rtems6-g++
Checking for program 'ar'   :
/opt/rtems/6/bin/sparc-rtems6-ar
Checking for program 'gas, gcc' :
/opt/rtems/6/bin/sparc-rtems6-gcc
Checking for program 'ar'   :
/opt/rtems/6/bin/sparc-rtems6-ar
Checking for c flags '-MMD' : yes
Checking for cxx flags '-MMD'   : yes
Compiler version (sparc-rtems6-gcc) : 10.2.1 20200904 (RTEMS 6,
RSB 31f936a7b74d60bda609a9960c6e1a705ba54974, Newlib a0d7982)
Checking for a valid RTEMS BSP installation : yes
Checking for RTEMS_DEBUG    : no
Checking for RTEMS_MULTIPROCESSING  : no
Checking for RTEMS_NEWLIB   : yes
Checking for RTEMS_POSIX_API    : yes
Checking for RTEMS_SMP  : no
Checking for RTEMS_NETWORKING   : no
Checking for header dlfcn.h : yes
Checking for header rtems/pci.h : yes
Configure variant:  : sparc-rtems6-leon3-default
Checking for library debugger   : yes
'configure' finished successfully (0.871s)
jiri@carbon:~/ibm/src/rtems/rtems-libbsd$ python3 ./waf
Waf: Entering directory
`/home/jiri/ibm/src/rtems/rtems-libbsd/build/sparc-rtems6-leon3-default'
[   7/1954] Compiling freebsd/contrib/libpcap/grammar.c
[   9/1954] Compiling freebsd/sbin/pfctl/parse.c
[  12/1954] Compiling freebsd/contrib/expat/lib/xmltok_ns.c
[  13/1954] Compiling freebsd/contrib/expat/lib/xmltok_impl.c
[  14/1954] Compiling freebsd/contrib/expat/lib/xmltok.c
[  15/1954] Compiling freebsd/lib/libc/net/getnetbynis.c
grammar.y: In function 'pcap_parse':
grammar.y:693:31: error: 'BPF_MOD' undeclared (first use in this
function); did you mean 'BPF_MODE'?
grammar.y:693:31: note: each undeclared identifier is reported only once
for each function it appears in
grammar.y:696:31: error: 'BPF_XOR' undeclared (first use in this
function); did you mean 'BPF_OR'?

parse.y: In function '_bsd_pfctl_expand_label_str':
parse.y:4853:10: error: macro "free" requires 2 arguments, but only 1 given
In file included from
/opt/rtems/6/sparc-rtems6/leon3/lib/include/sys/malloc.h:39,
 from ../../freebsd/sys/net/pfvar.h:42,
 from parse.y:64:
/opt/rtems/6/sparc-rtems6/leon3/lib/include/rtems/rtems_bsdnet_internal.h:148:
note: macro "free" defined here
  148 | #define free(ptr,type) rtems_bsdnet_free(ptr,type)
  |
parse.y: In function '_bsd_pfctl_expand_altq':
parse.y:5009:39: error: macro "free" requires 2 arguments, but only 1 given
In file included from
/opt/rtems/6/sparc-rtems6/leon3/lib/include/sys/malloc.h:39,
 from ../../freebsd/sys/net/pfvar.h:42,
 from parse.y:64:
/opt/rtems/6/sparc-rtems6/leon3/lib/include/rtems/rtems_bsdnet_internal.h:148:
note: macro "free" 

[PATCH v3 0/2] Add networking support for griscv bsp

[Jiri Gaisler]

Third attempt. Needed to fix the waf build and add correct link address
for the griscv bsp. Tested with rtems-netdemos.

Jiri Gaisler (2):
  Add networking support for griscv bsp
  Add correct link address for griscv waf build

 bsps/riscv/griscv/console/console.c  |  2 +-
 bsps/riscv/griscv/include/bsp.h  | 14 +
 bsps/riscv/griscv/net/griscv_greth.c | 59 
 bsps/shared/grlib/net/greth.c| 24 
 bsps/shared/net/greth2.c |  6 +-
 c/src/lib/libbsp/riscv/griscv/Makefile.am|  6 ++
 spec/build/bsps/riscv/griscv/grp.yml |  2 +
 spec/build/bsps/riscv/griscv/objnetnosmp.yml | 18 ++
 spec/build/bsps/riscv/optrambegin.yml|  3 +
 spec/build/bsps/riscv/optramsize.yml |  3 +
 10 files changed, 123 insertions(+), 14 deletions(-)
 create mode 100644 bsps/riscv/griscv/net/griscv_greth.c
 create mode 100644 spec/build/bsps/riscv/griscv/objnetnosmp.yml

-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v3 1/2] Add networking support for griscv bsp

[Jiri Gaisler]

* Only GRETH device supported for now
* Fix endian problem in GRETH driver
* Remove SPARC assembly from greth.c
* Builds with both autoconf and waf
---
 bsps/riscv/griscv/console/console.c  |  2 +-
 bsps/riscv/griscv/include/bsp.h  | 14 +
 bsps/riscv/griscv/net/griscv_greth.c | 59 
 bsps/shared/grlib/net/greth.c| 24 
 bsps/shared/net/greth2.c |  6 +-
 c/src/lib/libbsp/riscv/griscv/Makefile.am|  6 ++
 spec/build/bsps/riscv/griscv/grp.yml |  2 +
 spec/build/bsps/riscv/griscv/objnetnosmp.yml | 18 ++
 8 files changed, 117 insertions(+), 14 deletions(-)
 create mode 100644 bsps/riscv/griscv/net/griscv_greth.c
 create mode 100644 spec/build/bsps/riscv/griscv/objnetnosmp.yml

diff --git a/bsps/riscv/griscv/console/console.c 
b/bsps/riscv/griscv/console/console.c
index 582b4c81b8..c92be99fdb 100644
--- a/bsps/riscv/griscv/console/console.c
+++ b/bsps/riscv/griscv/console/console.c
@@ -64,7 +64,7 @@ static int find_matching_apbuart(struct ambapp_dev *dev, int 
index, void *arg)
 
   /* Extract needed information of one APBUART */
   apbuarts[uarts].regs = (struct apbuart_regs *)apb->start;
-  apbuarts[uarts].irq = apb->irq;
+  apbuarts[uarts].irq = apb->common.irq;
   /* Get APBUART core frequency, it is assumed that it is the same
* as Bus frequency where the UART is situated
*/
diff --git a/bsps/riscv/griscv/include/bsp.h b/bsps/riscv/griscv/include/bsp.h
index 95cccd3d0a..9d6fb2a16f 100644
--- a/bsps/riscv/griscv/include/bsp.h
+++ b/bsps/riscv/griscv/include/bsp.h
@@ -75,6 +75,20 @@ extern void BSP_shared_interrupt_mask(int irq);
 extern void BSP_shared_interrupt_clear(int irq);
 extern void BSP_shared_interrupt_unmask(int irq);
 
+/*
+ * Network driver configuration for greth
+ */
+struct rtems_bsdnet_ifconfig;
+extern int rtems_griscv_greth_driver_attach(
+  struct rtems_bsdnet_ifconfig *config,
+  int attach
+);
+
+#define RTEMS_BSP_NETWORK_DRIVER_NAME "gr_eth1"
+#define RTEMS_BSP_NETWORK_DRIVER_ATTACH rtems_griscv_greth_driver_attach
+#define GRETH_SUPPORTED
+#define CPU_U32_FIX
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/bsps/riscv/griscv/net/griscv_greth.c 
b/bsps/riscv/griscv/net/griscv_greth.c
new file mode 100644
index 00..e5c05fd060
--- /dev/null
+++ b/bsps/riscv/griscv/net/griscv_greth.c
@@ -0,0 +1,59 @@
+/*
+ *  LEON3 Opencores Ethernet MAC Configuration Information
+ *
+ *  COPYRIGHT (c) 2004.
+ *  Gaisler Research
+ *
+ *  The license and distribution terms for this file may be
+ *  found in the file LICENSE in this distribution or at
+ *  http://www.rtems.org/license/LICENSE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+/*#if (GRETH_DEBUG & GRETH_DEBUG_PRINT_REGISTERS)*/
+#include 
+/*#endif*/
+
+/*
+ * Default sizes of transmit and receive descriptor areas
+ */
+#define RDA_COUNT 32
+#define TDA_COUNT 32
+
+greth_configuration_t griscv_greth_configuration;
+
+int rtems_griscv_greth_driver_attach(
+  struct rtems_bsdnet_ifconfig *config,
+  int attach
+)
+{
+  unsigned int base_addr = 0; /* avoid warnings */
+  unsigned int eth_irq = 0;   /* avoid warnings */
+  struct ambapp_dev *adev;
+  struct ambapp_apb_info *apb;
+
+  /* Scan for MAC AHB slave interface */
+  adev = (void *)ambapp_for_each(&ambapp_plb, (OPTIONS_ALL|OPTIONS_APB_SLVS),
+ VENDOR_GAISLER, GAISLER_ETHMAC,
+ ambapp_find_by_idx, NULL);
+  if (adev) {
+apb = DEV_TO_APB(adev);
+base_addr = apb->start;
+eth_irq = apb->common.irq;
+
+/* clear control register and reset NIC */
+*(volatile int *) base_addr = 0;
+*(volatile int *) base_addr = GRETH_CTRL_RST;
+*(volatile int *) base_addr = 0;
+griscv_greth_configuration.base_address = (void*)base_addr;
+griscv_greth_configuration.vector = eth_irq; /* on LEON vector is IRQ no. 
*/
+griscv_greth_configuration.txd_count = TDA_COUNT;
+griscv_greth_configuration.rxd_count = RDA_COUNT;
+rtems_greth_driver_attach(config, &griscv_greth_configuration);
+  }
+  return 0;
+}
diff --git a/bsps/shared/grlib/net/greth.c b/bsps/shared/grlib/net/greth.c
index bc4d3cc40f..8b19b48211 100644
--- a/bsps/shared/grlib/net/greth.c
+++ b/bsps/shared/grlib/net/greth.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -721,10 +722,13 @@ void ipalign(struct mbuf *m)
   unsigned int tmp = 0;
 
   if int) m->m_data) & 2) && (m->m_len)) {
+#if CPU_LITTLE_ENDIAN == TRUE
+memmove((caddr_t)(((int) m->m_data) + 2), m->m_data, m->m_len);
+#else
 last = (unsigned int *) int) m->m_data) + m->m_len + 8) & ~3);
 first = (unsigned int *) (((int) m->m_data) & ~3);
/* tmp = *first << 16; */
-   asm volatile (" lda [%1] 1, %0\n" : "=r"(tmp) : "r"(first) );
+   tmp = GRETH_MEM_LOAD(first);
tmp = tmp << 16;
 first+

[PATCH v3 2/2] Add correct link address for griscv waf build

[Jiri Gaisler]

---
 spec/build/bsps/riscv/optrambegin.yml | 3 +++
 spec/build/bsps/riscv/optramsize.yml  | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/spec/build/bsps/riscv/optrambegin.yml 
b/spec/build/bsps/riscv/optrambegin.yml
index cf5d909562..2073926dac 100644
--- a/spec/build/bsps/riscv/optrambegin.yml
+++ b/spec/build/bsps/riscv/optrambegin.yml
@@ -16,6 +16,9 @@ default-by-variant:
 - value: 1879048192
   variants:
   - riscv/rv64.*
+- value: 1073741824
+  variants:
+  - riscv/griscv
 description: ''
 enabled-by: true
 format: '{:#010x}'
diff --git a/spec/build/bsps/riscv/optramsize.yml 
b/spec/build/bsps/riscv/optramsize.yml
index bbc226cc13..cd58dbd504 100644
--- a/spec/build/bsps/riscv/optramsize.yml
+++ b/spec/build/bsps/riscv/optramsize.yml
@@ -13,6 +13,9 @@ default-by-variant:
 - value: 268435456
   variants:
   - riscv/frdme310arty
+- value: 16777216
+  variants:
+  - riscv/griscv
 description: ''
 enabled-by: true
 format: '{:#010x}'
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2] Add networking support for griscv bsp

[Jiri Gaisler]

* Only GRETH device supported for now
* Fix endian problem in GRETH driver
* Remove SPARC assembly from greth.c
* Builds with both autoconf and waf
---
 bsps/riscv/griscv/console/console.c  |  2 +-
 bsps/riscv/griscv/include/bsp.h  | 14 +
 bsps/riscv/griscv/net/griscv_greth.c | 59 
 bsps/shared/grlib/net/greth.c| 23 
 bsps/shared/net/greth2.c |  6 +-
 c/src/lib/libbsp/riscv/griscv/Makefile.am|  6 ++
 spec/build/bsps/riscv/griscv/objnetnosmp.yml | 18 ++
 7 files changed, 114 insertions(+), 14 deletions(-)
 create mode 100644 bsps/riscv/griscv/net/griscv_greth.c
 create mode 100644 spec/build/bsps/riscv/griscv/objnetnosmp.yml

diff --git a/bsps/riscv/griscv/console/console.c 
b/bsps/riscv/griscv/console/console.c
index 582b4c81b8..c92be99fdb 100644
--- a/bsps/riscv/griscv/console/console.c
+++ b/bsps/riscv/griscv/console/console.c
@@ -64,7 +64,7 @@ static int find_matching_apbuart(struct ambapp_dev *dev, int 
index, void *arg)
 
   /* Extract needed information of one APBUART */
   apbuarts[uarts].regs = (struct apbuart_regs *)apb->start;
-  apbuarts[uarts].irq = apb->irq;
+  apbuarts[uarts].irq = apb->common.irq;
   /* Get APBUART core frequency, it is assumed that it is the same
* as Bus frequency where the UART is situated
*/
diff --git a/bsps/riscv/griscv/include/bsp.h b/bsps/riscv/griscv/include/bsp.h
index 95cccd3d0a..9d6fb2a16f 100644
--- a/bsps/riscv/griscv/include/bsp.h
+++ b/bsps/riscv/griscv/include/bsp.h
@@ -75,6 +75,20 @@ extern void BSP_shared_interrupt_mask(int irq);
 extern void BSP_shared_interrupt_clear(int irq);
 extern void BSP_shared_interrupt_unmask(int irq);
 
+/*
+ * Network driver configuration for greth
+ */
+struct rtems_bsdnet_ifconfig;
+extern int rtems_griscv_greth_driver_attach(
+  struct rtems_bsdnet_ifconfig *config,
+  int attach
+);
+
+#define RTEMS_BSP_NETWORK_DRIVER_NAME "gr_eth1"
+#define RTEMS_BSP_NETWORK_DRIVER_ATTACH rtems_griscv_greth_driver_attach
+#define GRETH_SUPPORTED
+#define CPU_U32_FIX
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/bsps/riscv/griscv/net/griscv_greth.c 
b/bsps/riscv/griscv/net/griscv_greth.c
new file mode 100644
index 00..e5c05fd060
--- /dev/null
+++ b/bsps/riscv/griscv/net/griscv_greth.c
@@ -0,0 +1,59 @@
+/*
+ *  LEON3 Opencores Ethernet MAC Configuration Information
+ *
+ *  COPYRIGHT (c) 2004.
+ *  Gaisler Research
+ *
+ *  The license and distribution terms for this file may be
+ *  found in the file LICENSE in this distribution or at
+ *  http://www.rtems.org/license/LICENSE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+/*#if (GRETH_DEBUG & GRETH_DEBUG_PRINT_REGISTERS)*/
+#include 
+/*#endif*/
+
+/*
+ * Default sizes of transmit and receive descriptor areas
+ */
+#define RDA_COUNT 32
+#define TDA_COUNT 32
+
+greth_configuration_t griscv_greth_configuration;
+
+int rtems_griscv_greth_driver_attach(
+  struct rtems_bsdnet_ifconfig *config,
+  int attach
+)
+{
+  unsigned int base_addr = 0; /* avoid warnings */
+  unsigned int eth_irq = 0;   /* avoid warnings */
+  struct ambapp_dev *adev;
+  struct ambapp_apb_info *apb;
+
+  /* Scan for MAC AHB slave interface */
+  adev = (void *)ambapp_for_each(&ambapp_plb, (OPTIONS_ALL|OPTIONS_APB_SLVS),
+ VENDOR_GAISLER, GAISLER_ETHMAC,
+ ambapp_find_by_idx, NULL);
+  if (adev) {
+apb = DEV_TO_APB(adev);
+base_addr = apb->start;
+eth_irq = apb->common.irq;
+
+/* clear control register and reset NIC */
+*(volatile int *) base_addr = 0;
+*(volatile int *) base_addr = GRETH_CTRL_RST;
+*(volatile int *) base_addr = 0;
+griscv_greth_configuration.base_address = (void*)base_addr;
+griscv_greth_configuration.vector = eth_irq; /* on LEON vector is IRQ no. 
*/
+griscv_greth_configuration.txd_count = TDA_COUNT;
+griscv_greth_configuration.rxd_count = RDA_COUNT;
+rtems_greth_driver_attach(config, &griscv_greth_configuration);
+  }
+  return 0;
+}
diff --git a/bsps/shared/grlib/net/greth.c b/bsps/shared/grlib/net/greth.c
index bc4d3cc40f..2daa38e3fc 100644
--- a/bsps/shared/grlib/net/greth.c
+++ b/bsps/shared/grlib/net/greth.c
@@ -721,10 +721,13 @@ void ipalign(struct mbuf *m)
   unsigned int tmp = 0;
 
   if int) m->m_data) & 2) && (m->m_len)) {
+#if CPU_LITTLE_ENDIAN == TRUE
+memmove((caddr_t)(((int) m->m_data) + 2), m->m_data, m->m_len);
+#else
 last = (unsigned int *) int) m->m_data) + m->m_len + 8) & ~3);
 first = (unsigned int *) (((int) m->m_data) & ~3);
/* tmp = *first << 16; */
-   asm volatile (" lda [%1] 1, %0\n" : "=r"(tmp) : "r"(first) );
+   tmp = GRETH_MEM_LOAD(first);
tmp = tmp << 16;
 first++;
 do {
@@ -733,12 +736,12 @@ void ipalign(struct mbuf *m)
 ** Load with forced cache miss
 * d

Re: AW: AW: [PATCH 1/3] Remove duplicate GRETH driver

[Jiri Gaisler]

On 10/28/20 8:57 AM, gabriel.moy...@dlr.de wrote:
>> Hi Jiri,
>>
>> My understanding was that one driver version was meant to be used 
>> with
 drvmgr (greth.c) and the other without it (greth2.c). May I ask why 
 do you've chosen to remove greth.c and not greth2.c?

 I have fixed-up the greth.c file to avoid inline SPARC assembly code, 
 but the file is not used even when RTEMS is compiled with 
 --enable-drvmgr. The problem is that both greth2.c and greth.c are 
 compiled, and as they define the same symbols, greth2.c is pulled in 
 first by chance.
>  
> I think the symbols of greth.c are linked into the final binary when 
> CONFIGURE_DRIVER_AMBAPP_GAISLER_GRETH is defined (drvmgr_confdefs.h).
> I hope this helps
Thanks, this helped a lot. But I still think that compilation of greth.c
and greth2.c must be mutually exclusive since they define the same
symbols. I will follow Sebastian's advise and use the new waf system
(once I have figured it out ...).
>
 I need to disable the building of the network files 
 in bsps/shared/shared-sources.am when -- enable-drvmgr is defined. 
 Does anyone know how to do this? My skills in m4 etc. are limited ... 
 :-(

>>> If 99% of the code are the same, would it be an option to have just one 
>>> driver implementation and in the drvmgr just use a wrapper for the driver?
>> This is my idea to, but the driver manager code is sprinkled out in the file 
>> so it might take quite a few >ifdefs to fix. In any case, I still need to 
>> fix the m4 macros to detect if driver manager is defined or not ...
>
>>> Best regards,
>>>
>>> Jan
>>>
> The problem I had was that greth.c contains SPARC assembly code and 
> cannot be built on any other architecture. I will change my patch to 
> disable greth.c on non-SPARC targets or try to replace the asssembly 
> code with macros as in greth2.c. Thanks for the feedback!
>
> An other issue is that the two files are 99% identical, but only 
> greth,c seems to be maintained. PHY handling and multi-cast support 
> are areas where the files have diverged. But this is an other discussion 
> ...

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: AW: [PATCH 1/3] Remove duplicate GRETH driver

[Jiri Gaisler]

On 10/28/20 2:44 AM, jan.som...@dlr.de wrote:
>
>> -Original Message-
>> From: devel  On Behalf Of Jiri Gaisler
>> Sent: Tuesday, October 27, 2020 3:18 PM
>> To: devel@rtems.org
>> Subject: Re: AW: [PATCH 1/3] Remove duplicate GRETH driver
>>
>>
>> On 10/26/20 8:52 AM, Jiri Gaisler wrote:
>>> On 10/26/20 3:37 AM, gabriel.moy...@dlr.de wrote:
>>>> Hi Jiri,
>>>>
>>>> My understanding was that one driver version was meant to be used with
>> drvmgr (greth.c) and the other without it (greth2.c). May I ask why do you've
>> chosen to remove greth.c and not greth2.c?
>>
>> I have fixed-up the greth.c file to avoid inline SPARC assembly code, but the
>> file is not used even when RTEMS is compiled with --enable-drvmgr. The
>> problem is that both greth2.c and greth.c are compiled, and as they define
>> the same symbols, greth2.c is pulled in first by chance. I need to disable 
>> the
>> building of the network files in bsps/shared/shared-sources.am when --
>> enable-drvmgr is defined. Does anyone know how to do this? My skills in m4
>> etc. are limited ... :-(
>>
> If 99% of the code are the same, would it be an option to have just one 
> driver implementation and in the drvmgr just use a wrapper for the driver?

This is my idea to, but the driver manager code is sprinkled out in the
file so it might take quite a few ifdefs to fix. In any case, I still
need to fix the m4 macros to detect if driver manager is defined or not ...


>
> Best regards,
>
> Jan
>
>>> The problem I had was that greth.c contains SPARC assembly code and
>>> cannot be built on any other architecture. I will change my patch to
>>> disable greth.c on non-SPARC targets or try to replace the asssembly
>>> code with macros as in greth2.c. Thanks for the feedback!
>>>
>>> An other issue is that the two files are 99% identical, but only
>>> greth,c seems to be maintained. PHY handling and multi-cast support
>>> are areas where the files have diverged. But this is an other discussion ...
>>>
>>>
>>>> Thanks,
>>>> Gabriel
>>>>
>>>> -Ursprüngliche Nachricht-
>>>> Von: devel  Im Auftrag von Jiri Gaisler
>>>> Gesendet: Sonntag, 25. Oktober 2020 23:26
>>>> An: devel@rtems.org
>>>> Betreff: [PATCH 1/3] Remove duplicate GRETH driver
>>>>
>>>>* bsps/shared/net/greth2.c is being used instead
>>>> ---
>>>>  bsps/shared/grlib-sources.am  |4 -
>>>>  bsps/shared/grlib/net/README  |7 -
>>>>  bsps/shared/grlib/net/greth.c | 1655 -
>>>>  bsps/shared/grlib/net/network_interface_add.c |   62 -
>>>>  4 files changed, 1728 deletions(-)
>>>>  delete mode 100644 bsps/shared/grlib/net/README  delete mode
>> 100644
>>>> bsps/shared/grlib/net/greth.c  delete mode 100644
>>>> bsps/shared/grlib/net/network_interface_add.c
>>>>
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: AW: [PATCH 1/3] Remove duplicate GRETH driver

[Jiri Gaisler]

On 10/26/20 8:52 AM, Jiri Gaisler wrote:
> On 10/26/20 3:37 AM, gabriel.moy...@dlr.de wrote:
>> Hi Jiri,
>>
>> My understanding was that one driver version was meant to be used with 
>> drvmgr (greth.c) and the other without it (greth2.c). May I ask why do 
>> you've chosen to remove greth.c and not greth2.c?

I have fixed-up the greth.c file to avoid inline SPARC assembly code,
but the file is not used even when RTEMS is compiled with
--enable-drvmgr. The problem is that both greth2.c and greth.c are
compiled, and as they define the same symbols, greth2.c is pulled in
first by chance. I need to disable the building of the network files in
bsps/shared/shared-sources.am when --enable-drvmgr is defined. Does
anyone know how to do this? My skills in m4 etc. are limited ... :-(


>
> The problem I had was that greth.c contains SPARC assembly code and
> cannot be built on any other architecture. I will change my patch to
> disable greth.c on non-SPARC targets or try to replace the asssembly
> code with macros as in greth2.c. Thanks for the feedback!
>
> An other issue is that the two files are 99% identical, but only greth,c
> seems to be maintained. PHY handling and multi-cast support are areas
> where the files have diverged. But this is an other discussion ...
>
>
>> Thanks,
>> Gabriel
>>
>> -Ursprüngliche Nachricht-
>> Von: devel  Im Auftrag von Jiri Gaisler
>> Gesendet: Sonntag, 25. Oktober 2020 23:26
>> An: devel@rtems.org
>> Betreff: [PATCH 1/3] Remove duplicate GRETH driver
>>
>>  * bsps/shared/net/greth2.c is being used instead
>> ---
>>  bsps/shared/grlib-sources.am  |4 -
>>  bsps/shared/grlib/net/README  |7 -
>>  bsps/shared/grlib/net/greth.c | 1655 -
>>  bsps/shared/grlib/net/network_interface_add.c |   62 -
>>  4 files changed, 1728 deletions(-)
>>  delete mode 100644 bsps/shared/grlib/net/README
>>  delete mode 100644 bsps/shared/grlib/net/greth.c
>>  delete mode 100644 bsps/shared/grlib/net/network_interface_add.c
>>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: AW: [PATCH 1/3] Remove duplicate GRETH driver

[Jiri Gaisler]

On 10/26/20 3:37 AM, gabriel.moy...@dlr.de wrote:
> Hi Jiri,
>
> My understanding was that one driver version was meant to be used with drvmgr 
> (greth.c) and the other without it (greth2.c). May I ask why do you've chosen 
> to remove greth.c and not greth2.c?


The problem I had was that greth.c contains SPARC assembly code and
cannot be built on any other architecture. I will change my patch to
disable greth.c on non-SPARC targets or try to replace the asssembly
code with macros as in greth2.c. Thanks for the feedback!

An other issue is that the two files are 99% identical, but only greth,c
seems to be maintained. PHY handling and multi-cast support are areas
where the files have diverged. But this is an other discussion ...


>
> Thanks,
> Gabriel
>
> -Ursprüngliche Nachricht-
> Von: devel  Im Auftrag von Jiri Gaisler
> Gesendet: Sonntag, 25. Oktober 2020 23:26
> An: devel@rtems.org
> Betreff: [PATCH 1/3] Remove duplicate GRETH driver
>
>   * bsps/shared/net/greth2.c is being used instead
> ---
>  bsps/shared/grlib-sources.am  |4 -
>  bsps/shared/grlib/net/README  |7 -
>  bsps/shared/grlib/net/greth.c | 1655 -
>  bsps/shared/grlib/net/network_interface_add.c |   62 -
>  4 files changed, 1728 deletions(-)
>  delete mode 100644 bsps/shared/grlib/net/README
>  delete mode 100644 bsps/shared/grlib/net/greth.c
>  delete mode 100644 bsps/shared/grlib/net/network_interface_add.c
>

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 2/3] Add networking support for griscv bsp

[Jiri Gaisler]

* Only GRETH device supported for now

* Fix endian problem in GRETH driver
---
 bsps/riscv/griscv/include/bsp.h   | 14 ++
 bsps/riscv/griscv/net/leon_greth.c| 59 +++
 bsps/shared/net/greth2.c  |  6 ++-
 c/src/lib/libbsp/riscv/griscv/Makefile.am |  6 +++
 4 files changed, 84 insertions(+), 1 deletion(-)
 create mode 100644 bsps/riscv/griscv/net/leon_greth.c

diff --git a/bsps/riscv/griscv/include/bsp.h b/bsps/riscv/griscv/include/bsp.h
index 95cccd3d0a..b0d72475cc 100644
--- a/bsps/riscv/griscv/include/bsp.h
+++ b/bsps/riscv/griscv/include/bsp.h
@@ -75,6 +75,20 @@ extern void BSP_shared_interrupt_mask(int irq);
 extern void BSP_shared_interrupt_clear(int irq);
 extern void BSP_shared_interrupt_unmask(int irq);
 
+/*
+ * Network driver configuration, use leon3 version
+ */
+struct rtems_bsdnet_ifconfig;
+extern int rtems_leon_greth_driver_attach(
+  struct rtems_bsdnet_ifconfig *config,
+  int attach
+);
+
+#define RTEMS_BSP_NETWORK_DRIVER_NAME "gr_eth1"
+#define RTEMS_BSP_NETWORK_DRIVER_ATTACH rtems_leon_greth_driver_attach
+#define GRETH_SUPPORTED
+#define CPU_U32_FIX
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/bsps/riscv/griscv/net/leon_greth.c 
b/bsps/riscv/griscv/net/leon_greth.c
new file mode 100644
index 00..eb5dedd413
--- /dev/null
+++ b/bsps/riscv/griscv/net/leon_greth.c
@@ -0,0 +1,59 @@
+/*
+ *  LEON3 Opencores Ethernet MAC Configuration Information
+ *
+ *  COPYRIGHT (c) 2004.
+ *  Gaisler Research
+ *
+ *  The license and distribution terms for this file may be
+ *  found in the file LICENSE in this distribution or at
+ *  http://www.rtems.org/license/LICENSE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+/*#if (GRETH_DEBUG & GRETH_DEBUG_PRINT_REGISTERS)*/
+#include 
+/*#endif*/
+
+/*
+ * Default sizes of transmit and receive descriptor areas
+ */
+#define RDA_COUNT 32
+#define TDA_COUNT 32
+
+greth_configuration_t leon_greth_configuration;
+
+int rtems_leon_greth_driver_attach(
+  struct rtems_bsdnet_ifconfig *config,
+  int attach
+)
+{
+  unsigned int base_addr = 0; /* avoid warnings */
+  unsigned int eth_irq = 0;   /* avoid warnings */
+  struct ambapp_dev *adev;
+  struct ambapp_apb_info *apb;
+
+  /* Scan for MAC AHB slave interface */
+  adev = (void *)ambapp_for_each(&ambapp_plb, (OPTIONS_ALL|OPTIONS_APB_SLVS),
+ VENDOR_GAISLER, GAISLER_ETHMAC,
+ ambapp_find_by_idx, NULL);
+  if (adev) {
+apb = DEV_TO_APB(adev);
+base_addr = apb->start;
+eth_irq = apb->irq;
+
+/* clear control register and reset NIC */
+*(volatile int *) base_addr = 0;
+*(volatile int *) base_addr = GRETH_CTRL_RST;
+*(volatile int *) base_addr = 0;
+leon_greth_configuration.base_address = (void*)base_addr;
+leon_greth_configuration.vector = eth_irq; /* on LEON vector is IRQ no. */
+leon_greth_configuration.txd_count = TDA_COUNT;
+leon_greth_configuration.rxd_count = RDA_COUNT;
+rtems_greth_driver_attach(config, &leon_greth_configuration);
+  }
+  return 0;
+}
diff --git a/bsps/shared/net/greth2.c b/bsps/shared/net/greth2.c
index 2fc35a5471..13bf7b8884 100644
--- a/bsps/shared/net/greth2.c
+++ b/bsps/shared/net/greth2.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -514,6 +515,9 @@ void ipalign(struct mbuf *m)
   unsigned int tmp;
 
   if int) m->m_data) & 2) && (m->m_len)) {
+#if CPU_LITTLE_ENDIAN == TRUE
+memmove((caddr_t)(((int) m->m_data) + 2), m->m_data, m->m_len);
+#else
 last = (unsigned int *) int) m->m_data) + m->m_len + 8) & ~3);
 first = (unsigned int *) (((int) m->m_data) & ~3);
 tmp = GRETH_MEM_LOAD(first);
@@ -529,7 +533,7 @@ void ipalign(struct mbuf *m)
   tmp = data << 16;
   first++;
 } while (first <= last);
-
+#endif
 m->m_data = (caddr_t)(((int) m->m_data) + 2);
   }
 }
diff --git a/c/src/lib/libbsp/riscv/griscv/Makefile.am 
b/c/src/lib/libbsp/riscv/griscv/Makefile.am
index e04598e4bf..221255d0c7 100644
--- a/c/src/lib/libbsp/riscv/griscv/Makefile.am
+++ b/c/src/lib/libbsp/riscv/griscv/Makefile.am
@@ -64,6 +64,12 @@ if HAS_SMP
 librtemsbsp_a_SOURCES += ../../../../../../bsps/riscv/griscv/start/bspsmp.c
 endif
 
+if HAS_NETWORKING
+if !HAS_SMP
+librtemsbsp_a_SOURCES += ../../../../../../bsps/riscv/griscv/net/leon_greth.c
+endif
+endif
+
 include $(srcdir)/../../../../../../bsps/shared/irq-sources.am
 include $(srcdir)/../../../../../../bsps/shared/grlib-sources.am
 include $(srcdir)/../../../../../../bsps/shared/shared-sources.am
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 0/3] RISC-V/griscv networking support

[Jiri Gaisler]

These patches add networking support to the RISC-V/griscv bsp.
Also a seemingly redundant GRETH driver is removed. Feedback on
the removal would be appreciated.

Jiri Gaisler (3):
  Remove duplicate GRETH driver
  Add networking support for griscv bsp
  The leon3 bsp should define CPU_U32_FIX

 bsps/riscv/griscv/include/bsp.h   |   14 +
 bsps/riscv/griscv/net/leon_greth.c|   59 +
 bsps/shared/grlib-sources.am  |4 -
 bsps/shared/grlib/net/README  |7 -
 bsps/shared/grlib/net/greth.c | 1655 -
 bsps/shared/grlib/net/network_interface_add.c |   62 -
 bsps/shared/net/greth2.c  |6 +-
 bsps/sparc/leon3/include/bsp.h|1 +
 c/src/lib/libbsp/riscv/griscv/Makefile.am |6 +
 9 files changed, 85 insertions(+), 1729 deletions(-)
 create mode 100644 bsps/riscv/griscv/net/leon_greth.c
 delete mode 100644 bsps/shared/grlib/net/README
 delete mode 100644 bsps/shared/grlib/net/greth.c
 delete mode 100644 bsps/shared/grlib/net/network_interface_add.c

-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 1/3] Remove duplicate GRETH driver

[Jiri Gaisler]

* bsps/shared/net/greth2.c is being used instead
---
 bsps/shared/grlib-sources.am  |4 -
 bsps/shared/grlib/net/README  |7 -
 bsps/shared/grlib/net/greth.c | 1655 -
 bsps/shared/grlib/net/network_interface_add.c |   62 -
 4 files changed, 1728 deletions(-)
 delete mode 100644 bsps/shared/grlib/net/README
 delete mode 100644 bsps/shared/grlib/net/greth.c
 delete mode 100644 bsps/shared/grlib/net/network_interface_add.c

diff --git a/bsps/shared/grlib-sources.am b/bsps/shared/grlib-sources.am
index 512a48c7f7..2261eb957f 100644
--- a/bsps/shared/grlib-sources.am
+++ b/bsps/shared/grlib-sources.am
@@ -34,10 +34,6 @@ librtemsbsp_a_SOURCES += 
../../../../../../bsps/shared/grlib/iommu/griommu.c
 librtemsbsp_a_SOURCES += ../../../../../../bsps/shared/grlib/irq/genirq.c
 librtemsbsp_a_SOURCES += ../../../../../../bsps/shared/grlib/l2c/l2c.c
 librtemsbsp_a_SOURCES += ../../../../../../bsps/shared/grlib/mem/mctrl.c
-if HAS_NETWORKING
-librtemsbsp_a_SOURCES += ../../../../../../bsps/shared/grlib/net/greth.c
-librtemsbsp_a_SOURCES += 
../../../../../../bsps/shared/grlib/net/network_interface_add.c
-endif
 librtemsbsp_a_SOURCES += ../../../../../../bsps/shared/grlib/pci/gr_701.c
 librtemsbsp_a_SOURCES += ../../../../../../bsps/shared/grlib/pci/grpci2.c
 librtemsbsp_a_SOURCES += ../../../../../../bsps/shared/grlib/pci/grpci2dma.c
diff --git a/bsps/shared/grlib/net/README b/bsps/shared/grlib/net/README
deleted file mode 100644
index 3ef086f223..00
--- a/bsps/shared/grlib/net/README
+++ /dev/null
@@ -1,7 +0,0 @@
-A non Driver Manager GRETH driver is located in libchip/network/greth.c. This
-version requires the driver manager.
-
-network_interface_add is used to assign IP/NETMASK and MAC address to
-GRETH interfaces dynamically according to in which order devices are
-registered. The function takes the settings from the user defined
-interface_configs[] array, defined in the project configuration.
diff --git a/bsps/shared/grlib/net/greth.c b/bsps/shared/grlib/net/greth.c
deleted file mode 100644
index bc4d3cc40f..00
--- a/bsps/shared/grlib/net/greth.c
+++ /dev/null
@@ -1,1655 +0,0 @@
-/*
- * Gaisler Research ethernet MAC driver
- * adapted from Opencores driver by Marko Isomaki
- *
- *  The license and distribution terms for this file may be
- *  found in found in the file LICENSE in this distribution or at
- *  http://www.rtems.org/license/LICENSE.
- *
- *
- *  2008-12-10, Converted to driver manager and added support for
- *  multiple GRETH cores. 
- *  2007-09-07, Ported GBIT support from 4.6.5
- */
-
-#include 
-
-#include 
-#define CPU_U32_FIX
-#include 
-
-#ifdef GRETH_SUPPORTED
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#ifdef malloc
-#undef malloc
-#endif
-#ifdef free
-#undef free
-#endif
-
-#include 
-
-#if defined(__m68k__)
-extern m68k_isr_entry set_vector( rtems_isr_entry, rtems_vector_number, int );
-#else
-extern rtems_isr_entry set_vector( rtems_isr_entry, rtems_vector_number, int );
-#endif
-
-
-/* #define GRETH_DEBUG */
-
-#ifdef GRETH_DEBUG
-#define DBG(args...) printk(args)
-#else
-#define DBG(args...)
-#endif
-
-/* #define GRETH_DEBUG_MII */
-
-#ifdef GRETH_DEBUG_MII
-#define MIIDBG(args...) printk(args)
-#else
-#define MIIDBG(args...)
-#endif
-
-#ifdef CPU_U32_FIX
-extern void ipalign(struct mbuf *m);
-#endif
-
-/* Used when reading from memory written by GRETH DMA unit */
-#ifndef GRETH_MEM_LOAD
-#define GRETH_MEM_LOAD(addr) (*(volatile unsigned int *)(addr))
-#endif
-
-/*
- * Number of OCs supported by this driver
- */
-#define NOCDRIVER  1
-
-/*
- * Receive buffer size -- Allow for a full ethernet packet including CRC
- */
-#define RBUF_SIZE 1518
-
-#defineET_MINLEN 64/* minimum message length */
-
-/*
- * RTEMS event used by interrupt handler to signal driver tasks.
- * This must not be any of the events used by the network task synchronization.
- */
-#define INTERRUPT_EVENTRTEMS_EVENT_1
-
-/*
- * RTEMS event used to start transmit daemon.
- * This must not be the same as INTERRUPT_EVENT.
- */
-#define START_TRANSMIT_EVENT   RTEMS_EVENT_2
-
- /* event to send when tx buffers become available */
-#define GRETH_TX_WAIT_EVENT  RTEMS_EVENT_3
-
-#if (MCLBYTES < RBUF_SIZE)
-# error "Driver must have MCLBYTES > RBUF_SIZE"
-#endif
-
-/* 4s Autonegotiation Timeout */
-#ifndef GRETH_AUTONEGO_TIMEOUT_MS
-#define GRETH_AUTONEGO_TIMEOUT_MS 4000
-#endif
-const struct timespec greth_tan = {
-   GRETH_AUTONEGO_TIMEOUT_MS/1000,
-   (GRETH_AUTONEGO_TIMEOUT_MS % 1000) * 100
-};
-
-/* For optimizing the autonegotiation time */
-#define GRETH_AUTONEGO_PRINT_TIME
-
-/* Ethernet buffer descriptor */
-
-typedef struct _greth_rxtxdesc {
-   volatile uint32_t ctrl; /* Length and status */
-   uint32_t *addr

[PATCH 3/3] The leon3 bsp should define CPU_U32_FIX

[Jiri Gaisler]

* CPU_U32_FIX needed to avoid unaligned data access trap
  in network stack.
---
 bsps/sparc/leon3/include/bsp.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bsps/sparc/leon3/include/bsp.h b/bsps/sparc/leon3/include/bsp.h
index 85730b5e20..a4060385c8 100644
--- a/bsps/sparc/leon3/include/bsp.h
+++ b/bsps/sparc/leon3/include/bsp.h
@@ -94,6 +94,7 @@ extern int rtems_leon_greth_driver_attach(
 #endif
 
 #define HAS_SMC9
+#define CPU_U32_FIX
 
 /* Configure GRETH driver */
 #define GRETH_SUPPORTED
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Updated network-demos ...?

[Jiri Gaisler]

Does anyone have more a updated version of network-demos than what is in 
https://git.rtems.org/network-demos/ ?

This version does not compile fully with RTEMS-6 and seems to be rather 
outdated.

If not, then I will try to fix the issues - just want to check if someone has 
already done this.

Jiri.

(I am trying to add network support to sis, so I need some test software ...)




___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: dl06 fails to build for RISC-V (griscv bsp)

[Jiri Gaisler]

On 9/7/20 10:44 AM, Hesham Almatary wrote:
> I have only made sure rap builds when I added libdl support for
> RISC-V. But I haven't tested it on run-time, only ELF objects. It's
> likely to have been failing in run-time all along. Also, there are a
> few relocations still to be implemented for ELF like PCREL_LO12_X and
> RELAX. I got around that by passing -mno-relax

Very interesting! I applied -mno-relax when building dl06, and the error then 
changed to:

error: rap::object: Section index '0' not found: 
/home/jiri/src/rtems/6/bin/../lib/gcc/riscv-rtems6/10.2.1/../../../../riscv-rtems6/lib/rv32imafd/ilp32d/libm.a:lib_a-e_atan2.o@709534

Does this indicate that newlib must be build with -mno-relax? If so, maybe we 
should disable the dlxx tests for RISC-V ..?


>
> On Sun, 6 Sep 2020 at 19:50, Jiri Gaisler  wrote:
>> I re-applied your patch and dl06 builds again, but the dl06.exe program 
>> fails. I have updated the ticket:
>>
>> https://devel.rtems.org/ticket/4069#no2
>>
>>
>> On 9/6/20 10:12 AM, Hesham Almatary wrote:
>>> That's the same as [1]. I've seen that error before and (thought I)
>>> fixed it [2], but not sure what has changed since then.
>>>
>>> [1] https://lists.rtems.org/pipermail/devel/2020-August/061717.html
>>> [2] 
>>> https://github.com/RTEMS/rtems-tools/commit/e6e610d262940b7651157597b6b1406aa806b4d1
>>>
>>> On Sun, 6 Sep 2020 at 09:14, Chris Johns  wrote:
>>>> On 6/9/20 6:32 am, Jiri Gaisler wrote:
>>>>> I have updated both RTEMS and RSB to git head, and dl06 now fails to 
>>>>> build:
>>>>>
>>>>> riscv-rtems6-g++ -march=rv32imafd -mabi=ilp32d -O2 -g -ffunction-sections 
>>>>> -fdata-sections -Wall  -Wl,--gc-sections  -march=rv32imafd 
>>>>> -mabi=ilp32d  -B./../../lib/libbsp/riscv/griscv 
>>>>> -B/home/jiri/ibm/src/rtems/rtems/bsps/riscv/griscv/start -specs bsp_specs 
>>>>> -qrtems -L./../../cpukit 
>>>>> -L/home/jiri/ibm/src/rtems/rtems/bsps/riscv/shared/start 
>>>>> -Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar -o dl05.exe 
>>>>> dl05/dl05-init.o dl05/dl05-dl-load.o dl05/dl05-dl-cpp.o dl05-dl05-tar.o 
>>>>> ../../lib/libbsp/riscv/griscv/librtemsbsp.a ../../cpukit/librtemscpu.a 
>>>>> ../../cpukit/librtemstest.a dl05-sym.o
>>>> This is dl05 and I do not think it is related to the issue.
>>>>
>>>>> rtems-ld -r /home/jiri/src/rtems/riscvmp/riscv-rtems6/c/griscv \
>>>>>   -C riscv-rtems6-gcc -c "-march=rv32imafd -mabi=ilp32d" \
>>>>>   -O rap -b dl06.pre -e rtems_main -s \
>>>>>   -o dl06.rap dl06-o1.o dl06-o2.o -lm
>>>>> error: rap::object: Section index '0' not found: dl06-o1.o
>>>>> Makefile:8528: recipe for target 'dl06.rap' failed
>>>>> make[5]: *** [dl06.rap] Error 10
>>>> This looks like something in rtems-ld in the rtems-tools.git repo.
>>>>
>>>>> It seems like dl06-o1.o not built but a link is attempted - is dl06 
>>>>> supposed to be enabled or disabled for RISC-V ?
>>>> Enabled but it seems something has changed to cause the test to not link. I
>>>> wonder if a tool upgrade is the reason. I have raised ..
>>>>
>>>> https://devel.rtems.org/ticket/4069
>>>>
>>>> Chris
>>>> ___
>>>> devel mailing list
>>>> devel@rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RTEMS Project] #4069: dl06 does not link on RISCV

[Jiri Gaisler]

On 9/6/20 11:12 PM, RTEMS trac wrote:
> #4069: dl06 does not link on RISCV
> -+-
>  Reporter:  Chris Johns  |   Owner:  Hesham Almatary
>  |  
>  Type:  defect   |  Status:  closed
>  Priority:  normal   |   Milestone:  6.1
> Component:  tool | Version:  6
>  Severity:  normal   |  Resolution:  fixed
>  Keywords:   |  Blocked By:
>  Blocking:   |
> -+-
> Changes (by Hesham Almatary ):
>
>  * owner:  (none) => Hesham Almatary 
>  * status:  new => closed
>  * resolution:   => fixed
>
>
> Comment:
>
>  In [changeset:"764ea5787926ee50d2c1df8db2eede5d31e427eb/rtems"
>  764ea578/rtems]:
>  {{{
>  #!CommitTicketReference repository="rtems"
>  revision="764ea5787926ee50d2c1df8db2eede5d31e427eb"
>  htif_console_handler is defined in htif.c
>
>  closes #4069.
>  }}}
>
> --
> Ticket URL: 
> RTEMS Project 
> RTEMS Project


This fix does not solve the problems for the griscv BSP. Note that htif.c is 
not used at all in griscv. Below is a verbose trace from rtems-ld, maybe 
somebody with more insight than me could look at it ...

rtems-ld -r /home/jiri/src/rtems/riscvmp/riscv-rtems6/c/griscv -C 
riscv-rtems6-gcc -c -march=rv32imafd -mabi=ilp32d -O rap -b dl06.pre -e 
rtems_main -s -o dl06.rap dl06-o1.o dl06-o2.o -lm -v
base-image: dl06.pre
cache:load-sym: object files: 1
cache:load-sym: symbols: 1046
Finding libraries:
 found: 
/home/jiri/src/rtems/6/bin/../lib/gcc/riscv-rtems6/10.2.1/../../../../riscv-rtems6/lib/rv32imafd/ilp32d/libm.a
cc::stdlib: libgcc.a
cc::stdlib: libssp.a
cc::stdlib: libc.a
cache:load-sym: object files: 1215
cache:load-sym: symbols: 1568
resolver:resolving:  undefines, unresolved: 1
resolver:resolve  :    |- rtems_main
resolver:resolved :    |   `--> dl06-o1.o (unresolved: 1)
resolver:resolved :    +-- referenced objects: 1
resolver:resolving:  ] undefines ==> dl06-o1.o
resolver:resolving:  dl06-o1.o, unresolved: 5
resolver:resolve  : |- dl_o2_func2
resolver:resolved : |   `--> dl06-o2.o (unresolved: 1)
resolver:resolve  : |- dl_o2_func3
resolver:resolved : |   `--> dl06-o2.o (unresolved: 2)
resolver:resolve  : |- dlsym
resolver:resolved : |   `--> dl06.pre (base)
resolver:resolve  : |- rtems_printf
resolver:resolved : |   `--> dl06.pre (base)
resolver:resolve  : |- rtems_test_printer
resolver:resolved : |   `--> dl06.pre (base)
resolver:resolved : +-- referenced objects: 1
resolver:resolving:   ] dl06-o1.o ==> dl06-o2.o
resolver:resolving:   dl06-o2.o, unresolved: 5
resolver:resolve  :  |- atan2
resolver:resolved :  |   `--> libm.a:lib_a-w_atan2.o@3274774 (unresolved: 1)
resolver:resolve  :  |- lcong48
resolver:resolved :  |   `--> libc.a:lib_a-lcong48.o@5312728 (unresolved: 2)
resolver:resolve  :  |- rtems_printf
resolver:resolved :  |   `--> dl06.pre (base)
resolver:resolve  :  |- rtems_test_printer
resolver:resolved :  |   `--> dl06.pre (base)
resolver:resolve  :  |- tan
resolver:resolved :  |   `--> libm.a:lib_a-s_tan.o@2659846 (unresolved: 3)
resolver:resolved :  +-- referenced objects: 3
resolver:resolving:    ] dl06-o2.o ==> libm.a:lib_a-w_atan2.o@3274774
resolver:resolving:    libm.a:lib_a-w_atan2.o@3274774, unresolved: 1
resolver:resolve  :   |- __ieee754_atan2
resolver:resolved :   |   `--> libm.a:lib_a-e_atan2.o@709534 (unresolved: 1)
resolver:resolved :   +-- referenced objects: 1
resolver:resolving: ] libm.a:lib_a-w_atan2.o@3274774 ==> 
libm.a:lib_a-e_atan2.o@709534
resolver:resolving: libm.a:lib_a-e_atan2.o@709534, unresolved: 2
resolver:resolve  :    |- atan
resolver:resolved :    |   `--> libm.a:lib_a-s_atan.o@2142850 (unresolved: 
1)
resolver:resolve  :    |- fabs
resolver:resolved :    |   `--> libm.a:lib_a-s_fabs.o@2300458 (unresolved: 
2)
resolver:resolved :    +-- referenced objects: 2
resolver:resolving:  ] libm.a:lib_a-e_atan2.o@709534 ==> 
libm.a:lib_a-s_atan.o@2142850
resolver:resolving:  libm.a:lib_a-s_atan.o@2142850, unresolved: 1
resolver:resolve  : |- fabs
resolver:resolved : |   `--> libm.a:lib_a-s_fabs.o@2300458 (unresolved: 
1)
resolver:resolved : +-- referenced objects: 1
resolver:resolving:   ] libm.a:lib_a-s_atan.o@2142850 ==> 
libm.a:lib_a-s_fabs.o@2300458
resolver:resolving:   libm.a:lib_a-s_fabs.o@2300458, unresolved: 0
resolver:resolved :  +-- referenced objects: 0
resolver:resolving:  ] libm.a:lib_a-e_atan2.o@709534 ==> 
libm.a:lib_a-s_fabs.o@2300458
resolver:resolving:  libm.a:lib_a-s_fabs.o@2300458 is resolved or resolving
resolver:resolving: ] dl06-o2.o ==> libc.a:lib_a-lcong48.o@5312728
resolver:resolving: libc.a:lib_a-lcong48.o@5312728, unresolved: 1
resolver:resolve  :

Tftp patch to rtems-tools breaks compilation (on ubuntu 18.04 x64)

[Jiri Gaisler]

jiri@office:~/ibm/src/rtems/rtems-tools$ ./waf configure --prefix=/opt/rtems/6
Setting top to   : /home/jiri/ibm/src/rtems/rtems-tools
Setting out to   : 
/home/jiri/ibm/src/rtems/rtems-tools/build
Version  : 6.eb3608133b41 (6)
Checking for program 'python'    : /usr/bin/python
Checking for python version >= 2.6.6 : 2.7.17
Checking for program 'python'    : /usr/bin/python
Checking for program 'python2'   : /usr/bin/python2
Checking for program 'python3'   : /usr/bin/python3
Checking for 'gcc' (C compiler)  : /usr/bin/gcc
Checking for 'g++' (C++ compiler)    : /usr/bin/g++
Checking for header alloca.h : yes
Checking for header fcntl.h  : yes
Checking for header process.h    : not found
Checking for header stdlib.h : yes
Checking for header string.h : yes
Checking for header strings.h    : yes
Checking for header sys/file.h   : yes
Checking for header sys/stat.h   : yes
Checking for header sys/time.h   : yes
Checking for header sys/types.h  : yes
Checking for header sys/wait.h   : yes
Checking for header unistd.h : yes
Checking for header vfork.h  : not found
Checking for getrusage   : yes
Checking for program 'm4'    : /usr/bin/m4
Checking for header sys/wait.h   : yes
Checking for kill    : yes
Checking for 'gcc' (C compiler)  : /usr/bin/gcc
Checking for 'g++' (C++ compiler)    : /usr/bin/g++
Checking for 'gcc' (C compiler)  : /usr/bin/gcc
Checking for strnlen : yes
Checking for 'g++' (C++ compiler)    : /usr/bin/g++
Checking for fopen64 : no
Checking for stat64  : no
Checking for 'gcc' (C compiler)  : /usr/bin/gcc
Checking for 'g++' (C++ compiler)    : /usr/bin/g++
Checking for library LLVM    : not found
Checking for header zlib.h   : yes
Checking for library z   : yes
Checking for library ws2_32  : not found
Checking for compiler flags -std=c++14   : yes
'configure' finished successfully (0.916s)
jiri@office:~/ibm/src/rtems/rtems-tools$ ./waf build
Waf: Entering directory `/home/jiri/ibm/src/rtems/rtems-tools/build'
Waf: Leaving directory `/home/jiri/ibm/src/rtems/rtems-tools/build'
source not found: 'rt/tftpy/__init__.py' in bld(target='', idx=3, 
tg_idx_count=42, meths=['feature_py', 'process_rule', 'process_source'], 
install_path='${PREFIX}/share/rtems/tester', _name='', 
source=['rt/tftpy/__init__.py', 'rt/tftpy/TftpClient.py', 
'rt/tftpy/TftpContexts.py', 'rt/tftpy/TftpPacketFactory.py', 
'rt/tftpy/TftpPacketTypes.py', 'rt/tftpy/TftpServer.py', 
'rt/tftpy/TftpShared.py', 'rt/tftpy/TftpStates.py'], 
path=/home/jiri/ibm/src/rtems/rtems-tools/tester, 
install_from=/home/jiri/ibm/src/rtems/rtems-tools/tester, posted=True, 
features=['py']) in /home/jiri/ibm/src/rtems/rtems-tools/tester


Going back one commit builds without issues ...

Jiri.


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: dl06 fails to build for RISC-V (griscv bsp)

[Jiri Gaisler]

I re-applied your patch and dl06 builds again, but the dl06.exe program fails. 
I have updated the ticket:

https://devel.rtems.org/ticket/4069#no2


On 9/6/20 10:12 AM, Hesham Almatary wrote:
> That's the same as [1]. I've seen that error before and (thought I)
> fixed it [2], but not sure what has changed since then.
>
> [1] https://lists.rtems.org/pipermail/devel/2020-August/061717.html
> [2] 
> https://github.com/RTEMS/rtems-tools/commit/e6e610d262940b7651157597b6b1406aa806b4d1
>
> On Sun, 6 Sep 2020 at 09:14, Chris Johns  wrote:
>> On 6/9/20 6:32 am, Jiri Gaisler wrote:
>>> I have updated both RTEMS and RSB to git head, and dl06 now fails to build:
>>>
>>> riscv-rtems6-g++ -march=rv32imafd -mabi=ilp32d -O2 -g -ffunction-sections 
>>> -fdata-sections -Wall  -Wl,--gc-sections  -march=rv32imafd -mabi=ilp32d 
>>>  -B./../../lib/libbsp/riscv/griscv 
>>> -B/home/jiri/ibm/src/rtems/rtems/bsps/riscv/griscv/start -specs bsp_specs 
>>> -qrtems -L./../../cpukit 
>>> -L/home/jiri/ibm/src/rtems/rtems/bsps/riscv/shared/start -Wl,--wrap=printf 
>>> -Wl,--wrap=puts -Wl,--wrap=putchar -o dl05.exe dl05/dl05-init.o 
>>> dl05/dl05-dl-load.o dl05/dl05-dl-cpp.o dl05-dl05-tar.o 
>>> ../../lib/libbsp/riscv/griscv/librtemsbsp.a ../../cpukit/librtemscpu.a 
>>> ../../cpukit/librtemstest.a dl05-sym.o
>> This is dl05 and I do not think it is related to the issue.
>>
>>> rtems-ld -r /home/jiri/src/rtems/riscvmp/riscv-rtems6/c/griscv \
>>>   -C riscv-rtems6-gcc -c "-march=rv32imafd -mabi=ilp32d" \
>>>   -O rap -b dl06.pre -e rtems_main -s \
>>>   -o dl06.rap dl06-o1.o dl06-o2.o -lm
>>> error: rap::object: Section index '0' not found: dl06-o1.o
>>> Makefile:8528: recipe for target 'dl06.rap' failed
>>> make[5]: *** [dl06.rap] Error 10
>> This looks like something in rtems-ld in the rtems-tools.git repo.
>>
>>> It seems like dl06-o1.o not built but a link is attempted - is dl06 
>>> supposed to be enabled or disabled for RISC-V ?
>> Enabled but it seems something has changed to cause the test to not link. I
>> wonder if a tool upgrade is the reason. I have raised ..
>>
>> https://devel.rtems.org/ticket/4069
>>
>> Chris
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

dl06 fails to build for RISC-V (griscv bsp)

[Jiri Gaisler]

I have updated both RTEMS and RSB to git head, and dl06 now fails to build:

riscv-rtems6-g++ -march=rv32imafd -mabi=ilp32d -O2 -g -ffunction-sections 
-fdata-sections -Wall  -Wl,--gc-sections  -march=rv32imafd -mabi=ilp32d  
-B./../../lib/libbsp/riscv/griscv 
-B/home/jiri/ibm/src/rtems/rtems/bsps/riscv/griscv/start -specs bsp_specs 
-qrtems -L./../../cpukit 
-L/home/jiri/ibm/src/rtems/rtems/bsps/riscv/shared/start -Wl,--wrap=printf 
-Wl,--wrap=puts -Wl,--wrap=putchar -o dl05.exe dl05/dl05-init.o 
dl05/dl05-dl-load.o dl05/dl05-dl-cpp.o dl05-dl05-tar.o 
../../lib/libbsp/riscv/griscv/librtemsbsp.a ../../cpukit/librtemscpu.a 
../../cpukit/librtemstest.a dl05-sym.o
rtems-ld -r /home/jiri/src/rtems/riscvmp/riscv-rtems6/c/griscv \
  -C riscv-rtems6-gcc -c "-march=rv32imafd -mabi=ilp32d" \
  -O rap -b dl06.pre -e rtems_main -s \
  -o dl06.rap dl06-o1.o dl06-o2.o -lm
error: rap::object: Section index '0' not found: dl06-o1.o
Makefile:8528: recipe for target 'dl06.rap' failed
make[5]: *** [dl06.rap] Error 10

It seems like dl06-o1.o not built but a link is attempted - is dl06 supposed to 
be enabled or disabled for RISC-V ?

Jiri.


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Need help to execute/debug smpschededf02.exe on leon3

[Jiri Gaisler]

Note that single-stepping of smp code at instruction-level might affect the 
timing of the execution. During single-stepping, only one core is advanced 
while the others stay halted. If you are trying to catch a race condition then 
the timing impact might change the program behavior. Shorter bursts of 
single-stepping will usually not have any side-effect as the default execution 
slot for each cpu is 50 clocks, but it might be good be aware of this behavior 
...

Jiri.

On 7/2/20 10:32 AM, Richi Dubey wrote:
> Yeah, this makes a lot of sense.
> Mr. Huber also told me a similar story about qemu using -O0 optimizations 
> which are easier to debug. 
>
> Thank you.
>
> On Wed, Jul 1, 2020 at 8:03 PM Gedare Bloom  <mailto:ged...@rtems.org>> wrote:
>
> On Wed, Jul 1, 2020 at 5:32 AM Richi Dubey  <mailto:richidu...@gmail.com>> wrote:
> >
> > Dear Dr. Gaisler,
> >
> > There's something that I am getting stuck at while trying to debug an 
> smp03 (https://git.rtems.org/rtems/tree/testsuites/smptests/smp03/init.c) 
> test suite with gdb running on sis.
> >
> > I started sis with the command:
> > 
> ---
> >
> > $ ./sparc-rtems5-sis -leon3 -m 4 -gdb
> >
> >  SIS - SPARC/RISCV instruction simulator 2.21,  copyright Jiri Gaisler 
> 2019
> >  Bug-reports to j...@gaisler.se <mailto:j...@gaisler.se>
> >
> >  LEON3 emulation enabled, 4 cpus online, delta 50 clocks
> >
> > gdb: listening on port 1234
> > 
> ---
> > and gdb with the command:
> >
> > 
> ---
> > $ ./sparc-rtems5-gdb 
> ~/quick-start/build/b-smp-leon3/sparc-rtems5/c/leon3/testsuites/smptests/smp03.exe
> > .
> > .
> > .
> > Reading symbols from 
> /home/richi/quick-start/build/b-smp-leon3/sparc-rtems5/c/leon3/testsuites/smptests/smp03.exe...
> > (gdb) target extended-remote localhost:1234
> > Remote debugging using localhost:1234
> > 0x in ?? ()
> > (gdb) load
> > Loading section .text, size 0x20440 lma 0x4000
> > Loading section .rtemsroset, size 0x90 lma 0x40020440
> > Loading section .data, size 0x690 lma 0x40028500
> > Start address 0x4000, load size 133984
> > Transfer rate: 1063 KB/sec, 271 bytes/write.
> > (gdb) b _Scheduler_EDF_SMP_Get_highest_ready
> > Breakpoint 1 at 0x4000e620: _Scheduler_EDF_SMP_Get_highest_ready. (4 
> locations)
> > (gdb) continue
> > Continuing.
> >
> > Breakpoint 1, _Scheduler_EDF_SMP_Get_highest_ready (filter=0x40029000 
> <_RTEMS_tasks_Objects+576>,
> >     context=0x4002bc28 <_Configuration_Scheduler_EDF_SMP_dflt>)
> >     at 
> /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/scheduleredfsmp.c:151
> > 151  self = _Scheduler_EDF_SMP_Get_self( context );
> > (gdb) stepi
> > 0x4000e624 151  self = _Scheduler_EDF_SMP_Get_self( context );
> > (gdb) stepi
> > RBTree_Control_RB_MINMAX (val=-1, head=head@entry=0x4002bc74 
> <_Configuration_Scheduler_EDF_SMP_dflt+76>)
> >     at 
> /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/rbtreenext.c:37
> > 37 {
> > (gdb) stepi
> > 0x4001787c 37 {
> > (gdb) stepi
> > 0x40017880 37 {
> > (gdb) stepi
> > 0x40017884 37 {
> > (gdb) stepi
> > 0x40017890 37 {
> > (gdb) stepi
> > 0x40017894 37 {
> > (gdb) stepi
> > _RBTree_Minimum (tree=tree@entry=0x4002bc74 
> <_Configuration_Scheduler_EDF_SMP_dflt+76>)
> >     at 
> /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/rbtreenext.c:39
> > 39 }
> > (gdb) stepi
> > 0x400178a0 39 }
> > (gdb) stepi
> > 0x400178a4 39 }
> > (gdb) stepi
> > 0x400178a8 39 }
> > (gdb) stepi
> > 0x4000e628 in _Scheduler_EDF_SMP_Get_highest_ready (filter=0x40029000 
> <_RTEMS_tasks_Objects+576>,
> >     context=0x4002bc28 <_Configuration_Scheduler_EDF_SMP_dflt>)
> >     at 
> /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/scheduleredfsmp.c:151
> > 151  self = _Scheduler_EDF_SMP_Get_self( context );
>

Re: Need help to execute/debug smpschededf02.exe on leon3

[Jiri Gaisler]

On 5/26/20 2:55 PM, Richi Dubey wrote:
> Hii,
>
> Thank you for your replies. I did not load the program before
> executing run on gdb. Now it works fine.
>
> However, I need your help with one more thing. When I run gdb with
> stepi or nexti to see how the code runs from the beginning to the end,
> gdb always ends up going in an infinite loop in hard_reset () at
> /home/richi/quick-start/src/rtems/c/src/lib/libbsp/sparc/leon3/../../../../../../bsps/sparc/shared/start/start.S:274
> while only executing the following commands:
>
> 371 std%g0,[%g2]
> (gdb)
> 372 add%g2,8,%g2
> (gdb)
> 373 cmp%g2,%g3
> (gdb)
> 374 bleu,a zerobss
> (gdb)
> 375 nop
>
>
> while the code in start.s is:
>
> zerobss:
> std%g0,[%g2]
> add%g2,8,%g2
> cmp%g2,%g3
> bleu,a zerobss
> nop
>
> -
>
> Can someone please tell me why gdb is not going back to the main file
> smpschededf02/init.c? Is it because we keep running start.s during the
> entire time of execution?

zerobss: function is not infinite, it just loops for many thousands (millions) 
iterations while it clears the bss segment. SIngle-stepping though zerobss: 
will obviously take a VERY long time, so put a breakpoint on somewhere after it 
has been called.


>  And how do I run gdb while going through
> every instruction that init.c processes without getting stuck in an
> infinite loop like this. I set up a breakpoint at Init and everythings
> work fine but I am stilling missing the commands that were executed
> before Init.c was called. How do I see those?
>
> Also, If I use step with breakpoint at Init, it again goes into an
> infinite loop inside apbuart_polled.c with the following commands:
>
> 20   while ( (regs->status & APBUART_STATUS_TE) == 0 ) {
> (gdb)
> 22 __asm__ volatile ("nop"::); __asm__ volatile ("nop"::);
> (gdb)
> 23 __asm__ volatile ("nop"::); __asm__ volatile ("nop"::);
> (gdb)
> 24 __asm__ volatile ("nop"::); __asm__ volatile ("nop"::);
> (gdb)
> 25 __asm__ volatile ("nop"::); __asm__ volatile ("nop"::);
>
> Why is it running into an infinite loop?(If I use nexti, it does not
> run into an infinite loop as next does get inside functions, and Init
> finishes successfully).

The loop is not infinite, it just loops while waiting for the UART transmitter 
to send out a character. nexti puts a breakpoint after the loop, that is why it 
finishes.

Jiri.


>
> Thanks,
> Richi.
>
> On Tue, May 26, 2020 at 12:44 AM Jiri Gaisler  wrote:
>>
>> On 5/25/20 4:30 PM, Richi Dubey wrote:
>>> Hii everyone,
>>>
>>> When I am executing smpschededf02.exe on my leon3 bsp running on
>>> sparc5 with  sparc-rtems5-sis with -m 4 -leon3 option, it fails to
>>> execute properly.
>>>
>>> I have built leon3 with --enable-smp option and I am guessing the
>>> execution fails because I don not see any output of the test and I can
>>> only see the following output:
>>> -
>>> ~/quick-start/rtems/5/bin$ ./sparc-rtems5-sis -leon3 -m 4
>>> ~/quick-start/build/leon3/sparc-rtems5/c/leon3/testsuites/smptests/smpschededf02.exe
>>>
>>>  SIS - SPARC/RISCV instruction simulator 2.21,  copyright Jiri Gaisler 2019
>>>  Bug-reports to j...@gaisler.se
>>>
>>>  LEON3 emulation enabled, 4 cpus online, delta 50 clocks
>>>
>>>  Loaded 
>>> /home/richi/quick-start/build/leon3/sparc-rtems5/c/leon3/testsuites/smptests/smpschededf02.exe,
>>> entry 0x4000
>>> cpu0> run
>>>
>>>
>>> *** BEGIN OF TEST SMPSCHEDEDF 2 ***
>>> *** TEST VERSION: 5.0.0.20a8361de4724658112ecd33c28fae82a15919f8
>>> *** TEST STATE: EXPECTED_PASS
>>> *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP
>>> *** TEST TOOLS: 7.5.0 20191114 (RTEMS 5, RSB 5 (0b7e87143b76), Newlib 
>>> fbaa096)
>>>
>>> *** END OF TEST SMPSCHEDEDF 2 ***
>>>
>>> cpu 1 in error mode (tt = 0x80)
>>>   3491850  40016360:  91d02000   ta  0x0
>>> ---
>> Looks good to me, test passed OK and processor is halted by RTEMS.
>>
>>
>>> On running the program with gdb with extended-remote and debugging
>>> with sis, I am encountering the following error:
>>>
>>> --
>>> (gdb) target extended-remote localhost:1234
>>> Remote debugging using localhost:1234
>>> 0x in ?? ()
>>> (gdb)
>>> 
>> This is indeed how you start remote debugging, but then you also have to do:
>>
>> load
>>
>> run
>>
>> Then the program should run as expected ...
>>
>>
>> Jiri.
>>
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Need help to execute/debug smpschededf02.exe on leon3

[Jiri Gaisler]

On 5/25/20 4:30 PM, Richi Dubey wrote:
> Hii everyone,
>
> When I am executing smpschededf02.exe on my leon3 bsp running on
> sparc5 with  sparc-rtems5-sis with -m 4 -leon3 option, it fails to
> execute properly.
>
> I have built leon3 with --enable-smp option and I am guessing the
> execution fails because I don not see any output of the test and I can
> only see the following output:
> -
> ~/quick-start/rtems/5/bin$ ./sparc-rtems5-sis -leon3 -m 4
> ~/quick-start/build/leon3/sparc-rtems5/c/leon3/testsuites/smptests/smpschededf02.exe
>
>  SIS - SPARC/RISCV instruction simulator 2.21,  copyright Jiri Gaisler 2019
>  Bug-reports to j...@gaisler.se
>
>  LEON3 emulation enabled, 4 cpus online, delta 50 clocks
>
>  Loaded 
> /home/richi/quick-start/build/leon3/sparc-rtems5/c/leon3/testsuites/smptests/smpschededf02.exe,
> entry 0x4000
> cpu0> run
>
>
> *** BEGIN OF TEST SMPSCHEDEDF 2 ***
> *** TEST VERSION: 5.0.0.20a8361de4724658112ecd33c28fae82a15919f8
> *** TEST STATE: EXPECTED_PASS
> *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP
> *** TEST TOOLS: 7.5.0 20191114 (RTEMS 5, RSB 5 (0b7e87143b76), Newlib fbaa096)
>
> *** END OF TEST SMPSCHEDEDF 2 ***
>
> cpu 1 in error mode (tt = 0x80)
>   3491850  40016360:  91d02000   ta  0x0
> ---

Looks good to me, test passed OK and processor is halted by RTEMS.


>
> On running the program with gdb with extended-remote and debugging
> with sis, I am encountering the following error:
>
> --
> (gdb) target extended-remote localhost:1234
> Remote debugging using localhost:1234
> 0x in ?? ()
> (gdb)
> 

This is indeed how you start remote debugging, but then you also have to do:

load

run

Then the program should run as expected ...


Jiri.


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Unable to complete the Hello World program

[Jiri Gaisler]

On 3/1/20 9:56 AM, Denil Verghese wrote:
> Hi,
>     I'm Denil C Verghese and I like to be a part contribute to this 
> organization as well as participate in upcoming GSoC program. I have checked 
> the Wiki entries related to GSoC. But I'm facing some error in completing the 
> quick start guide.
>
> Problem: Build failed when executing  *sb-set-builder *from this 
> 
>  page
> Log file is attached with this email.
>
> It would great if someone could help me with this issue. Thank you
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

You don't seem to have the 'cmp' command installed on your redhat system:

mv tmp2-tm.texi tmp-tm.texi
/bin/sh ../../gcc-7.5.0/gcc/../move-if-change tmp-tm.texi tm.texi
/bin/sh: cmp: command not found

make[2]: *** [Makefile:2435: s-tm-texi] Error 1
make[2]: *** Waiting for unfinished jobs

Check that you have /usr/bin/cmp, it is usually part of diffutils. If it is 
there, you must have messed up your PATH somehow ...


Jiri.


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Error in building rv32imac BSP

[Jiri Gaisler]

On 2/20/20 5:03 PM, Eshan Dhawan wrote:
>
> make[3]: Leaving directory
> '/home/eshan/development/rtems/kernel/rtems/rv32imac/riscv-rtems5/c/rv32imac'
> checking for RTEMS_CPU_MODEL...
> checking for RTEMS_BSP_FAMILY... riscv
> checking for CPU_CFLAGS... (cached) -march=rv32imac -mabi=ilp32
> checking for CFLAGS_OPTIMIZE_V... (cached) -O2 -g -ffunction-sections
> -fdata-sections
> checking for style of include used by make... GNU
> checking for riscv-rtems5-gcc... no

--^^^-


You need to have the RISC-V tool chain in the PATH. If you don't have a
tool chain, then you can build it with RSB. See the relevant docs on
rtems.org ...

Jiri.



___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Status of fenv.h header and floating point environment support in newlib

[Jiri Gaisler]

On 2/17/20 11:16 AM, Vaibhav Gupta wrote:
>
>
> On Mon, Feb 17, 2020, 3:07 PM Ayush Dwivedi <21cencturyay...@gmail.com 
> > wrote:
>
> Hello Joel,
> This is regarding the open project #2966 POSIX-Compliance #2971( Add 
> fenv.h to newlib). The task is about adding the floating point environment 
> header to the newlib library but the source code of the library already has 
> the header with the listed function declarations and data struct as needed. 
> The implementations for the following architectures are available in the 
> newlib-cygwin repository:
> >RISCV
> >i386
> >x86_64
> As pointed out in the POSIX Compliance project sub-task page the 
> implementations for following architectures are yet to be added:
> >ARM(software float implementation for this exists but no fenv 
> implementation)
> >AArch64(software float implementation for this exists but no fenv 
> implementation)
> >SPARC and SPARC64(directories for these architectures are missing from 
> libm/machine/ so no implementation of any sort)
>
> I would like to try and implement the functions declared in the header 
> using BSD libc of FreeBSD as reference for the ARM and SPARC architectures.
>
> Following is the output after running test for posix fenv 
> header(psxfenv01.exe) for SPARC using sparc-rtems5-sis and 
> sparc-rtems5-gdb.(The Test failed)
>
> Yes because testsuite needs modifications and moreover fenv on SPARC is not 
> yet supported. Since the support for RISCV and x86_64 is present, you can 
> make a testsuite for them. You can use qemu for running riscv files.

Note that sis (riscv-rtems5-sis) also supports RISCV32 using the griscv BSP in 
RTEMS.

Jiri.


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] doc/raspberrypi: Added instructions for raspberrypi

[Jiri Gaisler]

You should build devel/qemu4 with RSB, the older devel/qemu does not build on 
newer systems ...

Jiri.


On 1/12/20 4:48 PM, Niteesh wrote:
> I can't build QEMU using RSB, there seems to be a problem with GLib(see 
> attachment)
> but I had no problem building it from the source. Should I just mention build 
> qemu from
> source?
>
> On Tue, Jan 7, 2020 at 11:12 PM Niteesh  > wrote:
>
> I didn't use the QEMU build from RSB, I built it from the source directly 
> for another project
> I'll try QEMU from RSB, and will also add instructions for it in a couple 
> of days.
>
> On Tue, Jan 7, 2020 at 1:00 AM Gedare Bloom  > wrote:
>
> On Mon, Jan 6, 2020 at 11:25 AM Niteesh  > wrote:
> >
> > Do you want to add a build section or just add in a statement that 
> states "it was built
> > using xx version of RSB"?
> >
>
> Just a simple statement. Don't even  need to mention a specific
> version, if they use RSB to build QEMU it should just work, right?
>
> > On Mon, Jan 6, 2020 at 11:51 PM Gedare Bloom  > wrote:
> >>
> >> On Mon, Jan 6, 2020 at 2:47 AM Christian Mauderer 
> mailto:l...@c-mauderer.de>> wrote:
> >> >
> >> > Looks a lot better.
> >> >
> >> > On 05/01/2020 20:19, G S Niteesh wrote:
> >> > > Added instructions to run examples on raspberrypi.
> >> > > ---
> >> > >  user/bsps/arm/raspberrypi.rst | 74 
> ++-
> >> > >  1 file changed, 73 insertions(+), 1 deletion(-)
> >> > >
> >> > > diff --git a/user/bsps/arm/raspberrypi.rst 
> b/user/bsps/arm/raspberrypi.rst
> >> > > index 4ef75bd..7eccca5 100644
> >> > > --- a/user/bsps/arm/raspberrypi.rst
> >> > > +++ b/user/bsps/arm/raspberrypi.rst
> >> > > @@ -5,4 +5,76 @@
> >> > >  raspberrypi
> >> > >  ===
> >> > >
> >> > > -TODO.
> >> > > +This BSP supports `Raspberry Pi 1` and `Raspberry Pi 2` 
> currently.
> >> > > +The support for `Raspberry Pi 3` is work under progress.
> >> > > +The default bootloader on the raspberrypi which is used to 
> boot raspbian
> >> >
> >> > raspberrypi -> Raspberry Pi
> >> > raspbian -> Raspbian
> >> >
> >> > > +or other OS can be also used to boot RTEMS. U-boot can also 
> be used.
> >> > > +
> >> > > +Setup SD card
> >> > > +
> >> > > +
> >> > > +The Raspberry Pis have an unconventional booting mechanism. 
> The GPU
> >> > > +boots first, initializes itself, runs the bootloader and 
> starts the CPU.
> >> > > +The bootloader looks for a kernel image, by default the 
> kernel images must
> >> > > +have a name of the form `kernel*.img` but this can be changed 
> by adding
> >> >
> >> > Please highlight all files in the same way. Other BSPs use the 
> following
> >> > syntax:
> >> >
> >> >     The ``ticker.exe`` elf file must be translated ...
> >> >
> >> > So here it is:
> >> >
> >> > `kernel*.img` -> ``kernel*.img``
> >> >
> >> > > +`kernel=` to config.txt.
> >> >
> >> > config.txt -> ``config.txt``
> >> >
> >> > > +
> >> > > +You must provide the required files for the GPU to proceed. 
> These files
> >> > > +can be downloaded from this
> >> > > +`link 
> `_.
> >> >
> >> > I would suggest:
> >> >
> >> > ... can be downloaded from
> >> > `the Raspberry Pi Firmware Repository
> >> > `_.
> >> >
> >> > I think you shouldn't break links so if this is too long you can
> >> > exceptionally break the 80 character rule. It's done for other 
> links too.
> >> >
> >> > > +You can remove the kernel*.img if you want, but don't touch 
> the other files.
> >> >
> >> > kernel*.img -> ``kernel*.img``
> >> >
> >> > > +
> >> > > +Copy these files in to a SD card with FAT filesystem.
> >> > > +
> >> > > +Kernel image
> >> > > +
> >> > > +
> >> > > +The following steps show how to run hello.exe on a Raspberry 
> Pi 2.
> >> >
> >> > hello.exe -> ``hello.exe``
> >> >
> >> > > +The same instructions can be applied to Raspberry Pi 1 also.
> >> > > +Other executables can be processed in a similar way.
> >> > > +
> >> > > +To create the kernel image:
> >> > > +
> >> > > +.. code-block:: none
> >> > > +
> >> > > +     arm-rtems5-

Re: Build FreeBSD: FAILED 6/rtems-sparc on x86_64-freebsd12.1 (sparc-rtems6-gdb-5085593976-x86_64-freebsd12.1-1)

[Jiri Gaisler]

On 12/5/19 8:38 AM, Sebastian Huber wrote:
> On 04/12/2019 14:56, sebastian.hu...@embedded-brains.de wrote:
>> ../../../sourceware-mirror-binutils-gdb-5085593976/sim/erc32/sis.c:36:10: 
>> fatal error: 'readline/readline.h' file not found
>> #include "readline/readline.h"
>
> This is the GDB build failure on FreeBSD 12.1. I have a readline.h in:
>
> /usr/local/include/readline/readline.h
>
gdb should not be built with the internal sis anymore, as a much newer sis 
version exists as a standalone package. If you are building gdb manually, 
configure with --disable-sim .


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: dl06

[Jiri Gaisler]

On 11/18/19 9:12 AM, Sebastian Huber wrote:
> On 18/11/2019 08:59, Chris Johns wrote:
>>
>>> On 18 Nov 2019, at 6:14 pm, Sebastian Huber
>>>  wrote:
>>>
>>> Hallo,
>>>
>>> on which platform passes the dl06 test? I tried
>>> arm/realview_pbx_a9_qemu and got:
>>
>> It is a bug that has come in that I have not looked at.
>
> Is this a known issue or something which broke only recently? Do you
> know a version/platform on which it worked?


dl06 and dl09 has failed on all SPARC bsps for some time now ..

>
>>
>>> *** BEGIN OF TEST libdl (RTL) 6 ***
>>> *** TEST VERSION:
>>> 5.0.0.9438165d2cfb9a6a67f01f5ec7ba9156abb66d7d-modified
>>> *** TEST STATE: EXPECTED-PASS
>>> *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP
>>> *** TEST TOOLS: 7.4.1 20190514 (RTEMS 5, RSB
>>> a50f0c044ad732db728cc942d5fde82a1faf1d12, Newlib d14714c69)
>>>
>>> load: /dl06.rap
>>> handle: 0x210ce0 loaded
>>> Loaded module: argc:4
>>> [/home/EB/sebastian_h/git-rtems-5/c/src/../../testsuites/libtests/dl06/dl06-o1.c]
>>> libm: lcong48
>>> libm: atan2
>>>
>>> *** FATAL ***
>>> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
>>>
>>> R0   = 0x R8  = 0x
>>> R1   = 0x000a R9  = 0x
>>> R2   = 0x00213149 R10 = 0x
>>> R3   = 0x R11 = 0x
>>> R4   = 0x00206cac R12 = 0x
>>> R5   = 0x SP  = 0x00206c80
>>> R6   = 0x LR  = 0x00211e51
>>> R7   = 0x00206c80 PC  = 0x00211e94
>>> CPSR = 0x00070173 VEC = 0x0001
>>> FPEXC = 0x4000
>>> FPSCR = 0x
>>> D00 = 0x401c
>>> D01 = 0x40408000
>>> D02 = 0x3fddac670561bb4f
>>> D03 = 0x3fe921fb54442d18
>>> D04 = 0x3fef730bd281f69b
>>> D05 = 0x3ff921fb54442d18
>>> D06 = 0x3c7a2b7f222f65e2
>>> D07 = 0x3c81a62633145c07
>>> D08 = 0x
>>> D09 = 0x
>>> D10 = 0x
>>> D11 = 0x
>>> D12 = 0x
>>> D13 = 0x
>>> D14 = 0x
>>> D15 = 0x
>>> D16 = 0x
>>> D17 = 0x0002
>>> D18 = 0x
>>> D19 = 0x
>>> D20 = 0x
>>> D21 = 0x
>>> D22 = 0x
>>> D23 = 0x
>>> D24 = 0x
>>> D25 = 0x
>>> D26 = 0x
>>> D27 = 0x
>>> D28 = 0x
>>> D29 = 0x
>>> D30 = 0x
>>> D31 = 0x
>>> RTEMS version: 5.0.0.9438165d2cfb9a6a67f01f5ec7ba9156abb66d7d-modified
>>> RTEMS tools: 7.4.1 20190514 (RTEMS 5, RSB
>>> a50f0c044ad732db728cc942d5fde82a1faf1d12, Newlib d14714c69)
>>> executing thread ID: 0x08a010001
>>> executing thread name: UI1
>>>
>>> I tried arm/xilinx_zynq_a9_qemu and got:
>>>
>>> *** BEGIN OF TEST libdl (RTL) 6 ***
>>> *** TEST VERSION: 5.0.0.799c4f551806fb1124ea5d9f6633ec5deb91ad8e
>>> *** TEST STATE: EXPECTED-PASS
>>> *** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API
>>> *** TEST TOOLS: 7.4.1 20190514 (RTEMS 5, RSB
>>> a50f0c044ad732db728cc942d5fde82a1faf1d12, Newlib d14714c69)
>>>
>>> load: /dl06.rap
>>> dlopen failed: .text: THM_CALL/JUMP24: overflow: no tramp memory
>>>
>>> *** FATAL ***
>>> fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
>>> fatal code: 0 (0x)
>>> RTEMS version: 5.0.0.799c4f551806fb1124ea5d9f6633ec5deb91ad8e
>>> RTEMS tools: 7.4.1 20190514 (RTEMS 5, RSB
>>> a50f0c044ad732db728cc942d5fde82a1faf1d12, Newlib d14714c69)
>>> executing thread ID: 0x08a010001
>>> executing thread name: UI1
>>>
>>> I would like to remove the PAX archives to simplify the build and
>>> reduce the host dependencies.
>>
>> Is this because of handled the dependencies in waf?
>
> It is not a waf issue. I just want to get rid of another host
> dependency. pax is not a standard Linux tool.
>
>>
>> Converting to C is a broken path IMO. it does not scale.
>
> I would convert the individual object files with bin2c and load them
> with IMFS_make_linfile().
>
>>
>> I am not sure removing pax solves the need for 2 link passes.
>>
>>> It is not clear to me what the purpose of the dl06_pre_file file is.
>>
>> It tests the RAP format.
>
> How is the file used?
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: sparc-rtems-gdb doesn't recognize target "sim"

[Jiri Gaisler]

On 11/13/19 9:48 AM, Vaibhav Gupta wrote:
> You can also use "sis"
>
> 1- Open Terminal 1 and write:
>
> $ sparc-rtems5-sis -gdb
>         # It will print 'gdb: listening on port 1234'.
>         # Note you can define port number with '-port' option.
>
> 2-Open Terminal 2 and write:
>
> $ sparc-rtems5-gdb hello.exe
>         # gdb asks for several inputs
>                 $ target extended-remote localhost:1234
>                 $ load
>                 $ r
>
> Use the notes here: 
> https://github.com/VARoDeK/MyNotes/blob/master/RTEMS/run_a_testsuite.md


Note that the procedure for RISC-V can be exactly the same, usings 
riscv-rtems5-sis and the RTEMS griscv bsp ..

Jiri.


>
> On Wed, Nov 13, 2019, 1:06 PM Vijay Kumar Banerjee  > wrote:
>
>
>
> On Wed, Nov 13, 2019 at 12:39 AM Shubham Bhagat 
> mailto:shubhambhagat...@yahoo.com>> wrote:
>
> Hello everyone,
> I've been trying to run the hello world example in source tree 
>  to get 
> started with sparc/erc32 but after building all that is required ( followed 
> POSIX Compliance (Getting started challenge for RTEMS beginners) 
> ). I
> followed all the commands. But, when gdb starts and I set "tar sim" 
> it says:
>
> Undefined target command: "sim".  Try "help target".
>
> I also tried running hello.exe from the testsuites sample using 
> sparc-rtems5-run but it doesn't recognize the command.
> NOTE: The make and make install steps didn't finish with a "SUCCESS" 
> or anything. They exited without showing any error.
>
> Am I missing out anything here?
>
> I guess this thread will be helpful for you:
> https://lists.rtems.org/pipermail/devel/2019-September/055671.html 
>
>
>   
>
>
> POSIX Compliance (Getting started challenge for RTEMS beginners)
>
> Ravindra Kumar Meena
>
> POSIX stands for Portable Operating System Interface for uni-X. POSIX 
> Compliance allows us to port the source co...
>
> 
>
>
> ___
> devel mailing list
> devel@rtems.org 
> http://lists.rtems.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@rtems.org 
> http://lists.rtems.org/mailman/listinfo/devel
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: psxfenv01 fails to compile for RISCV

[Jiri Gaisler]

On 11/9/19 8:38 PM, Jiri Gaisler wrote:
>
>
> On 11/9/19 7:57 PM, Joel Sherrill wrote:
>>
>>
>> On Sat, Nov 9, 2019, 12:40 PM Jiri Gaisler > <mailto:j...@gaisler.se>> wrote:
>>
>> I get this error for psxfenv01 with the latest RTEMS and RSB build:
>>
>> riscv-rtems5-gcc -DHAVE_CONFIG_H -I.
>> -I/home/jiri/ibm/src/rtems/rtems/c/src/../../testsuites/psxtests  
>> -I.
>> -I/home/jiri/src/rtems/riscvmp/riscv-rtems5/c/griscv/include
>> -I/home/jiri/ibm/src/rtems/rtems/cpukit/include
>> -I/home/jiri/ibm/src/rtems/rtems/cpukit/score/cpu/riscv/include
>> 
>> -I/home/jiri/src/rtems/riscvmp/riscv-rtems5/c/griscv/lib/libbsp/riscv/griscv/include
>> -I/home/jiri/ibm/src/rtems/rtems/bsps/include
>> -I/home/jiri/ibm/src/rtems/rtems/bsps/riscv/include
>> -I/home/jiri/ibm/src/rtems/rtems/bsps/riscv/griscv/include
>> -DT_FILE_NAME='"init.c"' 
>> 
>> -I/home/jiri/ibm/src/rtems/rtems/c/src/../../testsuites/psxtests/../support/include
>>   
>> -march=rv32imafd -mabi=ilp32d -O2 -g -ffunction-sections
>> -fdata-sections
>> -Wall -Wmissing-prototypes -Wimplicit-function-declaration
>> -Wstrict-prototypes -Wnested-externs -MT
>> psxfenv01/psxfenv01-init.o -MD
>> -MP -MF psxfenv01/.deps/psxfenv01-init.Tpo -c -o
>> psxfenv01/psxfenv01-init.o `test -f 'psxfenv01/init.c' || echo
>> 
>> '/home/jiri/ibm/src/rtems/rtems/c/src/../../testsuites/psxtests/'`psxfenv01/init.c
>> In file included from
>> /home/jiri/src/rtems/5/riscv-rtems5/include/fenv.h:15,
>>  from
>> 
>> /home/jiri/ibm/src/rtems/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:42:
>> 
>> /home/jiri/ibm/src/rtems/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:
>> In function 'Init':
>> 
>> /home/jiri/ibm/src/rtems/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:71:18:
>> error: 'fe_dfl_env_p' undeclared (first use in this function);
>> did you
>> mean 'fe_dfl_env'?
>>    71 | r = fesetenv(FE_DFL_ENV);
>>   |  ^~
>> 
>> /home/jiri/ibm/src/rtems/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:71:18:
>> note: each undeclared identifier is reported only once for each
>> function
>> it appears in
>> Makefile:10569: recipe for target 'psxfenv01/psxfenv01-init.o' failed
>> make[5]: *** [psxfenv01/psxfenv01-init.o] Error 1
>> make[5]: Leaving directory
>> '/home/jiri/src/rtems/riscvmp/riscv-rtems5/c/griscv/testsuites/psxtests'
>> Makefile:663: recipe for target 'psxtests' failed
>> make[4]: *** [psxtests] Error 2
>> make[4]: Leaving directory
>> '/home/jiri/src/rtems/riscvmp/riscv-rtems5/c/griscv/testsuites'
>> Makefile:1222: recipe for target 'testsuites' failed
>> make[3]: *** [testsuites] Error 2
>> make[3]: Leaving directory
>> '/home/jiri/src/rtems/riscvmp/riscv-rtems5/c/griscv'
>> Makefile:716: recipe for target 'all-recursive' failed
>> make[2]: *** [all-recursive] Error 1
>> make[2]: Leaving directory
>> '/home/jiri/src/rtems/riscvmp/riscv-rtems5/c/griscv'
>> Makefile:289: recipe for target 'all-recursive' failed
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory
>> '/home/jiri/src/rtems/riscvmp/riscv-rtems5/c'
>> Makefile:410: recipe for target 'all-recursive' failed
>> make: *** [all-recursive] Error 1
>> jiri@office:~/src/rtems/riscvmp$
>>
>>
>> I thought I fixed this in the upstream newlib. 
>>
>> https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=9e06ba1ac310c5a2392bb9d150e4686bbb118d6c
>>
>> Either I didn't really fix it or your newlib is a bit old. 
>>
>> Did Sebastian bump 5's newlib recently? I recall a binutils bump.
>>
>>
> My RSB is in sync with git head, and I rebuilt the tool-chain 2 hours
> ago. The installed fenv.h for RISCV ends with:
>
>
> typedef size_t fenv_t;
> typedef size_t fexcept_t;
> extern const fenv_t fe_dfl_env;
> #define FE_DFL_ENV fe_dfl_env_p
>
> #endif /* _FENV_H_ */
> 
>
> fe_dfl_env_p seems to be missing it's declaration ...?

After looking at it in more detail, the newlib used in RSB head for
5/rtems-riscv is 6661a67, which is from July 30. The commit that fixes
fenv.h is pushed October 9. So we need to bump the newlib version to
something after this date, or pull in a patch that fixes it. I will fix
it locally for my build tree for now ...

Jiri.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: psxfenv01 fails to compile for RISCV

[Jiri Gaisler]

On 11/9/19 7:57 PM, Joel Sherrill wrote:
>
>
> On Sat, Nov 9, 2019, 12:40 PM Jiri Gaisler  <mailto:j...@gaisler.se>> wrote:
>
> I get this error for psxfenv01 with the latest RTEMS and RSB build:
>
> riscv-rtems5-gcc -DHAVE_CONFIG_H -I.
> -I/home/jiri/ibm/src/rtems/rtems/c/src/../../testsuites/psxtests   -I.
> -I/home/jiri/src/rtems/riscvmp/riscv-rtems5/c/griscv/include
> -I/home/jiri/ibm/src/rtems/rtems/cpukit/include
> -I/home/jiri/ibm/src/rtems/rtems/cpukit/score/cpu/riscv/include
> 
> -I/home/jiri/src/rtems/riscvmp/riscv-rtems5/c/griscv/lib/libbsp/riscv/griscv/include
> -I/home/jiri/ibm/src/rtems/rtems/bsps/include
> -I/home/jiri/ibm/src/rtems/rtems/bsps/riscv/include
> -I/home/jiri/ibm/src/rtems/rtems/bsps/riscv/griscv/include
> -DT_FILE_NAME='"init.c"' 
> 
> -I/home/jiri/ibm/src/rtems/rtems/c/src/../../testsuites/psxtests/../support/include
>   
> -march=rv32imafd -mabi=ilp32d -O2 -g -ffunction-sections
> -fdata-sections
> -Wall -Wmissing-prototypes -Wimplicit-function-declaration
> -Wstrict-prototypes -Wnested-externs -MT
> psxfenv01/psxfenv01-init.o -MD
> -MP -MF psxfenv01/.deps/psxfenv01-init.Tpo -c -o
> psxfenv01/psxfenv01-init.o `test -f 'psxfenv01/init.c' || echo
> 
> '/home/jiri/ibm/src/rtems/rtems/c/src/../../testsuites/psxtests/'`psxfenv01/init.c
> In file included from
> /home/jiri/src/rtems/5/riscv-rtems5/include/fenv.h:15,
>  from
> 
> /home/jiri/ibm/src/rtems/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:42:
> 
> /home/jiri/ibm/src/rtems/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:
> In function 'Init':
> 
> /home/jiri/ibm/src/rtems/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:71:18:
> error: 'fe_dfl_env_p' undeclared (first use in this function); did you
> mean 'fe_dfl_env'?
>    71 | r = fesetenv(FE_DFL_ENV);
>   |  ^~
> 
> /home/jiri/ibm/src/rtems/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:71:18:
> note: each undeclared identifier is reported only once for each
> function
> it appears in
> Makefile:10569: recipe for target 'psxfenv01/psxfenv01-init.o' failed
> make[5]: *** [psxfenv01/psxfenv01-init.o] Error 1
> make[5]: Leaving directory
> '/home/jiri/src/rtems/riscvmp/riscv-rtems5/c/griscv/testsuites/psxtests'
> Makefile:663: recipe for target 'psxtests' failed
> make[4]: *** [psxtests] Error 2
> make[4]: Leaving directory
> '/home/jiri/src/rtems/riscvmp/riscv-rtems5/c/griscv/testsuites'
> Makefile:1222: recipe for target 'testsuites' failed
> make[3]: *** [testsuites] Error 2
> make[3]: Leaving directory
> '/home/jiri/src/rtems/riscvmp/riscv-rtems5/c/griscv'
> Makefile:716: recipe for target 'all-recursive' failed
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory
> '/home/jiri/src/rtems/riscvmp/riscv-rtems5/c/griscv'
> Makefile:289: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory
> '/home/jiri/src/rtems/riscvmp/riscv-rtems5/c'
> Makefile:410: recipe for target 'all-recursive' failed
> make: *** [all-recursive] Error 1
> jiri@office:~/src/rtems/riscvmp$
>
>
> I thought I fixed this in the upstream newlib. 
>
> https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=9e06ba1ac310c5a2392bb9d150e4686bbb118d6c
>
> Either I didn't really fix it or your newlib is a bit old. 
>
> Did Sebastian bump 5's newlib recently? I recall a binutils bump.
>
>
My RSB is in sync with git head, and I rebuilt the tool-chain 2 hours
ago. The installed fenv.h for RISCV ends with:


typedef size_t fenv_t;
typedef size_t fexcept_t;
extern const fenv_t fe_dfl_env;
#define FE_DFL_ENV fe_dfl_env_p

#endif /* _FENV_H_ */


fe_dfl_env_p seems to be missing it's declaration ...?


>
> ___
> devel mailing list
> devel@rtems.org <mailto:devel@rtems.org>
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

psxfenv01 fails to compile for RISCV

[Jiri Gaisler]

I get this error for psxfenv01 with the latest RTEMS and RSB build:

riscv-rtems5-gcc -DHAVE_CONFIG_H -I.
-I/home/jiri/ibm/src/rtems/rtems/c/src/../../testsuites/psxtests   -I.
-I/home/jiri/src/rtems/riscvmp/riscv-rtems5/c/griscv/include
-I/home/jiri/ibm/src/rtems/rtems/cpukit/include
-I/home/jiri/ibm/src/rtems/rtems/cpukit/score/cpu/riscv/include
-I/home/jiri/src/rtems/riscvmp/riscv-rtems5/c/griscv/lib/libbsp/riscv/griscv/include
-I/home/jiri/ibm/src/rtems/rtems/bsps/include
-I/home/jiri/ibm/src/rtems/rtems/bsps/riscv/include
-I/home/jiri/ibm/src/rtems/rtems/bsps/riscv/griscv/include
-DT_FILE_NAME='"init.c"' 
-I/home/jiri/ibm/src/rtems/rtems/c/src/../../testsuites/psxtests/../support/include
  
-march=rv32imafd -mabi=ilp32d -O2 -g -ffunction-sections -fdata-sections
-Wall -Wmissing-prototypes -Wimplicit-function-declaration
-Wstrict-prototypes -Wnested-externs -MT psxfenv01/psxfenv01-init.o -MD
-MP -MF psxfenv01/.deps/psxfenv01-init.Tpo -c -o
psxfenv01/psxfenv01-init.o `test -f 'psxfenv01/init.c' || echo
'/home/jiri/ibm/src/rtems/rtems/c/src/../../testsuites/psxtests/'`psxfenv01/init.c
In file included from /home/jiri/src/rtems/5/riscv-rtems5/include/fenv.h:15,
 from
/home/jiri/ibm/src/rtems/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:42:
/home/jiri/ibm/src/rtems/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:
In function 'Init':
/home/jiri/ibm/src/rtems/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:71:18:
error: 'fe_dfl_env_p' undeclared (first use in this function); did you
mean 'fe_dfl_env'?
   71 | r = fesetenv(FE_DFL_ENV);
  |  ^~
/home/jiri/ibm/src/rtems/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:71:18:
note: each undeclared identifier is reported only once for each function
it appears in
Makefile:10569: recipe for target 'psxfenv01/psxfenv01-init.o' failed
make[5]: *** [psxfenv01/psxfenv01-init.o] Error 1
make[5]: Leaving directory
'/home/jiri/src/rtems/riscvmp/riscv-rtems5/c/griscv/testsuites/psxtests'
Makefile:663: recipe for target 'psxtests' failed
make[4]: *** [psxtests] Error 2
make[4]: Leaving directory
'/home/jiri/src/rtems/riscvmp/riscv-rtems5/c/griscv/testsuites'
Makefile:1222: recipe for target 'testsuites' failed
make[3]: *** [testsuites] Error 2
make[3]: Leaving directory
'/home/jiri/src/rtems/riscvmp/riscv-rtems5/c/griscv'
Makefile:716: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
'/home/jiri/src/rtems/riscvmp/riscv-rtems5/c/griscv'
Makefile:289: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/jiri/src/rtems/riscvmp/riscv-rtems5/c'
Makefile:410: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1
jiri@office:~/src/rtems/riscvmp$

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Expired certificate on devel.rtems.org ...?

[Jiri Gaisler]

I cannot connect to devel.rtems.org this morning, firefox and chromium claims 
that the certificate has expired. Seems that the let's encrypt certificate was 
not auto-updated ...


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RSB Qemu Leon3 patches error

[Jiri Gaisler]

On 10/25/19 4:01 PM, Joel Sherrill wrote:
> Hi
>
> I am not sure what's up with the Leon patches but I am getting a checksum 
> error and wanted to see if Jiri or someone else knowledgeable could 
> investigate and fix.
>
> warning: checksum error: 0001-LEON3-Add-emulation-of-AMBA-plug-play.patch
> warning: removing: 0001-LEON3-Add-emulation-of-AMBA-plug-play.patch
> making dir: /home/joel/rtems-cron-5/rtems-source-builder/bare/patches
> download: (full) 
> https://gaisler.org/qemu/0001-LEON3-Add-emulation-of-AMBA-plug-play.patch -> 
> patches/0001-LEON3-Add-emulation-of-AMBA-plug-play.patch
> download: 
> https://gaisler.org/qemu/0001-LEON3-Add-emulation-of-AMBA-plug-play.patch -> 
> patches/0001-LEON3-Add-emulation-of-AMBA-plug-play.patch
> checksums: 0001-LEON3-Add-emulation-of-AMBA-plug-play.patch: 
> 1162bfb7b5839237803356e5fb6efaafdec5b9d2df9d23de42c86d48c5e35327 => 
> 5f2ca77e727dc3b4f9d78ff8c62d610b1bc2afd3345106401cf26e99452db067
> warning: checksum error: 0001-LEON3-Add-emulation-of-AMBA-plug-play.patch
> error: checksum failure file: 
> patches/0001-LEON3-Add-emulation-of-AMBA-plug-play.patch
>
> Thanks.
>
> --joel


Could you try to build devel/qemu4 instead?

I cannot debug this at the moment as building of qemu fails on my system due to 
compile errors of glib-2.39.3 (Ubuntu 18.04). Building of qemu4 work OK though.

Jiri.

PS. I have mailed with the qemu team who will include my remaining patch for 
qemu-4.1 in the master. The next stable qemu should thus be usable without 
patches..



___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Update the help to match the available options.

[Jiri Gaisler]

Looks good to me - push ...

On 10/21/19 2:48 PM, chr...@rtems.org wrote:
> From: Chris Johns 
>
> ---
>  help.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/help.c b/help.c
> index 2593d84..b3f5407 100644
> --- a/help.c
> +++ b/help.c
> @@ -25,8 +25,11 @@ sis_usage ()
>  {
>  
>printf ("usage: sis [-uart1 uart_device1] [-uart2 uart_device2]\n");
> -  printf ("[-m ] [-dumbio] [-v] \n");
> -  printf ("[-nfp] [-freq frequency] [-c batch_file] [files]\n");
> +  printf ("[-m ] [-dumbio] [-gdb] [-port port]\n");
> +  printf ("[-cov] [-nfp] [-ift] [-wrp] [-rom8] [-uben]\n");
> +  printf ("[-freq frequency] [-c batch_file]\n");
> +  printf ("[-erc32] [-leon2] [-leon3] [-ricsv]\n");
> +  printf ("[-d] [-v] [files]\n");
>  }
>  
>  void
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Problem running sparc-rtems5-gdb

[Jiri Gaisler]

On 9/22/19 6:30 AM, Niteesh wrote:
> I was following the quick-start guide from
> https://docs.rtems.org/branches/master/user/start/index.html
> I followed the exact steps but still couldn't get the hello world
> running. I face issues when running the GDB, when trying to set the
> target to simulator I get "undefined target cmd: sim",
> Is it an issue on my side or is something missing in the docs?

The sis simulator has been detached from gdb. You can run your
application using sparc-rtems5-sis, or debug it  with sparc-rtems5-gdb
using sparc-rtems5-sis as a gdb server. For details, see the sis manual at:

https://gaisler.se/sis/sis.pdf

Jiri.

> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH RSB] Add gdb-8.3 as default debugger

[Jiri Gaisler]

I suggest that we switch to gdb-8.3 for targets that currently use 8.2.1. The 
update is relatively minor but allows building without any patches. Tested for 
SPARC and RISC-V targets.

Jiri.

>From 5b12c03d184d6cea7019636fc134e06d25a94d9f Mon Sep 17 00:00:00 2001
From: Jiri Gaisler 
Date: Wed, 21 Aug 2019 09:24:51 +0200
Subject: [PATCH] Add gdb-8.3 as default debugger

	* Minor update from 8.2.1
	* Can be built without patches (!)
---
 rtems/config/5/rtems-default.bset  |  2 +-
 rtems/config/5/rtems-sparc.bset|  1 +
 rtems/config/tools/rtems-gdb-8.3-1.cfg | 12 
 3 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100644 rtems/config/tools/rtems-gdb-8.3-1.cfg

diff --git a/rtems/config/5/rtems-default.bset b/rtems/config/5/rtems-default.bset
index e2e4ac0..8640499 100644
--- a/rtems/config/5/rtems-default.bset
+++ b/rtems/config/5/rtems-default.bset
@@ -15,7 +15,7 @@
 #
 
 devel/expat-2.1.0-1
-tools/rtems-gdb-8.2.1-1
+tools/rtems-gdb-8.3-1
 
 tools/rtems-binutils-2.32
 tools/rtems-gcc-fb371a33fa6-newlib-6661a67
diff --git a/rtems/config/5/rtems-sparc.bset b/rtems/config/5/rtems-sparc.bset
index 60bb792..ccb3e10 100644
--- a/rtems/config/5/rtems-sparc.bset
+++ b/rtems/config/5/rtems-sparc.bset
@@ -1,5 +1,6 @@
 %define release 1
 %define rtems_arch sparc
 %define with_libgomp
+%define gdb-disable-sim 1
 %include 5/rtems-default.bset
 devel/sis-2-1
diff --git a/rtems/config/tools/rtems-gdb-8.3-1.cfg b/rtems/config/tools/rtems-gdb-8.3-1.cfg
new file mode 100644
index 000..1577737
--- /dev/null
+++ b/rtems/config/tools/rtems-gdb-8.3-1.cfg
@@ -0,0 +1,12 @@
+#
+# GDB 8.3
+#
+
+%include %{_configdir}/checks.cfg
+%include %{_configdir}/base.cfg
+
+%define gdb_version 8.3
+%define gdb_src_ext xz
+%hash sha512 gdb-%{gdb_version}.tar.xz 47ac074d20a09a3fac8f4a41dce0a0cbe6ef702f7dc21ba8b7d650d306128dcae481e9a16bf65e596b3a541dc82ae57c02bcbb786d551b4ef3e2917b9b6f0ae1
+
+%include %{_configdir}/gdb-8-1.cfg
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RSB PATCH] Added qemu 4.1.0 as bare target

[Jiri Gaisler]

On 8/20/19 12:44 AM, Chris Johns wrote:
> On 20/8/19 6:53 am, Jiri Gaisler wrote:
>> This patch will add QEMU-4.1.0 as RSB target devel/qemu4.
> Looks good.
>
>> The current devel/qemu target will be preserved. 
> Should devel/qemu just point to qemu4? I am OK with this happening.
If preserving the current qemu is not necessary, then I can just update 
devel/qemu to version 4.1.0 and not add devel/qemu4. This probably makes more 
sense  ...
>
>> Builds and installs fine on ubuntu 18.04 x86_64. Build scripts might need 
>> tweaks for other platforms. 
> It can be a lot of work depending on how building the support libraries goes. 
> I
> think we have reached a point where a newer qemu on platforms that can build 
> it
> is more important and the problem hosts such as MinGW and MacOS can be cleaned
> up after.
Agree. On ubuntu, the supporting libraries are not needed at all as they can be 
installed through the standard package manager. But building them inside RSB 
makes it easier for the end-user who does not need to figure out what to 
install (or read the manual .. :-)
>> A few patches are still pulled in, currently hosted on gaisler.org but could 
>> be moved to Trac ..? Tested with sparc/leon3 bsp, about 10 unexpected 
>> fails/timeouts out of 530 tests.
> Does setting a longer timeout change this? I cannot find a suitable way to
> adjust the timeout depending on the load.

Not really, the tests are dead-locked somehow. This is probably because of qemu 
timing behavior. Here is the list of failures:

Failures:
 dl09.exe
 psx12.exe

Timeouts:
 spintrcritical06.exe
 spintrcritical07.exe
 spintrcritical12.exe
 spintrcritical11.exe
 spintrcritical13.exe
 spintrcritical14.exe
 spintrcritical15.exe
 spintrcritical18.exe
 spintrcritical24.exe

It would be great if rtems-test could (optionally) take a timeout value from 
the bsp file, as some targets need a bit longer delay. (e.g. crypt01.exe fails 
on sis/RISC-V due to this).

Jiri.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems-tools] leon3-qemu.ini for rtems-test needs custom parameters to work

[Jiri Gaisler]

The standard parameters for leon3-qemu bsp for rtems-test do not work - custom 
ones are needed.

From fb2d18063958d26c016bed2a4880507c9d688d87 Mon Sep 17 00:00:00 2001
From: Jiri Gaisler 
Date: Mon, 19 Aug 2019 22:45:04 +0200
Subject: [PATCH] leon3-qemu.ini for rtems-test needs custom parameters to
 work.

---
 tester/rtems/testing/bsps/leon3-qemu.ini | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tester/rtems/testing/bsps/leon3-qemu.ini b/tester/rtems/testing/bsps/leon3-qemu.ini
index 9e8854c..8760949 100644
--- a/tester/rtems/testing/bsps/leon3-qemu.ini
+++ b/tester/rtems/testing/bsps/leon3-qemu.ini
@@ -35,4 +35,4 @@
 bsp   = leon3-qemu
 arch  = sparc
 tester= %{_rtscripts}/qemu.cfg
-bsp_qemu_opts = %{qemu_opts_base} -M leon3_generic
+bsp_qemu_opts = -no-reboot -nographic -m 64M -M leon3_generic
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[RSB PATCH] Added qemu 4.1.0 as bare target

[Jiri Gaisler]

This patch will add QEMU-4.1.0 as RSB target devel/qemu4. The current 
devel/qemu target will be preserved. Builds and installs fine on ubuntu 18.04 
x86_64. Build scripts might need tweaks for other platforms. A few patches are 
still pulled in, currently hosted on gaisler.org but could be moved to Trac ..? 
Tested with sparc/leon3 bsp, about 10 unexpected fails/timeouts out of 530 
tests.

Passed:    409
Failed:  2
User Input:  6
Expected Fail:   0
Indeterminate:   0
Benchmark:   3
Timeout: 9
Invalid: 2
Wrong Version:  99
Wrong Build: 0
Wrong Tools: 0
--
Total: 530
Average test time: 0:00:00.539311
Testing time : 0:04:45.834903

From 690cbb8023a42d57fea352ff45458dd87ec93bb3 Mon Sep 17 00:00:00 2001
From: Jiri Gaisler 
Date: Mon, 19 Aug 2019 22:12:26 +0200
Subject: [PATCH] Added qemu 4.1.0 as bare target

	* target name is devel/qemu4, old qemu preserved as devel/qemu
---
 bare/config/devel/glib-2.46.2-1.cfg |  26 ++
 bare/config/devel/qemu4-git-1.cfg   |  58 
 bare/config/devel/qemu4.bset|  25 ++
 source-builder/config/qemu-4-1.cfg  | 135 
 4 files changed, 244 insertions(+)
 create mode 100644 bare/config/devel/glib-2.46.2-1.cfg
 create mode 100644 bare/config/devel/qemu4-git-1.cfg
 create mode 100644 bare/config/devel/qemu4.bset
 create mode 100644 source-builder/config/qemu-4-1.cfg

diff --git a/bare/config/devel/glib-2.46.2-1.cfg b/bare/config/devel/glib-2.46.2-1.cfg
new file mode 100644
index 000..cd006f2
--- /dev/null
+++ b/bare/config/devel/glib-2.46.2-1.cfg
@@ -0,0 +1,26 @@
+#
+# GLib
+#
+
+%if %{release} == %{nil}
+%define release 1
+%endif
+
+%include %{_configdir}/base.cfg
+
+%define glib_version_major 2.46
+%define glib_version_minor 2
+%define glib_version   %{glib_version_major}.%{glib_version_minor}
+
+%hash sha256 glib-%{glib_version}.tar.xz 5031722e37036719c1a09163cc6cf7c326e4c4f1f1e074b433c156862bd733db
+
+%patch add glib https://gaisler.org/qemu/glib-2.46.2-werror.patch
+%hash sha256 glib-2.46.2-werror.patch 389c00993f2890edaff6774d0dcfc7fcc99e92795ba913443fb9ec522f44a443
+
+
+#
+# The GLib build instructions. We use 2.x.x Release 1.
+#
+%ifn %{pkgconfig check glib-2.0}
+ %include %{_configdir}/glib-2-1.cfg
+%endif
diff --git a/bare/config/devel/qemu4-git-1.cfg b/bare/config/devel/qemu4-git-1.cfg
new file mode 100644
index 000..ece5d14
--- /dev/null
+++ b/bare/config/devel/qemu4-git-1.cfg
@@ -0,0 +1,58 @@
+#
+# Qemu from git
+#
+
+%if %{release} == %{nil}
+ %define release 1
+%endif
+
+%include %{_configdir}/base.cfg
+
+%include %{_configdir}/bare-config.cfg
+
+#
+# Stable version. Qemu is fast moving.
+#
+%define qemu_version v4.1.0
+
+#
+# Qemu is from GIT unless the RSB has been released.
+#
+# We need to handle the release process
+#
+%if %{rsb_released} && %{!defined without_release_url}
+ %source set qemu %{rtems_release_url}/%{rtems_version}/sources/qemu-git-42d58e7.tar.xz
+%else
+ %source set qemu git://git.qemu-project.org/qemu.git?pull?checkout=%{qemu_version}?submodule=dtc
+%endif
+
+#
+# Patches from Qemu's patchworks site.
+#
+%patch add qemu pw://patchwork.ozlabs.org/patch/406903/raw/Provide-the-missing-LIBUSB_LOG_LEVEL_-for-older-libusb-or-FreeBSD.-Providing-just-the-needed-value-as-a-defined..patch
+%hash sha256 Provide-the-missing-LIBUSB_LOG_LEVEL_-for-older-libusb-or-FreeBSD.-Providing-just-the-needed-value-as-a-defined..patch 40399fcedb44b2c1bfa1a95af482f7f335f42d713967ed2f34980a7a940c3740
+
+#
+# These patches are broken.
+#
+#%patch add qemu pw://patchwork.ozlabs.org/patch/347503/raw/CAN-bus-simple-SJA1000-PCI-card-emulation-for-QEMU.patch
+#%hash md5 CAN-bus-simple-SJA1000-PCI-card-emulation-for-QEMU.patch fbbe8f02867b8b8ee7c23c83cf1e1efa
+#%patch add qemu pw://patchwork.ozlabs.org/patch/347502/raw/CAN-bus-Kvaser-PCI-CAN-S-single-SJA1000-channel-emulation-added.patch
+#%hash md5 CAN-bus-Kvaser-PCI-CAN-S-single-SJA1000-channel-emulation-added.patch 7bd24fa8b55116c9a1301afd7dfa69d3
+
+#
+# Patches to build qemu-4.1.0-sparc with Leon3 support
+#
+%patch add qemu https://gaisler.org/qemu/qemu-4.1.0-leon3.patch
+%hash sha256 qemu-4.1.0-leon3.patch d62ff3418903f1c5eb7f6d727af0400caeb250e23cc120111930601c9ecce02a
+
+#
+# Patch to send halt signal to qemu-system-or32 process when RTEMS terminates
+#
+#%patch add qemu %{rtems_http_git}/rtems-tools/plain/tools/qemu/0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch
+#%hash sha256 0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch 88cd5c9e6e2a6bab23bf049a6f4212ff00083b002b73dbe63b2fe9832717f19e
+
+#
+# The Qemu build instructions. We use 4.x.x Release 1.
+#
+%include %{_configdir}/qemu-4-1.cfg
diff --git a/bare/config/devel/qemu4.bset b/bare/config/devel/qemu4.bset
new file mode 100644
index 000..6badab2
--- /dev/null
+++ b/bare/config/devel/qemu4.bset
@@ -0,0 +1,25 @@
+#
+# Build set for QEMU
+#
+
+%define release 1
+
+#
+# Name of the package

Re: Checksum Error on Leon3 Qemu patches

[Jiri Gaisler]

On 8/18/19 10:30 PM, Jiri Gaisler wrote:
>
>
> On 8/17/19 8:23 PM, Joel Sherrill wrote:
>>
>>
>> On Sat, Aug 17, 2019, 1:07 PM Jiri Gaisler > <mailto:j...@gaisler.se>> wrote:
>>
>>
>> On 8/16/19 11:03 PM, Juan Rafael García Blanco wrote:
>>> Hi,
>>>
>>> AFAIK, the last qemu major version includes support for leon3. But I 
>>> dont't know if that work was based on these patches.
>>
>> Indeed. Qemu git head now includes leon3 plug&play and should be able to 
>> run RTEMS images unpatched. Is there a reason why the qemu version built by 
>> RSB is from June 2015 ..?
>>
>>
>> Sadly no one has updated it. Beyond Leon, Zynq and PC, what should be tested?
>>
>> Riscv status in head?
>>
>> Beagle?
>>
>> Any other bsps we use with Qemu?
>>
>> I'd love to see it updated. It's a pain to test across all the hosts and get 
>> working.
>
>
> Unfortunately, qemu HEAD cannot execute RTEMS leon3 images unpatched. The 
> startup code needs a (simple) tweak, and the implementation of the plug&play 
> is not quite correct. An RTEMS binary fails to detect the interrupt 
> controller and subsequently terminates. I have spent a few hours on it but 
> the bug is rather elusive and
>
OK, the problem was that qemu did not implement byte access to the plug&play. 
With the attached patch, most tests for leon3 run:

Passed:    506
Failed:  4
User Input:  6
Expected Fail:   0
Indeterminate:   0
Benchmark:   3
Timeout: 9
Invalid: 2
Wrong Version:   0
Wrong Build: 0
Wrong Tools: 0
--
Total: 530
Average test time: 0:00:00.539755
Testing time : 0:04:46.070129

Maybe we can add it to RSB as qemu4.1, which was released this week. It could 
make it easier to test other targets ...?

Jiri.

diff --git a/hw/misc/grlib_ahb_apb_pnp.c b/hw/misc/grlib_ahb_apb_pnp.c
index 7338461694..eaaedbfbcc 100644
--- a/hw/misc/grlib_ahb_apb_pnp.c
+++ b/hw/misc/grlib_ahb_apb_pnp.c
@@ -228,6 +228,9 @@ static uint64_t grlib_apb_pnp_read(void *opaque, hwaddr offset, unsigned size)
 {
 APBPnp *apb_pnp = GRLIB_APB_PNP(opaque);
 
+if (size != 4)
+return apb_pnp->regs[offset >> 2] >> ((~offset & 3) * 8);
+
 return apb_pnp->regs[offset >> 2];
 }
 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Checksum Error on Leon3 Qemu patches

[Jiri Gaisler]

On 8/17/19 8:23 PM, Joel Sherrill wrote:
>
>
> On Sat, Aug 17, 2019, 1:07 PM Jiri Gaisler  <mailto:j...@gaisler.se>> wrote:
>
>
> On 8/16/19 11:03 PM, Juan Rafael García Blanco wrote:
>> Hi,
>>
>> AFAIK, the last qemu major version includes support for leon3.
>> But I dont't know if that work was based on these patches.
>
> Indeed. Qemu git head now includes leon3 plug&play and should be
> able to run RTEMS images unpatched. Is there a reason why the qemu
> version built by RSB is from June 2015 ..?
>
>
> Sadly no one has updated it. Beyond Leon, Zynq and PC, what should be
> tested?
>
> Riscv status in head?
>
> Beagle?
>
> Any other bsps we use with Qemu?
>
> I'd love to see it updated. It's a pain to test across all the hosts
> and get working.


Unfortunately, qemu HEAD cannot execute RTEMS leon3 images unpatched.
The startup code needs a (simple) tweak, and the implementation of the
plug&play is not quite correct. An RTEMS binary fails to detect the
interrupt controller and subsequently terminates. I have spent a few
hours on it but the bug is rather elusive and I am not sure I will be
able to track it down. Debugging low-level target code on qemu is not
exactly user friendly  :-) ...


>
> Jiri.
>
>>
>> Regards,
>> Juan.
>>
>> On Fri, Aug 16, 2019, 11:00 PM Jiri Gaisler > <mailto:j...@gaisler.se>> wrote:
>>
>>
>> On 8/15/19 12:09 AM, Joel Sherrill wrote:
>> > On Wed, Aug 14, 2019 at 4:42 PM Chris Johns
>> mailto:chr...@rtems.org>> wrote:
>> >> On 15/8/19 12:46 am, Joel Sherrill wrote:
>> >>> Qemu isn't building due to a checksum error.
>> >>>
>> >>> These patches are at gaisler.org <http://gaisler.org>. I
>> don't know where to move them but
>> >>> eventually they should be moved.
>> >> You can post them to qemu's patchworks and then get them
>> from there. The RSB
>> >> supports fetching from patchworks.
>> > Jiri: Are these already on patchworks by any chance?
>>
>> Not that I am aware of. The checksum probably changed because
>> the original patches were lost during a server rehost, and I
>> recovered some earlier version from a backup disk. The
>> patches do not apply cleanly to the latest version of qemu:
>>
>> + /bin/cat
>> 
>> /home/jiri/ibm/src/rtems/rtems-source-builder/bare/patches/0001-LEON3-Add-emulation-of-AMBA-plug-play.patch
>> + /usr/bin/patch -p1
>> patching file hw/sparc/Makefile.objs
>> patching file hw/sparc/grlib_ambapnp.c
>> patching file hw/sparc/leon3.c
>> Hunk #1 succeeded at 207 (offset -7 lines).
>> patching file include/hw/sparc/grlib.h
>> Hunk #1 FAILED at 117.
>> 1 out of 1 hunk FAILED -- saving rejects to file
>> include/hw/sparc/grlib.h.rej
>>
>> Could be that qemu has moved since the patches were make, I
>> will try to take a look ...
>>
>> Jiri.
>>
>>
>>
>> ___
>> devel mailing list
>> devel@rtems.org <mailto:devel@rtems.org>
>> http://lists.rtems.org/mailman/listinfo/devel
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Checksum Error on Leon3 Qemu patches

[Jiri Gaisler]

On 8/17/19 8:23 PM, Joel Sherrill wrote:
>
>
> On Sat, Aug 17, 2019, 1:07 PM Jiri Gaisler  <mailto:j...@gaisler.se>> wrote:
>
>
> On 8/16/19 11:03 PM, Juan Rafael García Blanco wrote:
>> Hi,
>>
>> AFAIK, the last qemu major version includes support for leon3. But I 
>> dont't know if that work was based on these patches.
>
> Indeed. Qemu git head now includes leon3 plug&play and should be able to 
> run RTEMS images unpatched. Is there a reason why the qemu version built by 
> RSB is from June 2015 ..?
>
>
> Sadly no one has updated it. Beyond Leon, Zynq and PC, what should be tested?
>
> Riscv status in head?
>
> Beagle?
>
> Any other bsps we use with Qemu?
>
> I'd love to see it updated. It's a pain to test across all the hosts and get 
> working.

I have now managed to find the original patches, and restored them on 
gaisler.org! The checksums matches again and does not block qemu from building. 
(On Ubuntu 18.04.3, qemu does not build anyway because glib fails to compile 
with gcc-7.4 ...)

Hope this helps ...

Jiri.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Checksum Error on Leon3 Qemu patches

[Jiri Gaisler]

On 8/16/19 11:03 PM, Juan Rafael García Blanco wrote:
> Hi,
>
> AFAIK, the last qemu major version includes support for leon3. But I
> dont't know if that work was based on these patches.

Indeed. Qemu git head now includes leon3 plug&play and should be able to
run RTEMS images unpatched. Is there a reason why the qemu version built
by RSB is from June 2015 ..?

Jiri.

>
> Regards,
> Juan.
>
> On Fri, Aug 16, 2019, 11:00 PM Jiri Gaisler  <mailto:j...@gaisler.se>> wrote:
>
>
> On 8/15/19 12:09 AM, Joel Sherrill wrote:
> > On Wed, Aug 14, 2019 at 4:42 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> >> On 15/8/19 12:46 am, Joel Sherrill wrote:
> >>> Qemu isn't building due to a checksum error.
> >>>
> >>> These patches are at gaisler.org <http://gaisler.org>. I don't
> know where to move them but
> >>> eventually they should be moved.
> >> You can post them to qemu's patchworks and then get them from
> there. The RSB
> >> supports fetching from patchworks.
> > Jiri: Are these already on patchworks by any chance?
>
> Not that I am aware of. The checksum probably changed because the
> original patches were lost during a server rehost, and I recovered
> some earlier version from a backup disk. The patches do not apply
> cleanly to the latest version of qemu:
>
> + /bin/cat
> 
> /home/jiri/ibm/src/rtems/rtems-source-builder/bare/patches/0001-LEON3-Add-emulation-of-AMBA-plug-play.patch
> + /usr/bin/patch -p1
> patching file hw/sparc/Makefile.objs
> patching file hw/sparc/grlib_ambapnp.c
> patching file hw/sparc/leon3.c
> Hunk #1 succeeded at 207 (offset -7 lines).
> patching file include/hw/sparc/grlib.h
> Hunk #1 FAILED at 117.
> 1 out of 1 hunk FAILED -- saving rejects to file
> include/hw/sparc/grlib.h.rej
>
> Could be that qemu has moved since the patches were make, I will
> try to take a look ...
>
> Jiri.
>
>
>
> ___
> devel mailing list
> devel@rtems.org <mailto:devel@rtems.org>
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Checksum Error on Leon3 Qemu patches

[Jiri Gaisler]

On 8/15/19 12:09 AM, Joel Sherrill wrote:
> On Wed, Aug 14, 2019 at 4:42 PM Chris Johns  wrote:
>> On 15/8/19 12:46 am, Joel Sherrill wrote:
>>> Qemu isn't building due to a checksum error.
>>>
>>> These patches are at gaisler.org. I don't know where to move them but
>>> eventually they should be moved.
>> You can post them to qemu's patchworks and then get them from there. The RSB
>> supports fetching from patchworks.
> Jiri: Are these already on patchworks by any chance?

Not that I am aware of. The checksum probably changed because the original 
patches were lost during a server rehost, and I recovered some earlier version 
from a backup disk. The patches do not apply cleanly to the latest version of 
qemu:

+ /bin/cat 
/home/jiri/ibm/src/rtems/rtems-source-builder/bare/patches/0001-LEON3-Add-emulation-of-AMBA-plug-play.patch
+ /usr/bin/patch -p1
patching file hw/sparc/Makefile.objs
patching file hw/sparc/grlib_ambapnp.c
patching file hw/sparc/leon3.c
Hunk #1 succeeded at 207 (offset -7 lines).
patching file include/hw/sparc/grlib.h
Hunk #1 FAILED at 117.
1 out of 1 hunk FAILED -- saving rejects to file include/hw/sparc/grlib.h.rej

Could be that qemu has moved since the patches were make, I will try to take a 
look ...

Jiri.



___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: fenv on RISC-V

[Jiri Gaisler]

Having said that, I will check if the generation of FP exception flag for 
RISC-V in sis are as accurate as for SPARC. Generating the wrong flags could 
cause the type of failures we are seeing ...

On 8/14/19 10:42 PM, Jiri Gaisler wrote:
> Interesting. I can confirm that the griscv bsp is using hard floats and 
> doubles, it is compiled with -march=rv32imafd -mabi=ilp32d. The paranoia 
> benchmark runs successfully and uses float instructions and registers. The 
> sis simulator emulates all float and double instructions as define in the 
> RISC-V specification. So the failures in psxfenv01 are likely be due to some 
> gcc/newlib limitations or possibly some shortcomings in the RTEMS RISC-V port.
>
> Jiri.
>
> On 8/14/19 8:44 PM, Joel Sherrill wrote:
>> Hi
>>
>> I emailed Jim Wilson of SiFive and got a quick response. Much thanks
>> to him and this is his reply:
>>
>> ==
>> I don't have any embedded hardware that I can use for testing.  I just
>> have linux and simulators (qemu, gdb sim).  I haven't seen gcc
>> testsuite failures related to fenv, but not sure if those tests are
>> being run for embedded elf targets.  The testcase doesn't work with
>> gdb sim, probably a gdb sim bug.  It does work with qemu, but only if
>> I use a -march that has FP support.  Checking the code, it looks
>> pretty obvious, fegetexceptflag for instance is
>>
>> int fegetexceptflag(fexcept_t *flagp, int excepts)
>> {
>> #if __riscv_flen
>> ...
>> #endif
>>   return 0;
>> }
>>
>> __riscv_flen is the number of bits (bytes?) in the FP registers, and
>> is zero if this is target has no FP support.  So fenv for soft-float
>> targets hasn't been implemented.  Was probably implemented for hard
>> float targets because it is easy, we just directly read/write the fp
>> status register.
>>
>> feraiseexcept isn't fully supported, but that seems to be a standards
>> interpretation question.  RISC-V hardware doesn't have a way to
>> automatically trap when an exception is raised.  We can only set a bit
>> in the fp status register and something else needs to check that and
>> trap.  So is feraiseexcept full implemented if we set the bit but
>> don't trap?  Newlib says no.  Glibc says yes.  But glibc has
>> feenableexcept and FE_NOMASK_ENV.  Newlib does not.  So on RISC-V, all
>> exceptions are masked, and that can't be changed.
>> ==
>>
>> This test (and fenv in general) is unlikely to work on an target with
>> soft float per Jim and some newlib discussions. On those BSPs,
>> it may have to be marked as NA with a comment about soft float.
>> Unless the test is automatically disabled if the CPU_HARDWARE_FP
>> define in RTEMS is false. But this is always defined to FALSE on risc-v.
>>
>> Q: Is hardware FP even supported right now on RISC-V? I don't see the
>> context switch code assuming there are registers to switch.
>>
>> And as Jim notes, even on some hardware targets (yes RISC-V), some
>> things don't work.
>>
>> So let's try this on a HW FP target and see if the works.
>>
>> Then address how to automatically disable this test with fall back to
>> updating a lot of .tcfg files.
>>
>> --joel
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: fenv on RISC-V

[Jiri Gaisler]

Interesting. I can confirm that the griscv bsp is using hard floats and 
doubles, it is compiled with -march=rv32imafd -mabi=ilp32d. The paranoia 
benchmark runs successfully and uses float instructions and registers. The sis 
simulator emulates all float and double instructions as define in the RISC-V 
specification. So the failures in psxfenv01 are likely be due to some 
gcc/newlib limitations or possibly some shortcomings in the RTEMS RISC-V port.

Jiri.

On 8/14/19 8:44 PM, Joel Sherrill wrote:
> Hi
>
> I emailed Jim Wilson of SiFive and got a quick response. Much thanks
> to him and this is his reply:
>
> ==
> I don't have any embedded hardware that I can use for testing.  I just
> have linux and simulators (qemu, gdb sim).  I haven't seen gcc
> testsuite failures related to fenv, but not sure if those tests are
> being run for embedded elf targets.  The testcase doesn't work with
> gdb sim, probably a gdb sim bug.  It does work with qemu, but only if
> I use a -march that has FP support.  Checking the code, it looks
> pretty obvious, fegetexceptflag for instance is
>
> int fegetexceptflag(fexcept_t *flagp, int excepts)
> {
> #if __riscv_flen
> ...
> #endif
>   return 0;
> }
>
> __riscv_flen is the number of bits (bytes?) in the FP registers, and
> is zero if this is target has no FP support.  So fenv for soft-float
> targets hasn't been implemented.  Was probably implemented for hard
> float targets because it is easy, we just directly read/write the fp
> status register.
>
> feraiseexcept isn't fully supported, but that seems to be a standards
> interpretation question.  RISC-V hardware doesn't have a way to
> automatically trap when an exception is raised.  We can only set a bit
> in the fp status register and something else needs to check that and
> trap.  So is feraiseexcept full implemented if we set the bit but
> don't trap?  Newlib says no.  Glibc says yes.  But glibc has
> feenableexcept and FE_NOMASK_ENV.  Newlib does not.  So on RISC-V, all
> exceptions are masked, and that can't be changed.
> ==
>
> This test (and fenv in general) is unlikely to work on an target with
> soft float per Jim and some newlib discussions. On those BSPs,
> it may have to be marked as NA with a comment about soft float.
> Unless the test is automatically disabled if the CPU_HARDWARE_FP
> define in RTEMS is false. But this is always defined to FALSE on risc-v.
>
> Q: Is hardware FP even supported right now on RISC-V? I don't see the
> context switch code assuming there are registers to switch.
>
> And as Jim notes, even on some hardware targets (yes RISC-V), some
> things don't work.
>
> So let's try this on a HW FP target and see if the works.
>
> Then address how to automatically disable this test with fall back to
> updating a lot of .tcfg files.
>
> --joel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-tester with griscv

[Jiri Gaisler]

You should probably use --rtems-bsp=griscv-sis . The griscv bsp uses the (now 
deleted) built-in sis in gdb...

I am preparing a patch to purge the stale tester bsps ...

Jiri.

On 8/12/19 8:22 PM, Joel Sherrill wrote:
> Hi
>
> Running riscv-rtems5-sis by hand, hello.exe runs. But when I try it with 
> rtems-tester, nothign passes and the tester hangs. I killed python after 
> about 30 minutes of CPU time.
>
>
> + /home/joel/rtems-work/rtems-tools//tester/rtems-test 
> --rtems-tools=/home/joel/rtems-work/tools/5 --rtems-bsp=griscv --log=run.log .
> RTEMS Testing - Tester, 5 (30a5cd65cc54)
> [ 1/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv/griscv: 
> base_sp.exe
> [ 8/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv/griscv: nsecs.exe
> [ 2/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv/griscv: 
> capture.exe
> [ 6/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv/griscv: hello.exe
> [ 5/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv/griscv: 
> fileio.exe
> [ 4/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv/griscv: 
> cxx_iostream.exe
> [ 3/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv/griscv: 
> cdtest.exe
> [10/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv/griscv: 
> ticker.exe
> [ 7/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv/griscv: 
> minimum.exe
> [ 9/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv/griscv: 
> paranoia.exe
> [11/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv/griscv: 
> unlimited.exe
> ^Cabort: user terminated
>
> Any ideas?
>
> Thanks.
>
> --joel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Problem: RSB does no longer install stand-alone sis

[Jiri Gaisler]

On 8/11/19 2:35 AM, Chris Johns wrote:
> On 10/8/19 11:17 pm, Jiri Gaisler wrote:
>> The problem comes from a commit to source-builder/config/sis-2-1.cfg,
>> made on July 23. 
> I am aware this is the problem and a revert may work for you but I seem to
> remember it did a problem but I cannot remember what. :)
OK. I ran RSB on Freebsd, MacOSX, ubuntu 18.04 and WSL before pushing the 
revert to minimize the likelihood of me breaking anything.
>
> I would prefer we have the configs in the RSB use `%{host_build_flags}` 
> because
> in that expanded macro is the logic that handles all hosts and situations we
> have found over the years.
>
>> If I revert that, installation works again. If nobody
>> objects, I will push a revert in about an hour and we can debug this at
>> a later stage.
> It hard for me to object or comment when I am not awake. Maybe a day or so 
> would
> be a better time frame and on a weekend a bit longer maybe be needed. :)

Sorry, I got a bit impatient there! Just trying to get at least one version of 
sis to compile and install. I will show more restraint next time ... :-)


Jiri.


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RISC-V Test Results

[Jiri Gaisler]

On 8/8/19 3:33 PM, Joel Sherrill wrote:
> Hi
>
> If you are subscribed to the build@ mailing list, then you saw the
> flurry of test
> results from over night. I built every variant and ran the test suite
> with RTEMS 
> debug on and off.  Here are some observations:
>
> + rv64imafd only has one test pass
> + rv64_iamd_medany only has one test pass
> + Generally speaking, 17-19 tests failed or timed out on every variant
> with 
>    551-553 passing. It would be great for someone to mark the tests in
> the 
>    tcfg files as expected fails.
>
> Hopefully this gives someone incentive to look into the failures.
>
> I would also run them on qemu but I don't think we have an RSB recipe
> for a 
> Qemu with RISC-V support.


I don't know about RV64, but most RV32 tests pass on sis using the
griscv bsp:

$ rtems-test --rtems-bsp=riscv-sis riscv-rtems5/c/griscv/testsuites
--log=all.txt

Passed:    633
Failed:  0
User Input:  5
Expected Fail:   0
Indeterminate:   0
Benchmark:   3
Timeout: 2
Invalid: 0
Wrong Version:   0
Wrong Build: 0
Wrong Tools: 0
--
Total: 643
User Input:
 monitor.exe
 termios.exe
 top.exe
 capture.exe
 fileio.exe
Benchmark:
 whetstone.exe
 dhrystone.exe
 linpack.exe
Timeouts:
 crypt01.exe
 smpmrsp01.exe
Average test time: 0:00:00.354592
Testing time : 0:03:48.002439

The crypt01 would succeed if the timeout limit would be a bit longer.
smpmrsp01 never terminates, this is most likely a simulator issue.
Remaining tests including SMP pass as expected.

Jiri.

>
> --joel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Problem: RSB does no longer install stand-alone sis

[Jiri Gaisler]

The problem comes from a commit to source-builder/config/sis-2-1.cfg,
made on July 23. If I revert that, installation works again. If nobody
objects, I will push a revert in about an hour and we can debug this at
a later stage.

Jiri.

On 8/9/19 2:34 AM, Chris Johns wrote:
> On 9/8/19 7:59 am, Gedare Bloom wrote:
>> On Thu, Aug 8, 2019 at 3:53 PM Gedare Bloom  wrote:
>>> I can confirm something is wrong. The install step does copy something
>>> though, I get a tree like this:
>>> /share/rtems/rsb:
>>> sis-2.17-x86_64-linux-gnu-1.txt  sis-2.17-x86_64-linux-gnu-1.xml
>>>
>>> I gave --log option to sb-set-builder. I can see the build compiled.
>>>
>>> It looks like %clean is running before %copy. That looks suspicious to me.
>>>
>> Nvm, I think that may be normal.  I don't have any more guesses at the 
>> moment!
>>
> Thanks for taking the time to look. I must have broken something. I will take 
> a
> look this weekend. Sorry about this.
>
> Chris
>>> On Thu, Aug 8, 2019 at 3:43 PM Jiri Gaisler  wrote:
>>>> RSB does not longer install the stand-alone version of sis. Even though 
>>>> the RSB log claims is does, the binary is not copied to the install 
>>>> location:
>>>>
>>>> installing: sis-2.17-x86_64-linux-gnu-1 -> /opt/rtems/5does nothing 
>>>> 
>>>>
>>>> There has been a few commits that changes the RSB install scripts but I am 
>>>> not able to see where it goes wrong. Maybe someone more enlightened than 
>>>> me could look at this.
>>>>
>>>> Building sis as bare tool has that same problem. The binary is built but 
>>>> not installed:
>>>>
>>>> rtems-source-builder/bare$ ../source-builder/sb-set-builder 
>>>> --prefix=/opt/rtems/5 devel/sis
>>>> RTEMS Source Builder - Set Builder, 5 (e5460e9ecb99)
>>>> Build Set: devel/sis
>>>> config: devel/sis-2-1.cfg
>>>> package: sis-2.17-x86_64-linux-gnu-1
>>>> building: sis-2.17-x86_64-linux-gnu-1
>>>> sizes: sis-2.17-x86_64-linux-gnu-1: 3.770MB (installed: 633.499KB)
>>>> cleaning: sis-2.17-x86_64-linux-gnu-1
>>>> reporting: devel/sis-2-1.cfg -> sis-2.17-x86_64-linux-gnu-1.txt
>>>> reporting: devel/sis-2-1.cfg -> sis-2.17-x86_64-linux-gnu-1.xml
>>>> installing: sis-2.17-x86_64-linux-gnu-1 -> /opt/rtems/5
>>>> Build Set: Time 0:00:04.271759
>>>>  $
>>>>
>>>> $ ls -l /opt/rtems/5/bin/*sis*
>>>> ls: cannot access '/opt/rtems/5/bin/*sis*': No such file or directory
>>>>
>>>>
>>>> ___
>>>> devel mailing list
>>>> devel@rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: sis/gdb on Cygwin

[Jiri Gaisler]

On 8/9/19 8:34 PM, Jiri Gaisler wrote:
>
>
> On 8/9/19 3:24 PM, Joel Sherrill wrote:
>> I thought I saw a patch pushed yesterday afternoon but a fresh build today 
>> shows the same
>> breakage. 
>>
>> Jiri .. feel free to push a fix for this and I will test when I get back.
> The problem right now is that RSB has some breakage which causes the 
> stand-alone version of sis not to be installed. If I push the patch, then no 
> sis at all will be installed. I will try to find some time to look at the 
> cygwin build problem, until Chris gets some time to look at the RSB issue ...

I tried to build gdb on cygwin but failed on configuration issues and python3 
problems. Cygwin has a million packages with various versions and it is hard to 
figure out what needs to be installed. For windows 10 users, my recommendation 
is to use WSL with ubuntu 18.04. I built RSB without issues in WSL at near 
native speed, and no windows specific patches are needed. Even async SIGIO on 
sockets works ...! With windows 7 being unsupported from January 2020, is it 
really necessary to maintaining msys/mingw/cygwin support ...?



>>
>> On Thu, Aug 8, 2019 at 2:37 PM Joel Sherrill > <mailto:j...@rtems.org>> wrote:
>>
>> This is really easy to fix and hopefully Jiri can produce a patch since 
>> I am about to leave for the weekend.
>>
>> The git master has this in erc32 configure.ac <http://configure.ac>. It 
>> should be in both sis/configure.ac <http://configure.ac> and 
>> erc32/configure.ac <http://configure.ac> 
>> in our gdb 8.2.1 with patches.
>>
>> # Keep in sync with gdb's configure.ac <http://configure.ac> list.
>> AC_SEARCH_LIBS(tgetent, [termcap tinfo curses ncurses],
>>   [TERMCAP=$ac_cv_search_tgetent], [TERMCAP=""])
>> if test x$sim_cv_os_cygwin = xyes; then
>>   TERMCAP="${TERMCAP} -luser32"
>> fi
>> AC_SUBST(TERMCAP)
>>
>> The gdb version we are using has some old hack-ish code specific to 
>> Cygwin and termcap which is 
>> now not needed. Unfortunately, that same code is in sis/configure.ac 
>> <http://configure.ac>. 
>>
>> Please and thank you. :)
>>
>> --joel
>>
>>
>> On Wed, Aug 7, 2019 at 8:37 PM Chris Johns > <mailto:chr...@rtems.org>> wrote:
>>
>> On 8/8/19 5:46 am, Joel Sherrill wrote:
>> > On Wed, Aug 7, 2019 at 2:33 PM Jiri Gaisler > <mailto:j...@gaisler.se>
>> > <mailto:j...@gaisler.se <mailto:j...@gaisler.se>>> wrote:
>> >
>> >
>> >     On 8/7/19 8:22 PM, Joel Sherrill wrote:
>> >     > Hi
>> >     >
>> >     > Looks like Cygwin has libncurses but doesn't install the 
>> libtermcap.
>> >     > compatibility library.
>> >     >
>> >     > https://cygwin.com/ml/cygwin/2010-10/msg00018.html  says to 
>> link
>> >     > against ncurses.
>> >     >
>> >     >  gdb-8.2.1/sim/sis/../.. `echo -Dsparc-rtems5 | sed 
>> s/-rtems.//`   -I.
>> >     > -I../../../gdb-8.2.1/sim/sis -I../common
>> >     > -I../../../gdb-8.2.1/sim/sis/../common -I../../include
>> >     > -I../../../gdb-8.2.1/sim/sis/../../include -I../../bfd
>> >     > -I../../../gdb-8.2.1/sim/sis/../../bfd -I../../opcodes
>> >     > -I../../../gdb-8.2.1/sim/sis/../../opcodes  -g -O2 -o sis \
>> >     >   sis.o exec.o erc32.o func.o help.o float.o grlib.o leon3.o 
>> leon2.o
>> >     >  ../../bfd/libbfd.a ../../opcodes/libopcodes.a
>> >     >  ../../libiberty/libiberty.a -L../../zlib -lz
>> >     > ../../readline/libreadline.a `if test -r
>> >     > ../../libtermcap/libtermcap.a; then echo
>> >     > ../../libtermcap/libtermcap.a; else echo -ltermcap; fi` 
>> -luser32 -lm
>> >     > 
>> /usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/ld:
>> >     > cannot find -ltermcap
>> >     > collect2: error: ld returned 1 exit status
>> >     >
>> >     > Is the solution to just add -lncurses to the list of 
>> libraries it
>> >     > looks for?
>> >     >
>> >     > Hopefully someone has some insight into this one.
>> >
>>

Re: sis/gdb on Cygwin

[Jiri Gaisler]

On 8/9/19 3:24 PM, Joel Sherrill wrote:
> I thought I saw a patch pushed yesterday afternoon but a fresh build
> today shows the same
> breakage. 
>
> Jiri .. feel free to push a fix for this and I will test when I get back.
The problem right now is that RSB has some breakage which causes the
stand-alone version of sis not to be installed. If I push the patch,
then no sis at all will be installed. I will try to find some time to
look at the cygwin build problem, until Chris gets some time to look at
the RSB issue ...
>
> On Thu, Aug 8, 2019 at 2:37 PM Joel Sherrill  <mailto:j...@rtems.org>> wrote:
>
> This is really easy to fix and hopefully Jiri can produce a patch
> since I am about to leave for the weekend.
>
> The git master has this in erc32 configure.ac
> <http://configure.ac>. It should be in both sis/configure.ac
> <http://configure.ac> and erc32/configure.ac <http://configure.ac> 
> in our gdb 8.2.1 with patches.
>
> # Keep in sync with gdb's configure.ac <http://configure.ac> list.
> AC_SEARCH_LIBS(tgetent, [termcap tinfo curses ncurses],
>   [TERMCAP=$ac_cv_search_tgetent], [TERMCAP=""])
> if test x$sim_cv_os_cygwin = xyes; then
>   TERMCAP="${TERMCAP} -luser32"
> fi
> AC_SUBST(TERMCAP)
>
> The gdb version we are using has some old hack-ish code specific
> to Cygwin and termcap which is 
> now not needed. Unfortunately, that same code is in
> sis/configure.ac <http://configure.ac>. 
>
> Please and thank you. :)
>
> --joel
>
>
> On Wed, Aug 7, 2019 at 8:37 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
>
> On 8/8/19 5:46 am, Joel Sherrill wrote:
> > On Wed, Aug 7, 2019 at 2:33 PM Jiri Gaisler  <mailto:j...@gaisler.se>
> > <mailto:j...@gaisler.se <mailto:j...@gaisler.se>>> wrote:
> >
> >
> >     On 8/7/19 8:22 PM, Joel Sherrill wrote:
> >     > Hi
> >     >
> >     > Looks like Cygwin has libncurses but doesn't install
> the libtermcap.
> >     > compatibility library.
> >     >
> >     > https://cygwin.com/ml/cygwin/2010-10/msg00018.html 
> says to link
> >     > against ncurses.
> >     >
> >     >  gdb-8.2.1/sim/sis/../.. `echo -Dsparc-rtems5 | sed
> s/-rtems.//`   -I.
> >     > -I../../../gdb-8.2.1/sim/sis -I../common
> >     > -I../../../gdb-8.2.1/sim/sis/../common -I../../include
> >     > -I../../../gdb-8.2.1/sim/sis/../../include -I../../bfd
> >     > -I../../../gdb-8.2.1/sim/sis/../../bfd -I../../opcodes
> >     > -I../../../gdb-8.2.1/sim/sis/../../opcodes  -g -O2 -o
> sis \
> >     >   sis.o exec.o erc32.o func.o help.o float.o grlib.o
> leon3.o leon2.o
> >     >  ../../bfd/libbfd.a ../../opcodes/libopcodes.a
> >     >  ../../libiberty/libiberty.a -L../../zlib -lz
> >     > ../../readline/libreadline.a `if test -r
> >     > ../../libtermcap/libtermcap.a; then echo
> >     > ../../libtermcap/libtermcap.a; else echo -ltermcap;
> fi` -luser32 -lm
> >     >
> 
> /usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/ld:
> >     > cannot find -ltermcap
> >     > collect2: error: ld returned 1 exit status
> >     >
> >     > Is the solution to just add -lncurses to the list of
> libraries it
> >     > looks for?
> >     >
> >     > Hopefully someone has some insight into this one.
> >
> >     How about a patch that disables building sis inside gdb
> and only use the
> >     newer stand-alone sis version?
>
> +1
>
> > As long as the rtems tester supports it, I am cool with that.
>
> It should. Please find the existing `sis` run or gdb INI
> configuration files and
> replace with SIS. I suspect you can get down to one INI config
> rather than the
> run and gdb versions we currently have.
>
> > My goal is to begin to do regular builds and test sweeps on
> Cygwin
> > and Mingw and report to build@. So the RSB and tester need
> to work. :) 
> >
>
> Nice.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RSB PATCH v2] Disable built-in sis in gdb.

[Jiri Gaisler]

On 8/8/19 11:48 PM, Joel Sherrill wrote:
> Unless it causes an issue, I would really like to leave sis enabled inside 
> gdb. It really is such a nice environment to debug.

Stand-alone sis has a gdb server, so the gdb debug environment should be 
identical. In gdb, just do target extended-remote localhost:1234 instead of 
target sim. Keeping sis inside gdb has a number of problems:

* The sis patches will never be accepted into the gdb mainline

* We will have to maintain a patch set for each gdb version

* Making new versions of sis is cumbersome since we have to provided patches 
rather than just a git repo

* No support for data watchpoints in the gdb sim interface

* Build problems for Cygwin

I also like the simplicity of a built-in simulator, but a stand-alone sim is 
just so much easier to develop and maintain...

>
> On Thu, Aug 8, 2019, 4:47 PM Jiri Gaisler  <mailto:j...@gaisler.se>> wrote:
>
> This time it also works on RISC-V ... :-)
>
> ___
> devel mailing list
> devel@rtems.org <mailto:devel@rtems.org>
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[RSB PATCH v2] Disable built-in sis in gdb.

[Jiri Gaisler]

This time it also works on RISC-V ... :-)

>From e5460e9ecb9995298319653460fab8852274c211 Mon Sep 17 00:00:00 2001
From: Jiri Gaisler 
Date: Thu, 8 Aug 2019 22:20:39 +0200
Subject: [PATCH] Disable built-in sis in gdb.

	* Avoid building problems on Cygwin et al.
	* Avoid mix-up with more recent stand-alone sis version.
---
 rtems/config/tools/rtems-gdb-8.2.1-1.cfg | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/rtems/config/tools/rtems-gdb-8.2.1-1.cfg b/rtems/config/tools/rtems-gdb-8.2.1-1.cfg
index f294207..73e38f8 100644
--- a/rtems/config/tools/rtems-gdb-8.2.1-1.cfg
+++ b/rtems/config/tools/rtems-gdb-8.2.1-1.cfg
@@ -9,16 +9,10 @@
 %define gdb_src_ext xz
 %hash sha512 gdb-%{gdb_version}.tar.xz 2aa81cfd389bb48c35d7d9f95cc10e88b4f7ad4597bdde0f8f1fd312f60f10d9fb2cc6e5a9355227d89ff328f7feb0fc411a69394560cafeb9fa75d35d896d11
 
-%patch add gdb https://devel.rtems.org/raw-attachment/ticket/3460/gdb-8.2.1-sis-2.11.patch.bz2
-%hash sha512 gdb-8.2.1-sis-2.11.patch.bz2 e7edaab94b36d0261a68c07780f881a7dcfaacc9a4c62a006d4b3a7cb24764455fd0081c9c4c30466f04fcbe75ff233743ba3a720bb909328670d74d47cf22a0
-
 %patch add gdb https://devel.rtems.org/raw-attachment/ticket/3460/gdb-8.2.1-riscv-config.patch
 %hash sha512 gdb-8.2.1-riscv-config.patch 193eb9ddfc79c494eb8b1e971cc230f5f01b1653ba3f85b8541b973dfcd23ead65dea7a638a6ccdb7f6fc0201f9a764bfdf3f89b2d9afba5c13a5ca97e52ce9d
 
-%patch add gdb https://devel.rtems.org/raw-attachment/ticket/3460/gdb-8.2.1-sis-2.12.patch
-%hash sha512 gdb-8.2.1-sis-2.12.patch ee321be58c4788580eb16f2e9c7329fddd6d9c22922f22f93a33aaa7ff97804cdf3539de835756109b99b4c975ec68880d438debebe22923c303b565fe2188da
-
-%patch add gdb  https://devel.rtems.org/raw-attachment/ticket/3460/gdb-8.2.1-sis-2.13.patch
-%hash sha512 gdb-8.2.1-sis-2.13.patch 8239ef23240ef27f64e4deb2a81f91e6d189572fbfd4f5b26e525f2907413f8f09e643fa4ae793616feeeb5db1878a0caa5eea5c9c51ad946ad930adc46e4599
+%patch add gdb https://devel.rtems.org/raw-attachment/ticket/3460/gdb-8.2.1-disable-sis.patch
+%hash sha512 gdb-8.2.1-disable-sis.patch 295f915d6663b397a25692d89059cccbedf686fd6b1e0b5a7f04dff0a8e4b06614d4ffcde19a9790e122c0f43de1d561f3e0ba75c03ad215a906e8cd051c6960
 
 %include %{_configdir}/gdb-8-1.cfg
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Problem: RSB does no longer install stand-alone sis

[Jiri Gaisler]

RSB does not longer install the stand-alone version of sis. Even though the RSB 
log claims is does, the binary is not copied to the install location:

installing: sis-2.17-x86_64-linux-gnu-1 -> /opt/rtems/5    does nothing 

There has been a few commits that changes the RSB install scripts but I am not 
able to see where it goes wrong. Maybe someone more enlightened than me could 
look at this.

Building sis as bare tool has that same problem. The binary is built but not 
installed:

rtems-source-builder/bare$ ../source-builder/sb-set-builder 
--prefix=/opt/rtems/5 devel/sis
RTEMS Source Builder - Set Builder, 5 (e5460e9ecb99)
Build Set: devel/sis
config: devel/sis-2-1.cfg
package: sis-2.17-x86_64-linux-gnu-1
building: sis-2.17-x86_64-linux-gnu-1
sizes: sis-2.17-x86_64-linux-gnu-1: 3.770MB (installed: 633.499KB)
cleaning: sis-2.17-x86_64-linux-gnu-1
reporting: devel/sis-2-1.cfg -> sis-2.17-x86_64-linux-gnu-1.txt
reporting: devel/sis-2-1.cfg -> sis-2.17-x86_64-linux-gnu-1.xml
installing: sis-2.17-x86_64-linux-gnu-1 -> /opt/rtems/5
Build Set: Time 0:00:04.271759
 $

$ ls -l /opt/rtems/5/bin/*sis*
ls: cannot access '/opt/rtems/5/bin/*sis*': No such file or directory


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RSB PATCH] Disable built-in sis in gdb.

[Jiri Gaisler]

OK, this patch kills building gdb for RISC-V - I will resubmit with a proper 
fix ...

Jiri.

On 8/8/19 10:45 PM, Jiri Gaisler wrote:
> Small patch for RSB  to disable building sis inside gdb.
>
> I will follow up with a patch for rtems-tools to clean up rtems-test targets 
> for sis ...
>
> Jiri.
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[RSB PATCH] Disable built-in sis in gdb.

[Jiri Gaisler]

Small patch for RSB  to disable building sis inside gdb.

I will follow up with a patch for rtems-tools to clean up rtems-test targets 
for sis ...

Jiri.

>From 9165334d3ffe9996276de9c7843998124890c3e3 Mon Sep 17 00:00:00 2001
From: Jiri Gaisler 
Date: Thu, 8 Aug 2019 22:20:39 +0200
Subject: [PATCH] Disable built-in sis in gdb.

	* Avoid building problems on Cygwin et al.
	* Avoid mix-up with more recent stand-alone sis version.
---
 rtems/config/tools/rtems-gdb-8.2.1-1.cfg | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/rtems/config/tools/rtems-gdb-8.2.1-1.cfg b/rtems/config/tools/rtems-gdb-8.2.1-1.cfg
index f294207..4a4b41c 100644
--- a/rtems/config/tools/rtems-gdb-8.2.1-1.cfg
+++ b/rtems/config/tools/rtems-gdb-8.2.1-1.cfg
@@ -9,16 +9,7 @@
 %define gdb_src_ext xz
 %hash sha512 gdb-%{gdb_version}.tar.xz 2aa81cfd389bb48c35d7d9f95cc10e88b4f7ad4597bdde0f8f1fd312f60f10d9fb2cc6e5a9355227d89ff328f7feb0fc411a69394560cafeb9fa75d35d896d11
 
-%patch add gdb https://devel.rtems.org/raw-attachment/ticket/3460/gdb-8.2.1-sis-2.11.patch.bz2
-%hash sha512 gdb-8.2.1-sis-2.11.patch.bz2 e7edaab94b36d0261a68c07780f881a7dcfaacc9a4c62a006d4b3a7cb24764455fd0081c9c4c30466f04fcbe75ff233743ba3a720bb909328670d74d47cf22a0
-
-%patch add gdb https://devel.rtems.org/raw-attachment/ticket/3460/gdb-8.2.1-riscv-config.patch
-%hash sha512 gdb-8.2.1-riscv-config.patch 193eb9ddfc79c494eb8b1e971cc230f5f01b1653ba3f85b8541b973dfcd23ead65dea7a638a6ccdb7f6fc0201f9a764bfdf3f89b2d9afba5c13a5ca97e52ce9d
-
-%patch add gdb https://devel.rtems.org/raw-attachment/ticket/3460/gdb-8.2.1-sis-2.12.patch
-%hash sha512 gdb-8.2.1-sis-2.12.patch ee321be58c4788580eb16f2e9c7329fddd6d9c22922f22f93a33aaa7ff97804cdf3539de835756109b99b4c975ec68880d438debebe22923c303b565fe2188da
-
-%patch add gdb  https://devel.rtems.org/raw-attachment/ticket/3460/gdb-8.2.1-sis-2.13.patch
-%hash sha512 gdb-8.2.1-sis-2.13.patch 8239ef23240ef27f64e4deb2a81f91e6d189572fbfd4f5b26e525f2907413f8f09e643fa4ae793616feeeb5db1878a0caa5eea5c9c51ad946ad930adc46e4599
+%patch add gdb https://devel.rtems.org/raw-attachment/ticket/3460/gdb-8.2.1-disable-sis.patch
+%hash sha512 gdb-8.2.1-disable-sis.patch 295f915d6663b397a25692d89059cccbedf686fd6b1e0b5a7f04dff0a8e4b06614d4ffcde19a9790e122c0f43de1d561f3e0ba75c03ad215a906e8cd051c6960
 
 %include %{_configdir}/gdb-8-1.cfg
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: sis/gdb on Cygwin

[Jiri Gaisler]

On 8/7/19 8:22 PM, Joel Sherrill wrote:
> Hi
>
> Looks like Cygwin has libncurses but doesn't install the libtermcap.
> compatibility library.
>
> https://cygwin.com/ml/cygwin/2010-10/msg00018.html  says to link
> against ncurses.
>
>  gdb-8.2.1/sim/sis/../.. `echo -Dsparc-rtems5 | sed s/-rtems.//`   -I.
> -I../../../gdb-8.2.1/sim/sis -I../common
> -I../../../gdb-8.2.1/sim/sis/../common -I../../include
> -I../../../gdb-8.2.1/sim/sis/../../include -I../../bfd
> -I../../../gdb-8.2.1/sim/sis/../../bfd -I../../opcodes
> -I../../../gdb-8.2.1/sim/sis/../../opcodes  -g -O2 -o sis \
>   sis.o exec.o erc32.o func.o help.o float.o grlib.o leon3.o leon2.o
>  ../../bfd/libbfd.a ../../opcodes/libopcodes.a
>  ../../libiberty/libiberty.a -L../../zlib -lz
> ../../readline/libreadline.a `if test -r
> ../../libtermcap/libtermcap.a; then echo
> ../../libtermcap/libtermcap.a; else echo -ltermcap; fi` -luser32 -lm
> /usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -ltermcap
> collect2: error: ld returned 1 exit status
>
> Is the solution to just add -lncurses to the list of libraries it
> looks for?
>
> Hopefully someone has some insight into this one.

How about a patch that disables building sis inside gdb and only use the
newer stand-alone sis version?

Jiri.


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[RSB PATCH 1/2] Add bare target to build standalone sis (devel/sis)

[Jiri Gaisler]

---
 bare/config/devel/sis-2-1.cfg | 18 +
 bare/config/devel/sis.bset|  8 
 source-builder/config/sis-2-1.cfg | 66 +++
 3 files changed, 92 insertions(+)
 create mode 100644 bare/config/devel/sis-2-1.cfg
 create mode 100644 bare/config/devel/sis.bset
 create mode 100644 source-builder/config/sis-2-1.cfg

diff --git a/bare/config/devel/sis-2-1.cfg b/bare/config/devel/sis-2-1.cfg
new file mode 100644
index 000..ad6e527
--- /dev/null
+++ b/bare/config/devel/sis-2-1.cfg
@@ -0,0 +1,18 @@
+#
+# Sis emulator 2.16
+#
+
+%if %{release} == %{nil}
+%define release 1
+%endif
+
+%include %{_configdir}/base.cfg
+
+%define sis_version 2.16
+%hash sha256 sis-%{sis_version}.tar.bz2 
37cdb8f5cc1255e273423f580f5c76755e5851dabb677f6bc1100f27557b8dce
+
+#
+# The sis build instructions. We use 2.15
+#
+%include %{_configdir}/sis-2-1.cfg
+
diff --git a/bare/config/devel/sis.bset b/bare/config/devel/sis.bset
new file mode 100644
index 000..50ffbae
--- /dev/null
+++ b/bare/config/devel/sis.bset
@@ -0,0 +1,8 @@
+#
+# Build set for sis emulator 
+#
+
+%define release 1
+
+devel/sis-2-1
+
diff --git a/source-builder/config/sis-2-1.cfg 
b/source-builder/config/sis-2-1.cfg
new file mode 100644
index 000..a07b2db
--- /dev/null
+++ b/source-builder/config/sis-2-1.cfg
@@ -0,0 +1,66 @@
+#
+# Sis 2.xx Version 1.
+#
+# This configuration file configure's, make's and install's sis
+#
+
+Name:  sis-%{sis_version}-%{_host}-%{release}
+Summary:   Sis v%{sis_version} for host %{_host}
+Version:   %{sis_version}
+Release:   %{release}
+#URL: http://www.gnu.org/software/sis/
+
+#
+# Source
+#
+%define sis_source sis-%{sis_version}
+%source set sis https://git.rtems.org/sis/snapshot/%{sis_source}.tar.bz2
+
+#
+# Prepare the source code.
+#
+%prep
+  build_top=$(pwd)
+
+  %source setup sis -q -n sis-%{sis_version}
+
+  cd ${build_top}
+
+%build
+  build_top=$(pwd)
+
+  cd sis-%{sis_version}
+
+  ac_prefix=%{_prefix}
+
+  if test "%{_build}" != "%{_host}" ; then
+CFLAGS_FOR_BUILD="-g -O2 -Wall"
+  fi
+  export CFLAGS CFLAGS_FOR_BUILD CC
+
+  if test "%{_target}" != "" ; then
+SIS_PREFIX="%{_target}-"
+  fi
+  CFLAGS="$SB_CFLAGS" \
+  ./configure \
+--build=%{_build} --host=%{_host} \
+--program-prefix="$SIS_PREFIX" \
+--prefix=${ac_prefix}
+
+  %{__make} %{?_smp_mflags} all
+
+  unset CFLAGS_FOR_BUILD
+
+  cd ${build_top}
+
+%install
+  build_top=$(pwd)
+
+  export PATH="%{_bindir}:${PATH}"
+  %{__rmdir} $SB_BUILD_ROOT
+
+  cd sis-%{sis_version}
+
+  %{__make} DESTDIR=$SB_BUILD_ROOT install
+
+  cd ${build_top}
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[RSB PATCH 0/2] Add standalone SIS as build target

[Jiri Gaisler]

Two patches to add standalone SIS as bare target, and to build it for 
SPARC and RISC-V tool-chains.

Jiri Gaisler (2):
  Add bare target to build standalone sis (devel/sis)
  Build standalone sis for SPARC and RISC-V targets

 bare/config/devel/sis-2-1.cfg | 18 +
 bare/config/devel/sis.bset|  8 
 rtems/config/5/rtems-riscv.bset   |  1 +
 rtems/config/5/rtems-sparc.bset   |  2 +
 source-builder/config/sis-2-1.cfg | 66 +++
 5 files changed, 95 insertions(+)
 create mode 100644 bare/config/devel/sis-2-1.cfg
 create mode 100644 bare/config/devel/sis.bset
 create mode 100644 source-builder/config/sis-2-1.cfg

-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[RSB PATCH 2/2] Build standalone sis for SPARC and RISC-V targets

[Jiri Gaisler]

---
 rtems/config/5/rtems-riscv.bset | 1 +
 rtems/config/5/rtems-sparc.bset | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/rtems/config/5/rtems-riscv.bset b/rtems/config/5/rtems-riscv.bset
index 99f0754..6e9de99 100644
--- a/rtems/config/5/rtems-riscv.bset
+++ b/rtems/config/5/rtems-riscv.bset
@@ -15,3 +15,4 @@ tools/rtems-binutils-2.32
 tools/rtems-gcc-9.1.0-newlib-5c2a3661c
 tools/rtems-tools-5-1
 tools/rtems-kernel-5
+devel/sis-2-1.cfg
diff --git a/rtems/config/5/rtems-sparc.bset b/rtems/config/5/rtems-sparc.bset
index 187d337..23ddaca 100644
--- a/rtems/config/5/rtems-sparc.bset
+++ b/rtems/config/5/rtems-sparc.bset
@@ -2,3 +2,5 @@
 %define rtems_arch sparc
 %define with_libgomp
 %include 5/rtems-default.bset
+devel/sis-2-1.cfg
+
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RSB SPARC gdb 8.2.1 Build Issue on MSYS2 (64-bit)

[Jiri Gaisler]

On 6/4/19 12:59 AM, Joel Sherrill wrote:
> Hi
>
> I was trying to build the sparc tools on MSYS2 today. SIS was enabled
> by default and failed to build. 
>
> Is it expected to build?
>
> Is it supposed to be disabled and the host is not properly detected by
> the RSB?
>
> Not sure which way to push on the fix.

Did you catch any specific error output from the build?

Maybe it is time to switch to the standalone sis - it does build/work on
msys2 (but has the same ctrl-c limitation as cygwin).

Jiri.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Potential SIS or RTEMS/libbsd problem

[Jiri Gaisler]

On 6/3/19 4:14 AM, Chris Johns wrote:
> On 1/6/19 6:58 am, Jiri Gaisler wrote:
>> I have pushed a small patch to fix some build problems on Cygwin and 
>> FreeBSD. I don't know how fast we want to progress, but I could prepare a 
>> patch for RSB to use the new sis repository and skip the sis patches for 
>> gdb. I guess this would also have include updating any documentation that 
>> refers to the old sis ...
> I am happy to move to using a separate sis executable built by the RSB and for
> the gdb versions and patches to stop being maintained.
OK, I will look at this on some rainy day ...
>
> By the way have you looked at the GDB pipe interface to the a remote 
> executable?
> It would be interesting to know how using that transport effects the ^C issue 
> on
> Windows.

I will check this. However, I thought pipes were unidirectional on linux...?

Jiri.


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Potential SIS or RTEMS/libbsd problem

[Jiri Gaisler]

On 5/31/19 7:06 AM, Sebastian Huber wrote:
> On 27/05/2019 11:03, Jiri Gaisler wrote:
>> On 5/23/19 1:47 PM, Sebastian Huber wrote:
>>> On 22/05/2019 22:34, Jiri Gaisler wrote:
>>>> Adding a pseudo-random delay of 0 - 15 clocks to each trap/interrupt 
>>>> causes the test to pass on all cpu configurations with the default time 
>>>> slice (50)..! I am not sure what this means - it could be a hidden race 
>>>> condition, the algorithm might need some jitter to work or it could still 
>>>> be a simulator issue.
>>> Adding a pseudo-random delay to interrupts is probably not enough. 
>>> Sometimes the atomic instructions are carried out with interrupts disabled. 
>>> Would it be possible to add a pseudo-random delay to each of the 
>>> instruction cycles per core?
>>>
>> I have pushed a patch to my sis repository at rtems.org that adds an 
>> emulated L1 cache to SMP configurations and also improves timing for a few 
>> instructions. The epoch.exe test now runs on both SPARC and RISC-V for 3 and 
>> 4 cpus. To pass on 2 cpus, a smaller time-slice in the simulator is needed, 
>> e.g. -d 17. Feel free to test...
>
> Thanks for your update, I cloned the repository and it builds fine on my 
> machine. The instruction trace is really nice. If I have a bit of time I will 
> try to figure out why the EBR algorithm ends up in the endless loop.

Good to hear. Note that epoch01 now passes for both SPARC and RISC-V even 
without the simulated L1 cache. This was done by adding proper timing to all 
MUL/DIV instructions and to add a more random delay to the trap response time.

I have pushed a small patch to fix some build problems on Cygwin and FreeBSD. I 
don't know how fast we want to progress, but I could prepare a patch for RSB to 
use the new sis repository and skip the sis patches for gdb. I guess this would 
also have include updating any documentation that refers to the old sis ...

Jiri.


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: How important is Cygwin support for host tools?

[Jiri Gaisler]

On 5/30/19 2:46 PM, Joel Sherrill wrote:
>
>
> On Thu, May 30, 2019, 7:41 AM Jiri Gaisler  <mailto:j...@gaisler.se>> wrote:
>
> Does anyone still use Cygwin for RTEMS development? The reason I
> ask is
> that I have some portability issues for sis (no async I/O on
> sockets in
> Cygwin) and I would like to avoid some ugly workarounds if
> possible. In
> the age of virtualization and even WSL in Win 10, do we still need
> Cygwin ...?
>
>
> There are still users on Cygwin and we test there periodically to
> avoid breakage.
>
> It would be nice to see sis work on Cygwin but I understand if it won't.

There is really only one issue - when sis is connected to gdb, a running
program cannot be interrupted by pressing ctrl-C in gdb. The program can
be stopped by pressing ctrl-C in the simulator window instead, which is
maybe a sufficient workaround..? I will start by letting sis print a
warning for this if gdb mode is entered under cygwin. If there are (too)
many complaints, I will look at it again...

Jiri.


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

How important is Cygwin support for host tools?

[Jiri Gaisler]

Does anyone still use Cygwin for RTEMS development? The reason I ask is
that I have some portability issues for sis (no async I/O on sockets in
Cygwin) and I would like to avoid some ugly workarounds if possible. In
the age of virtualization and even WSL in Win 10, do we still need
Cygwin ...?

Jiri.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Potential SIS or RTEMS/libbsd problem

[Jiri Gaisler]

On 5/23/19 1:47 PM, Sebastian Huber wrote:
> On 22/05/2019 22:34, Jiri Gaisler wrote:
>> Adding a pseudo-random delay of 0 - 15 clocks to each trap/interrupt causes 
>> the test to pass on all cpu configurations with the default time slice 
>> (50)..! I am not sure what this means - it could be a hidden race condition, 
>> the algorithm might need some jitter to work or it could still be a 
>> simulator issue.
>
> Adding a pseudo-random delay to interrupts is probably not enough. Sometimes 
> the atomic instructions are carried out with interrupts disabled. Would it be 
> possible to add a pseudo-random delay to each of the instruction cycles per 
> core?
>
I have pushed a patch to my sis repository at rtems.org that adds an emulated 
L1 cache to SMP configurations and also improves timing for a few instructions. 
The epoch.exe test now runs on both SPARC and RISC-V for 3 and 4 cpus. To pass 
on 2 cpus, a smaller time-slice in the simulator is needed, e.g. -d 17. Feel 
free to test...

Jiri.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Potential SIS or RTEMS/libbsd problem

[Jiri Gaisler]

On 5/23/19 7:35 AM, Sebastian Huber wrote:
> On 22/05/2019 22:34, Jiri Gaisler wrote:
>> On 5/22/19 7:43 PM, Jiri Gaisler wrote:
>>> On 5/22/19 9:49 AM, Sebastian Huber wrote:
>>>> On 22/05/2019 09:39, Jiri Gaisler wrote:
>>>>> On 5/22/19 8:03 AM, Sebastian Huber wrote:
>>>>>> Hello,
>>>>>>
>>>>>> in the libbsd there is a test for the Epoch Based Reclamation:
>>>>>>
>>>>>> https://git.rtems.org/rtems-libbsd/tree/testsuite/epoch01/test_main.c
>>>>>>
>>>>>>
>>>>>> When I run this test using the leon3 BSP on real hardware (150MHz
>>>>>> NGMP FP) the test completes successfully.
>>>>>>
>>>>>> If I run the test on the SIS, it is stuck at some point (using "-m
>>>>>> 1" works):
>>>>>>
>>>>>> sparc-rtems5-sis -leon3 -nouartrx -r -tlim 200 s -m 2
>>>>>> build/sparc-rtems5-leon3-everything/epoch01.exe
>>>>>>
>>>>>>
>>>>> This test needs a shorter time-slice in the simulator to succeed (-d
>>>>> option). The more cpus, the lower number of clocks in the slice is
>>>>> needed. Through trial-and-error, these values seem to work:
>>>>>
>>>>> 2 CPUs: -m 2 -d 25
>>>>>
>>>>> 3 CPUs: -m 3 -d 10
>>>>>
>>>>> 4 CPUs will not work, even if -d 1 is set. This is most likely a
>>>>> simulator problem, I will try to find time to look at it in more
>>>>> detail. A quick trace shows that all CPUs are stuck in a loop
>>>>> checking for a lock or similar:
>>>>>
>>>> It seems cpu 2 and 3 are in _SMP_barrier_Wait(). The cpu 0 and 1 still
>>>> to some stuff in the EBR algorithm (ck_* functions). Maybe the
>>>> algorithm works only in case some random timing fluctuations occur.
>>> Either that or there is a hidden race condition in the test that does
>>> not show up on real hardware. I noticed that increasing the time slice
>>> actually make the test succeed even on 4 cpus ..!
>>>
>>> -m 2 -d 200    PASS
>>>
>>> -m 3 -d 200    PASS
>>>
>>> -m 4 -d 200    FAIL
>>>
>>> -m 4 -d 400    PASS!
>>>
>>> BUT
>>>
>>> -m 3 -d 400    FAIL!
>>>
>>> I will try to add random delays to the interrupt response time to
>>> see if
>>> that will make a difference. That is more inline with the real
>>> hardware ...
>> Adding a pseudo-random delay of 0 - 15 clocks to each trap/interrupt
>> causes the test to pass on all cpu configurations with the default
>> time slice (50)..! I am not sure what this means - it could be a
>> hidden race condition, the algorithm might need some jitter to work
>> or it could still be a simulator issue.
>>
>> Is there any chance that you could compile this test for sis-riscv?
>> RISC-V has different atomic operations and trap handlers so it would
>> be interesting to see if the test behaves differently.
>
> It locks up at the same spot:
>
> riscv-rtems5-sis -m 4 build/riscv-rtems5-griscv-default/epoch01.exe
>
>  SIS - SPARC/RISCV instruction simulator 2.13,  copyright Jiri Gaisler
> 2019
>  Bug-reports to j...@gaisler.se
>
>  RISCV emulation enabled, 4 cpus online, delta 50 clocks
>
> cpu0> run
> *** LIBBSD EPOCH 1 TEST ***
> nexus0: 
> 
>   
>     1059417
>   
>   
>     1059303
>     1049390
>   
>   
>     1058922
>     1049008
>     1061640
>   
>   
>     1058540
>     1048679
>     1061258
>     1061258
>   
>   
>     925414
>     100
>   
>   
>     704898
>     704835
>     46
>     45
>   
>   
>     589977
>     585688
>     592200
>     23
>     23
>     23
>   
>   
>     505834
>     501869
>     507615
>     507614
>     19
>     18
>     18
>     18
>   
>   
>     275348
>   
>   
>     275971
>     280381
>   
>   
>     275956
>     280283
>     280283
>   
>   
>     275800
>     280185
>     280185
>     280185
>   
>   
>     266212
>     68
>   
> Interrupt!
>  Stopped at time 975738600 (19514.772 ms)
> cpu0>
>
> The EBR is a core synchronization primitive in libbsd. It makes me a
> bit nervous to have this dependency on random fluctuations to make
> progress. I don't know the algorithm good enough to say if this is the
> expected behaviour. A real machine with such an exact relative
> instruction execution is probably non-existent.
>
> In general, you can lock up an SMP system quite easily if you perform
> the right LL/SC pair on two processors to that they endlessly steal
> each other the reservation.

So I added an emulated 4 Kbyte L1 instruction cache to each core and a
shared 256 Kbyte L2 instruction cache to get some instruction timing
jitter. The cache refill time also has a pseudo-random element to
emulate the shared AHB bus latency. This makes of the epoch01 tests pass
but I can get a fail by playing with the time slice size or changing the
cache size. I wonder if it was pure luck that the test worked on the
real SPARC hardware. Is it possible to run the test using only three or
two cores on the hardware? In my experiments, three cores seemed to fail
more often than the other configurations ...

Jiri.


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Potential SIS or RTEMS/libbsd problem

[Jiri Gaisler]

On 5/23/19 1:47 PM, Sebastian Huber wrote:
> On 22/05/2019 22:34, Jiri Gaisler wrote:
>> Adding a pseudo-random delay of 0 - 15 clocks to each trap/interrupt
>> causes the test to pass on all cpu configurations with the default
>> time slice (50)..! I am not sure what this means - it could be a
>> hidden race condition, the algorithm might need some jitter to work
>> or it could still be a simulator issue.
>
> Adding a pseudo-random delay to interrupts is probably not enough.
> Sometimes the atomic instructions are carried out with interrupts
> disabled. Would it be possible to add a pseudo-random delay to each of
> the instruction cycles per core?

I think this is what I have done. The interrupt/trap latency for each
core get a random delay, which causes the instruction count to vary for
each core. The delay varies dynamically for each trap/core, and applies
to all traps not just interrupts (window underflow etc.).

Jiri.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Potential SIS or RTEMS/libbsd problem

[Jiri Gaisler]

On 5/22/19 7:43 PM, Jiri Gaisler wrote:
> On 5/22/19 9:49 AM, Sebastian Huber wrote:
>> On 22/05/2019 09:39, Jiri Gaisler wrote:
>>> On 5/22/19 8:03 AM, Sebastian Huber wrote:
>>>> Hello,
>>>>
>>>> in the libbsd there is a test for the Epoch Based Reclamation:
>>>>
>>>> https://git.rtems.org/rtems-libbsd/tree/testsuite/epoch01/test_main.c
>>>>
>>>> When I run this test using the leon3 BSP on real hardware (150MHz
>>>> NGMP FP) the test completes successfully.
>>>>
>>>> If I run the test on the SIS, it is stuck at some point (using "-m
>>>> 1" works):
>>>>
>>>> sparc-rtems5-sis -leon3 -nouartrx -r -tlim 200 s -m 2
>>>> build/sparc-rtems5-leon3-everything/epoch01.exe
>>>>
>>>>
>>> This test needs a shorter time-slice in the simulator to succeed (-d
>>> option). The more cpus, the lower number of clocks in the slice is
>>> needed. Through trial-and-error, these values seem to work:
>>>
>>> 2 CPUs: -m 2 -d 25
>>>
>>> 3 CPUs: -m 3 -d 10
>>>
>>> 4 CPUs will not work, even if -d 1 is set. This is most likely a
>>> simulator problem, I will try to find time to look at it in more
>>> detail. A quick trace shows that all CPUs are stuck in a loop
>>> checking for a lock or similar:
>>>
>> It seems cpu 2 and 3 are in _SMP_barrier_Wait(). The cpu 0 and 1 still
>> to some stuff in the EBR algorithm (ck_* functions). Maybe the
>> algorithm works only in case some random timing fluctuations occur.
> Either that or there is a hidden race condition in the test that does
> not show up on real hardware. I noticed that increasing the time slice
> actually make the test succeed even on 4 cpus ..!
>
> -m 2 -d 200    PASS
>
> -m 3 -d 200    PASS
>
> -m 4 -d 200    FAIL
>
> -m 4 -d 400    PASS!
>
> BUT
>
> -m 3 -d 400    FAIL!
>
> I will try to add random delays to the interrupt response time to see if
> that will make a difference. That is more inline with the real hardware ...

Adding a pseudo-random delay of 0 - 15 clocks to each trap/interrupt causes the 
test to pass on all cpu configurations with the default time slice (50)..! I am 
not sure what this means - it could be a hidden race condition, the algorithm 
might need some jitter to work or it could still be a simulator issue.

Is there any chance that you could compile this test for sis-riscv? RISC-V has 
different atomic operations and trap handlers so it would be interesting to see 
if the test behaves differently.

Jiri.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Potential SIS or RTEMS/libbsd problem

[Jiri Gaisler]

On 5/22/19 9:49 AM, Sebastian Huber wrote:
> On 22/05/2019 09:39, Jiri Gaisler wrote:
>> On 5/22/19 8:03 AM, Sebastian Huber wrote:
>>> Hello,
>>>
>>> in the libbsd there is a test for the Epoch Based Reclamation:
>>>
>>> https://git.rtems.org/rtems-libbsd/tree/testsuite/epoch01/test_main.c
>>>
>>> When I run this test using the leon3 BSP on real hardware (150MHz
>>> NGMP FP) the test completes successfully.
>>>
>>> If I run the test on the SIS, it is stuck at some point (using "-m
>>> 1" works):
>>>
>>> sparc-rtems5-sis -leon3 -nouartrx -r -tlim 200 s -m 2
>>> build/sparc-rtems5-leon3-everything/epoch01.exe
>>>
>>>
>> This test needs a shorter time-slice in the simulator to succeed (-d
>> option). The more cpus, the lower number of clocks in the slice is
>> needed. Through trial-and-error, these values seem to work:
>>
>> 2 CPUs: -m 2 -d 25
>>
>> 3 CPUs: -m 3 -d 10
>>
>> 4 CPUs will not work, even if -d 1 is set. This is most likely a
>> simulator problem, I will try to find time to look at it in more
>> detail. A quick trace shows that all CPUs are stuck in a loop
>> checking for a lock or similar:
>>
>
> It seems cpu 2 and 3 are in _SMP_barrier_Wait(). The cpu 0 and 1 still
> to some stuff in the EBR algorithm (ck_* functions). Maybe the
> algorithm works only in case some random timing fluctuations occur.

Either that or there is a hidden race condition in the test that does
not show up on real hardware. I noticed that increasing the time slice
actually make the test succeed even on 4 cpus ..!

-m 2 -d 200    PASS

-m 3 -d 200    PASS

-m 4 -d 200    FAIL

-m 4 -d 400    PASS!

BUT

-m 3 -d 400    FAIL!

I will try to add random delays to the interrupt response time to see if
that will make a difference. That is more inline with the real hardware ...

Jiri.



___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Potential SIS or RTEMS/libbsd problem

[Jiri Gaisler]

On 5/22/19 8:03 AM, Sebastian Huber wrote:
> Hello,
>
> in the libbsd there is a test for the Epoch Based Reclamation:
>
> https://git.rtems.org/rtems-libbsd/tree/testsuite/epoch01/test_main.c
>
> When I run this test using the leon3 BSP on real hardware (150MHz NGMP FP) 
> the test completes successfully.
>
> If I run the test on the SIS, it is stuck at some point (using "-m 1" works):
>
> sparc-rtems5-sis -leon3 -nouartrx -r -tlim 200 s -m 2 
> build/sparc-rtems5-leon3-everything/epoch01.exe
>
>

This test needs a shorter time-slice in the simulator to succeed (-d option). 
The more cpus, the lower number of clocks in the slice is needed. Through 
trial-and-error, these values seem to work:

2 CPUs: -m 2 -d 25

3 CPUs: -m 3 -d 10

4 CPUs will not work, even if -d 1 is set. This is most likely a simulator 
problem, I will try to find time to look at it in more detail. A quick trace 
shows that all CPUs are stuck in a loop checking for a lock or similar:

$ ./sis -leon3 ~/epoch01.exe -m 4 -d 1

 SIS - SPARC/RISCV instruction simulator 2.14,  copyright Jiri Gaisler 2019
 Bug-reports to j...@gaisler.se

 LEON3 emulation enabled, 4 cpus online, delta 1 clocks

 Loaded /home/jiri/epoch01.exe, entry 0x4000
cpu0> run
Waking CPU 1
Waking CPU 2
Waking CPU 3
*** LIBBSD EPOCH 1 TEST ***
nexus0: 

  
    74357
  
  
    74464
    59621
  
  
    74353
    59529
    74710
  
  
    74221
    66362
    74605
    74605
  
  
    53231
    82
  
  
    51659
    51862
    42
    42
  
  
    50492
    46310
    51516
    25
    24
    24
  
  
    46105
    41697
    46499
    46515
    19
    18
    18
    18
  
  
    29273
  
  
    29262
    37024
  
  
    32622
    36973
    36973
  
  
    29126
    36917
    36917
    36918
  
  
    27539
    61
  
Interrupt!
 Stopped at time 1090141103 (21802.822 ms)
cpu0> tra 20
cpu 1  1090141103  40001840:  81e8   restore 
cpu 2  1090141103  401cc2f4:  82102000   mov  0, %g1
cpu 3  1090141103  401cc2f4:  82102000   mov  0, %g1
cpu 0  1090141104  40001798:  7fea   call  0x40001740
cpu 1  1090141104  40001844:  81c3e008   retl 
cpu 2  1090141104  401cc2e8:  c200c000   ld  [%g3], %g1
cpu 3  1090141104  401cc2e8:  c200c000   ld  [%g3], %g1
cpu 0  1090141105  4000179c:  0100   nop
cpu 0  1090141106  40001740:  9de3bfa0   save  %sp, -96, %sp
cpu 1  1090141106  40001848:  0100   nop
cpu 2  1090141106  401cc2ec:  80a08001   cmp  %g2, %g1
cpu 3  1090141106  401cc2ec:  80a08001   cmp  %g2, %g1
cpu 0  1090141107  40001744:  0100   nop
cpu 1  1090141107  400018a0:  0100   nop
cpu 0  1090141108  40001748:  81e8   restore 
cpu 1  1090141108  400018a4:  81e8   restore 
cpu 2  1090141108  401cc2f0:  12be   bne  0x401cc2e8
cpu 3  1090141108  401cc2f0:  12be   bne  0x401cc2e8
cpu 0  1090141109  4000174c:  81c3e008   retl 
cpu 1  1090141109  400018a8:  81c3e008   retl 
cpu 2  1090141109  401cc2f4:  82102000   mov  0, %g1
cpu 3  1090141109  401cc2f4:  82102000   mov  0, %g1
cpu 2  1090141110  401cc2e8:  c200c000   ld  [%g3], %g1
cpu 3  1090141110  401cc2e8:  c200c000   ld  [%g3], %g1
cpu 0  109014  40001750:  0100   nop
cpu 1  109014  400018ac:  0100   nop
cpu 0  1090141112  400017a0:  c207a044   ld  [%fp + 0x44], %g1
cpu 1  1090141112  40002484:  c207bff0   ld  [%fp - 0x10], %g1
cpu 2  1090141112  401cc2ec:  80a08001   cmp  %g2, %g1
cpu 3  1090141112  401cc2ec:  80a08001   cmp  %g2, %g1
cpu 0  1090141114  400017a4:  c407a048   ld  [%fp + 0x48], %g2
cpu 1  1090141114  40002488:  9011   mov  %g1, %o0
cpu 2  1090141114  401cc2f0:  12be   bne  0x401cc2e8
cpu 3  1090141114  401cc2f0:  12be   bne  0x401cc2e8
cpu 2  1090141115  401cc2f4:  82102000   mov  0, %g1
cpu 3  1090141115  401cc2f4:  82102000   mov  0, %g1
cpu 0  1090141116  400017a8:  c4204000   st  %g2, [%g1]
cpu 1  1090141116  4000248c:  7cb2   call  0x40001754
cpu 2  1090141116  401cc2e8:  c200c000   ld  [%g3], %g1
cpu 3  1090141116  401cc2e8:  c200c000   ld  [%g3], %g1
cpu 1  1090141117  40002490:  0100   nop
cpu 1  1090141118  40001754:  9de3bf98   save  %sp, -104, %sp
cpu 2  1090141118  401cc2ec:  80a08001   cmp  %g2, %g1
cpu 3  1090141118  401cc2ec:  80a08001   cmp  %g2, %g1
cpu 0  1090141119  400017ac:  7fe5   call  0x40001740
cpu 1  1090141119  40001758:  f027a044   st  %i0, [%fp + 0x44]
cpu 0  1090141120  400017b0:  0100   nop
cpu 2  1090141120  401cc2f0:  12be   bne  0x401cc2e8
cpu 3  1090141120  401cc2f0:  12be   bne  0x401cc2e8
cpu 0  1090141121  40001740:  9de3bfa0   save  %sp, -96, %sp
cpu 2  1090141121  401cc2f4:  82102000   mov  0, %g1
cpu 3  1090141121  401cc2f4:  82102000   mov  0, %g1
cpu 0  1090141122  40001744:  0100   nop
cpu 1  1090141122  4000175c:  7ff9   call  0x40001740
cpu 2  1090141122  401cc2e8:  c200c000   ld  [%g3], %g1
cpu 3  1090141122  401cc2e8:  c200c000   ld  [%g3], %g1

 Stopped at time 1090141123 (21802.822 ms)
cpu0>

__

Re: TSIM coverage format?

[Jiri Gaisler]

From the TSIM manual:

"The coverage data for each 32-bit word of memory consists of a 5-bit field, 
with bit0 (lsb) indicating that the
word has been executed, bit1 indicating that the word has been written, and 
bit2 that the word has been read.
Bit3 and bit4 indicates the presence of a branch instruction; if bit3 is set 
then the branch was taken while bit4
is set if the branch was not taken."

sis implements the same format, but does not set bits 1 & 2 (data read/write).

Jiri.

On 5/17/19 11:23 AM, Sebastian Huber wrote:
> Hello,
>
> is there a documentation for the TSIM coverage format available? From the 
> tester/covoar/CoverageReaderTSIM.cc
>
>     if ( cover & 0x01 ) {
>   aCoverageMap->setWasExecuted( a );
>   aCoverageMap->setWasExecuted( a + 1 );
>   aCoverageMap->setWasExecuted( a + 2 );
>   aCoverageMap->setWasExecuted( a + 3 );
>   if ( cover & 0x08 ) {
>             aCoverageMap->setWasTaken( a );
>             BranchInfoAvailable = true;
>   }
>   if ( cover & 0x10 ) {
>             aCoverageMap->setWasNotTaken( a );
>             BranchInfoAvailable = true;
>   }
>         }
>
> it seems to be a bit field. Do the other five bits in this byte have a 
> meaning too?
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] leon2-sis.ini, leon3-sis.ini: Correct run arguments

[Jiri Gaisler]

I don't think this patch is necessary, the -r option is already present 
and does not need to be duplicated.


Jiri.

On 2019-03-14 14:21, Joel Sherrill wrote:

---
  tester/rtems/testing/bsps/leon2-sis.ini | 2 +-
  tester/rtems/testing/bsps/leon3-sis.ini | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tester/rtems/testing/bsps/leon2-sis.ini 
b/tester/rtems/testing/bsps/leon2-sis.ini
index 61205ad..d0dd315 100644
--- a/tester/rtems/testing/bsps/leon2-sis.ini
+++ b/tester/rtems/testing/bsps/leon2-sis.ini
@@ -36,4 +36,4 @@ bsp  = leon2
  arch = sparc
  tester   = %{_rtscripts}/run.cfg
  bsp_run_cmd  = %{rtems_tools}/%{bsp_arch}-rtems%{rtems_version}-sis
-bsp_run_opts = -leon2 -nouartrx -r -tlim 200 s
+bsp_run_opts = -r -leon2 -nouartrx -r -tlim 200 s
diff --git a/tester/rtems/testing/bsps/leon3-sis.ini 
b/tester/rtems/testing/bsps/leon3-sis.ini
index 2f933a7..9e8111f 100644
--- a/tester/rtems/testing/bsps/leon3-sis.ini
+++ b/tester/rtems/testing/bsps/leon3-sis.ini
@@ -36,4 +36,4 @@ bsp  = leon3
  arch = sparc
  tester   = %{_rtscripts}/run.cfg
  bsp_run_cmd  = %{rtems_tools}/%{bsp_arch}-rtems%{rtems_version}-sis
-bsp_run_opts = -leon3 -nouartrx -r -tlim 200 s -m 4
+bsp_run_opts = -r -leon3 -nouartrx -r -tlim 200 s -m 4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] RSB: upgrade to sis 2.13 (was: Issue with sis and Leon3)

[Jiri Gaisler]

The attached patch for RSB solves the problem of output not being
flushed in gdb/sis and run/sis.  Note that I would discourage the use of
run as it cannot run the SMP tests. I have also experienced some random
hangs in rtems-test when using run, but never with sis.

Jiri.

On 3/1/19 4:53 PM, Joel Sherrill wrote:
> Thank you for being so responsive. 
>
> I suspected a missing flush but had no idea where to look. I hopedyou
> would spot the missing line of code quickly and was right. :)
>
> --joel
>
> On Thu, Feb 28, 2019 at 1:01 PM Jiri Gaisler  <mailto:j...@gaisler.se>> wrote:
>
> I have found the problem, stdout is not flushed when the simulator
> stops and it has been invoked by gdb. The run command uses the gdb
> interface to call sis, so this is why it happens there too. I will
> make a new sis patch (2.13) with some additional (speed)
> improvements...
>
> Jiri.
>
diff --git a/rtems/config/tools/rtems-gdb-8.2.1-1.cfg b/rtems/config/tools/rtems-gdb-8.2.1-1.cfg
index 2473ee6..3e90826 100644
--- a/rtems/config/tools/rtems-gdb-8.2.1-1.cfg
+++ b/rtems/config/tools/rtems-gdb-8.2.1-1.cfg
@@ -18,4 +18,7 @@
 %patch add gdb https://devel.rtems.org/raw-attachment/ticket/3460/gdb-8.2.1-sis-2.12.patch
 %hash sha512 gdb-8.2.1-sis-2.12.patch ee321be58c4788580eb16f2e9c7329fddd6d9c22922f22f93a33aaa7ff97804cdf3539de835756109b99b4c975ec68880d438debebe22923c303b565fe2188da
 
+%patch add gdb https://gaisler.se/gdb/gdb-8.2.1-sis-2.13.patch
+%hash sha512 gdb-8.2.1-sis-2.13.patch 8239ef23240ef27f64e4deb2a81f91e6d189572fbfd4f5b26e525f2907413f8f09e643fa4ae793616feeeb5db1878a0caa5eea5c9c51ad946ad930adc46e4599
+
 %include %{_configdir}/gdb-8-1.cfg
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Issue with sis and Leon3

[Jiri Gaisler]

I have found the problem, stdout is not flushed when the simulator stops
and it has been invoked by gdb. The run command uses the gdb interface
to call sis, so this is why it happens there too. I will make a new sis
patch (2.13) with some additional (speed) improvements...

Jiri.


On 2/27/19 9:34 AM, Jiri Gaisler wrote:
>
>
> On 2/26/19 11:04 PM, Joel Sherrill wrote:
>>
>>
>> On Tue, Feb 26, 2019 at 2:06 PM Jiri Gaisler > <mailto:j...@gaisler.se>> wrote:
>>
>>
>> On 2/26/19 8:49 PM, Joel Sherrill wrote:
>>>
>>>
>>> On Tue, Feb 26, 2019 at 1:28 PM Jiri Gaisler >> <mailto:j...@gaisler.se>> wrote:
>>>
>>>
>>> On 2/26/19 8:08 PM, Joel Sherrill wrote:
>>> > Hi
>>> >
>>> > I think something is wrong with sis on the leon3 which is
>>> impacting rtems-tester.
>>> > ticker ends like this:
>>> >
>>> > TA1  - rtems_clock_get_tod - 09:00:34   12/31/1988
>>> >
>>> > *** END OF TEST CLOCK TICK ***[joel@
>>> >
>>> > Notice that there is no carriage return at the end. Hello
>>> ends with a CR and an
>>> > blank line and it passes. Similar issue on the tests I
>>> picked which passed or failed.
>>> >
>>> > Any idea what's up? I assume something isn't quite right
>>> after all the sis work
>>> > since it is reproducible.
>>>
>>>
>>> Works OK here on Ubuntu 18.04.2 x64. Which host O/S are you on?
>>>
>>>
>>> Interesting. OS is:
>>>
>>> CentOS Linux release 7.5.1804 (Core) 
>>>
>>> Here is the output of my last run by hand with a subsequent
>>> comment. Notice that
>>>
>>> ===
>>> [joel@rtbf64c b-leon3]$ sparc-rtems5-run -a -leon3
>>> ./sparc-rtems5/c/leon3/testsuites/sptests/sp05.exe
>>
>> The run program has some issues, I think we should sis with -r
>> instead:
>>
>> $ sparc-rtems5-sis -r -leon3
>> ./sparc-rtems5/c/leon3/testsuites/sptests/sp05.exe
>>
>> .
>>
>> .
>>
>>
>> *** END OF TEST SP 5 ***
>>
>>
>> Thanks. Then do you agree that this patch is needed for rtems-tools
>> to invoke sis correctly:
>>
>> diff --git a/tester/rtems/testing/bsps/leon3-sis.ini
>> b/tester/rtems/testing/bsps
>> index 2f933a7..9e8111f 100644
>> --- a/tester/rtems/testing/bsps/leon3-sis.ini
>> +++ b/tester/rtems/testing/bsps/leon3-sis.ini
>> @@ -36,4 +36,4 @@ bsp          = leon3
>>  arch         = sparc
>>  tester       = %{_rtscripts}/run.cfg
>>  bsp_run_cmd  = %{rtems_tools}/%{bsp_arch}-rtems%{rtems_version}-sis
>> -bsp_run_opts = -leon3 -nouartrx -r -tlim 200 s -m 4
>> +bsp_run_opts = -r -leon3 -nouartrx -r -tlim 200 s -m 4
>>
> Hmm, bsp_run_opts already has -r, I don't think you need a second copy
> ...?
>
>
>> And the cut-off output also occurs when running it from inside gdb so
>> using leon3
>> (leon3.ini) configuration with rtems-test is broken. Not sure how to
>> fix that.
>
> I will look into this.
>
> Jiri.
>
>>
>> The tests pass with leon3-sis with my above patch but fail with
>> simple leon3
>> passed to tester.
>>
>> --joel
>>
>>
>> Jiri.
>>
>>
>>
>>
>>>
>>>
>>> *** BEGIN OF TEST SP 5 ***
>>> *** TEST VERSION: 5.0.0.7abc497b6c763ccdc090014f310951b17c742ae9
>>> *** TEST STATE: EXPECTED-PASS
>>> *** TEST BUILD: RTEMS_NETWORKING
>>> *** TEST TOOLS: 7.4.0 20181206 (RTEMS 5, RSB
>>> 38241392a4f96dabf2d1aba51a43dcb623db4dfb, Newlib 1d35a003f)
>>> TA1 - rtems_task_wake_after - sleep 5 seconds
>>> TA2 - rtems_task_suspend - suspend self
>>> TA3 - rtems_task_suspend - suspend self
>>> ..
>>> TA1 - rtems_task_resume - resume TA3
>>>
>>> *** END OF TEST [joel@rtbf64c b-leon3]$ cat /etc/redhat-release 
>>> CentOS Linux release 7.5.1804 (Core) 
>>> === 
>>>
>>> And this is the end of the erc32 output from the same test and
>>> same sis on the same computer: 
>>>
>>> ==

Re: Issue with sis and Leon3

[Jiri Gaisler]

On 2/26/19 11:04 PM, Joel Sherrill wrote:
>
>
> On Tue, Feb 26, 2019 at 2:06 PM Jiri Gaisler  <mailto:j...@gaisler.se>> wrote:
>
>
> On 2/26/19 8:49 PM, Joel Sherrill wrote:
>>
>>
>> On Tue, Feb 26, 2019 at 1:28 PM Jiri Gaisler > <mailto:j...@gaisler.se>> wrote:
>>
>>
>> On 2/26/19 8:08 PM, Joel Sherrill wrote:
>> > Hi
>> >
>> > I think something is wrong with sis on the leon3 which is 
>> impacting rtems-tester.
>> > ticker ends like this:
>> >
>> > TA1  - rtems_clock_get_tod - 09:00:34   12/31/1988
>> >
>> > *** END OF TEST CLOCK TICK ***[joel@
>> >
>> > Notice that there is no carriage return at the end. Hello ends 
>> with a CR and an
>> > blank line and it passes. Similar issue on the tests I picked 
>> which passed or failed.
>> >
>> > Any idea what's up? I assume something isn't quite right after all 
>> the sis work
>> > since it is reproducible.
>>
>>
>> Works OK here on Ubuntu 18.04.2 x64. Which host O/S are you on?
>>
>>
>> Interesting. OS is:
>>
>> CentOS Linux release 7.5.1804 (Core) 
>>
>> Here is the output of my last run by hand with a subsequent comment. 
>> Notice that
>>
>> ===
>> [joel@rtbf64c b-leon3]$ sparc-rtems5-run -a -leon3 
>> ./sparc-rtems5/c/leon3/testsuites/sptests/sp05.exe
>
> The run program has some issues, I think we should sis with -r instead:
>
> $ sparc-rtems5-sis -r -leon3 
> ./sparc-rtems5/c/leon3/testsuites/sptests/sp05.exe
>
> .
>
> .
>
>
> *** END OF TEST SP 5 ***
>
>
> Thanks. Then do you agree that this patch is needed for rtems-tools to invoke 
> sis correctly:
>
> diff --git a/tester/rtems/testing/bsps/leon3-sis.ini 
> b/tester/rtems/testing/bsps
> index 2f933a7..9e8111f 100644
> --- a/tester/rtems/testing/bsps/leon3-sis.ini
> +++ b/tester/rtems/testing/bsps/leon3-sis.ini
> @@ -36,4 +36,4 @@ bsp          = leon3
>  arch         = sparc
>  tester       = %{_rtscripts}/run.cfg
>  bsp_run_cmd  = %{rtems_tools}/%{bsp_arch}-rtems%{rtems_version}-sis
> -bsp_run_opts = -leon3 -nouartrx -r -tlim 200 s -m 4
> +bsp_run_opts = -r -leon3 -nouartrx -r -tlim 200 s -m 4
>
Hmm, bsp_run_opts already has -r, I don't think you need a second copy ...?


> And the cut-off output also occurs when running it from inside gdb so using 
> leon3
> (leon3.ini) configuration with rtems-test is broken. Not sure how to fix that.

I will look into this.

Jiri.

>
> The tests pass with leon3-sis with my above patch but fail with simple leon3
> passed to tester.
>
> --joel
>
>
> Jiri.
>
>
>
>
>>
>>
>> *** BEGIN OF TEST SP 5 ***
>> *** TEST VERSION: 5.0.0.7abc497b6c763ccdc090014f310951b17c742ae9
>> *** TEST STATE: EXPECTED-PASS
>> *** TEST BUILD: RTEMS_NETWORKING
>> *** TEST TOOLS: 7.4.0 20181206 (RTEMS 5, RSB 
>> 38241392a4f96dabf2d1aba51a43dcb623db4dfb, Newlib 1d35a003f)
>> TA1 - rtems_task_wake_after - sleep 5 seconds
>> TA2 - rtems_task_suspend - suspend self
>> TA3 - rtems_task_suspend - suspend self
>> ..
>> TA1 - rtems_task_resume - resume TA3
>>
>> *** END OF TEST [joel@rtbf64c b-leon3]$ cat /etc/redhat-release 
>> CentOS Linux release 7.5.1804 (Core) 
>> === 
>>
>> And this is the end of the erc32 output from the same test and same sis 
>> on the same computer: 
>>
>> ===
>>  TA1 - rtems_task_resume - resume TA3
>>
>> *** END OF TEST SP 5 ***
>>
>>
>> *** FATAL ***
>> fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
>> fatal code: 0 (0x)
>> RTEMS version: 5.0.0.7abc497b6c763ccdc090014f310951b17c742ae9
>> RTEMS tools: 7.4.0 20181206 (RTEMS 5, RSB 
>> 38241392a4f96dabf2d1aba51a43dcb623db4dfb, Newlib 1d35a003f)
>>
>> === 
>>
>> Looks like a lot of output got chopped or not flushed or something.
>>
>> If the final output makes it out on your system, then rtems-test will be 
>> happy and pass them. 
>> In my case, it ends most of the time just a little too early to make 
>> that happen.
>>  
>>
>>
>> jiri@office:~/src/rtems/sparc$ rtems-test 

Re: Issue with sis and Leon3

[Jiri Gaisler]

On 2/26/19 8:49 PM, Joel Sherrill wrote:
>
>
> On Tue, Feb 26, 2019 at 1:28 PM Jiri Gaisler  <mailto:j...@gaisler.se>> wrote:
>
>
> On 2/26/19 8:08 PM, Joel Sherrill wrote:
> > Hi
> >
> > I think something is wrong with sis on the leon3 which is
> impacting rtems-tester.
> > ticker ends like this:
> >
> > TA1  - rtems_clock_get_tod - 09:00:34   12/31/1988
> >
> > *** END OF TEST CLOCK TICK ***[joel@
> >
> > Notice that there is no carriage return at the end. Hello ends
> with a CR and an
> > blank line and it passes. Similar issue on the tests I picked
> which passed or failed.
> >
> > Any idea what's up? I assume something isn't quite right after
> all the sis work
> > since it is reproducible.
>
>
> Works OK here on Ubuntu 18.04.2 x64. Which host O/S are you on?
>
>
> Interesting. OS is:
>
> CentOS Linux release 7.5.1804 (Core) 
>
> Here is the output of my last run by hand with a subsequent comment.
> Notice that
>
> ===
> [joel@rtbf64c b-leon3]$ sparc-rtems5-run -a -leon3
> ./sparc-rtems5/c/leon3/testsuites/sptests/sp05.exe

The run program has some issues, I think we should sis with -r instead:

$ sparc-rtems5-sis -r -leon3
./sparc-rtems5/c/leon3/testsuites/sptests/sp05.exe

.

.


*** END OF TEST SP 5 ***

Jiri.




>
>
> *** BEGIN OF TEST SP 5 ***
> *** TEST VERSION: 5.0.0.7abc497b6c763ccdc090014f310951b17c742ae9
> *** TEST STATE: EXPECTED-PASS
> *** TEST BUILD: RTEMS_NETWORKING
> *** TEST TOOLS: 7.4.0 20181206 (RTEMS 5, RSB
> 38241392a4f96dabf2d1aba51a43dcb623db4dfb, Newlib 1d35a003f)
> TA1 - rtems_task_wake_after - sleep 5 seconds
> TA2 - rtems_task_suspend - suspend self
> TA3 - rtems_task_suspend - suspend self
> ..
> TA1 - rtems_task_resume - resume TA3
>
> *** END OF TEST [joel@rtbf64c b-leon3]$ cat /etc/redhat-release 
> CentOS Linux release 7.5.1804 (Core) 
> === 
>
> And this is the end of the erc32 output from the same test and same
> sis on the same computer: 
>
> ===
>  TA1 - rtems_task_resume - resume TA3
>
> *** END OF TEST SP 5 ***
>
>
> *** FATAL ***
> fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
> fatal code: 0 (0x)
> RTEMS version: 5.0.0.7abc497b6c763ccdc090014f310951b17c742ae9
> RTEMS tools: 7.4.0 20181206 (RTEMS 5, RSB
> 38241392a4f96dabf2d1aba51a43dcb623db4dfb, Newlib 1d35a003f)
>
> === 
>
> Looks like a lot of output got chopped or not flushed or something.
>
> If the final output makes it out on your system, then rtems-test will
> be happy and pass them. 
> In my case, it ends most of the time just a little too early to make
> that happen.
>  
>
>
> jiri@office:~/src/rtems/sparc$ rtems-test --rtems-bsp=leon3-sis
> sparc-rtems5/c/leon3/testsuites/samples
> RTEMS Testing - Tester, 5.0.not_released
>  Command Line: /opt/rtems/5/bin/rtems-test --rtems-bsp=leon3-sis
> sparc-rtems5/c/leon3/testsuites/samples
>  Python: 3.6.7 (default, Oct 22 2018, 11:32:17) [GCC 8.2.0]
> Host: Linux-4.18.0-15-generic-x86_64-with-Ubuntu-18.04-bionic
> (Linux office 4.18.0-15-generic #16~18.04.1-Ubuntu SMP Thu Feb 7
> 14:06:04 UTC 2019 x86_64 x86_64)
> [ 8/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
> sparc/leon3: minimum.exe
> [ 6/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
> sparc/leon3: hello.exe
> [ 4/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
> sparc/leon3: cxx_iostream.exe
> [ 2/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
> sparc/leon3: capture.exe
> [ 3/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
> sparc/leon3: cdtest.exe
> [ 1/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
> sparc/leon3: base_sp.exe
> [ 5/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
> sparc/leon3: fileio.exe
> [ 7/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
> sparc/leon3: loopback.exe
> [ 1/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
> sparc/leon3: base_sp.exe
> [ 2/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
> sparc/leon3: capture.exe
> [ 3/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
> sparc/leon3: cdtest.exe
> [ 4/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
> sparc/leon3: cxx_iostream.exe
> [ 5/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
> sparc/leon3: fileio.exe
> [ 6/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
> sparc/leon3: hello.exe
> [ 7/13

Re: Issue with sis and Leon3

[Jiri Gaisler]

On 2/26/19 8:08 PM, Joel Sherrill wrote:
> Hi
>
> I think something is wrong with sis on the leon3 which is impacting 
> rtems-tester.
> ticker ends like this:
>
> TA1  - rtems_clock_get_tod - 09:00:34   12/31/1988
>
> *** END OF TEST CLOCK TICK ***[joel@
>
> Notice that there is no carriage return at the end. Hello ends with a CR and 
> an
> blank line and it passes. Similar issue on the tests I picked which passed or 
> failed.
>
> Any idea what's up? I assume something isn't quite right after all the sis 
> work
> since it is reproducible.


Works OK here on Ubuntu 18.04.2 x64. Which host O/S are you on?

jiri@office:~/src/rtems/sparc$ rtems-test --rtems-bsp=leon3-sis 
sparc-rtems5/c/leon3/testsuites/samples
RTEMS Testing - Tester, 5.0.not_released
 Command Line: /opt/rtems/5/bin/rtems-test --rtems-bsp=leon3-sis 
sparc-rtems5/c/leon3/testsuites/samples
 Python: 3.6.7 (default, Oct 22 2018, 11:32:17) [GCC 8.2.0]
Host: Linux-4.18.0-15-generic-x86_64-with-Ubuntu-18.04-bionic (Linux office 
4.18.0-15-generic #16~18.04.1-Ubuntu SMP Thu Feb 7 14:06:04 UTC 2019 x86_64 
x86_64)
[ 8/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: minimum.exe
[ 6/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: hello.exe
[ 4/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: 
cxx_iostream.exe
[ 2/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: capture.exe
[ 3/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: cdtest.exe
[ 1/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: base_sp.exe
[ 5/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: fileio.exe
[ 7/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: loopback.exe
[ 1/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: base_sp.exe
[ 2/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: capture.exe
[ 3/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: cdtest.exe
[ 4/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: 
cxx_iostream.exe
[ 5/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: fileio.exe
[ 6/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: hello.exe
[ 7/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: loopback.exe
[ 8/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: minimum.exe
[10/13] p:6  f:0  u:2  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: paranoia.exe
[11/13] p:6  f:0  u:2  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: pppd.exe
[13/13] p:6  f:0  u:2  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: 
unlimited.exe
[ 9/13] p:6  f:0  u:2  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: nsecs.exe
[12/13] p:6  f:0  u:2  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: ticker.exe
[ 9/13] p:6  f:0  u:2  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: nsecs.exe
[10/13] p:6  f:0  u:2  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: paranoia.exe
[11/13] p:6  f:0  u:2  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: pppd.exe
[12/13] p:6  f:0  u:2  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: ticker.exe
[13/13] p:6  f:0  u:2  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3: 
unlimited.exe

Passed:    11
Failed: 0
User Input: 2
Expected Fail:  0
Indeterminate:  0
Benchmark:  0
Timeout:    0
Invalid:    0
Wrong Version:  0
Wrong Build:    0
Wrong Tools:    0
-
Total: 13
User Input:
 capture.exe
 fileio.exe
Average test time: 0:00:00.212905
Testing time : 0:00:02.767759
jiri@office:~/src/rtems/sparc$ sparc-rtems5-sis

 SIS - SPARC/RISCV instruction simulator 2.12,  copyright Jiri Gaisler 2019
 Bug-reports to j...@gaisler.se

 ERC32 emulation enabled

sis> q

Jiri.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] griscv: add additional cpu configurations

[Jiri Gaisler]

>From 568490a054b9bf27ddad99a6a186e363123dd432 Mon Sep 17 00:00:00 2001
From: Jiri Gaisler 
Date: Fri, 8 Feb 2019 12:40:45 +0100
Subject: [PATCH] griscv: add additional cpu configurations

	* Also switch default config to imafd as the C extension
	  is not supported for code coverage
---
 bsps/riscv/griscv/config/griscv.cfg  | 2 +-
 bsps/riscv/griscv/config/grv32i.cfg  | 9 +
 bsps/riscv/griscv/config/grv32im.cfg | 9 +
 bsps/riscv/griscv/config/grv32imac.cfg   | 9 +
 bsps/riscv/griscv/config/grv32imafdc.cfg | 9 +
 5 files changed, 37 insertions(+), 1 deletion(-)
 create mode 100644 bsps/riscv/griscv/config/grv32i.cfg
 create mode 100644 bsps/riscv/griscv/config/grv32im.cfg
 create mode 100644 bsps/riscv/griscv/config/grv32imac.cfg
 create mode 100644 bsps/riscv/griscv/config/grv32imafdc.cfg

diff --git a/bsps/riscv/griscv/config/griscv.cfg b/bsps/riscv/griscv/config/griscv.cfg
index bd4a0cacbe..471f5ee2a6 100644
--- a/bsps/riscv/griscv/config/griscv.cfg
+++ b/bsps/riscv/griscv/config/griscv.cfg
@@ -2,7 +2,7 @@ include $(RTEMS_ROOT)/make/custom/default.cfg
 
 RTEMS_CPU = riscv
 
-CPU_CFLAGS = -march=rv32imafc -mabi=ilp32f
+CPU_CFLAGS = -march=rv32imafd -mabi=ilp32d
 
 LDFLAGS = -Wl,--gc-sections
 
diff --git a/bsps/riscv/griscv/config/grv32i.cfg b/bsps/riscv/griscv/config/grv32i.cfg
new file mode 100644
index 00..a394590dc2
--- /dev/null
+++ b/bsps/riscv/griscv/config/grv32i.cfg
@@ -0,0 +1,9 @@
+include $(RTEMS_ROOT)/make/custom/default.cfg
+
+RTEMS_CPU = riscv
+
+CPU_CFLAGS = -march=rv32i -mabi=ilp32
+
+LDFLAGS = -Wl,--gc-sections
+
+CFLAGS_OPTIMIZE_V ?= -O2 -g -ffunction-sections -fdata-sections
diff --git a/bsps/riscv/griscv/config/grv32im.cfg b/bsps/riscv/griscv/config/grv32im.cfg
new file mode 100644
index 00..46dfdad09c
--- /dev/null
+++ b/bsps/riscv/griscv/config/grv32im.cfg
@@ -0,0 +1,9 @@
+include $(RTEMS_ROOT)/make/custom/default.cfg
+
+RTEMS_CPU = riscv
+
+CPU_CFLAGS = -march=rv32im -mabi=ilp32
+
+LDFLAGS = -Wl,--gc-sections
+
+CFLAGS_OPTIMIZE_V ?= -O2 -g -ffunction-sections -fdata-sections
diff --git a/bsps/riscv/griscv/config/grv32imac.cfg b/bsps/riscv/griscv/config/grv32imac.cfg
new file mode 100644
index 00..e19e431b53
--- /dev/null
+++ b/bsps/riscv/griscv/config/grv32imac.cfg
@@ -0,0 +1,9 @@
+include $(RTEMS_ROOT)/make/custom/default.cfg
+
+RTEMS_CPU = riscv
+
+CPU_CFLAGS = -march=rv32imac -mabi=ilp32
+
+LDFLAGS = -Wl,--gc-sections
+
+CFLAGS_OPTIMIZE_V ?= -O2 -g -ffunction-sections -fdata-sections
diff --git a/bsps/riscv/griscv/config/grv32imafdc.cfg b/bsps/riscv/griscv/config/grv32imafdc.cfg
new file mode 100644
index 00..623f76fa47
--- /dev/null
+++ b/bsps/riscv/griscv/config/grv32imafdc.cfg
@@ -0,0 +1,9 @@
+include $(RTEMS_ROOT)/make/custom/default.cfg
+
+RTEMS_CPU = riscv
+
+CPU_CFLAGS = -march=rv32imafdc -mabi=ilp32d
+
+LDFLAGS = -Wl,--gc-sections
+
+CFLAGS_OPTIMIZE_V ?= -O2 -g -ffunction-sections -fdata-sections
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Break points with latest SIS

[Jiri Gaisler]

Hello Sebastian,

here is a patch for RSB that improves sis debugging in gdb and on SMP systems:

* Correct break-point handling in gdb

* Detect and break on NULL pointer derefence (call/jump)

* Single stepping (stepi) in gdb/sis keeps focus on debugged cpu

* 'sim cpu' command shows active cpu in gdb, 'sim cpu x' switches gdb focus to 
cpu x (needs stepi afterwards)

* Trace buffer works in gdb

 I still have more fixes in the pipeline (symbol handling, tab expansion, 
documentation) but I thought I provide a patch of what I have now to help you 
in your debugging. I will also be away skiing next week so there will not be 
much progress in near term.

Below is a debug session of your failing SMP program as an example:


$ ~/src/gdb/sparc/gdb/gdb  
./sparc-rtems5/c/leon3/testsuites/smptests/smpswitchextension01.exe

Reading symbols from 
./sparc-rtems5/c/leon3/testsuites/smptests/smpswitchextension01.exe...
(gdb) tar sim -leon3 -m 4
Connected to the simulator.
(gdb) load
(gdb) sim hi 5
trace history length = 5
(gdb) run
Starting program: 
/home/jiri/src/rtems/leon3mp2/sparc-rtems5/c/leon3/testsuites/smptests/smpswitchextension01.exe
Waking CPU 1


*** BEGIN OF TEST SMPSWITCHEXTENSION 1 ***
*** TEST VERSION: 5.0.0.03fcbb15d24e2eec41bac9f5dee30bbf7dc888b8-modified
*** TEST STATE: EXPECTED-PASS
*** TEST BUILD: RTEMS_DEBUG RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP
*** TEST TOOLS: 7.4.0 20181206 (RTEMS 5, RSB 
c41b9d0df7e5b4a5056ca50c2534380a44e92769, Newlib 3e24fbf6f)

Program received signal SIGSEGV, Segmentation fault.
0x4000a2e4 in _User_extensions_Thread_switch (heir=0x4
    0027aa8 <_RTEMS_tasks_Objects+3936>, executing
    =) at /home/jiri/ibm/src/rtems/rtems/cpukit
   /include/rtems/score/userextimpl.h:280
280      (*extension->thread_switch)( executing, heir );

(gdb) list
275    
276    while ( node != tail ) {
277      const User_extensions_Switch_control *extension =
278    (const User_extensions_Switch_control *) node;
279    
280      (*extension->thread_switch)( executing, heir );
281    
282      node = _Chain_Immutable_next( node );
283    }
284   

(gdb) sim cpu
active cpu: 1
(gdb) sim hi
   243329  4000a2f0  80a74016  cmp  %i5, %l6
   243331  4000a2f4  32bb  bne,a   0x4000a2e0
   243332  4000a2f8  c2076008  ld  [ %i5 + 8 ], %g1
   243334  4000a2e0  9210001c  mov  %i4, %o1
   243335  4000a2e4  9fc04000  call  %g1

(gdb) sim reg

      INS   LOCALS  OUTS GLOBALS
   0:  40029740   F3000FC7   40027FC8   
   1:  F34000E6   40029850   40027AA8   
   2:  F3E6   40006F04   40028238   0013
   3:  40029740   40027FC8   000B   40029854
   4:  40027AA8   4002985C   8000   8000
   5:     40029858   40029010   
   6:  40031240   400264B8   400311A8   40029740
   7:  40006FC8   40026400   4000A2E4   

 psr: F3900FE7   wim: 0004   tbr: 4890   y: 0A6A

  pc: 4000A2E4 = 9FC04000    call  %g1
 npc: 4000A2E8 = 90100013    mov  %l3, %o0
 IU in error mode

Run again

(gdb) load

(gdb) bre switcher
Breakpoint 1 at 0x40001794: file 
/home/jiri/ibm/src/rtems/rtems/c/src/../../testsuites/smptests/smpswitchextension01/init.c,
 line 109.

(gdb) run
Starting program: 
/home/jiri/src/rtems/leon3mp2/sparc-rtems5/c/leon3/testsuites/smptests/smpswitchextension01.exe
Waking CPU 1


*** BEGIN OF TEST SMPSWITCHEXTENSION 1 ***
*** TEST VERSION: 5.0.0.03fcbb15d24e2eec41bac9f5dee30bbf7dc888b8-modified
*** TEST STATE: EXPECTED-PASS
*** TEST BUILD: RTEMS_DEBUG RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP
*** TEST TOOLS: 7.4.0 20181206 (RTEMS 5, RSB 
c41b9d0df7e5b4a5056ca50c2534380a44e92769, Newlib 3e24fbf6f)

Breakpoint 1, switcher (self=0) at /home/jiri/ibm/src/rtems/rt
   ems/c/src/../../testsuites/smptests/smpswitchextension01/init.c:109
109    {
(gdb) sim cpu
active cpu: 0
(gdb) sim hi
   180980  40001794  9de3bfa0  save  %sp, -96, %sp
   180972  4000bb18  9de3bfa0  save  %sp, -96, %sp
   180973  4000bb1c  c206216c  ld  [ %i0 + 0x16c ], %g1
   180975  4000bb20  9fc04000  call  %g1
   180978  4000bb24  d0062170  ld  [ %i0 + 0x170 ], %o0
(gdb) sim cpu 1
active cpu: 1
(gdb) sim hi
   180992  400139fc  9207bff8  add  %fp, -8, %o1
   180993  40013a00  40001c79  call  0x4001abe4
   180994  40013a04  9010001b  mov  %i3, %o0
   180995  4001abe4  d0226004  st  %o0, [ %o1 + 4 ]
   180998  4001abe8  c202  ld  [ %o0 ], %g1
(gdb) stepi
0x4001abf0    274      return atomic_fetch_add_explicit( obj, arg, order );
(gdb)


diff --git a/rtems/config/tools/rtems-gdb-8.2.1-1.cfg b/rtems/config/tools/rtems-gdb-8.2.1-1.cfg
index 974577e..b12f43d 100644
--- a/rtems/config/tools/rtems-gdb-8.2.1-1.cfg
+++ b/rtems/config/tools/rtems-gdb-8.2.1-1.cfg
@@ -15,4 +15,7 @@
 %patch add gdb https://devel.rtems.org/raw-attachment/ticket/3460/gdb-8.2.1-riscv-config.patch
 %hash sha512 gdb-8.2.1-riscv-config.patch 193eb9ddfc79c494eb8b1e971cc230f5f01b1653ba3f85b8541b973dfcd23ead65dea7a638a6ccdb7f6fc0201f9a764bfdf3f89b2d9afba5c13

Re: Break points with latest SIS

[Jiri Gaisler]

On 2/7/19 12:53 PM, Jiri Gaisler wrote:
> On 2/7/19 12:45 PM, Sebastian Huber wrote:
>> On 07/02/2019 12:43, Jiri Gaisler wrote:
>>> Works OK here:
>>>
>>> $ sparc-rtems5-sis -leon3 -nouartrx -r -tlim 200 s -m 4  
>>> ./sparc-rtems5/c/leon3/testsuites/smptests/smpswitchextension01.exe
>>>
>>>   SIS - SPARC/RISCV instruction simulator 2.11,  copyright Jiri Gaisler 1995
>>>   Bug-reports to j...@gaisler.se
>>>
>>>   LEON3 emulation enabled, 4 cpus online, delta 50 clocks
>>>
>>>
>>>
>>> *** BEGIN OF TEST SMPSWITCHEXTENSION 1 ***
>>> *** TEST VERSION: 5.0.0.03fcbb15d24e2eec41bac9f5dee30bbf7dc888b8-modified
>>> *** TEST STATE: EXPECTED-PASS
>>> *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP
>> I used --enable-rtems-debug:
>>
>> *** TEST BUILD: RTEMS_DEBUG RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP
> OK, I can repeat it. I will debug it ...


The problem comes from a function call to a NULL pointer in cpu 1:

   243329  4000a2f0  80a74016  cmp  %i5, %l6
   243331  4000a2f4  32bb  bne,a   0x4000a2e0
   243332  4000a2f8  c2076008  ld  [ %i5 + 8 ], %g1
   243334  4000a2e0  9210001c  mov  %i4, %o1
   243335  4000a2e4  9fc04000  call  %g1  < %g1 is 0
   243337  4000a2e8  90100013  mov  %l3, %o0
   243338      unimp  0
   243341  4020  a148  rd  %psr, %l0

The source code is in cpukit/include/rtems/score/userextimpl.h:280

    while ( node != tail ) {
  const User_extensions_Switch_control *extension =
    (const User_extensions_Switch_control *) node;
   
  (*extension->thread_switch)( executing, heir );    <=
   
  node = _Chain_Immutable_next( node );
    }
   
    _Per_CPU_Release( cpu_self );


I don't think anything changed in the latest sis (2.11). I get the same error 
in 2.10.

(SMP debugging is not working well in sis - I am trying to improve it ...)


> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel