Re: dl06

2019-11-18 Thread Sebastian Huber 

On 19/11/2019 01:59, Chris Johns wrote:

On 18/11/19 7:12 pm, Sebastian Huber wrote:

On 18/11/2019 08:59, Chris Johns wrote:



On 18 Nov 2019, at 6:14 pm, Sebastian Huber
 wrote:

Hallo,

on which platform passes the dl06 test? I tried arm/realview_pbx_a9_qemu and
got:


It is a bug that has come in that I have not looked at.


Is this a known issue or something which broke only recently? Do you know a
version/platform on which it worked?


The test broke a while ago when I made a change to ELF loading issues. I forget
what the change was. I need to take a look and fix it but doing so means I need
to revisit the RAP format and it's support and so it will take a bit of time to
work through. I have had other more pressing things to working on.


This is not an issue, I just have to know if something broke due to the 
build system changes.





*** BEGIN OF TEST libdl (RTL) 6 ***
*** TEST VERSION: 5.0.0.9438165d2cfb9a6a67f01f5ec7ba9156abb66d7d-modified
*** TEST STATE: EXPECTED-PASS
*** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP
*** TEST TOOLS: 7.4.1 20190514 (RTEMS 5, RSB
a50f0c044ad732db728cc942d5fde82a1faf1d12, Newlib d14714c69)

load: /dl06.rap
handle: 0x210ce0 loaded
Loaded module: argc:4
[/home/EB/sebastian_h/git-rtems-5/c/src/../../testsuites/libtests/dl06/dl06-o1.c]

libm: lcong48
libm: atan2

*** FATAL ***
fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)

R0   = 0x R8  = 0x
R1   = 0x000a R9  = 0x
R2   = 0x00213149 R10 = 0x
R3   = 0x R11 = 0x
R4   = 0x00206cac R12 = 0x
R5   = 0x SP  = 0x00206c80
R6   = 0x LR  = 0x00211e51
R7   = 0x00206c80 PC  = 0x00211e94
CPSR = 0x00070173 VEC = 0x0001
FPEXC = 0x4000
FPSCR = 0x
D00 = 0x401c
D01 = 0x40408000
D02 = 0x3fddac670561bb4f
D03 = 0x3fe921fb54442d18
D04 = 0x3fef730bd281f69b
D05 = 0x3ff921fb54442d18
D06 = 0x3c7a2b7f222f65e2
D07 = 0x3c81a62633145c07
D08 = 0x
D09 = 0x
D10 = 0x
D11 = 0x
D12 = 0x
D13 = 0x
D14 = 0x
D15 = 0x
D16 = 0x
D17 = 0x0002
D18 = 0x
D19 = 0x
D20 = 0x
D21 = 0x
D22 = 0x
D23 = 0x
D24 = 0x
D25 = 0x
D26 = 0x
D27 = 0x
D28 = 0x
D29 = 0x
D30 = 0x
D31 = 0x
RTEMS version: 5.0.0.9438165d2cfb9a6a67f01f5ec7ba9156abb66d7d-modified
RTEMS tools: 7.4.1 20190514 (RTEMS 5, RSB
a50f0c044ad732db728cc942d5fde82a1faf1d12, Newlib d14714c69)
executing thread ID: 0x08a010001
executing thread name: UI1

I tried arm/xilinx_zynq_a9_qemu and got:

*** BEGIN OF TEST libdl (RTL) 6 ***
*** TEST VERSION: 5.0.0.799c4f551806fb1124ea5d9f6633ec5deb91ad8e
*** TEST STATE: EXPECTED-PASS
*** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API
*** TEST TOOLS: 7.4.1 20190514 (RTEMS 5, RSB
a50f0c044ad732db728cc942d5fde82a1faf1d12, Newlib d14714c69)

load: /dl06.rap
dlopen failed: .text: THM_CALL/JUMP24: overflow: no tramp memory

*** FATAL ***
fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
fatal code: 0 (0x)
RTEMS version: 5.0.0.799c4f551806fb1124ea5d9f6633ec5deb91ad8e
RTEMS tools: 7.4.1 20190514 (RTEMS 5, RSB
a50f0c044ad732db728cc942d5fde82a1faf1d12, Newlib d14714c69)
executing thread ID: 0x08a010001
executing thread name: UI1

I would like to remove the PAX archives to simplify the build and reduce the
host dependencies.


Is this because of handled the dependencies in waf?


It is not a waf issue. I just want to get rid of another host dependency. pax is
not a standard Linux tool.


What do you mean when you say Linux is not standard, I get so confused with all
the distros?

I thought it was a standard tool and part of POSIX or something like that,
checking, hmm yeah it is. This is why we changed, supporting standards and all
that sort of thing.


Yes, it is a POSIX tool, but it is not installed by default on some 
distributions. We had several mailing list posts related to this.




I am fine with tar being used if configure magic is used to select it. This may
expose RTEMS tar support bugs, I cannot remember now.


Is tar supported by RTEMS? The last time I tried to use didn't work as 
far as I remember. Maybe it is related to our two independent untar 
solutions ( and rtems_tarfs_load()).




I do not use Linux and so I do not see these changes.


Converting to C is a broken path IMO. it does not scale.


I would convert the individual object files with bin2c and load them with
IMFS_make_linfile().


I see this as a broke way to handle building root file systems and to further
embed in our build system and processes. Our users inspect what we do and take
that as a lead and copy it. As I stated and Jonathan confirmed it does not
scale. My preferred method is to use objcopy and to convert the bin

Re: [PATCH 2/3] tar01 and tar02: Do not generate tar archives

2019-11-18 Thread Sebastian Huber 

On 19/11/2019 02:15, Chris Johns wrote:

On 18/11/19 6:10 pm, Sebastian Huber wrote:

This simplifies the build and avoids some host dependencies, e.g.
availability of symbolic links in the host file system.  Makes it
possible to validate time stamps.

Update #3818.
---
  testsuites/libtests/Makefile.am|  41 -
  testsuites/libtests/tar01/tar01.tar| Bin 0 -> 10240 bytes
  testsuites/libtests/tar01/tar01.tar.gz | Bin 0 -> 296 bytes
  testsuites/libtests/tar01/tar01.tar.xz | Bin 0 -> 340 bytes
  testsuites/libtests/tar02/tar02.tar| Bin 0 -> 10240 bytes
  5 files changed, 9 insertions(+), 32 deletions(-)
  create mode 100644 testsuites/libtests/tar01/tar01.tar
  create mode 100644 testsuites/libtests/tar01/tar01.tar.gz
  create mode 100644 testsuites/libtests/tar01/tar01.tar.xz
  create mode 100644 testsuites/libtests/tar02/tar02.tar


How are the tar files created?


I copied the files from my build tree to the source tree.



How do we capture what is in them and how to regenerate them? 


Ok, this is an issue. You have to unpack them, change your stuff, and 
re-create them by hand.



At the moment I
can inspect all of this test via cgit. The idea of downloading and checking can
be problematic depending on the host and set up, ie a tablet.

Has the generation of these files been checked on more than Linux?


I doubt that anyone did run the tests using a FAT file system on the 
host for example.




How do we check updated host tools have not broken the code we have in RTEMS?


I would consider it a serious bug in a future host pax tool if it breaks 
the RTEMS code.




I am concerned we are loosing some of the checking that we currently have moving
to this approach. The symlink issue is a real one so maybe we hold a single tar
to check that works.


With the dynamic generation of the archive we cannot test the file 
permissions, the group and user IDs, and the time stamps.


--
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: dl06

2019-11-18 Thread Sebastian Huber 

On 19/11/2019 02:04, Chris Johns wrote:

On 19/11/19 4:33 am, Jonathan Brandmeyer wrote:

On Mon, Nov 18, 2019 at 1:12 AM Sebastian Huber
mailto:sebastian.hu...@embedded-brains.de>>
wrote:

 On 18/11/2019 08:59, Chris Johns wrote:
 >

 >
 > Converting to C is a broken path IMO. it does not scale.

 I would convert the individual object files with bin2c and load them
 with IMFS_make_linfile().


We stopped using rtems-bin2c in our project, because the performance was so poor
for larger files.  Both bin2c and gcc were very slow.


I have experienced this as well.


Yes, the rtems-bin2c approach is only suitable for small files. For the 
RTEMS test suite it is fine.





   We've replaced that
workflow with something based on GNU AS `.incbin` instead, which is fast enough
to be unnoticeable.


I have used objcopy to copy a binary format file to the support ELF object file.
Doing this scales well and is almost fully portable across architectures, I
think the i386 needs a special option.


The problem with using objcopy is that you need to know the output 
target (-O option). The output target may depend on the GCC multilib 
(32-bit vs. 64 bit, big-endian vs. little-endian).


--
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: Fwd: The GCC 7 branch is now closed

2019-11-18 Thread Sebastian Huber 

On 14/11/2019 18:45, Joel Sherrill wrote:

GCC 7.5 is available now and this branch is closed.


I updated the RSB to use GCC 7.5.0.

--
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: psxfenv01 fails to compile for RISCV

2019-11-18 Thread Chris Johns 
On 18/11/19 5:28 pm, Sebastian Huber wrote:
> On 11/11/2019 23:35, Chris Johns wrote:
>> On 12/11/19 12:10 am, Sebastian Huber wrote:
>>> On 11/11/2019 07:04, Sebastian Huber wrote:
 On 09/11/2019 19:57, Joel Sherrill wrote:
> I thought I fixed this in the upstream newlib.
>
> https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=9e06ba1ac310c5a2392bb9d150e4686bbb118d6c
>
>
>
> Either I didn't really fix it or your newlib is a bit old.
>
> Did Sebastian bump 5's newlib recently? I recall a binutils bump.

 No, sorry. I planned to do the GCC 7.5 and Newlib update in one rush.
>>>
>>> I updated right now the RSB to pick up the latest Newlib.
>>>
>>
>> Libbsd is failing for the bbb (plus the other BSPs in 5/bsps/*). The build
>> archive shows the failures ...
>>
>> https://lists.rtems.org/pipermail/build/2019-November/008223.html
>>
>> The error is ...
>>
>> ../../testsuite/syscalls01/test_main.c:174:23: error: 'IPPROTO_SEP' 
>> undeclared
>> here (not in a function); did you mean 'IPPROTO_EGP'?
>>    { PF_INET, SOCK_RAW, IPPROTO_SEP, 0 },
>>     ^~~
>>     IPPROTO_EGP
> 
> This should be fixed now.
> 

Thanks. I have moved the RSB libbsd to build the 5-freebsd-12 branch. The BSP
vertical stack is building again.

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

Re: [PATCH 2/3] tar01 and tar02: Do not generate tar archives

2019-11-18 Thread Chris Johns 
On 18/11/19 6:10 pm, Sebastian Huber wrote:
> This simplifies the build and avoids some host dependencies, e.g.
> availability of symbolic links in the host file system.  Makes it
> possible to validate time stamps.
> 
> Update #3818.
> ---
>  testsuites/libtests/Makefile.am|  41 
> -
>  testsuites/libtests/tar01/tar01.tar| Bin 0 -> 10240 bytes
>  testsuites/libtests/tar01/tar01.tar.gz | Bin 0 -> 296 bytes
>  testsuites/libtests/tar01/tar01.tar.xz | Bin 0 -> 340 bytes
>  testsuites/libtests/tar02/tar02.tar| Bin 0 -> 10240 bytes
>  5 files changed, 9 insertions(+), 32 deletions(-)
>  create mode 100644 testsuites/libtests/tar01/tar01.tar
>  create mode 100644 testsuites/libtests/tar01/tar01.tar.gz
>  create mode 100644 testsuites/libtests/tar01/tar01.tar.xz
>  create mode 100644 testsuites/libtests/tar02/tar02.tar

How are the tar files created?

How do we capture what is in them and how to regenerate them? At the moment I
can inspect all of this test via cgit. The idea of downloading and checking can
be problematic depending on the host and set up, ie a tablet.

Has the generation of these files been checked on more than Linux?

How do we check updated host tools have not broken the code we have in RTEMS?

I am concerned we are loosing some of the checking that we currently have moving
to this approach. The symlink issue is a real one so maybe we hold a single tar
to check that works.

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

Re: dl06

2019-11-18 Thread Chris Johns 
On 19/11/19 4:33 am, Jonathan Brandmeyer wrote:
> On Mon, Nov 18, 2019 at 1:12 AM Sebastian Huber
>  >
> wrote:
> 
> On 18/11/2019 08:59, Chris Johns wrote:
> >
> 
> >
> > Converting to C is a broken path IMO. it does not scale.
> 
> I would convert the individual object files with bin2c and load them
> with IMFS_make_linfile().
> 
> 
> We stopped using rtems-bin2c in our project, because the performance was so 
> poor
> for larger files.  Both bin2c and gcc were very slow.

I have experienced this as well.

>  We've replaced that
> workflow with something based on GNU AS `.incbin` instead, which is fast 
> enough
> to be unnoticeable.

I have used objcopy to copy a binary format file to the support ELF object file.
Doing this scales well and is almost fully portable across architectures, I
think the i386 needs a special option.

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

Re: dl06

2019-11-18 Thread Chris Johns 
On 18/11/19 10:12 pm, Jiri Gaisler wrote:
> 
> On 11/18/19 9:12 AM, Sebastian Huber wrote:
>> On 18/11/2019 08:59, Chris Johns wrote:
>>>
 On 18 Nov 2019, at 6:14 pm, Sebastian Huber
  wrote:

 Hallo,

 on which platform passes the dl06 test? I tried
 arm/realview_pbx_a9_qemu and got:
>>>
>>> It is a bug that has come in that I have not looked at.
>>
>> Is this a known issue or something which broke only recently? Do you
>> know a version/platform on which it worked?
> 
> 
> dl06 

Known about.

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

This needs to be excluded on targets that cannot support lots of memory. It
requires a lot of RAM to work. It would be nice to have at least one SPARC
target run it to make sure trampoline changes do not break the SPARC arch.

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

Re: dl06

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

The test broke a while ago when I made a change to ELF loading issues. I forget
what the change was. I need to take a look and fix it but doing so means I need
to revisit the RAP format and it's support and so it will take a bit of time to
work through. I have had other more pressing things to working on.

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

What do you mean when you say Linux is not standard, I get so confused with all
the distros?

I thought it was a standard tool and part of POSIX or something like that,
checking, hmm yeah it is. This is why we changed, supporting standards and all
that sort of thing.

I am fine with tar being used if configure magic is used to select it. This may
expose RTEMS tar support bugs, I cannot remember now.

I do not use Linux and so I do not see these changes.

>> Converting to C is a broken path IMO. it does not scale.
> 
> I would convert the individual object files with bin2c and load them with
> IMFS_make_linfile().

I see this as a broke way to handle building root file systems and to further
embed in our build system and processes. Our users inspect what we do and take
that as a lead and copy it. As I stated and Jonathan confirmed it does not
scale. My preferred method is to use objcopy and to convert the bin tar file to
an object file.

>> I am not sure removing pax

Re: Hello World Patch

2019-11-18 Thread Christian Mauderer 
Hello Shubham Bhagat,

no problem. And don't hesitate to ask on the mailing list if something
sounds interesting.

Best regards

Christian

On 18/11/2019 20:34, Shubham Bhagat wrote:
> Thank you Christian. I am also looking at previous GSOC projects. I am
> hopeful to find some leads there too! Thank you for your time :D
> 
> On Tuesday, 19 November, 2019, 12:08:40 am IST, Christian Mauderer
>  wrote:
> 
> 
> Hello Shubham Bhagat,
> 
> it really depends a lot on what interests you. Independent what you pick
> ask on the mailing list and maybe ask people that have worked on the
> tickets what the status is.
> 
> There are some really small tickets like that stuff:
> 
> https://devel.rtems.org/ticket/3300
> https://devel.rtems.org/ticket/2876
> 
> You will find a lot of similar tickets created by David Binderman. From
> the look of it they have been created either out of a really thorough
> code review or out of the results of some static code analysis tool.
> Most of them look valid and would need someone who finds out what went
> wrong and how the code should be. Most likely that's not really
> interesting work and it would need someone who tries it on real hardware.
> 
> 
> There is a ticket that wants to add a driver to the PowerPC qemu:
> 
> https://devel.rtems.org/ticket/3353
> 
> It seems that no one really noticed it and the patch is most likely
> rotting. Would be nice if someone could test it and bring it to the
> attention of the mailing list.
> 
> 
> If you want to work on a simulator, I think no one has tried the Beagle
> Qemu Simulator for quite some time. If you want you can try it and add
> some information on how to use it to the user manual:
> https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#beagle
> 
> There's also a ticket for adding any simulator during GSoC Projects:
> https://devel.rtems.org/ticket/2903
> 
> 
> The tickets for Raspberry and Beagle are most likely not up to date but
> there could be some drivers there too that wait to be written:
> 
> https://devel.rtems.org/ticket/2899
> https://devel.rtems.org/ticket/2891
> 
> Best regards
> 
> Christian
> 
> On 18/11/2019 17:28, Shubham Bhagat wrote:
>>
>> Sorry I missed your replies in my inbox!
>>
>> I actually do not have required hardware. I have little experience with
>> GPOS (no experience with embedded!). I was wondering if you could point
>> to some tickets/projects that come to your mind that would be
>> well-suited for me? Or if you tell me where I could look for them, it'd
>> be great help.
>>
>> And thanks for the update on IRC. I'll connect there soon. Thanks!
>> On Monday, 18 November, 2019, 2:21:16 am IST, Christian Mauderer
>> mailto:l...@c-mauderer.de>> wrote:
>>
>>
>> Hello Shubham Bhagat,
>>
>> sorry, I missed the IRC question: In my experience our community doesn't
>> have lot of active people in IRC. You can try to mention some of the
>> connected and available people so they get pinged. For me that works if
>> I'm in front of a PC that is connected to my IRC-Bouncer and if I see
>> the message from my chat program (most of the time when it's evening in
>> Germany).
>>
>> Best regards
>>
>> Christian
>>
>> On 16/11/2019 08:54, Christian Mauderer wrote:
>>> Hello Shubham Bhagat,
>>>
>>> sounds like a good plan. Like I said: If you want to look around a bit
>>> without picking a fixed project yet it might would be a good idea to
>>> have a look at some of the tickets. Topics in the BSP or driver area are
>>> most of the time good starting points if you have the hardware or a
>>> simulator.
>>>
>>> PS: Please keep the devel list on CC.
>>>
>>> Best regards
>>>
>>> Christian
>>>
>>> On 16/11/2019 07:29, Shubham Bhagat wrote:
 Hi!
 I decided to start early to understand things here and find what I would
 like to work on, if I have to choose a project. I intended to contribute
 to some OS org to improve my understanding of OS and get some experience
 along the way. RTEMS participating in GSOC is only like a cherry
 topping. Thank you for your help! I will stay connected. Is the IRC only
 active during GSOC?
 On Thursday, 14 November, 2019, 12:13:44 am IST, Christian Mauderer
 mailto:l...@c-mauderer.de>
> >> wrote:


 Hello Shubham Bhagat,

 welcome to RTEMS and congratulations for completing the Hello World
> task.

 You are quite early for GSoC 2020. So just to be sure let me ask: Do you
 plan to participate as a GSoC student or do you want to start just out
 of interest outside of a program like GSoC?

 If you want to start for GSoC: Most of us are not in GSoC mode and the
 infrastructure isn't prepared yet. That's not really a problem but you
 might don't find the information that well prepared at the moment.

 Regarding tasks to do: You can either have a look at the Open Projects
 page in the wiki [1] or suggest some topics yourself. If you find

Re: Hello World Patch

2019-11-18 Thread Christian Mauderer 
Hello Shubham Bhagat,

it really depends a lot on what interests you. Independent what you pick
ask on the mailing list and maybe ask people that have worked on the
tickets what the status is.

There are some really small tickets like that stuff:

https://devel.rtems.org/ticket/3300
https://devel.rtems.org/ticket/2876

You will find a lot of similar tickets created by David Binderman. From
the look of it they have been created either out of a really thorough
code review or out of the results of some static code analysis tool.
Most of them look valid and would need someone who finds out what went
wrong and how the code should be. Most likely that's not really
interesting work and it would need someone who tries it on real hardware.


There is a ticket that wants to add a driver to the PowerPC qemu:

https://devel.rtems.org/ticket/3353

It seems that no one really noticed it and the patch is most likely
rotting. Would be nice if someone could test it and bring it to the
attention of the mailing list.


If you want to work on a simulator, I think no one has tried the Beagle
Qemu Simulator for quite some time. If you want you can try it and add
some information on how to use it to the user manual:
https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#beagle

There's also a ticket for adding any simulator during GSoC Projects:
https://devel.rtems.org/ticket/2903


The tickets for Raspberry and Beagle are most likely not up to date but
there could be some drivers there too that wait to be written:

https://devel.rtems.org/ticket/2899
https://devel.rtems.org/ticket/2891

Best regards

Christian

On 18/11/2019 17:28, Shubham Bhagat wrote:
> 
> Sorry I missed your replies in my inbox!
> 
> I actually do not have required hardware. I have little experience with
> GPOS (no experience with embedded!). I was wondering if you could point
> to some tickets/projects that come to your mind that would be
> well-suited for me? Or if you tell me where I could look for them, it'd
> be great help.
> 
> And thanks for the update on IRC. I'll connect there soon. Thanks!
> On Monday, 18 November, 2019, 2:21:16 am IST, Christian Mauderer
>  wrote:
> 
> 
> Hello Shubham Bhagat,
> 
> sorry, I missed the IRC question: In my experience our community doesn't
> have lot of active people in IRC. You can try to mention some of the
> connected and available people so they get pinged. For me that works if
> I'm in front of a PC that is connected to my IRC-Bouncer and if I see
> the message from my chat program (most of the time when it's evening in
> Germany).
> 
> Best regards
> 
> Christian
> 
> On 16/11/2019 08:54, Christian Mauderer wrote:
>> Hello Shubham Bhagat,
>>
>> sounds like a good plan. Like I said: If you want to look around a bit
>> without picking a fixed project yet it might would be a good idea to
>> have a look at some of the tickets. Topics in the BSP or driver area are
>> most of the time good starting points if you have the hardware or a
>> simulator.
>>
>> PS: Please keep the devel list on CC.
>>
>> Best regards
>>
>> Christian
>>
>> On 16/11/2019 07:29, Shubham Bhagat wrote:
>>> Hi!
>>> I decided to start early to understand things here and find what I would
>>> like to work on, if I have to choose a project. I intended to contribute
>>> to some OS org to improve my understanding of OS and get some experience
>>> along the way. RTEMS participating in GSOC is only like a cherry
>>> topping. Thank you for your help! I will stay connected. Is the IRC only
>>> active during GSOC?
>>> On Thursday, 14 November, 2019, 12:13:44 am IST, Christian Mauderer
>>> mailto:l...@c-mauderer.de>> wrote:
>>>
>>>
>>> Hello Shubham Bhagat,
>>>
>>> welcome to RTEMS and congratulations for completing the Hello World task.
>>>
>>> You are quite early for GSoC 2020. So just to be sure let me ask: Do you
>>> plan to participate as a GSoC student or do you want to start just out
>>> of interest outside of a program like GSoC?
>>>
>>> If you want to start for GSoC: Most of us are not in GSoC mode and the
>>> infrastructure isn't prepared yet. That's not really a problem but you
>>> might don't find the information that well prepared at the moment.
>>>
>>> Regarding tasks to do: You can either have a look at the Open Projects
>>> page in the wiki [1] or suggest some topics yourself. If you find
>>> something just discuss it on the mailing list. Someone will show up and
>>> help with how to approach the topic. Again: Please note that some of the
>>> open projects might still have some left over from last year. But even
>>> if you pick something that is solved yet we can then find something
> similar.
>>>
>>> Another possible starting point at this time could be to have a look at
>>> some of the tickets at [2]. A lot of stuff piled up there and we are
>>> always happy if someone starts to work on the less active tickets. Just
>>> tell the mailing list that you want to work on a ticket to avoid
>>> duplicate work.
>>>
>>> Note that most

Re: dl06

2019-11-18 Thread Jonathan Brandmeyer 
On Mon, Nov 18, 2019 at 1:12 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 18/11/2019 08:59, Chris Johns wrote:
> >
>
> >
> > Converting to C is a broken path IMO. it does not scale.
>
> I would convert the individual object files with bin2c and load them
> with IMFS_make_linfile().
>

We stopped using rtems-bin2c in our project, because the performance was so
poor for larger files.  Both bin2c and gcc were very slow.  We've replaced
that workflow with something based on GNU AS `.incbin` instead, which is
fast enough to be unnoticeable.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Hello World Patch

2019-11-18 Thread Shubham Bhagat 
 
Sorry I missed your replies in my inbox!
I actually do not have required hardware. I have little experience with GPOS 
(no experience with embedded!). I was wondering if you could point to some 
tickets/projects that come to your mind that would be well-suited for me? Or if 
you tell me where I could look for them, it'd be great help.
And thanks for the update on IRC. I'll connect there soon. Thanks!
On Monday, 18 November, 2019, 2:21:16 am IST, Christian Mauderer 
 wrote:  
 
 Hello Shubham Bhagat,

sorry, I missed the IRC question: In my experience our community doesn't
have lot of active people in IRC. You can try to mention some of the
connected and available people so they get pinged. For me that works if
I'm in front of a PC that is connected to my IRC-Bouncer and if I see
the message from my chat program (most of the time when it's evening in
Germany).

Best regards

Christian

On 16/11/2019 08:54, Christian Mauderer wrote:
> Hello Shubham Bhagat,
> 
> sounds like a good plan. Like I said: If you want to look around a bit
> without picking a fixed project yet it might would be a good idea to
> have a look at some of the tickets. Topics in the BSP or driver area are
> most of the time good starting points if you have the hardware or a
> simulator.
> 
> PS: Please keep the devel list on CC.
> 
> Best regards
> 
> Christian
> 
> On 16/11/2019 07:29, Shubham Bhagat wrote:
>> Hi!
>> I decided to start early to understand things here and find what I would
>> like to work on, if I have to choose a project. I intended to contribute
>> to some OS org to improve my understanding of OS and get some experience
>> along the way. RTEMS participating in GSOC is only like a cherry
>> topping. Thank you for your help! I will stay connected. Is the IRC only
>> active during GSOC?
>> On Thursday, 14 November, 2019, 12:13:44 am IST, Christian Mauderer
>>  wrote:
>>
>>
>> Hello Shubham Bhagat,
>>
>> welcome to RTEMS and congratulations for completing the Hello World task.
>>
>> You are quite early for GSoC 2020. So just to be sure let me ask: Do you
>> plan to participate as a GSoC student or do you want to start just out
>> of interest outside of a program like GSoC?
>>
>> If you want to start for GSoC: Most of us are not in GSoC mode and the
>> infrastructure isn't prepared yet. That's not really a problem but you
>> might don't find the information that well prepared at the moment.
>>
>> Regarding tasks to do: You can either have a look at the Open Projects
>> page in the wiki [1] or suggest some topics yourself. If you find
>> something just discuss it on the mailing list. Someone will show up and
>> help with how to approach the topic. Again: Please note that some of the
>> open projects might still have some left over from last year. But even
>> if you pick something that is solved yet we can then find something similar.
>>
>> Another possible starting point at this time could be to have a look at
>> some of the tickets at [2]. A lot of stuff piled up there and we are
>> always happy if someone starts to work on the less active tickets. Just
>> tell the mailing list that you want to work on a ticket to avoid
>> duplicate work.
>>
>> Note that most tickets are not really well suited for the time frame of
>> a GSoC project. But you might find some topics that you are interested
>> in and we can then find a GSoC project in that area.
>>
>> Best regards
>>
>> Christian
>>
>> [1] https://devel.rtems.org/wiki/Developer/OpenProjects
>> [2] https://devel.rtems.org/query
>>
>> On 13/11/2019 10:45, Shubham Bhagat wrote:
>>> Hi!
>>> I've completed the Hello World task for GSOC and have included the patch
>>> and screenshot in the attachments. Please do check. I am a sophomore
>>> Computer Science student from India looking to gain more knowledge in
>>> Operating Systems. Please do share with me interesting projects/issues
>>> that I can tackle!
>>>
>>> Thank you Ravindra Kumar Meena for writing a very detailed blog so I
>>> could successfully build :)
>>
>>>
>>> ___
>>> 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

no_cpu/no_bsp?

2019-11-18 Thread Sebastian Huber 

Hello,

should I add the no_cpu/no_bsp BSP to the new build system? It results 
in errors like this:


./waf bsp_defaults > bsps.ini
...
Configure board support package (BSP)  : no_cpu/no_bsp
Checking for program 'no_cpu-rtems5-gcc'   : not found
Could not find the program ['no_cpu-rtems5-gcc']
(complete log in /build/git-rtems-5/build/config.log)

--
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

[PATCH] user/start/bsp-test.rst: Changed bsp to erc32-sis.

2019-11-18 Thread gsnb . gn 
From: gs-niteesh 

This commit (id=abc540105d10ddc9cad7de3c7ac0a9aa209ac828) removed
the target sim from gdb, but the doc was not updated, so on running
rtems test as per the doc caused failures, this commit changes it
use the erc32-sis which used standalone sis simulator.
---
 user/start/bsp-test.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/start/bsp-test.rst b/user/start/bsp-test.rst
index 5278375..8a14862 100644
--- a/user/start/bsp-test.rst
+++ b/user/start/bsp-test.rst
@@ -21,7 +21,7 @@ Just run this command:
 .. code-block:: none
 
 cd $HOME/quick-start/build/b-erc32
-rtems-test --rtems-bsp=erc32 --rtems-tools=$HOME/quick-start/rtems/5 .
+rtems-test --rtems-bsp=erc32-sis --rtems-tools=$HOME/quick-start/rtems/5 .
 
 This command should output something like this (omitted lines are denoted by
 ...).  In this output the base directory :file:`$HOME/quick-start` was replaced
-- 
2.17.1

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

Re: sparc-erc32 testsuites failures

2019-11-18 Thread Vaibhav Gupta 
On Mon, Nov 18, 2019, 12:52 PM Niteesh  wrote:

> I have updated the doc to use erc32-sis, and attached the patch file in
> this mail. Can someone review it.
>
Use "git send-email" for sending patches.

>
> On Mon, Nov 18, 2019 at 12:07 PM Niteesh  wrote:
>
>> I know this, but the docs are not updated so should I send a pull request?
>>
>>
>> On Mon, Nov 18, 2019 at 12:06 PM Vaibhav Gupta 
>> wrote:
>>
>>>
>>>
>>> On Mon, Nov 18, 2019, 11:12 AM Niteesh  wrote:
>>>
 On Mon, Nov 18, 2019 at 3:17 AM Joel Sherrill  wrote:

> The instructions are out of date by a couple of months. The SPARC
> Instruction Simulator (sis) has seen significant enhancements and it's now
> a standalone program. It is not enabled as a built-in with gdb because
> that's some very old version of sis. The new version has symmetric
> multiprocessing and support for the RISC-V.
>
> Those instructions worked for a LONG time but need to be updated to
> reflect the recent changes with SIS.
>
> If you used rtems-tester, it should work. And looking at the .ini file
> for this bsp will sure you have to just run programs with the simulator. 
> My
> recollection is that by adding -gdb argument, you can attached to it as a
> remote debugger.
>
 Yes. And I also faced this problem (in my case it was riscv)and i guess
>>> this question was asked by others also on devel.
>>> I simply used these steps:
>>>
>>> Open Terminal 1:
>>>
>>> $ sparc-rtems5-sis -gdb
>>>
>>> # It will print 'gdb: listening on port 1234'.
>>>
>>> # Note you can define port number with '-port' option.
>>>
>>> Open Terminal 2:
>>>
>>> $ sparc-rtems5-gdb hello.exe
>>>
>>> # gdb asks for several inputs
>>>
>>> $ target extended-remote localhost:1234
>>>
>>> $ load
>>>
>>> $ r
>>>
>>> You will see output in Terminal 1.
>>>
 I would like to update the docs for this, Can I proceed? I am planning
 to change the cmd to use erc-sis instead of erc. And also the build your
 application section is incomplete, can I add the instruction to modify a
 test program and build it in this section?

> BTW I know it's a way too early for GSOC but I have anyway attached
>> the patch for hello world.
>>
>
> What type projects are you interested in?
>
 I am interested in driver development and BSP support.

> ___
>> 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: dl06

2019-11-18 Thread Sebastian Huber 

On 18/11/2019 08:59, Chris Johns wrote:



On 18 Nov 2019, at 6:14 pm, Sebastian Huber 
 wrote:

Hallo,

on which platform passes the dl06 test? I tried arm/realview_pbx_a9_qemu and 
got:


It is a bug that has come in that I have not looked at.


Is this a known issue or something which broke only recently? Do you 
know a version/platform on which it worked?





*** BEGIN OF TEST libdl (RTL) 6 ***
*** TEST VERSION: 5.0.0.9438165d2cfb9a6a67f01f5ec7ba9156abb66d7d-modified
*** TEST STATE: EXPECTED-PASS
*** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP
*** TEST TOOLS: 7.4.1 20190514 (RTEMS 5, RSB 
a50f0c044ad732db728cc942d5fde82a1faf1d12, Newlib d14714c69)

load: /dl06.rap
handle: 0x210ce0 loaded
Loaded module: argc:4 
[/home/EB/sebastian_h/git-rtems-5/c/src/../../testsuites/libtests/dl06/dl06-o1.c]
libm: lcong48
libm: atan2

*** FATAL ***
fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)

R0   = 0x R8  = 0x
R1   = 0x000a R9  = 0x
R2   = 0x00213149 R10 = 0x
R3   = 0x R11 = 0x
R4   = 0x00206cac R12 = 0x
R5   = 0x SP  = 0x00206c80
R6   = 0x LR  = 0x00211e51
R7   = 0x00206c80 PC  = 0x00211e94
CPSR = 0x00070173 VEC = 0x0001
FPEXC = 0x4000
FPSCR = 0x
D00 = 0x401c
D01 = 0x40408000
D02 = 0x3fddac670561bb4f
D03 = 0x3fe921fb54442d18
D04 = 0x3fef730bd281f69b
D05 = 0x3ff921fb54442d18
D06 = 0x3c7a2b7f222f65e2
D07 = 0x3c81a62633145c07
D08 = 0x
D09 = 0x
D10 = 0x
D11 = 0x
D12 = 0x
D13 = 0x
D14 = 0x
D15 = 0x
D16 = 0x
D17 = 0x0002
D18 = 0x
D19 = 0x
D20 = 0x
D21 = 0x
D22 = 0x
D23 = 0x
D24 = 0x
D25 = 0x
D26 = 0x
D27 = 0x
D28 = 0x
D29 = 0x
D30 = 0x
D31 = 0x
RTEMS version: 5.0.0.9438165d2cfb9a6a67f01f5ec7ba9156abb66d7d-modified
RTEMS tools: 7.4.1 20190514 (RTEMS 5, RSB 
a50f0c044ad732db728cc942d5fde82a1faf1d12, Newlib d14714c69)
executing thread ID: 0x08a010001
executing thread name: UI1

I tried arm/xilinx_zynq_a9_qemu and got:

*** BEGIN OF TEST libdl (RTL) 6 ***
*** TEST VERSION: 5.0.0.799c4f551806fb1124ea5d9f6633ec5deb91ad8e
*** TEST STATE: EXPECTED-PASS
*** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API
*** TEST TOOLS: 7.4.1 20190514 (RTEMS 5, RSB 
a50f0c044ad732db728cc942d5fde82a1faf1d12, Newlib d14714c69)

load: /dl06.rap
dlopen failed: .text: THM_CALL/JUMP24: overflow: no tramp memory

*** FATAL ***
fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
fatal code: 0 (0x)
RTEMS version: 5.0.0.799c4f551806fb1124ea5d9f6633ec5deb91ad8e
RTEMS tools: 7.4.1 20190514 (RTEMS 5, RSB 
a50f0c044ad732db728cc942d5fde82a1faf1d12, Newlib d14714c69)
executing thread ID: 0x08a010001
executing thread name: UI1

I would like to remove the PAX archives to simplify the build and reduce the 
host dependencies.


Is this because of handled the dependencies in waf?


It is not a waf issue. I just want to get rid of another host 
dependency. pax is not a standard Linux tool.




Converting to C is a broken path IMO. it does not scale.


I would convert the individual object files with bin2c and load them 
with IMFS_make_linfile().




I am not sure removing pax solves the need for 2 link passes.


It is not clear to me what the purpose of the dl06_pre_file file is.


It tests the RAP format.


How is the file used?

--
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: dl06

2019-11-18 Thread Chris Johns 

> On 18 Nov 2019, at 6:14 pm, Sebastian Huber 
>  wrote:
> 
> Hallo,
> 
> on which platform passes the dl06 test? I tried arm/realview_pbx_a9_qemu and 
> got:

It is a bug that has come in that I have not looked at. 

> *** BEGIN OF TEST libdl (RTL) 6 ***
> *** TEST VERSION: 5.0.0.9438165d2cfb9a6a67f01f5ec7ba9156abb66d7d-modified
> *** TEST STATE: EXPECTED-PASS
> *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP
> *** TEST TOOLS: 7.4.1 20190514 (RTEMS 5, RSB 
> a50f0c044ad732db728cc942d5fde82a1faf1d12, Newlib d14714c69)
> 
> load: /dl06.rap
> handle: 0x210ce0 loaded
> Loaded module: argc:4 
> [/home/EB/sebastian_h/git-rtems-5/c/src/../../testsuites/libtests/dl06/dl06-o1.c]
> libm: lcong48
> libm: atan2
> 
> *** FATAL ***
> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
> 
> R0   = 0x R8  = 0x
> R1   = 0x000a R9  = 0x
> R2   = 0x00213149 R10 = 0x
> R3   = 0x R11 = 0x
> R4   = 0x00206cac R12 = 0x
> R5   = 0x SP  = 0x00206c80
> R6   = 0x LR  = 0x00211e51
> R7   = 0x00206c80 PC  = 0x00211e94
> CPSR = 0x00070173 VEC = 0x0001
> FPEXC = 0x4000
> FPSCR = 0x
> D00 = 0x401c
> D01 = 0x40408000
> D02 = 0x3fddac670561bb4f
> D03 = 0x3fe921fb54442d18
> D04 = 0x3fef730bd281f69b
> D05 = 0x3ff921fb54442d18
> D06 = 0x3c7a2b7f222f65e2
> D07 = 0x3c81a62633145c07
> D08 = 0x
> D09 = 0x
> D10 = 0x
> D11 = 0x
> D12 = 0x
> D13 = 0x
> D14 = 0x
> D15 = 0x
> D16 = 0x
> D17 = 0x0002
> D18 = 0x
> D19 = 0x
> D20 = 0x
> D21 = 0x
> D22 = 0x
> D23 = 0x
> D24 = 0x
> D25 = 0x
> D26 = 0x
> D27 = 0x
> D28 = 0x
> D29 = 0x
> D30 = 0x
> D31 = 0x
> RTEMS version: 5.0.0.9438165d2cfb9a6a67f01f5ec7ba9156abb66d7d-modified
> RTEMS tools: 7.4.1 20190514 (RTEMS 5, RSB 
> a50f0c044ad732db728cc942d5fde82a1faf1d12, Newlib d14714c69)
> executing thread ID: 0x08a010001
> executing thread name: UI1
> 
> I tried arm/xilinx_zynq_a9_qemu and got:
> 
> *** BEGIN OF TEST libdl (RTL) 6 ***
> *** TEST VERSION: 5.0.0.799c4f551806fb1124ea5d9f6633ec5deb91ad8e
> *** TEST STATE: EXPECTED-PASS
> *** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API
> *** TEST TOOLS: 7.4.1 20190514 (RTEMS 5, RSB 
> a50f0c044ad732db728cc942d5fde82a1faf1d12, Newlib d14714c69)
> 
> load: /dl06.rap
> dlopen failed: .text: THM_CALL/JUMP24: overflow: no tramp memory
> 
> *** FATAL ***
> fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
> fatal code: 0 (0x)
> RTEMS version: 5.0.0.799c4f551806fb1124ea5d9f6633ec5deb91ad8e
> RTEMS tools: 7.4.1 20190514 (RTEMS 5, RSB 
> a50f0c044ad732db728cc942d5fde82a1faf1d12, Newlib d14714c69)
> executing thread ID: 0x08a010001
> executing thread name: UI1
> 
> I would like to remove the PAX archives to simplify the build and reduce the 
> host dependencies.

Is this because of handled the dependencies in waf?

Converting to C is a broken path IMO. it does not scale.

I am not sure removing pax solves the need for 2 link passes.  

> It is not clear to me what the purpose of the dl06_pre_file file is.

It tests the RAP format. 

Chris

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