RTEMS available tasks

[Andre Marques]

On 01/27/14 12:56, Sebastian Huber wrote:
> On 2014-01-27 13:30, Andre Marques wrote:
>> On 01/27/14 08:00, Sebastian Huber wrote:
>>> Hello Andre,
>>>
>>> On 2014-01-26 01:31, Andre Marques wrote:
>>>> Hello,
>>>>
>>>> I'm a CS undergraduate student and i've decided to do something 
>>>> RTEMS related
>>>> for my final project.
>>>
>>> this is nice.
>>>
>>>>
>>>> I already have a RTEMS build (4.11) working on my Gentoo system and 
>>>> played a
>>>> bit with the EDF and RM schedulers (just launching some tasks and 
>>>> counting the
>>>> deadline misses).
>>>
>>> Which BSP do you use?  If you want to work with a simulator BSP, 
>>> then you
>>> should have a look at the arm/realview_pbx_a9_qemu BSP since it 
>>> offers a NULL
>>> pointer read and write protection.  Qemu is also a fast simulator which
>>> provides support for GDB watch points.  This is quite handy for 
>>> development
>>> and test suite runs.
>>>
>> I'm using the pc386 BSP using Qemu with the pc386 script provided on
>> rtems_testing. Only today I tested GDB with Qemu, which I'm finding a 
>> bit
>> tricky with the pc386 script because as soon as the program finishes 
>> It closes
>> Qemu, so I can't connect to the gdb server. To solve that I used the
>> instructions on the Wiki about Qemu (which seems to be a little 
>> outdated, so I
>> needed to change some steps) and I can now load a program and connect 
>> to the
>> gdb server, but I don't have the symbol table for any program. I 
>> can't recall
>> enabling debugging during the rtems configure stage, but will that 
>> generate
>> symbol tables for every compiled program? Can't I just generate a 
>> symbol table
>> for a specific program?
>
> With the arm/realview_pbx_a9_qemu BSP I use this.
>
> 1. Start Qemu in one window:
>
> qemu-system-arm -nographic -M realview-pbx-a9 -m 256M -kernel app.exe 
> -s -S
>
> 2. Connect with GDB:
>
> arm-rtems4.11-gdb app.exe
>
> tar remote :1234
> load
> continue
>
> You don't have to restart Qemu to load a new program, e.g. you can use 
> the following GDB function:
>
> def new
> make
> monitor system_reset
> load
> continue
> end
>

Well, for me Qemu seems to be having some problems with the output, 
because I can set breakpoints, and run the code on the remote target, 
but Qemu doesn't show any output (with -nographic, and different 
consoles), or shows the output for the program passed with the -kernel 
parameter, regardless of what gdb says that is printing.

For now I guess I'm leaving this as it is, as I've tried for several 
hours already to make the output work.

On pc386 the -S option leads to a fatal error, because when loading the 
program it seems to load it on the Bios memory space. If I dont use that 
option all seems to work. As for arm, I could't get any output.

>>
>>>>
>>>> As of right now i'm between semesters, and looking to fill this gap 
>>>> with some
>>>> coding fun. In [1] there is a task for making the implementation of 
>>>> rename()
>>>> POSIX conformant. If this task is still open I would like to start 
>>>> working
>>>> on it.
>>>
>>> Yes, this task is still open and it is a good start point.
>>>
>>> I would start with a new test in
>>>
>>> http://git.rtems.org/rtems/tree/testsuites/fstests/
>>>
>>> which covers the POSIX rename() specification
>>>
>>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html
>>>
>> In that case that's where I'm going to start. Any questions that I 
>> might have
>> should I post them on the users list or somewhere else?
>
> That list or to the rtems-devel list.
>