Re: RTEMS 5 gcc-fb371a33fa6 vs gcc-9.2.0
On 14/8/19 4:52 pm, Sebastian Huber wrote: > On 14/08/2019 08:52, Chris Johns wrote: > On ARM a breaking change in compiler options is necessary. What options are these? >>> ARM changed the FPU options in GCC 8 and later. >>> Also this seems back to front to me. Should all hosts be on 9.2.0 and those that cannot have specific versions? >>> Only PowerPC should stay at GCC 7 until the next RTEMS release from my >>> point of >>> view. Everything else can move on. >> Awesome. To make sure I understand the steps ... >> >> 1. Move gcc-fb371a33fa6 to 5/rtems-powerpc >> 2. Set the default to gcc-9.2.0 >> 3. Move all other archs to the defaults >> >> ? > > Yes, and: > > 4. Update the ARM BSPs to use the new machine options. Is there something that documents the changes we need to make? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Bug Reporting Page
On 14/8/19 3:39 pm, Sebastian Huber wrote: > I completed my work with moving the bug reporting information to the user > manual. Please have a look at the changed New Ticket page: > > https://devel.rtems.org/wiki/NewTicket > Why remove the information from the page that guides a user? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Bug Reporting Page
On 14/08/2019 09:13, Chris Johns wrote: On 14/8/19 3:39 pm, Sebastian Huber wrote: I completed my work with moving the bug reporting information to the user manual. Please have a look at the changed New Ticket page: https://devel.rtems.org/wiki/NewTicket Why remove the information from the page that guides a user? The four steps guide the user. The detailed information is now contained in the bug reporting section in the user manual: https://docs.rtems.org/branches/master/user/support/bugs.html -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 5 gcc-fb371a33fa6 vs gcc-9.2.0
On 14/08/2019 09:09, Chris Johns wrote: On 14/8/19 4:52 pm, Sebastian Huber wrote: On 14/08/2019 08:52, Chris Johns wrote: On ARM a breaking change in compiler options is necessary. What options are these? ARM changed the FPU options in GCC 8 and later. Also this seems back to front to me. Should all hosts be on 9.2.0 and those that cannot have specific versions? Only PowerPC should stay at GCC 7 until the next RTEMS release from my point of view. Everything else can move on. Awesome. To make sure I understand the steps ... 1. Move gcc-fb371a33fa6 to 5/rtems-powerpc 2. Set the default to gcc-9.2.0 3. Move all other archs to the defaults ? Yes, and: 4. Update the ARM BSPs to use the new machine options. Is there something that documents the changes we need to make? No, you have to compare the multilib configurations in GCC 7 and 9. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 5 gcc-fb371a33fa6 vs gcc-9.2.0
On 14/08/2019 09:25, Sebastian Huber wrote: On 14/08/2019 09:09, Chris Johns wrote: On 14/8/19 4:52 pm, Sebastian Huber wrote: On 14/08/2019 08:52, Chris Johns wrote: On ARM a breaking change in compiler options is necessary. What options are these? ARM changed the FPU options in GCC 8 and later. Also this seems back to front to me. Should all hosts be on 9.2.0 and those that cannot have specific versions? Only PowerPC should stay at GCC 7 until the next RTEMS release from my point of view. Everything else can move on. Awesome. To make sure I understand the steps ... 1. Move gcc-fb371a33fa6 to 5/rtems-powerpc 2. Set the default to gcc-9.2.0 3. Move all other archs to the defaults ? Yes, and: 4. Update the ARM BSPs to use the new machine options. Is there something that documents the changes we need to make? No, you have to compare the multilib configurations in GCC 7 and 9. Are you looking for information for users of ARM BSPs which have to update their hard-coded compiler options? No, we have to provide this information somewhere. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV
Thank you.
Do you see anything wrong with the riscv fenv implementation? His program
runs under Linux and hangs on both Qemu and sis.
On Wed, Aug 14, 2019, 2:18 AM Jiri Gaisler wrote:
> I have attached the sis manual. Page 17:
>
> "SIS can be connected to gdb through a network socket using the gdb remote
> interface.
> Either start SIS with -gdb, or issue the ’gdb’ command inside SIS, and
> connect gdb with
> ’target extended-remote localhost:1234’. The port can be changed using the
> -port option."
>
> You still need all other options, so to start on a windows host do:
>
> $ riscv-rtems-sis -riscv -nouartrx -gdb
>
> To start gdb, do:
>
> $ riscv-rtems-gdb app.exe
>
> (gdb) target extended-remote localhost:1234
>
> (gdb) load
>
> (gdb) run
>
> To re-run the application, issue a new load command first.
>
> Regards, Jiri.
>
> On 8/14/19 12:37 AM, Vaibhav Gupta wrote:
>
>
>
> On Wed, Aug 14, 2019 at 4:04 AM Joel Sherrill wrote:
>
>>
>>
>> On Tue, Aug 13, 2019 at 5:09 PM Vaibhav Gupta
>> wrote:
>>
>>>
>>>
>>> On Mon, Aug 12, 2019 at 11:50 PM Joel Sherrill wrote:
>>>
Can you post or email me privately the full patch? I can try to see
what I spot.
>>> I have sent you the patch.
>>>
Can you check with objdump or gdb that the methods which don't appear
to work
are actually the RISC-V implementation? Look at the disassembly and see
if it
looks like you expect.
>>> I am exploring for this.
>>>
>>
>> Since I don't know how to attach gdb to the new sis for griscv, I emailed
>> Jiri privately.
>> Your program works as expected on Linux. Perhaps Jiri has some advice for
>> my
>> debugging setup ignorance and fenv on RISC-V.
>>
> Okay, I will wait. Till then I can work with porting for other
> architecture. :)
>
>>
>> Do you happen to have fenv support for another architecture queued up? It
>> would be
>> interesting to see if it works on other targets.
>>
> Yup, they were in my to do list. Till testsuite method is solved, I will
> work on them now.
>
> - Vaibhav Gupta
>
>>
>> --joel
>>
>>
>>>
>>> - Vaibhav Gupta
>>>
Does this require a patch to newlib as well?
--joel
On Sun, Aug 11, 2019 at 10:49 AM Vaibhav Gupta <
vaibhavgupt...@gmail.com> wrote:
> Configure command I used to build BSP:
> ==
> $ /home/varodek/development/rtems/kernel/rtems/configure
> --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
> --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
> --enable-posix --disable-networking --enable-cxx
> RISCV_ENABLE_HTIF_SUPPORT=1
> ==
> .
> .
> .
> .
> Qemu command I used to run test:
> ==
> $ qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M
> -kernel psxfenv01.exe
> ==
> .
> .
> .
> .
> Makefile.am
> ==
> + if TEST_psxfenv01
> + psx_tests += psxfenv01
> + psxfenv01_SOURCES = psxfenv01/init.c
> + psxfenv01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfenv01) \
> + $(support_includes)
> + psxfenv01_LDADD = -lm $(LDADD)
> + endif
> +
> ==
>
> On Sun, Aug 11, 2019 at 8:36 PM Vaibhav Gupta <
> vaibhavgupt...@gmail.com> wrote:
>
>> My code of testsuite:
>> ===
>> /* Test 'FE_DIVBYZERO' */
>> puts( "\nDivide by zero and confirm fetestexcept()." );
>> a = 0.0;
>> b = 1.0;
>> c = b/a;
>> printf("\n%d",FE_DIVBYZERO);
>> fegetexceptflag(&excepts,FE_ALL_EXCEPT);
>> printf("\n%d",excepts);
>> r = feraiseexcept(FE_DIVBYZERO);
>> printf("\n%d\n",r);
>> rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
>> ==
>> OUTPUT
>> ==
>> Divide by zero and confirm fetestexcept().
>>
>> 8
>> 0
>> 1
>> /home/varodek/development/rtems/kernel/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:
>> 84 fetestexcept( FE_DIVBYZERO )
>> ==
>> EXPECTED OUTPUT
>> ==
>> Divide by zero and confirm fetestexcept().
>>
>> 8
>> 8
>> 0
>> ==
>> - fetestexcept( FE_DIVBYZERO ), should return a non-zero value as
>> division-by-zero was performed.
>> .
>> - feraiseexcept(FE_DIVBYZERO); is also not working. It should return
>> zero when successful
>> .
>> ==
>>
>> Thank You
>> Vaibhav Gupta
>>
>> _
Re: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV
Hello
I get following errors:
=
$ riscv-rtems5-sis -riscv -nouartrx -gdb
SIS - SPARC/RISCV instruction simulator 2.13, copyright Jiri Gaisler 2019
Bug-reports to j...@gaisler.se
unknown option -riscv
usage: sis [-uart1 uart_device1] [-uart2 uart_device2]
[-m ] [-dumbio] [-v]
[-nfp] [-freq frequency] [-c batch_file] [files]
=
$ riscv-rtems5-sis -gdb
SIS - SPARC/RISCV instruction simulator 2.13, copyright Jiri Gaisler 2019
Bug-reports to j...@gaisler.se
unknown option -gdb
usage: sis [-uart1 uart_device1] [-uart2 uart_device2]
[-m ] [-dumbio] [-v]
[-nfp] [-freq frequency] [-c batch_file] [files]
=
Vaibhav Gupta
On Wed, Aug 14, 2019 at 5:14 PM Joel Sherrill wrote:
> Thank you.
>
> Do you see anything wrong with the riscv fenv implementation? His program
> runs under Linux and hangs on both Qemu and sis.
>
> On Wed, Aug 14, 2019, 2:18 AM Jiri Gaisler wrote:
>
>> I have attached the sis manual. Page 17:
>>
>> "SIS can be connected to gdb through a network socket using the gdb remote
>> interface.
>> Either start SIS with -gdb, or issue the ’gdb’ command inside SIS, and
>> connect gdb with
>> ’target extended-remote localhost:1234’. The port can be changed using the
>> -port option."
>>
>> You still need all other options, so to start on a windows host do:
>>
>> $ riscv-rtems-sis -riscv -nouartrx -gdb
>>
>> To start gdb, do:
>>
>> $ riscv-rtems-gdb app.exe
>>
>> (gdb) target extended-remote localhost:1234
>>
>> (gdb) load
>>
>> (gdb) run
>>
>> To re-run the application, issue a new load command first.
>>
>> Regards, Jiri.
>>
>> On 8/14/19 12:37 AM, Vaibhav Gupta wrote:
>>
>>
>>
>> On Wed, Aug 14, 2019 at 4:04 AM Joel Sherrill wrote:
>>
>>>
>>>
>>> On Tue, Aug 13, 2019 at 5:09 PM Vaibhav Gupta
>>> wrote:
>>>
On Mon, Aug 12, 2019 at 11:50 PM Joel Sherrill wrote:
> Can you post or email me privately the full patch? I can try to see
> what I spot.
>
I have sent you the patch.
>
> Can you check with objdump or gdb that the methods which don't appear
> to work
> are actually the RISC-V implementation? Look at the disassembly and
> see if it
> looks like you expect.
>
I am exploring for this.
>>>
>>> Since I don't know how to attach gdb to the new sis for griscv, I
>>> emailed Jiri privately.
>>> Your program works as expected on Linux. Perhaps Jiri has some advice
>>> for my
>>> debugging setup ignorance and fenv on RISC-V.
>>>
>> Okay, I will wait. Till then I can work with porting for other
>> architecture. :)
>>
>>>
>>> Do you happen to have fenv support for another architecture queued up?
>>> It would be
>>> interesting to see if it works on other targets.
>>>
>> Yup, they were in my to do list. Till testsuite method is solved, I will
>> work on them now.
>>
>> - Vaibhav Gupta
>>
>>>
>>> --joel
>>>
>>>
- Vaibhav Gupta
>
> Does this require a patch to newlib as well?
>
> --joel
>
> On Sun, Aug 11, 2019 at 10:49 AM Vaibhav Gupta <
> vaibhavgupt...@gmail.com> wrote:
>
>> Configure command I used to build BSP:
>> ==
>> $ /home/varodek/development/rtems/kernel/rtems/configure
>> --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
>> --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
>> --enable-posix --disable-networking --enable-cxx
>> RISCV_ENABLE_HTIF_SUPPORT=1
>> ==
>> .
>> .
>> .
>> .
>> Qemu command I used to run test:
>> ==
>> $ qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M
>> -kernel psxfenv01.exe
>> ==
>> .
>> .
>> .
>> .
>> Makefile.am
>> ==
>> + if TEST_psxfenv01
>> + psx_tests += psxfenv01
>> + psxfenv01_SOURCES = psxfenv01/init.c
>> + psxfenv01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfenv01) \
>> + $(support_includes)
>> + psxfenv01_LDADD = -lm $(LDADD)
>> + endif
>> +
>> ==
>>
>> On Sun, Aug 11, 2019 at 8:36 PM Vaibhav Gupta <
>> vaibhavgupt...@gmail.com> wrote:
>>
>>> My code of testsuite:
>>> ===
>>> /* Test 'FE_DIVBYZERO' */
>>> puts( "\nDivide by zero and confirm fetestexcept()." );
>>> a = 0.0;
>>> b = 1.0;
>>> c = b/a;
>>> printf("\n%d",FE_DIVBYZERO);
>>> fegetexceptflag(&excepts,FE_ALL_EXCEPT);
>>> printf("\n%d",excepts);
>>> r = feraiseexcept(FE_DIVBYZERO);
>>> printf("\n%d\n",r);
>>> rtems_test_assert( fetestexcept(
Re: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV
So I cloned the 'sis' repository and build it locally:
$ git clone git://git.rtems.org/sis.git
.
.
On one terminal I was running sis:
$ ~/development/sis/sis -riscv nouartrx -gdb
.
.
.
.
On another terminal I did:
$ riscv-rtems5-gdb psxfenv01.exe
Reading symbols from psxfenv01.exe...done.
(gdb) target extended-remote localhost:1234
Remote debugging using localhost:1234
0x in ?? ()
(gdb) load
Loading section .start, size 0x3c lma 0x8000
Loading section .text, size 0xd8c4 lma 0x803c
Loading section .rodata, size 0x11e29 lma 0x8000d900
Loading section .sdata2, size 0x20 lma 0x8001f72c
Loading section .eh_frame, size 0x68 lma 0x8001f74c
Loading section .init_array, size 0x4 lma 0x8001f7b4
Loading section .fini_array, size 0x4 lma 0x8001f7b8
Loading section .rtemsroset, size 0x34 lma 0x8001f7bc
Loading section .data, size 0x488 lma 0x8001f7f0
Loading section .htif, size 0x1000 lma 0x8001fc80
Loading section .sdata, size 0x3c lma 0x80021000
Start address 0x8000, load size 134321
Transfer rate: 2474 KB/sec, 236 bytes/write.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program:
/home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/psxtests/psxfenv01.exe
.
.
The screen just hangs here.
Vaibhav Gupta
On Wed, Aug 14, 2019 at 12:48 PM Jiri Gaisler wrote:
> I have attached the sis manual. Page 17:
>
> "SIS can be connected to gdb through a network socket using the gdb remote
> interface.
> Either start SIS with -gdb, or issue the ’gdb’ command inside SIS, and
> connect gdb with
> ’target extended-remote localhost:1234’. The port can be changed using the
> -port option."
>
> You still need all other options, so to start on a windows host do:
>
> $ riscv-rtems-sis -riscv -nouartrx -gdb
>
> To start gdb, do:
>
> $ riscv-rtems-gdb app.exe
>
> (gdb) target extended-remote localhost:1234
>
> (gdb) load
>
> (gdb) run
>
> To re-run the application, issue a new load command first.
>
> Regards, Jiri.
>
> On 8/14/19 12:37 AM, Vaibhav Gupta wrote:
>
>
>
> On Wed, Aug 14, 2019 at 4:04 AM Joel Sherrill wrote:
>
>>
>>
>> On Tue, Aug 13, 2019 at 5:09 PM Vaibhav Gupta
>> wrote:
>>
>>>
>>>
>>> On Mon, Aug 12, 2019 at 11:50 PM Joel Sherrill wrote:
>>>
Can you post or email me privately the full patch? I can try to see
what I spot.
>>> I have sent you the patch.
>>>
Can you check with objdump or gdb that the methods which don't appear
to work
are actually the RISC-V implementation? Look at the disassembly and see
if it
looks like you expect.
>>> I am exploring for this.
>>>
>>
>> Since I don't know how to attach gdb to the new sis for griscv, I emailed
>> Jiri privately.
>> Your program works as expected on Linux. Perhaps Jiri has some advice for
>> my
>> debugging setup ignorance and fenv on RISC-V.
>>
> Okay, I will wait. Till then I can work with porting for other
> architecture. :)
>
>>
>> Do you happen to have fenv support for another architecture queued up? It
>> would be
>> interesting to see if it works on other targets.
>>
> Yup, they were in my to do list. Till testsuite method is solved, I will
> work on them now.
>
> - Vaibhav Gupta
>
>>
>> --joel
>>
>>
>>>
>>> - Vaibhav Gupta
>>>
Does this require a patch to newlib as well?
--joel
On Sun, Aug 11, 2019 at 10:49 AM Vaibhav Gupta <
vaibhavgupt...@gmail.com> wrote:
> Configure command I used to build BSP:
> ==
> $ /home/varodek/development/rtems/kernel/rtems/configure
> --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
> --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
> --enable-posix --disable-networking --enable-cxx
> RISCV_ENABLE_HTIF_SUPPORT=1
> ==
> .
> .
> .
> .
> Qemu command I used to run test:
> ==
> $ qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M
> -kernel psxfenv01.exe
> ==
> .
> .
> .
> .
> Makefile.am
> ==
> + if TEST_psxfenv01
> + psx_tests += psxfenv01
> + psxfenv01_SOURCES = psxfenv01/init.c
> + psxfenv01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfenv01) \
> + $(support_includes)
> + psxfenv01_LDADD = -lm $(LDADD)
> + endif
> +
> ==
>
> On Sun, Aug 11, 2019 at 8:36 PM Vaibhav Gupta <
> vaibhavgupt...@gmail.com> wrote:
>
>> My code of testsuite:
>> ===
>> /* Test 'FE_DIVBYZERO' */
>> puts( "\nDivide by zero and confirm fetestexcept()." );
>> a = 0.0;
>> b = 1.0;
>> c = b/a;
>> printf("\n%d",FE_DIVBYZERO);
Re: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV
On Sun, 11 Aug 2019 at 16:49, Vaibhav Gupta wrote:
>
> Configure command I used to build BSP:
> ==
> $ /home/varodek/development/rtems/kernel/rtems/configure
> --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
> --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
> --enable-posix --disable-networking --enable-cxx RISCV_ENABLE_HTIF_SUPPORT=1
> ==
> .
RISCV_ENABLE_HTIF_SUPPORT=1 should only be used if you're going to run
on a Spike platform. I see you're using virt below
> .
> .
> .
> Qemu command I used to run test:
> ==
> $ qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M -kernel
> psxfenv01.exe
> ==
> .
> .
> .
> .
> Makefile.am
> ==
> + if TEST_psxfenv01
> + psx_tests += psxfenv01
> + psxfenv01_SOURCES = psxfenv01/init.c
> + psxfenv01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfenv01) \
> + $(support_includes)
> + psxfenv01_LDADD = -lm $(LDADD)
> + endif
> +
> ==
>
> On Sun, Aug 11, 2019 at 8:36 PM Vaibhav Gupta
> wrote:
>>
>> My code of testsuite:
>> ===
>> /* Test 'FE_DIVBYZERO' */
>> puts( "\nDivide by zero and confirm fetestexcept()." );
>> a = 0.0;
>> b = 1.0;
>> c = b/a;
>> printf("\n%d",FE_DIVBYZERO);
>> fegetexceptflag(&excepts,FE_ALL_EXCEPT);
>> printf("\n%d",excepts);
>> r = feraiseexcept(FE_DIVBYZERO);
>> printf("\n%d\n",r);
>> rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
>> ==
>> OUTPUT
>> ==
>> Divide by zero and confirm fetestexcept().
>>
>> 8
>> 0
>> 1
>> /home/varodek/development/rtems/kernel/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:
>> 84 fetestexcept( FE_DIVBYZERO )
>> ==
>> EXPECTED OUTPUT
>> ==
>> Divide by zero and confirm fetestexcept().
>>
>> 8
>> 8
>> 0
>> ==
>> - fetestexcept( FE_DIVBYZERO ), should return a non-zero value as
>> division-by-zero was performed.
>> .
>> - feraiseexcept(FE_DIVBYZERO); is also not working. It should return zero
>> when successful
>> .
>> ==
>>
>> Thank You
>> Vaibhav Gupta
>>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
--
Hesham
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV
On Wed, Aug 14, 2019 at 6:22 PM Hesham Almatary
wrote:
> On Sun, 11 Aug 2019 at 16:49, Vaibhav Gupta
> wrote:
> >
> > Configure command I used to build BSP:
> > ==
> > $ /home/varodek/development/rtems/kernel/rtems/configure
> --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
> --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
> --enable-posix --disable-networking --enable-cxx RISCV_ENABLE_HTIF_SUPPORT=1
> > ==
> > .
> RISCV_ENABLE_HTIF_SUPPORT=1 should only be used if you're going to run
> on a Spike platform. I see you're using virt below
>
Yah this was the time I was doing all kind of experiments to run the hello
world thing.
I have disabled HTIF now.
>
> > .
> > .
> > .
> > Qemu command I used to run test:
> > ==
> > $ qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M
> -kernel psxfenv01.exe
> > ==
> > .
> > .
> > .
> > .
> > Makefile.am
> > ==
> > + if TEST_psxfenv01
> > + psx_tests += psxfenv01
> > + psxfenv01_SOURCES = psxfenv01/init.c
> > + psxfenv01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfenv01) \
> > + $(support_includes)
> > + psxfenv01_LDADD = -lm $(LDADD)
> > + endif
> > +
> > ==
> >
> > On Sun, Aug 11, 2019 at 8:36 PM Vaibhav Gupta
> wrote:
> >>
> >> My code of testsuite:
> >> ===
> >> /* Test 'FE_DIVBYZERO' */
> >> puts( "\nDivide by zero and confirm fetestexcept()." );
> >> a = 0.0;
> >> b = 1.0;
> >> c = b/a;
> >> printf("\n%d",FE_DIVBYZERO);
> >> fegetexceptflag(&excepts,FE_ALL_EXCEPT);
> >> printf("\n%d",excepts);
> >> r = feraiseexcept(FE_DIVBYZERO);
> >> printf("\n%d\n",r);
> >> rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
> >> ==
> >> OUTPUT
> >> ==
> >> Divide by zero and confirm fetestexcept().
> >>
> >> 8
> >> 0
> >> 1
> >>
> /home/varodek/development/rtems/kernel/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:
> 84 fetestexcept( FE_DIVBYZERO )
> >> ==
> >> EXPECTED OUTPUT
> >> ==
> >> Divide by zero and confirm fetestexcept().
> >>
> >> 8
> >> 8
> >> 0
> >> ==
> >> - fetestexcept( FE_DIVBYZERO ), should return a non-zero value as
> division-by-zero was performed.
> >> .
> >> - feraiseexcept(FE_DIVBYZERO); is also not working. It should return
> zero when successful
> >> .
> >> ==
> >>
> >> Thank You
> >> Vaibhav Gupta
> >>
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
> --
> Hesham
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV
I ran it on sis built from the git repository. Unfortunately, the output
doesn't match that I got on Linux.
=
$ ~/sis-riscv/install/bin/sis -riscv -gdb
SIS - SPARC/RISCV instruction simulator 2.17, copyright Jiri Gaisler 2019
Bug-reports to j...@gaisler.se
RISCV emulation enabled, 1 cpus online, delta 50 clocks
gdb: listening on port 1234 connected
X4000,0:#72
*** BEGIN OF TEST PSXFENV 01 ***
*** TEST VERSION: 5.0.0.a4d7e4cee77d16b0e34ef543f0804e7eb2954137
*** TEST STATE: EXPECTED-PASS
*** TEST BUILD: RTEMS_POSIX_API
*** TEST TOOLS: 9.1.0 20190503 (RTEMS 5, RSB
be90fb89678206e469f2f9189eb290cec49fd827, Newlib 6661a67)
Divide by zero and confirm fetestexcept().
8
0
1
*** END OF TEST PSXFENV 01 ***
*** FATAL ***
fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
fatal code: 0 (0x)
RTEMS version: 5.0.0.a4d7e4cee77d16b0e34ef543f0804e7eb2954137
RTEMS tools: 9.1.0 20190503 (RTEMS 5, RSB
be90fb89678206e469f2f9189eb290cec49fd827, Newlib 6661a67)
executing thread ID: 0x08a010001
executing thread name: UI1
=
On Wed, Aug 14, 2019 at 7:55 AM Vaibhav Gupta
wrote:
>
>
> On Wed, Aug 14, 2019 at 6:22 PM Hesham Almatary
> wrote:
>
>> On Sun, 11 Aug 2019 at 16:49, Vaibhav Gupta
>> wrote:
>> >
>> > Configure command I used to build BSP:
>> > ==
>> > $ /home/varodek/development/rtems/kernel/rtems/configure
>> --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
>> --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
>> --enable-posix --disable-networking --enable-cxx RISCV_ENABLE_HTIF_SUPPORT=1
>> > ==
>> > .
>> RISCV_ENABLE_HTIF_SUPPORT=1 should only be used if you're going to run
>> on a Spike platform. I see you're using virt below
>>
> Yah this was the time I was doing all kind of experiments to run the
> hello world thing.
> I have disabled HTIF now.
>
>>
>> > .
>> > .
>> > .
>> > Qemu command I used to run test:
>> > ==
>> > $ qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M
>> -kernel psxfenv01.exe
>> > ==
>> > .
>> > .
>> > .
>> > .
>> > Makefile.am
>> > ==
>> > + if TEST_psxfenv01
>> > + psx_tests += psxfenv01
>> > + psxfenv01_SOURCES = psxfenv01/init.c
>> > + psxfenv01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfenv01) \
>> > + $(support_includes)
>> > + psxfenv01_LDADD = -lm $(LDADD)
>> > + endif
>> > +
>> > ==
>> >
>> > On Sun, Aug 11, 2019 at 8:36 PM Vaibhav Gupta
>> wrote:
>> >>
>> >> My code of testsuite:
>> >> ===
>> >> /* Test 'FE_DIVBYZERO' */
>> >> puts( "\nDivide by zero and confirm fetestexcept()." );
>> >> a = 0.0;
>> >> b = 1.0;
>> >> c = b/a;
>> >> printf("\n%d",FE_DIVBYZERO);
>> >> fegetexceptflag(&excepts,FE_ALL_EXCEPT);
>> >> printf("\n%d",excepts);
>> >> r = feraiseexcept(FE_DIVBYZERO);
>> >> printf("\n%d\n",r);
>> >> rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
>> >> ==
>> >> OUTPUT
>> >> ==
>> >> Divide by zero and confirm fetestexcept().
>> >>
>> >> 8
>> >> 0
>> >> 1
>> >>
>> /home/varodek/development/rtems/kernel/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:
>> 84 fetestexcept( FE_DIVBYZERO )
>> >> ==
>> >> EXPECTED OUTPUT
>> >> ==
>> >> Divide by zero and confirm fetestexcept().
>> >>
>> >> 8
>> >> 8
>> >> 0
>> >> ==
>> >> - fetestexcept( FE_DIVBYZERO ), should return a non-zero value as
>> division-by-zero was performed.
>> >> .
>> >> - feraiseexcept(FE_DIVBYZERO); is also not working. It should return
>> zero when successful
>> >> .
>> >> ==
>> >>
>> >> Thank You
>> >> Vaibhav Gupta
>> >>
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>>
>> --
>> Hesham
>>
> ___
> 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: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV
You are also getting same error :(
I thought problem is with my system/laptop and was trying to correct things.
Should we take the discussion to newlib?
Vaibhav Gupta
On Wed, Aug 14, 2019 at 7:51 PM Joel Sherrill wrote:
>
> I ran it on sis built from the git repository. Unfortunately, the output
> doesn't match that I got on Linux.
>
> =
> $ ~/sis-riscv/install/bin/sis -riscv -gdb
>
> SIS - SPARC/RISCV instruction simulator 2.17, copyright Jiri Gaisler 2019
> Bug-reports to j...@gaisler.se
>
> RISCV emulation enabled, 1 cpus online, delta 50 clocks
>
> gdb: listening on port 1234 connected
> X4000,0:#72
>
>
> *** BEGIN OF TEST PSXFENV 01 ***
> *** TEST VERSION: 5.0.0.a4d7e4cee77d16b0e34ef543f0804e7eb2954137
> *** TEST STATE: EXPECTED-PASS
> *** TEST BUILD: RTEMS_POSIX_API
> *** TEST TOOLS: 9.1.0 20190503 (RTEMS 5, RSB
> be90fb89678206e469f2f9189eb290cec49fd827, Newlib 6661a67)
>
> Divide by zero and confirm fetestexcept().
>
> 8
> 0
> 1
>
> *** END OF TEST PSXFENV 01 ***
>
>
> *** FATAL ***
> fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
> fatal code: 0 (0x)
> RTEMS version: 5.0.0.a4d7e4cee77d16b0e34ef543f0804e7eb2954137
> RTEMS tools: 9.1.0 20190503 (RTEMS 5, RSB
> be90fb89678206e469f2f9189eb290cec49fd827, Newlib 6661a67)
> executing thread ID: 0x08a010001
> executing thread name: UI1
> =
> On Wed, Aug 14, 2019 at 7:55 AM Vaibhav Gupta
> wrote:
>
>>
>>
>> On Wed, Aug 14, 2019 at 6:22 PM Hesham Almatary
>> wrote:
>>
>>> On Sun, 11 Aug 2019 at 16:49, Vaibhav Gupta
>>> wrote:
>>> >
>>> > Configure command I used to build BSP:
>>> > ==
>>> > $ /home/varodek/development/rtems/kernel/rtems/configure
>>> --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
>>> --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
>>> --enable-posix --disable-networking --enable-cxx RISCV_ENABLE_HTIF_SUPPORT=1
>>> > ==
>>> > .
>>> RISCV_ENABLE_HTIF_SUPPORT=1 should only be used if you're going to run
>>> on a Spike platform. I see you're using virt below
>>>
>> Yah this was the time I was doing all kind of experiments to run the
>> hello world thing.
>> I have disabled HTIF now.
>>
>>>
>>> > .
>>> > .
>>> > .
>>> > Qemu command I used to run test:
>>> > ==
>>> > $ qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M
>>> -kernel psxfenv01.exe
>>> > ==
>>> > .
>>> > .
>>> > .
>>> > .
>>> > Makefile.am
>>> > ==
>>> > + if TEST_psxfenv01
>>> > + psx_tests += psxfenv01
>>> > + psxfenv01_SOURCES = psxfenv01/init.c
>>> > + psxfenv01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfenv01) \
>>> > + $(support_includes)
>>> > + psxfenv01_LDADD = -lm $(LDADD)
>>> > + endif
>>> > +
>>> > ==
>>> >
>>> > On Sun, Aug 11, 2019 at 8:36 PM Vaibhav Gupta <
>>> vaibhavgupt...@gmail.com> wrote:
>>> >>
>>> >> My code of testsuite:
>>> >> ===
>>> >> /* Test 'FE_DIVBYZERO' */
>>> >> puts( "\nDivide by zero and confirm fetestexcept()." );
>>> >> a = 0.0;
>>> >> b = 1.0;
>>> >> c = b/a;
>>> >> printf("\n%d",FE_DIVBYZERO);
>>> >> fegetexceptflag(&excepts,FE_ALL_EXCEPT);
>>> >> printf("\n%d",excepts);
>>> >> r = feraiseexcept(FE_DIVBYZERO);
>>> >> printf("\n%d\n",r);
>>> >> rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
>>> >> ==
>>> >> OUTPUT
>>> >> ==
>>> >> Divide by zero and confirm fetestexcept().
>>> >>
>>> >> 8
>>> >> 0
>>> >> 1
>>> >>
>>> /home/varodek/development/rtems/kernel/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:
>>> 84 fetestexcept( FE_DIVBYZERO )
>>> >> ==
>>> >> EXPECTED OUTPUT
>>> >> ==
>>> >> Divide by zero and confirm fetestexcept().
>>> >>
>>> >> 8
>>> >> 8
>>> >> 0
>>> >> ==
>>> >> - fetestexcept( FE_DIVBYZERO ), should return a non-zero value as
>>> division-by-zero was performed.
>>> >> .
>>> >> - feraiseexcept(FE_DIVBYZERO); is also not working. It should return
>>> zero when successful
>>> >> .
>>> >> ==
>>> >>
>>> >> Thank You
>>> >> Vaibhav Gupta
>>> >>
>>> > ___
>>> > devel mailing list
>>> > devel@rtems.org
>>> > http://lists.rtems.org/mailman/listinfo/devel
>>>
>>> --
>>> Hesham
>>>
>> ___
>> 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: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV
On Wed, Aug 14, 2019 at 9:35 AM Vaibhav Gupta wrote:
>
> You are also getting same error :(
> I thought problem is with my system/laptop and was trying to correct things.
> Should we take the discussion to newlib?
I would like Jiri and Hesham to chime in on the next step. I don't
know the RISC-V
well enough to say if this is a bug in risc-v fenv or not.
Keep plugging at another architecture.
--joel
>
> Vaibhav Gupta
>
> On Wed, Aug 14, 2019 at 7:51 PM Joel Sherrill wrote:
>>
>>
>> I ran it on sis built from the git repository. Unfortunately, the output
>> doesn't match that I got on Linux.
>>
>> =
>> $ ~/sis-riscv/install/bin/sis -riscv -gdb
>>
>> SIS - SPARC/RISCV instruction simulator 2.17, copyright Jiri Gaisler 2019
>> Bug-reports to j...@gaisler.se
>>
>> RISCV emulation enabled, 1 cpus online, delta 50 clocks
>>
>> gdb: listening on port 1234 connected
>> X4000,0:#72
>>
>>
>> *** BEGIN OF TEST PSXFENV 01 ***
>> *** TEST VERSION: 5.0.0.a4d7e4cee77d16b0e34ef543f0804e7eb2954137
>> *** TEST STATE: EXPECTED-PASS
>> *** TEST BUILD: RTEMS_POSIX_API
>> *** TEST TOOLS: 9.1.0 20190503 (RTEMS 5, RSB
>> be90fb89678206e469f2f9189eb290cec49fd827, Newlib 6661a67)
>>
>> Divide by zero and confirm fetestexcept().
>>
>> 8
>> 0
>> 1
>>
>> *** END OF TEST PSXFENV 01 ***
>>
>>
>> *** FATAL ***
>> fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
>> fatal code: 0 (0x)
>> RTEMS version: 5.0.0.a4d7e4cee77d16b0e34ef543f0804e7eb2954137
>> RTEMS tools: 9.1.0 20190503 (RTEMS 5, RSB
>> be90fb89678206e469f2f9189eb290cec49fd827, Newlib 6661a67)
>> executing thread ID: 0x08a010001
>> executing thread name: UI1
>> =
>> On Wed, Aug 14, 2019 at 7:55 AM Vaibhav Gupta
>> wrote:
>>>
>>>
>>>
>>> On Wed, Aug 14, 2019 at 6:22 PM Hesham Almatary
>>> wrote:
On Sun, 11 Aug 2019 at 16:49, Vaibhav Gupta
wrote:
>
> Configure command I used to build BSP:
> ==
> $ /home/varodek/development/rtems/kernel/rtems/configure
> --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
> --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
> --enable-posix --disable-networking --enable-cxx
> RISCV_ENABLE_HTIF_SUPPORT=1
> ==
> .
RISCV_ENABLE_HTIF_SUPPORT=1 should only be used if you're going to run
on a Spike platform. I see you're using virt below
>>>
>>> Yah this was the time I was doing all kind of experiments to run the hello
>>> world thing.
>>> I have disabled HTIF now.
> .
> .
> .
> Qemu command I used to run test:
> ==
> $ qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M
> -kernel psxfenv01.exe
> ==
> .
> .
> .
> .
> Makefile.am
> ==
> + if TEST_psxfenv01
> + psx_tests += psxfenv01
> + psxfenv01_SOURCES = psxfenv01/init.c
> + psxfenv01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfenv01) \
> + $(support_includes)
> + psxfenv01_LDADD = -lm $(LDADD)
> + endif
> +
> ==
>
> On Sun, Aug 11, 2019 at 8:36 PM Vaibhav Gupta
> wrote:
>>
>> My code of testsuite:
>> ===
>> /* Test 'FE_DIVBYZERO' */
>> puts( "\nDivide by zero and confirm fetestexcept()." );
>> a = 0.0;
>> b = 1.0;
>> c = b/a;
>> printf("\n%d",FE_DIVBYZERO);
>> fegetexceptflag(&excepts,FE_ALL_EXCEPT);
>> printf("\n%d",excepts);
>> r = feraiseexcept(FE_DIVBYZERO);
>> printf("\n%d\n",r);
>> rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
>> ==
>> OUTPUT
>> ==
>> Divide by zero and confirm fetestexcept().
>>
>> 8
>> 0
>> 1
>> /home/varodek/development/rtems/kernel/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:
>> 84 fetestexcept( FE_DIVBYZERO )
>> ==
>> EXPECTED OUTPUT
>> ==
>> Divide by zero and confirm fetestexcept().
>>
>> 8
>> 8
>> 0
>> ==
>> - fetestexcept( FE_DIVBYZERO ), should return a non-zero value as
>> division-by-zero was performed.
>> .
>> - feraiseexcept(FE_DIVBYZERO); is also not working. It should return
>> zero when successful
>> .
>> ==
>>
>> Thank You
>> Vaibhav Gupta
>>
> ___
> d
Checksum Error on Leon3 Qemu patches
Hi 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. checksums: 0001-LEON3-Add-emulation-of-AMBA-plug-play.patch: 1162bfb7b5839237803356e5fb6efaafdec5b9d2df9d23de42c86d48c5e35327 => 5f2ca77e727dc3b4f9d78ff8c62d610b1bc2afd3345106401cf26e99452db067 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV
On Wed, Aug 14, 2019, 8:09 PM Joel Sherrill wrote:
> On Wed, Aug 14, 2019 at 9:35 AM Vaibhav Gupta
> wrote:
> >
> > You are also getting same error :(
> > I thought problem is with my system/laptop and was trying to correct
> things.
> > Should we take the discussion to newlib?
>
> I would like Jiri and Hesham to chime in on the next step. I don't
> know the RISC-V
> well enough to say if this is a bug in risc-v fenv or not.
>
Okay
>
> Keep plugging at another architecture.
>
On that!
>
> --joel
>
> >
> > Vaibhav Gupta
> >
> > On Wed, Aug 14, 2019 at 7:51 PM Joel Sherrill wrote:
> >>
> >>
> >> I ran it on sis built from the git repository. Unfortunately, the
> output doesn't match that I got on Linux.
> >>
> >> =
> >> $ ~/sis-riscv/install/bin/sis -riscv -gdb
> >>
> >> SIS - SPARC/RISCV instruction simulator 2.17, copyright Jiri Gaisler
> 2019
> >> Bug-reports to j...@gaisler.se
> >>
> >> RISCV emulation enabled, 1 cpus online, delta 50 clocks
> >>
> >> gdb: listening on port 1234 connected
> >> X4000,0:#72
> >>
> >>
> >> *** BEGIN OF TEST PSXFENV 01 ***
> >> *** TEST VERSION: 5.0.0.a4d7e4cee77d16b0e34ef543f0804e7eb2954137
> >> *** TEST STATE: EXPECTED-PASS
> >> *** TEST BUILD: RTEMS_POSIX_API
> >> *** TEST TOOLS: 9.1.0 20190503 (RTEMS 5, RSB
> be90fb89678206e469f2f9189eb290cec49fd827, Newlib 6661a67)
> >>
> >> Divide by zero and confirm fetestexcept().
> >>
> >> 8
> >> 0
> >> 1
> >>
> >> *** END OF TEST PSXFENV 01 ***
> >>
> >>
> >> *** FATAL ***
> >> fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
> >> fatal code: 0 (0x)
> >> RTEMS version: 5.0.0.a4d7e4cee77d16b0e34ef543f0804e7eb2954137
> >> RTEMS tools: 9.1.0 20190503 (RTEMS 5, RSB
> be90fb89678206e469f2f9189eb290cec49fd827, Newlib 6661a67)
> >> executing thread ID: 0x08a010001
> >> executing thread name: UI1
> >> =
> >> On Wed, Aug 14, 2019 at 7:55 AM Vaibhav Gupta
> wrote:
> >>>
> >>>
> >>>
> >>> On Wed, Aug 14, 2019 at 6:22 PM Hesham Almatary <
> heshamelmat...@gmail.com> wrote:
>
> On Sun, 11 Aug 2019 at 16:49, Vaibhav Gupta
> wrote:
> >
> > Configure command I used to build BSP:
> > ==
> > $ /home/varodek/development/rtems/kernel/rtems/configure
> --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
> --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
> --enable-posix --disable-networking --enable-cxx RISCV_ENABLE_HTIF_SUPPORT=1
> > ==
> > .
> RISCV_ENABLE_HTIF_SUPPORT=1 should only be used if you're going to run
> on a Spike platform. I see you're using virt below
> >>>
> >>> Yah this was the time I was doing all kind of experiments to run the
> hello world thing.
> >>> I have disabled HTIF now.
>
>
> > .
> > .
> > .
> > Qemu command I used to run test:
> > ==
> > $ qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M
> -kernel psxfenv01.exe
> > ==
> > .
> > .
> > .
> > .
> > Makefile.am
> > ==
> > + if TEST_psxfenv01
> > + psx_tests += psxfenv01
> > + psxfenv01_SOURCES = psxfenv01/init.c
> > + psxfenv01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfenv01) \
> > + $(support_includes)
> > + psxfenv01_LDADD = -lm $(LDADD)
> > + endif
> > +
> > ==
> >
> > On Sun, Aug 11, 2019 at 8:36 PM Vaibhav Gupta <
> vaibhavgupt...@gmail.com> wrote:
> >>
> >> My code of testsuite:
> >> ===
> >> /* Test 'FE_DIVBYZERO' */
> >> puts( "\nDivide by zero and confirm fetestexcept()." );
> >> a = 0.0;
> >> b = 1.0;
> >> c = b/a;
> >> printf("\n%d",FE_DIVBYZERO);
> >> fegetexceptflag(&excepts,FE_ALL_EXCEPT);
> >> printf("\n%d",excepts);
> >> r = feraiseexcept(FE_DIVBYZERO);
> >> printf("\n%d\n",r);
> >> rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
> >> ==
> >> OUTPUT
> >> ==
> >> Divide by zero and confirm fetestexcept().
> >>
> >> 8
> >> 0
> >> 1
> >>
> /home/varodek/development/rtems/kernel/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:
> 84 fetestexcept( FE_DIVBYZERO )
> >> ==
> >> EXPECTED OUTPUT
> >> ==
> >> Divide by zero and confirm fetestexcept().
> >>
> >> 8
> >> 8
> >> 0
> >> ==
> >> - fetestexcept( FE_DIVBYZERO ), should return a non-zero value as
> divi
Re: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV
On Wed, 14 Aug 2019 at 16:18, Vaibhav Gupta wrote:
>
>
>
> On Wed, Aug 14, 2019, 8:09 PM Joel Sherrill wrote:
>>
>> On Wed, Aug 14, 2019 at 9:35 AM Vaibhav Gupta
>> wrote:
>> >
>> > You are also getting same error :(
>> > I thought problem is with my system/laptop and was trying to correct
>> > things.
>> > Should we take the discussion to newlib?
>>
>> I would like Jiri and Hesham to chime in on the next step. I don't
>> know the RISC-V
>> well enough to say if this is a bug in risc-v fenv or not.
>
> Okay
Can you try to build a BSP with FPU instructions? rv32imafdc? and test
again? I assume this will eventually do FPU calculations that will
emit FPU instructions in the case of rv32imafdc or softfloat in the
case of rv32imac.
>>
>>
>> Keep plugging at another architecture.
>
> On that!
>>
>>
>> --joel
>>
>> >
>> > Vaibhav Gupta
>> >
>> > On Wed, Aug 14, 2019 at 7:51 PM Joel Sherrill wrote:
>> >>
>> >>
>> >> I ran it on sis built from the git repository. Unfortunately, the output
>> >> doesn't match that I got on Linux.
>> >>
>> >> =
>> >> $ ~/sis-riscv/install/bin/sis -riscv -gdb
>> >>
>> >> SIS - SPARC/RISCV instruction simulator 2.17, copyright Jiri Gaisler
>> >> 2019
>> >> Bug-reports to j...@gaisler.se
>> >>
>> >> RISCV emulation enabled, 1 cpus online, delta 50 clocks
>> >>
>> >> gdb: listening on port 1234 connected
>> >> X4000,0:#72
>> >>
>> >>
>> >> *** BEGIN OF TEST PSXFENV 01 ***
>> >> *** TEST VERSION: 5.0.0.a4d7e4cee77d16b0e34ef543f0804e7eb2954137
>> >> *** TEST STATE: EXPECTED-PASS
>> >> *** TEST BUILD: RTEMS_POSIX_API
>> >> *** TEST TOOLS: 9.1.0 20190503 (RTEMS 5, RSB
>> >> be90fb89678206e469f2f9189eb290cec49fd827, Newlib 6661a67)
>> >>
>> >> Divide by zero and confirm fetestexcept().
>> >>
>> >> 8
>> >> 0
>> >> 1
>> >>
>> >> *** END OF TEST PSXFENV 01 ***
>> >>
>> >>
>> >> *** FATAL ***
>> >> fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
>> >> fatal code: 0 (0x)
>> >> RTEMS version: 5.0.0.a4d7e4cee77d16b0e34ef543f0804e7eb2954137
>> >> RTEMS tools: 9.1.0 20190503 (RTEMS 5, RSB
>> >> be90fb89678206e469f2f9189eb290cec49fd827, Newlib 6661a67)
>> >> executing thread ID: 0x08a010001
>> >> executing thread name: UI1
>> >> =
>> >> On Wed, Aug 14, 2019 at 7:55 AM Vaibhav Gupta
>> >> wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Wed, Aug 14, 2019 at 6:22 PM Hesham Almatary
>> >>> wrote:
>>
>> On Sun, 11 Aug 2019 at 16:49, Vaibhav Gupta
>> wrote:
>> >
>> > Configure command I used to build BSP:
>> > ==
>> > $ /home/varodek/development/rtems/kernel/rtems/configure
>> > --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
>> > --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
>> > --enable-posix --disable-networking --enable-cxx
>> > RISCV_ENABLE_HTIF_SUPPORT=1
>> > ==
>> > .
>> RISCV_ENABLE_HTIF_SUPPORT=1 should only be used if you're going to run
>> on a Spike platform. I see you're using virt below
>> >>>
>> >>> Yah this was the time I was doing all kind of experiments to run the
>> >>> hello world thing.
>> >>> I have disabled HTIF now.
>>
>>
>> > .
>> > .
>> > .
>> > Qemu command I used to run test:
>> > ==
>> > $ qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M
>> > -kernel psxfenv01.exe
>> > ==
>> > .
>> > .
>> > .
>> > .
>> > Makefile.am
>> > ==
>> > + if TEST_psxfenv01
>> > + psx_tests += psxfenv01
>> > + psxfenv01_SOURCES = psxfenv01/init.c
>> > + psxfenv01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfenv01) \
>> > + $(support_includes)
>> > + psxfenv01_LDADD = -lm $(LDADD)
>> > + endif
>> > +
>> > ==
>> >
>> > On Sun, Aug 11, 2019 at 8:36 PM Vaibhav Gupta
>> > wrote:
>> >>
>> >> My code of testsuite:
>> >> ===
>> >> /* Test 'FE_DIVBYZERO' */
>> >> puts( "\nDivide by zero and confirm fetestexcept()." );
>> >> a = 0.0;
>> >> b = 1.0;
>> >> c = b/a;
>> >> printf("\n%d",FE_DIVBYZERO);
>> >> fegetexceptflag(&excepts,FE_ALL_EXCEPT);
>> >> printf("\n%d",excepts);
>> >> r = feraiseexcept(FE_DIVBYZERO);
>> >> printf("\n%d\n",r);
>> >> rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
>> >> ==
>> >> OUTPUT
>> >> ==
>> >> Divide by zero and confirm fetestexcept().
>> >>
>> >> 8
>> >> 0
>> >> 1
>> >> /home/varodek/development/rtems/kerne
Re: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV
On Wed, Aug 14, 2019 at 8:56 PM Hesham Almatary
wrote:
> On Wed, 14 Aug 2019 at 16:18, Vaibhav Gupta
> wrote:
> >
> >
> >
> > On Wed, Aug 14, 2019, 8:09 PM Joel Sherrill wrote:
> >>
> >> On Wed, Aug 14, 2019 at 9:35 AM Vaibhav Gupta
> wrote:
> >> >
> >> > You are also getting same error :(
> >> > I thought problem is with my system/laptop and was trying to correct
> things.
> >> > Should we take the discussion to newlib?
> >>
> >> I would like Jiri and Hesham to chime in on the next step. I don't
> >> know the RISC-V
> >> well enough to say if this is a bug in risc-v fenv or not.
> >
> > Okay
>
> Can you try to build a BSP with FPU instructions? rv32imafdc? and test
> again? I assume this will eventually do FPU calculations that will
> emit FPU instructions in the case of rv32imafdc or softfloat in the
> case of rv32imac.
>
Okay I will try this direction too then.
>
> >>
> >>
> >> Keep plugging at another architecture.
> >
> > On that!
> >>
> >>
> >> --joel
> >>
> >> >
> >> > Vaibhav Gupta
> >> >
> >> > On Wed, Aug 14, 2019 at 7:51 PM Joel Sherrill wrote:
> >> >>
> >> >>
> >> >> I ran it on sis built from the git repository. Unfortunately, the
> output doesn't match that I got on Linux.
> >> >>
> >> >> =
> >> >> $ ~/sis-riscv/install/bin/sis -riscv -gdb
> >> >>
> >> >> SIS - SPARC/RISCV instruction simulator 2.17, copyright Jiri
> Gaisler 2019
> >> >> Bug-reports to j...@gaisler.se
> >> >>
> >> >> RISCV emulation enabled, 1 cpus online, delta 50 clocks
> >> >>
> >> >> gdb: listening on port 1234 connected
> >> >> X4000,0:#72
> >> >>
> >> >>
> >> >> *** BEGIN OF TEST PSXFENV 01 ***
> >> >> *** TEST VERSION: 5.0.0.a4d7e4cee77d16b0e34ef543f0804e7eb2954137
> >> >> *** TEST STATE: EXPECTED-PASS
> >> >> *** TEST BUILD: RTEMS_POSIX_API
> >> >> *** TEST TOOLS: 9.1.0 20190503 (RTEMS 5, RSB
> be90fb89678206e469f2f9189eb290cec49fd827, Newlib 6661a67)
> >> >>
> >> >> Divide by zero and confirm fetestexcept().
> >> >>
> >> >> 8
> >> >> 0
> >> >> 1
> >> >>
> >> >> *** END OF TEST PSXFENV 01 ***
> >> >>
> >> >>
> >> >> *** FATAL ***
> >> >> fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
> >> >> fatal code: 0 (0x)
> >> >> RTEMS version: 5.0.0.a4d7e4cee77d16b0e34ef543f0804e7eb2954137
> >> >> RTEMS tools: 9.1.0 20190503 (RTEMS 5, RSB
> be90fb89678206e469f2f9189eb290cec49fd827, Newlib 6661a67)
> >> >> executing thread ID: 0x08a010001
> >> >> executing thread name: UI1
> >> >> =
> >> >> On Wed, Aug 14, 2019 at 7:55 AM Vaibhav Gupta <
> vaibhavgupt...@gmail.com> wrote:
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Wed, Aug 14, 2019 at 6:22 PM Hesham Almatary <
> heshamelmat...@gmail.com> wrote:
> >>
> >> On Sun, 11 Aug 2019 at 16:49, Vaibhav Gupta <
> vaibhavgupt...@gmail.com> wrote:
> >> >
> >> > Configure command I used to build BSP:
> >> > ==
> >> > $ /home/varodek/development/rtems/kernel/rtems/configure
> --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
> --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
> --enable-posix --disable-networking --enable-cxx RISCV_ENABLE_HTIF_SUPPORT=1
> >> > ==
> >> > .
> >> RISCV_ENABLE_HTIF_SUPPORT=1 should only be used if you're going to
> run
> >> on a Spike platform. I see you're using virt below
> >> >>>
> >> >>> Yah this was the time I was doing all kind of experiments to run
> the hello world thing.
> >> >>> I have disabled HTIF now.
> >>
> >>
> >> > .
> >> > .
> >> > .
> >> > Qemu command I used to run test:
> >> > ==
> >> > $ qemu-system-riscv32 -no-reboot -nographic -machine virt -m
> 256M -kernel psxfenv01.exe
> >> > ==
> >> > .
> >> > .
> >> > .
> >> > .
> >> > Makefile.am
> >> > ==
> >> > + if TEST_psxfenv01
> >> > + psx_tests += psxfenv01
> >> > + psxfenv01_SOURCES = psxfenv01/init.c
> >> > + psxfenv01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfenv01) \
> >> > + $(support_includes)
> >> > + psxfenv01_LDADD = -lm $(LDADD)
> >> > + endif
> >> > +
> >> > ==
> >> >
> >> > On Sun, Aug 11, 2019 at 8:36 PM Vaibhav Gupta <
> vaibhavgupt...@gmail.com> wrote:
> >> >>
> >> >> My code of testsuite:
> >> >> ===
> >> >> /* Test 'FE_DIVBYZERO' */
> >> >> puts( "\nDivide by zero and confirm fetestexcept()." );
> >> >> a = 0.0;
> >> >> b = 1.0;
> >> >> c = b/a;
> >> >> printf("\n%d",FE_DIVBYZERO);
> >> >> fegetexceptflag(&excepts,FE_ALL_EXCEPT);
> >> >> printf("\n%d",excepts);
> >> >> r = feraiseexcept(FE_DIVBYZERO);
> >> >> p
[PATCH] dtc.bset: update to 1.4.1 to match qemu
From: Joel Sherrill --- bare/config/devel/dtc.bset | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bare/config/devel/dtc.bset b/bare/config/devel/dtc.bset index d701f93..54521f6 100644 --- a/bare/config/devel/dtc.bset +++ b/bare/config/devel/dtc.bset @@ -4,4 +4,4 @@ %define release 1 -devel/dtc-1.2.0 +devel/dtc-1.4.1-1 -- 1.8.3.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/2] spike.bset: Add dtc
From: Joel Sherrill --- bare/config/devel/spike.bset | 1 + 1 file changed, 1 insertion(+) diff --git a/bare/config/devel/spike.bset b/bare/config/devel/spike.bset index c7a6340..76392f7 100644 --- a/bare/config/devel/spike.bset +++ b/bare/config/devel/spike.bset @@ -4,4 +4,5 @@ %define release 1 +devel/dtc-1.4.1-1 devel/spike-1.1.0 -- 1.8.3.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
littleVGL now supports FreeBSD framebuffer
Hello all, I wrote a patch for lv_drivers repository to support FreeBSD framebuffer in fbdev, which they merged to the master today. I have tested the driver to be working with an app that I wrote on FreeBSD and tested it on Beaglebone black image 12-STABLE. I intend to write an RSB recipe to build littleVGL and seek some guidance on how to proceed. :) Thanks, Vijay ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
GSoC Final report review
Hello all, I have prepared a draft for the GSoC final report. It would be nice to have some review on it before I push it to the blog. The google docs link [1] contains a paste from the .md file that will be converted to html for the blog so the formatting got messed up in the word file and the links are also there. If it's difficult to read it this way then I'll post it to the blog and then make changes according to the review on the blog. Note: I haven't added littleVGL port to RSB in this draft. If I complete it before deadline, I'll include it in the report. Also, I'll post the blog link here before submitting to Google, for any last changes needed. [1]: https://docs.google.com/document/d/1ZEU3uP1Tx51lnmvwDOZzc861c_YpS6Zu6RsR8jqk56k/edit?usp=sharing Thanks, Vijay ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
fenv on RISC-V
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
Re: RTEMS Source Builder failed for MX Linux
Hi Chris, Finally RTEMS build run for MX Linux. I will soon release the patch after testing it. Thanks Himanshu ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: fenv on RISC-V
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: fenv on RISC-V
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: [PATCH] dtc.bset: update to 1.4.1 to match qemu
Which qemu? On 15/8/19 1:36 am, j...@rtems.org wrote: > From: Joel Sherrill > > --- > bare/config/devel/dtc.bset | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/bare/config/devel/dtc.bset b/bare/config/devel/dtc.bset > index d701f93..54521f6 100644 > --- a/bare/config/devel/dtc.bset > +++ b/bare/config/devel/dtc.bset > @@ -4,4 +4,4 @@ > > %define release 1 > > -devel/dtc-1.2.0 > +devel/dtc-1.4.1-1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Checksum Error on Leon3 Qemu patches
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. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] dtc.bset: update to 1.4.1 to match qemu
qemu-couverture.bset explicitly has 1.4.1. qemu.bset doesn't list dtc at all. No idea why not. But qemu-git-1.cfg has a dtc submodule of qemu pulled out of git so I guess qemu.bset is implicitly getting that. Clear as mud to me. On Wed, Aug 14, 2019 at 4:40 PM Chris Johns wrote: > > Which qemu? > > On 15/8/19 1:36 am, j...@rtems.org wrote: > > From: Joel Sherrill > > > > --- > > bare/config/devel/dtc.bset | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/bare/config/devel/dtc.bset b/bare/config/devel/dtc.bset > > index d701f93..54521f6 100644 > > --- a/bare/config/devel/dtc.bset > > +++ b/bare/config/devel/dtc.bset > > @@ -4,4 +4,4 @@ > > > > %define release 1 > > > > -devel/dtc-1.2.0 > > +devel/dtc-1.4.1-1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Checksum Error on Leon3 Qemu patches
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? > > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: littleVGL now supports FreeBSD framebuffer
On 15/8/19 2:07 am, Vijay Kumar Banerjee wrote:
> I wrote a patch for lv_drivers repository to support FreeBSD framebuffer
> in fbdev, which they merged to the master today.
Well done, that is great.
> I have tested
> the driver to be working with an app that I wrote on FreeBSD and
> tested it on Beaglebone black image 12-STABLE.
Awesome.
> I intend to write an RSB recipe to build littleVGL and seek some guidance
> on how to proceed. :)
Please review
https://docs.rtems.org/branches/master/user/rsb/third-party-packages.html
I suggest you see how the curl package is done. It is a nice clean example.
The packages are sort of based on the FreeBSD ports layout. Littlevgl is not a
port so we can use `graphics/littlevgl`.
The file pattern used in the RSB for a 3rd party package is:
- A buildset or bset file, this is the top level wrapper for the config files
and selects the version to be built...
https://git.rtems.org/rtems-source-builder/tree/rtems/config/ftp/curl.bset
- The version specific config file that sets the version and checksum for the
package. It includes the build config or recipe...
https://git.rtems.org/rtems-source-builder/tree/rtems/config/ftp/curl-7.65.1-1.cfg
Note, this is a 3prd party package so includes `rtems-bsp.cfg`. This create a
suitable environment to build a package for a BSP.
- The build config file ...
https://git.rtems.org/rtems-source-builder/tree/source-builder/config/curl-1.cfg
These configs do not include any other configs and could be used to build a
native package for a host or a 3rd party package for RTEMS.
- The `%prep` section prepares the source to build. For github if we are
building from master we select a commit and fetch a compressed tarball. This
means we can snapshot the source when making a release. The RSB can work
directly with the git repo however this has proven to be more fragile than a
tarball.
- The `%build` section builds the package. The contents of this file are used to
create a shell script. Use --dry-run, --trace and --log to debug what is
happening. The shell script contents should be viewable in the log file if a dry
run does not created it. There is a lot of trace but searching will help you
locate the piece you are interested in. The `source_dir_*` shell variable is the
directory created by extracting the tarfile. The macros `%{build_directory}` and
`%{host_build_flags}` are defined in `defaults.mc` and should handle the
compiler and flags. You may want to check libbsd is installed in your config,
see ...
https://git.rtems.org/rtems-source-builder/tree/rtems/config/rtems-bsp.cfg#n198
.. for an example of how to check and add `%error This package needs libbsd,
please build and install` or something like that as an error. The paths to
install to are set up for you, these match how a BSP and RTEMS are installed.
The layout needs to be followed or applications will not be able to find the
header or the library.
- The `%install` section installs the package. The install process is to a
staging area `${SB_BUILD_ROOT}`. Nothing is installed unless all parts build so
we do not have an inconsistent build in the install prefix.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] dtc.bset: update to 1.4.1 to match qemu
On 15/8/19 8:08 am, Joel Sherrill wrote: > qemu-couverture.bset explicitly has 1.4.1. OK. > qemu.bset doesn't list dtc at all. No idea why not. Because you cannot build dtc on MinGW and I doubt you ever will be able to. Here the MSYS2 package is used. I cannot remember the specifics. > But qemu-git-1.cfg has a dtc submodule of qemu pulled out of git so I > guess qemu.bset is implicitly getting that. Yes, qemu's release cycle did not carry changes we needed. > Clear as mud to me. Be careful here because it a rather deep hole and time consuming to get all this to work on all hosts. The qemu.bset did build on all hosts we support at one point in time. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 5 gcc-fb371a33fa6 vs gcc-9.2.0
On 14/8/19 5:38 pm, Sebastian Huber wrote: > On 14/08/2019 09:25, Sebastian Huber wrote: >> >> On 14/08/2019 09:09, Chris Johns wrote: >>> On 14/8/19 4:52 pm, Sebastian Huber wrote: On 14/08/2019 08:52, Chris Johns wrote: On ARM a breaking change in compiler options is necessary. >>> What options are these? >> ARM changed the FPU options in GCC 8 and later. >> >>> Also this seems back to front to me. Should all hosts be on 9.2.0 and >>> those >>> that >>> cannot have specific versions? >> Only PowerPC should stay at GCC 7 until the next RTEMS release from my >> point of >> view. Everything else can move on. > Awesome. To make sure I understand the steps ... > > 1. Move gcc-fb371a33fa6 to 5/rtems-powerpc > 2. Set the default to gcc-9.2.0 > 3. Move all other archs to the defaults > > ? Yes, and: 4. Update the ARM BSPs to use the new machine options. >>> Is there something that documents the changes we need to make? >> >> No, you have to compare the multilib configurations in GCC 7 and 9. I was after something that says change `xxx` to `yyy`. I am happy to do the change, I do not have the time to figure which options are which. > Are you looking for information for users of ARM BSPs which have to update > their > hard-coded compiler options? No, we have to provide this information > somewhere. No, users who hard code options into their applications will have to update. We do not have a way to convey this detail at this point in time, may be a section in the user manual. My long term wish is to provide a stable interface to RTEMS that provides these flags. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] dtc.bset: update to 1.4.1 to match qemu
On Wed, Aug 14, 2019 at 5:27 PM Chris Johns wrote: > > On 15/8/19 8:08 am, Joel Sherrill wrote: > > qemu-couverture.bset explicitly has 1.4.1. > > OK. > > > qemu.bset doesn't list dtc at all. No idea why not. > > Because you cannot build dtc on MinGW and I doubt you ever will be able to. > Here > the MSYS2 package is used. I cannot remember the specifics. > > > But qemu-git-1.cfg has a dtc submodule of qemu pulled out of git so I > > guess qemu.bset is implicitly getting that. > > Yes, qemu's release cycle did not carry changes we needed. > > > Clear as mud to me. > > Be careful here because it a rather deep hole and time consuming to get all > this > to work on all hosts. The qemu.bset did build on all hosts we support at one > point in time. Should I punt and use the native provided dtc? Or try to build it by hand as a singleton using the RSB? I think updating to 1.4.1 vs 1.2 is OK but am happy to drop it from the qemu set. But we can defer this and I will try dtc 1.2 as an RSB singleton, then host DTC. It is needed by spike. --joel > > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
SPE Support
Hi Just thinking out loud. If the SPE continues to be supported by GCC, why can't we just have spe as a separate CPU in the tree with all the build infrastructure just reference PowerPC files as needed in their current location? I can see a need to copy/move a bsp.h and perhaps, score/cpu/spe/include would have to be populated. Just thinking there has to be a relatively straightforward hack to make this work. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] dtc.bset: update to 1.4.1 to match qemu
On 15/8/19 8:50 am, Joel Sherrill wrote: > On Wed, Aug 14, 2019 at 5:27 PM Chris Johns wrote: >> >> On 15/8/19 8:08 am, Joel Sherrill wrote: >>> qemu-couverture.bset explicitly has 1.4.1. >> >> OK. >> >>> qemu.bset doesn't list dtc at all. No idea why not. >> >> Because you cannot build dtc on MinGW and I doubt you ever will be able to. >> Here >> the MSYS2 package is used. I cannot remember the specifics. >> >>> But qemu-git-1.cfg has a dtc submodule of qemu pulled out of git so I >>> guess qemu.bset is implicitly getting that. >> >> Yes, qemu's release cycle did not carry changes we needed. >> >>> Clear as mud to me. >> >> Be careful here because it a rather deep hole and time consuming to get all >> this >> to work on all hosts. The qemu.bset did build on all hosts we support at one >> point in time. > > Should I punt and use the native provided dtc? Or try to build it by hand as a > singleton using the RSB? > > I think updating to 1.4.1 vs 1.2 is OK but am happy to drop it from > the qemu set. Yeap. > But we can defer this and I will try dtc 1.2 as an RSB singleton, then host > DTC. > It is needed by spike. I do not know as I cannot remember the specific now and things may have changed. Maybe add it and then try and see what breaks? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] dtc.bset: update to 1.4.1 to match qemu
On Wed, Aug 14, 2019, 6:02 PM Chris Johns wrote: > On 15/8/19 8:50 am, Joel Sherrill wrote: > > On Wed, Aug 14, 2019 at 5:27 PM Chris Johns wrote: > >> > >> On 15/8/19 8:08 am, Joel Sherrill wrote: > >>> qemu-couverture.bset explicitly has 1.4.1. > >> > >> OK. > >> > >>> qemu.bset doesn't list dtc at all. No idea why not. > >> > >> Because you cannot build dtc on MinGW and I doubt you ever will be able > to. Here > >> the MSYS2 package is used. I cannot remember the specifics. > >> > >>> But qemu-git-1.cfg has a dtc submodule of qemu pulled out of git so I > >>> guess qemu.bset is implicitly getting that. > >> > >> Yes, qemu's release cycle did not carry changes we needed. > >> > >>> Clear as mud to me. > >> > >> Be careful here because it a rather deep hole and time consuming to get > all this > >> to work on all hosts. The qemu.bset did build on all hosts we support > at one > >> point in time. > > > > Should I punt and use the native provided dtc? Or try to build it by > hand as a > > singleton using the RSB? > > > > I think updating to 1.4.1 vs 1.2 is OK but am happy to drop it from > > the qemu set. > > Yeap. > > > But we can defer this and I will try dtc 1.2 as an RSB singleton, then > host DTC. > > It is needed by spike. > > I do not know as I cannot remember the specific now and things may have > changed. > > Maybe add it and then try and see what breaks? > I'll take the baby step of building it from the rsb manually until we get all the testing hosts online. > > Chris > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] rtems-record: New program
On 14/8/19 3:19 pm, Sebastian Huber wrote: > On 14/08/2019 03:57, Chris Johns wrote: >> On 13/8/19 3:10 pm, Sebastian Huber wrote: >>> sorry for the rush, >> >> Sorry for the delay, I have a client demo this week I am helping with. >> >>> but what do you think of this patch? >> >> Why not C++? The rtems-tools repo has strong support for C++ and it brings a >> range of benefits, for example no need to code call handlers at a low level, >> containers so no need for us to include and maintain trace/record/tree.h, and >> more. When I see us adding code like `tree.h` I have in the back of my mind >> the >> long term support issues it brings while a `std::map` is maintained for us. > > Originally, the program should be able to filter live traces with about > 20MiB/s. > The std::map is simply too slow. It is difficult to comment without us heading into detail and I do not think there is any value in doing that. > Boost.Intrusive would be an option (it is > slower than tree.h in my tests too: https://github.com/sebhub/rb-bench). The > tree.h is a copy from Newlib, so it doesn't introduce new maintenance issues. > Anyway, for the CTF conversion the map is unnecessary and could be optimized > away. We didn't had the time to do this in the GSoC project. So performance is not an issue here and the code's presence is historical? >> GNU projects like gdb and gcc have moved to C++ and of course llvm is C++ and >> this is for good reason. I provide these examples in the hope this does not >> start a C vs C++ debate. >> >>> I would like to >>> integrate the tracing work of the GSoC project and this patch is a blocking >>> point. >> >> I understand. I am excited by the work that has been done here and what you >> are >> doing. It is taking all my will power to not read the ARM debug trace >> section of >> an ARM TRM as I think that hardware is ripe for integration with this code >> base >> and set of tools. A C++ framework in rtemstoolkit would be really helpful if >> I >> do as it would grow what we have rather than us collecting isolated C >> programs. >> >> I also understand and appreciate the limited time we all have so I am happy >> to >> hear how you see the host side progressing over time and how it fits into our >> ecosystem. I would also like to hear what others think. > > I don't have a problem with C++ in general. However, I don't think that the > use > of C in this small program is a blocking point to integrate the GSoC work. > This is work in progress anyway. This program only scratches the surface. What parts are to be added that depend on this tool? Maybe it would help if this is presented. Work in progress pieces are fine if there is a progression however I did state at the start of GSoC we currently use python and C++. I am weary of isolated tools that become unclear if we need to keep or we can remove after a period of time. Tools added to rtems-tools and installed are public facing user interfaces to our users. By installing the RTEMS project is agreeing to provide and support the interface provided. I am fine with tools being add if they serve other roles, for example as a means to test rtemstoolkit code, ie regression and development test tools. It is unclear to me where this tool fits. Maybe we need an option to rtems-tools's configure such as --experimental that builds and installs tools that are a work in progress but are not a public interface? > When we think about C++, then we should also think about boost, but this is > another topic. Yes this is off topic. Boost is great, there is no issue here. It's leadership role in C++ is impressive. I am however unlikely to agree to adding boost to rtems-tools as source unless there is a compelling reason. MacOS's Xcode does not seem to contain boost headers by default and I have not check MSYS2 mingw support. The C++ standards have so far proved to be portable and predicable across different hosts and compilers with no extra effort from us. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
LibBSD master vs 5-freebsd12 TI frame buffer patches
Hi, Currently the RSB libbsd package is building and installing LibBSD `master` and I was looking to move this to `5-freebsd12` to align it with the needs of a release. >From what I can see important patches are on both branches which is great. >Thanks. I am wondering about the recent GSoC commits to add frame buffer support to `master`. If a package to build LittlevGL is added and there is no frame buffer support the resulting BBB BSP build will not work. I do not know of a way to check the LibBSD library for frame buffer support and conditionally build LittlevGL. Possible solutions ... 1. Add --enable-libbsd-master and build master when ask by a user? 2. A LibBSD check. How? 3. Merge patches on to 5-freebsd12 branch? 4. Switch to `5-freebsd12` and do nothing and let the user figure out frame buffer support is on LibBSD `master` and implement 1. ? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/2] sb/download: Add support for a base64 hash string
From: Chris Johns
---
source-builder/sb/download.py | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/source-builder/sb/download.py b/source-builder/sb/download.py
index d8061e6..1fb0155 100644
--- a/source-builder/sb/download.py
+++ b/source-builder/sb/download.py
@@ -24,6 +24,7 @@
from __future__ import print_function
+import base64
import hashlib
import os
import re
@@ -110,8 +111,13 @@ def _hash_check(file_, absfile, macros, remove = True):
raise
if _in is not None:
_in.close()
-log.output('checksums: %s: %s => %s' % (file_, hasher.hexdigest(),
hash[1]))
-if hasher.hexdigest() != hash[1]:
+hash_hex = hasher.hexdigest()
+hash_base64 = base64.b64encode(hasher.digest()).decode('utf-8')
+log.output('checksums: %s: (hex: %s) (b64: %s) => %s' % (file_,
+ hash_hex,
+ hash_base64,
+ hash[1]))
+if hash_hex != hash[1] and hash_base64 != hash[1]:
log.warning('checksum error: %s' % (file_))
failed = True
if failed and remove:
--
2.20.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Fwd: [PATCH v1] Remove back-slash in 'pacman' command in 'PDF' section under Arch Linux (installation of Sphinx).
--- README.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.txt b/README.txt index 3679d1d..1567be6 100644 --- a/README.txt +++ b/README.txt @@ -247,7 +247,7 @@ Sphinx: PDF: - # pacman -S texlive-bin texlive-core texlive-latexextra texlive-fontsextra \ + # pacman -S texlive-bin texlive-core texlive-latexextra texlive-fontsextra openSUSE -- 2.21.0 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v1] Add steps to test Newlib patch.
Update the checksum to be used for the Newlib patches. Earlier it was msd5, but it is depreciated for security reasons. Now RSB accepts sha512. --- user/rsb/project-sets.rst | 41 +-- 1 file changed, 35 insertions(+), 6 deletions(-) diff --git a/user/rsb/project-sets.rst b/user/rsb/project-sets.rst index 5ffce26..b01857e 100644 --- a/user/rsb/project-sets.rst +++ b/user/rsb/project-sets.rst @@ -261,17 +261,46 @@ in the ``source-builder/config`` template configuration files. To test a patch simply copy it to your local ``patches`` directory. The RSB will see the patch is present and will not attempt to download it. Once you are happy with the patch submit it to the project and a core developer will review -it and add it to the RTEMS Tools git repository. For example, to test a local -patch for newlib, add the following two lines to the .cfg file in -``rtems/config/tools/`` that is included by the bset you use: +it and add it to the RTEMS Tools git repository. + +Testing a Newlib Patch +~~ + +To test a local patch for newlib, you need to add the following +two lines to the ``.cfg`` file in ``rsb/rtems/config/tools/`` that is included +by the bset you use: + +.. topic:: Steps: + + 1. Create patches for the changes you want to test. (Note: For RSB, before + creating Newlib patch, you must run ``autoreconf -fvi`` in the required + directory after you make changes to the code. This is not required when + you create patch to send to ``newlib-devel``. But if you want RSB to + address your changes, your patch should also include regenerated files.) + + 2. Calculate ``sha512`` of your patch. + + 3. Place the patches in ``rsb/rtems/patches`` directory. + + 4. Open the ``.bset`` file used by your BSP in ``rsb/rtems/config``. + For example, for ``rtems5``, ``SPARC``, the file will be + ``rsb/rtems/config/5/rtems-sparc.bset``. + + 5. Inside it you will find the name of ``.cfg`` file for Newlib, used by + your BSP. + For example, I found ``tools/rtems-gcc-7.4.0-newlib-1d35a003f``. + + 6. Edit your ``.cfg`` file. In my case it will be, + ``rsb/rtems/config/tools/rtems-gcc-7.4.0-newlib-1d35a003f.cfg``. And + add the information about your patch as mentioned below. .. code-block:: spec -%patch add newlib file://0001-this-is-a-newlib-patch.patch <1> -%hash md5 0001-this-is-a-newlib-patch.diff 77d070878112783292461bd6e7db17fb <2> +%patch add newlib -p1 file://0001-Port-ndbm.patch <1> +%hash sha512 0001-Port-ndbm.patch 7d999ceeea4f3dc82e8e0aadc09d983a7a68b44470da8a3d61ab6fc558fdba6f2c2de3acc2f32c0b0b97fcc9ab799c27e87afe046544a69519881f947e7881d1 <2> .. topic:: Items: 1. The diff file prepended with ``file://`` to tell RSB this is a local file. - 2. The output from md5sum on the diff file. + 2. The output from sha512sum on the patch file. -- 2.21.0 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] rtems-record: New program
- Am 15. Aug 2019 um 2:09 schrieb Chris Johns chr...@rtems.org: > On 14/8/19 3:19 pm, Sebastian Huber wrote: >> On 14/08/2019 03:57, Chris Johns wrote: >>> On 13/8/19 3:10 pm, Sebastian Huber wrote: sorry for the rush, >>> >>> Sorry for the delay, I have a client demo this week I am helping with. >>> but what do you think of this patch? >>> >>> Why not C++? The rtems-tools repo has strong support for C++ and it brings a >>> range of benefits, for example no need to code call handlers at a low level, >>> containers so no need for us to include and maintain trace/record/tree.h, >>> and >>> more. When I see us adding code like `tree.h` I have in the back of my mind >>> the >>> long term support issues it brings while a `std::map` is maintained for us. >> >> Originally, the program should be able to filter live traces with about >> 20MiB/s. >> The std::map is simply too slow. > > It is difficult to comment without us heading into detail and I do not think > there is any value in doing that. > >> Boost.Intrusive would be an option (it is >> slower than tree.h in my tests too: https://github.com/sebhub/rb-bench). The >> tree.h is a copy from Newlib, so it doesn't introduce new maintenance issues. >> Anyway, for the CTF conversion the map is unnecessary and could be optimized >> away. We didn't had the time to do this in the GSoC project. > > So performance is not an issue here and the code's presence is historical? Ravindra needs this patch to integrate his work on top of it. I posted this patch on January and at this time using C was not an issue: https://lists.rtems.org/pipermail/devel/2019-January/024640.html His integration is now blocked because of something he didn't cause. > >>> GNU projects like gdb and gcc have moved to C++ and of course llvm is C++ >>> and >>> this is for good reason. I provide these examples in the hope this does not >>> start a C vs C++ debate. >>> I would like to integrate the tracing work of the GSoC project and this patch is a blocking point. >>> >>> I understand. I am excited by the work that has been done here and what you >>> are >>> doing. It is taking all my will power to not read the ARM debug trace >>> section of >>> an ARM TRM as I think that hardware is ripe for integration with this code >>> base >>> and set of tools. A C++ framework in rtemstoolkit would be really helpful >>> if I >>> do as it would grow what we have rather than us collecting isolated C >>> programs. >>> >>> I also understand and appreciate the limited time we all have so I am happy >>> to >>> hear how you see the host side progressing over time and how it fits into >>> our >>> ecosystem. I would also like to hear what others think. >> >> I don't have a problem with C++ in general. However, I don't think that the >> use >> of C in this small program is a blocking point to integrate the GSoC work. >> This is work in progress anyway. This program only scratches the surface. > > What parts are to be added that depend on this tool? Maybe it would help if > this > is presented. > > Work in progress pieces are fine if there is a progression however I did state > at the start of GSoC we currently use python and C++. I am weary of isolated > tools that become unclear if we need to keep or we can remove after a period > of > time. Sorry, but you should have stated that C++ is mandatory a bit earlier. Now it is difficult to change. Ravindra did his work on top of a C program. We can easily convert it to C++, but only after the integration of Ravindra's work. The tool is already useful, it converts the RTEMS record stream into a CTF stream which can be read by Trace Compass to display the thread switches on multiple CPUs and the CPU utilization. > > Tools added to rtems-tools and installed are public facing user interfaces to > our users. By installing the RTEMS project is agreeing to provide and support > the interface provided. I am fine with tools being add if they serve other > roles, for example as a means to test rtemstoolkit code, ie regression and > development test tools. It is unclear to me where this tool fits. > > Maybe we need an option to rtems-tools's configure such as --experimental that > builds and installs tools that are a work in progress but are not a public > interface? Ok, sorry, I should have started with the integration planning of the GSoC work a bit earlier. Ravindara, I added a now branch to your repository: https://github.com/rmeena840/rtems-tools/tree/ravindra-record-ctf It is a rebase of your work to the current rtems-tools master with all your commits squashed into one. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 5 gcc-fb371a33fa6 vs gcc-9.2.0
- Am 15. Aug 2019 um 0:43 schrieb Chris Johns chr...@rtems.org: > On 14/8/19 5:38 pm, Sebastian Huber wrote: >> On 14/08/2019 09:25, Sebastian Huber wrote: >>> >>> On 14/08/2019 09:09, Chris Johns wrote: On 14/8/19 4:52 pm, Sebastian Huber wrote: > On 14/08/2019 08:52, Chris Johns wrote: [...] > 4. Update the ARM BSPs to use the new machine options. Is there something that documents the changes we need to make? >>> >>> No, you have to compare the multilib configurations in GCC 7 and 9. > > I was after something that says change `xxx` to `yyy`. I am happy to do the > change, I do not have the time to figure which options are which. I can do that. I don't know the mapping off hand. I have to look at the new multilib options. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: SPE Support
- Am 15. Aug 2019 um 0:55 schrieb joel j...@rtems.org: > Hi > > Just thinking out loud. > > If the SPE continues to be supported by GCC, why can't we just have > spe as a separate CPU in the tree with all the build infrastructure > just reference PowerPC files as needed in their current location? > > I can see a need to copy/move a bsp.h and perhaps, > score/cpu/spe/include would have to be populated. > > Just thinking there has to be a relatively straightforward hack to > make this work. The GCC powerpcspe target was removed in GCC 9: https://github.com/RTEMS/gnu-mirror-gcc/commit/b31d0348ddada49453e3edaaf93a423fdc61dc79 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] rtems-record: New program
On 15/8/19 4:05 pm, Sebastian Huber wrote: > - Am 15. Aug 2019 um 2:09 schrieb Chris Johns chr...@rtems.org: > >> On 14/8/19 3:19 pm, Sebastian Huber wrote: >>> On 14/08/2019 03:57, Chris Johns wrote: On 13/8/19 3:10 pm, Sebastian Huber wrote: > sorry for the rush, Sorry for the delay, I have a client demo this week I am helping with. > but what do you think of this patch? Why not C++? The rtems-tools repo has strong support for C++ and it brings a range of benefits, for example no need to code call handlers at a low level, containers so no need for us to include and maintain trace/record/tree.h, and more. When I see us adding code like `tree.h` I have in the back of my mind the long term support issues it brings while a `std::map` is maintained for us. >>> >>> Originally, the program should be able to filter live traces with about >>> 20MiB/s. >>> The std::map is simply too slow. >> >> It is difficult to comment without us heading into detail and I do not think >> there is any value in doing that. >> >>> Boost.Intrusive would be an option (it is >>> slower than tree.h in my tests too: https://github.com/sebhub/rb-bench). The >>> tree.h is a copy from Newlib, so it doesn't introduce new maintenance >>> issues. >>> Anyway, for the CTF conversion the map is unnecessary and could be optimized >>> away. We didn't had the time to do this in the GSoC project. >> >> So performance is not an issue here and the code's presence is historical? > > Ravindra needs this patch to integrate his work on top of it. I posted this > patch on January and at this time using C was not an issue: > > https://lists.rtems.org/pipermail/devel/2019-January/024640.html > Yes and I am sorry I did not raise this in that specific case. > His integration is now blocked because of something he didn't cause. Yes and I would to avoid there being a block. >> GNU projects like gdb and gcc have moved to C++ and of course llvm is C++ and this is for good reason. I provide these examples in the hope this does not start a C vs C++ debate. > I would like to > integrate the tracing work of the GSoC project and this patch is a > blocking > point. I understand. I am excited by the work that has been done here and what you are doing. It is taking all my will power to not read the ARM debug trace section of an ARM TRM as I think that hardware is ripe for integration with this code base and set of tools. A C++ framework in rtemstoolkit would be really helpful if I do as it would grow what we have rather than us collecting isolated C programs. I also understand and appreciate the limited time we all have so I am happy to hear how you see the host side progressing over time and how it fits into our ecosystem. I would also like to hear what others think. >>> >>> I don't have a problem with C++ in general. However, I don't think that the >>> use >>> of C in this small program is a blocking point to integrate the GSoC work. >>> This is work in progress anyway. This program only scratches the surface. >> >> What parts are to be added that depend on this tool? Maybe it would help if >> this >> is presented. >> >> Work in progress pieces are fine if there is a progression however I did >> state >> at the start of GSoC we currently use python and C++. I am weary of isolated >> tools that become unclear if we need to keep or we can remove after a period >> of >> time. > > Sorry, but you should have stated that C++ is mandatory a bit earlier. I did ... https://lists.rtems.org/pipermail/devel/2019-May/025957.html There is C code in rtems-tools, ie elftools and bin2c and I am sure there will be others. In the case of trace there is a history of C++ and I think this work is important enough that we consider the long term use cases. I have attempted to avoid stating C++ is mandatory because that places us in a corner. > Now it is difficult to change. Ravindra did his work on top of a C program. > We can easily convert it to C++, but only after the integration of Ravindra's > work. The tool is already useful, it converts the RTEMS record stream into a > CTF stream which can be read by Trace Compass to display the thread switches > on multiple CPUs and the CPU utilization. Great. This is all I am asking for. I would prefer we resolve what happens before we merge and we avoid a misunderstanding. >> Tools added to rtems-tools and installed are public facing user interfaces to >> our users. By installing the RTEMS project is agreeing to provide and support >> the interface provided. I am fine with tools being add if they serve other >> roles, for example as a means to test rtemstoolkit code, ie regression and >> development test tools. It is unclear to me where this tool fits. >> >> Maybe we need an option to rtems-tools's confi
Re: RTEMS 5 gcc-fb371a33fa6 vs gcc-9.2.0
On 15/8/19 4:10 pm, Sebastian Huber wrote: > - Am 15. Aug 2019 um 0:43 schrieb Chris Johns chr...@rtems.org: > >> On 14/8/19 5:38 pm, Sebastian Huber wrote: >>> On 14/08/2019 09:25, Sebastian Huber wrote: On 14/08/2019 09:09, Chris Johns wrote: > On 14/8/19 4:52 pm, Sebastian Huber wrote: >> On 14/08/2019 08:52, Chris Johns wrote: > [...] >> 4. Update the ARM BSPs to use the new machine options. > Is there something that documents the changes we need to make? No, you have to compare the multilib configurations in GCC 7 and 9. >> >> I was after something that says change `xxx` to `yyy`. I am happy to do the >> change, I do not have the time to figure which options are which. > > I can do that. I don't know the mapping off hand. I have to look at the new > multilib options. > Thank you, I would feel more comfortable following your lead. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
