Re: [PATCH] port newlib for or1k/rtems (avoiding GPL licence problem)

[Hesham Moustafa]

On Apr 29, 2014 7:54 AM, "Ralf Corsepius"  wrote:
>
> On 04/29/2014 05:20 AM, Hesham Moustafa wrote:
>>
>> Hi,
>>
>> In the last few days, I have been working on porting newlib for
>> or1k/rtems. Joel and Chris mentioned that the previous newlib port has
>> some GPL code which conflicts with RTEMS;
>
> Which? I could be missing something, but I am not seeing such code in [1].
>
By "previous newlib port" I mean this one
https://github.com/heshamelmatary/or1k-rtems/blob/master/patches/newlib-2.1.0-or1k-rtems.diff
I gave generated that patch against upstream or1k/newlib there
https://github.com/openrisc/or1k-src?files=1
Which Chris and Joel cited about its illegal licence.
>
>> No libgloss stuff is being used.
>
> Correct. libgloss stuff is completely irrelevant wrt RTEMS.
>
>
>> Please take a look, I would
>> appreciate your feedback.
>
>
> I am seeing one issue with newlib/libc/machine/or1k/setjmp.S
>
> It is not properly licensed. All it carries is this:
>
> +/* Simple setjmp/longjmp for the OpenRISC 1000 (OR32 ISA).
> +   Damjan Lampret, OpenCores.org, Aug 15 2000.  */
>
> You'll have to contact a legal copyright holder of this code (I'd guess
Damjan Lampert or representative of opencores.org) and ask him to (re-)
license this code under legal terms which are suitable to newlib.
>
>
>> [1] http://www.doc.ic.ac.uk/~jab00/or32-newlib/newlib-patch
>> [2]
https://github.com/heshamelmatary/or1k-rtems/blob/master/patches/newlib-cvs-or1k-rtems-29-4-2014.diff
>> [3]
https://github.com/heshamelmatary/or1k-rtems/blob/master/patches/gcc-4.8.2-or1k-rtems-29-4-2014.diff
>
>
> Ralf
>
> ___
> rtems-devel mailing list
> rtems-devel@rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel

Re: *** PROFILING DONE XXX *** Message

[Sebastian Huber]

On 2014-04-28 19:05, Jennifer Averett wrote:

Tests now output a *** PROFILING DONE XXX *** message.

Should all *.scn files be changed to show this message,

so that automatic testing will work correctly?



I silenced the output if RTEMS_PROFILING is disabled.

--
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.
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel

Re: [PATCH] port newlib for or1k/rtems (avoiding GPL licence problem)

[Ralf Corsepius]

On 04/29/2014 05:20 AM, Hesham Moustafa wrote:

Hi,

In the last few days, I have been working on porting newlib for
or1k/rtems. Joel and Chris mentioned that the previous newlib port has
some GPL code which conflicts with RTEMS;

Which? I could be missing something, but I am not seeing such code in [1].


No libgloss stuff is being used.

Correct. libgloss stuff is completely irrelevant wrt RTEMS.


Please take a look, I would
appreciate your feedback.


I am seeing one issue with newlib/libc/machine/or1k/setjmp.S

It is not properly licensed. All it carries is this:

+/* Simple setjmp/longjmp for the OpenRISC 1000 (OR32 ISA).
+   Damjan Lampret, OpenCores.org, Aug 15 2000.  */

You'll have to contact a legal copyright holder of this code (I'd guess 
Damjan Lampert or representative of opencores.org) and ask him to (re-) 
license this code under legal terms which are suitable to newlib.



[1] http://www.doc.ic.ac.uk/~jab00/or32-newlib/newlib-patch
[2] 
https://github.com/heshamelmatary/or1k-rtems/blob/master/patches/newlib-cvs-or1k-rtems-29-4-2014.diff
[3] 
https://github.com/heshamelmatary/or1k-rtems/blob/master/patches/gcc-4.8.2-or1k-rtems-29-4-2014.diff


Ralf

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

[PATCH] port newlib for or1k/rtems (avoiding GPL licence problem)

[Hesham Moustafa]

Hi,

In the last few days, I have been working on porting newlib for
or1k/rtems. Joel and Chris mentioned that the previous newlib port has
some GPL code which conflicts with RTEMS; that's why I used this patch
[1] as a starting point. I had to do some changes and additions over
the patch including: configuration files, renaming, setjmp.S
modifications due to ABI changes, and others.

The new newlib patch [2] is against the latest newlib cvs source. It's
too big to be sent via mailing list. Also I have made some minor
changes to gcc port [3] (by help of Joel), to make gcc/newlib building
process works normally.

No libgloss stuff is being used. Please take a look, I would
appreciate your feedback.

[1] http://www.doc.ic.ac.uk/~jab00/or32-newlib/newlib-patch
[2] 
https://github.com/heshamelmatary/or1k-rtems/blob/master/patches/newlib-cvs-or1k-rtems-29-4-2014.diff
[3] 
https://github.com/heshamelmatary/or1k-rtems/blob/master/patches/gcc-4.8.2-or1k-rtems-29-4-2014.diff
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel

Re: SD card libblock bdpart linker problem

[Chris Johns]

On 29/04/2014 10:50 am, Alan Cudmore wrote:

Do you have the right configuration options defined?

I rebuilt the raspberry Pi BSP with all tests ( --enable-tests=yes ).
This includes the testsuites/fstests/fsbdpart01 test.
The test links and runs, but I'm not sure if it passes ( or if it should
completely, since there is no IDE hardware on the Pi)
I get this output:
*** BEGIN OF TEST FSBDPART 1 ***
../../../../../../../rtems-git/c/src/../../testsuites/fstests/fsbdpart01/init.c:
143 (sc) == RTEMS_SUCCESSFUL

After this it seems to hang.



Set a break point on _Terminate. The Split _Terminate patch I posted 
helps here with some tests. Being able to ste a break point and catch 
the absolute end of the test run is why we run the tests via gdb.


FYI I am currently reworking the _Terminate patch after talking to 
Sebastian to change the way _CPU_Fatal_halt works.


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

Re: [GSOC] RPi BSP RTEMS

[Chris Johns]

On 29/04/2014 10:37 am, Alan Cudmore wrote:

I will definitely try that out. It would be great to automate all tests
on this board.
It seems less than 10 seconds to load a 1 megabyte RTEMS image to the Pi
using JTAG.



The last test from the Beagleboard xM test log shows ...

[498/498] p:488 f:1   t:8   i:0   | arm/beagleboardxm: tmoverhd.exe
Result: passed Time: 0:00:12.141110

This test took just over 12 seconds so this seems close to what we have.

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

Re: SD card libblock bdpart linker problem

[Alan Cudmore]

Do you have the right configuration options defined?

I rebuilt the raspberry Pi BSP with all tests ( --enable-tests=yes ). This
includes the testsuites/fstests/fsbdpart01 test.
The test links and runs, but I'm not sure if it passes ( or if it should
completely, since there is no IDE hardware on the Pi)
I get this output:
*** BEGIN OF TEST FSBDPART 1 ***
../../../../../../../rtems-git/c/src/../../testsuites/fstests/fsbdpart01/init.c:
143 (sc) == RTEMS_SUCCESSFUL

After this it seems to hang.


But , the init.c for that test may help you with the configuration in your
code.





On Mon, Apr 28, 2014 at 2:56 PM, Andre Marques <
andre.lousa.marq...@gmail.com> wrote:

> Hello,
>
> I am currently working on an emmc driver for the Raspberry Pi, and I am
> trying to mount the SD card using libblock on RTEMS GIT HEAD.
>
> To mount the SD card I am doing:
>
> 1. rtems_io_register_driver (by calling my driver with
> CONFIGURE_APPLICATION_EXTRA_DRIVERS on hello sample)
>
> 2. rtems_filesystem_make_dev_t to get the device file
>
> 3.  rtems_disk_io_initialize
>
> 4. rtems_disk_create_phys
>
> Up until this point everything seems good.
>
> Next I try to read the SD card partition table with
> rtems_bdpart_register_from_disk, and for that I add an include for
> rtems/bdpart.h
>
> When I hit compile, the result seems to point at a linker problem
> (conflict with dummy.o):
>
> (..)
> Making all in hello
> gmake[6]: Entering directory `/home/bison/RTEMS/arm/
> raspberry_pi/b-rtems4.11/arm-rtems4.11/c/raspberrypi/
> testsuites/samples/hello'
> arm-rtems4.11-gcc -B../../../../../raspberrypi/lib/ -specs bsp_specs
> -qrtems -DHAVE_CONFIG_H -I. -I/home/bison/RTEMS/code/c/
> src/../../testsuites/samples/hello -I.. -mcpu=arm1176jzf-s -O2 -g
> -Wall -Wmissing-prototypes -Wimplicit-function-declaration
> -Wstrict-prototypes -Wnested-externs -MT init.o -MD -MP -MF .deps/init.Tpo
> -c -o init.o /home/bison/RTEMS/code/c/src/../../testsuites/samples/hello/
> init.c
> mv -f .deps/init.Tpo .deps/init.Po
> arm-rtems4.11-gcc -B../../../../../raspberrypi/lib/ -specs bsp_specs
> -qrtems -mcpu=arm1176jzf-s -O2 -g -Wall -Wmissing-prototypes
> -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs
>  -mcpu=arm1176jzf-s   -o hello.exe init.o
> ../../../../../raspberrypi/lib/librtemscpu.a(dummy.o): In function
> `_Thread_Idle_body':
> /home/bison/RTEMS/arm/raspberry_pi/b-rtems4.11/arm-
> rtems4.11/c/raspberrypi/cpukit/libmisc/../../cpukit/..
> /../../raspberrypi/lib/include/rtems/confdefs.h:849: multiple definition
> of `_Thread_Idle_body'
> init.o:/home/bison/RTEMS/arm/raspberry_pi/b-rtems4.11/arm-
> rtems4.11/c/raspberrypi/testsuites/samples/hello/../..
> /../../../raspberrypi/lib/include/rtems/confdefs.h:849: first defined here
> ../../../../../raspberrypi/lib/librtemscpu.a(dummy.o): In function
> `_Thread_Get_executing':
> /home/bison/RTEMS/arm/raspberry_pi/b-rtems4.11/arm-
> rtems4.11/c/raspberrypi/cpukit/libmisc/../../cpukit/..
> /../../raspberrypi/lib/include/rtems/score/thread.h:632: multiple
> definition of `__getreent'
> init.o:/home/bison/RTEMS/arm/raspberry_pi/b-rtems4.11/arm-
> rtems4.11/c/raspberrypi/testsuites/samples/hello/../..
> /../../../raspberrypi/lib/include/rtems/score/thread.h:632: first defined
> here
> ../../../../../raspberrypi/lib/librtemscpu.a(dummy.o): In function
> `_Thread_Idle_body':
> /home/bison/RTEMS/arm/raspberry_pi/b-rtems4.11/arm-
> rtems4.11/c/raspberrypi/cpukit/libmisc/../../cpukit/..
> /../../raspberrypi/lib/include/rtems/confdefs.h:849: multiple definition
> of `_POSIX_Threads_Initialize_user_threads_p'
> init.o:/home/bison/RTEMS/arm/raspberry_pi/b-rtems4.11/arm-
> rtems4.11/c/raspberrypi/testsuites/samples/hello/../..
> /../../../raspberrypi/lib/include/rtems/confdefs.h:849: first defined here
> ../../../../../raspberrypi/lib/librtemscpu.a(dummy.o):(.data+0x0):
> multiple definition of `_RTEMS_tasks_Initialize_user_tasks_p'
> init.o:(.data+0x0): first defined here
> ../../../../../raspberrypi/lib/librtemscpu.a(dummy.o):(.rodata+0x0):
> multiple definition of `Configuration'
> init.o:(.rodata+0x0): first defined here
> ../../../../../raspberrypi/lib/librtemscpu.a(dummy.o):(.data+0x4):
> multiple definition of `rtems_maximum_priority'
> init.o:(.data+0x4): first defined here
> ../../../../../raspberrypi/lib/librtemscpu.a(dummy.o):(.data+0x8):
> multiple definition of `rtems_minimum_stack_size'
> init.o:(.data+0x8): first defined here
> ../../../../../raspberrypi/lib/librtemscpu.a(dummy.o): In function
> `_Thread_Get_executing':
> /home/bison/RTEMS/arm/raspberry_pi/b-rtems4.11/arm-
> rtems4.11/c/raspberrypi/cpukit/libmisc/../../cpukit/..
> /../../raspberrypi/lib/include/rtems/score/thread.h:632: multiple
> definition of `Configuration_POSIX_API'
> init.o:/home/bison/RTEMS/arm/raspberry_pi/b-rtems4.11/arm-
> rtems4.11/c/raspberrypi/testsuites/samples/hello/../..
> /../../../raspberrypi/lib/include/rtems/test.h:73: first defined here
> ../../../../../raspberrypi/lib/librtemscpu.a(dummy.o):(

Re: [GSOC] RPi BSP RTEMS

[Alan Cudmore]

I will definitely try that out. It would be great to automate all tests on
this board.
It seems less than 10 seconds to load a 1 megabyte RTEMS image to the Pi
using JTAG.

Alan


On Mon, Apr 28, 2014 at 7:20 PM, Chris Johns  wrote:

> On 29/04/2014 12:34 am, Alan Cudmore wrote:
>
>>
>> The FT2232H MiniMod is working so far! I am able to use the UART and at
>> the same time load and run images over the JTAG interface using OpenOCD.
>> Next, I plan on trying GDB. I will try to document the setup soon, but
>> it just requires ~10 jumper wires to connect the MiniMod to the Pi GPIO
>> header.
>>
>
> The rtems-tester works well with OpenOCD and GDB. Please take a look at
> the recent BeagleBoard xM script Ben and I are currently using ...
>
> http://git.rtems.org/rtems-tools/tree/tester/rtems/
> testing/bsps/beagleboardxm.mc
>
> It took us a while to get a stable way to force a full reset on the xM's
> ARM. It takes about 3 hours to run all 500 tests.
>
> If you get a working configuration please send me a patch. Hard coded
> paths are ok at this stage of the rtems-test's development. I am yet to
> figure out a way to manage the host variations.
>
> Chris
>
> ___
> rtems-devel mailing list
> rtems-devel@rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel

Re: virtualpok bsp: can't build hello.exe

[Gedare Bloom]

That or the virtualpok BSP needs an update to its linkcmds. :)

On Mon, Apr 28, 2014 at 8:12 PM, Gedare Bloom  wrote:
> You need to update RTEMS I suspect, there were some fixes made in
> linker scripts to adjust for thread-local storage (TLS).
>
> On Mon, Apr 28, 2014 at 7:42 PM, Janek van Oirschot
>  wrote:
>> Hello,
>>
>> I am currently trying to get RTEMS running on POK. I've gone from problem to
>> problem and now I find myself stuck on one of them. (see attachment).
>>
>> I've found that while building RTEMS for POK that hello.exe wont compile due
>> to undefined references to a few extern variables. I've looked into
>> 'threadinitialize.c' and 'wkspace.c' and noticed they properly included
>> 'rtems/score/tls.h' where these variables are properly defined.
>>
>> Does anybody know a solution for this problem or has anybody ran into a
>> similar problem?
>>
>> Thanks in advance,
>> Janek
>>
>> ___
>> rtems-devel mailing list
>> rtems-devel@rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel

Re: virtualpok bsp: can't build hello.exe

[Gedare Bloom]

You need to update RTEMS I suspect, there were some fixes made in
linker scripts to adjust for thread-local storage (TLS).

On Mon, Apr 28, 2014 at 7:42 PM, Janek van Oirschot
 wrote:
> Hello,
>
> I am currently trying to get RTEMS running on POK. I've gone from problem to
> problem and now I find myself stuck on one of them. (see attachment).
>
> I've found that while building RTEMS for POK that hello.exe wont compile due
> to undefined references to a few extern variables. I've looked into
> 'threadinitialize.c' and 'wkspace.c' and noticed they properly included
> 'rtems/score/tls.h' where these variables are properly defined.
>
> Does anybody know a solution for this problem or has anybody ran into a
> similar problem?
>
> Thanks in advance,
> Janek
>
> ___
> rtems-devel mailing list
> rtems-devel@rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel

Re: [GSOC] RPi BSP RTEMS

[Chris Johns]

On 29/04/2014 12:34 am, Alan Cudmore wrote:


The FT2232H MiniMod is working so far! I am able to use the UART and at
the same time load and run images over the JTAG interface using OpenOCD.
Next, I plan on trying GDB. I will try to document the setup soon, but
it just requires ~10 jumper wires to connect the MiniMod to the Pi GPIO
header.


The rtems-tester works well with OpenOCD and GDB. Please take a look at 
the recent BeagleBoard xM script Ben and I are currently using ...


http://git.rtems.org/rtems-tools/tree/tester/rtems/testing/bsps/beagleboardxm.mc

It took us a while to get a stable way to force a full reset on the xM's 
ARM. It takes about 3 hours to run all 500 tests.


If you get a working configuration please send me a patch. Hard coded 
paths are ok at this stage of the rtems-test's development. I am yet to 
figure out a way to manage the host variations.


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

Re: *** PROFILING DONE XXX *** Message

[Chris Johns]

On 29/04/2014 3:05 am, Jennifer Averett wrote:

Tests now output a *** PROFILING DONE XXX *** message.



Not for me. Please see the attached hello trace for the SIS.

Is this specific to SMP ?

Which BSP are these files based on ?

Which BSPs produce the same output ?


Should all *.scn files be changed to show this message,

so that automatic testing will work correctly?



I do not see why you need to. Any results based on comparing the output 
with these files is suspect. The output contains the ids of various 
objects and the base value of these can vary, eg the issue of termios 
task mode using an extra semaphore highlights this. Also the unlimited 
test depends on the size of the workspace and that can vary. I am not 
confident of generating test results unless these things can be 
correctly managed and currently only the start and end markers do this.


I see these options:

1. Do not rely on output other than the test start and end tags. 
Anything else is consider informational and nothing more. A number of 
tests print nothing and given the time it takes to test doing this is a 
performance win.


2. Add tags to the scn files to highlight the areas that change. I do 
not consider this viable long term because of the overhead of 
maintaining the files.


3. Add a tprintf function all "test output" passes through. To this we 
add things like '%I' to print a suitable id. The "test output" could be 
encapsulated to allow us to track what is considered important and what 
is not. Anything not encapsulated is out of band and ignored. The id 
base for each type of id in the system would need to be recorded when 
testing starts and offsets printed. In the end I am not sure what this 
added complexity gives us.


Personally I currently prefer 1. The output becomes informational and 
based on a selected reference BSP.


Chris
RTEMS Testing - Tester, v0.2.0
 Command Line: 
/home/chris/development/rtems/src/rt/rtems-tools.git/tester/rtems-test 
--rtems-bsp=sis --rtems-tools=/home/chris/development/rtems/4.11 
--log=log_sis_hello --report-mode=all 
sparc-rtems4.11/c/sis/testsuites/samples/hello/
 Python: 2.7.6 (default, Mar  5 2014, 10:19:04) [GCC 4.2.1 20070831 patched 
[FreeBSD]]
[1/1] p:0 f:0 t:0 i:0 | sparc/sis: hello.exe
> gdb: /home/chris/development/rtems/4.11/bin/sparc-rtems4.11-gdb -i=mi --nx 
> --quiet sparc-rtems4.11/c/sis/testsuites/samples/hello/hello.exe
> Reading symbols from 
> sparc-rtems4.11/c/sis/testsuites/samples/hello/hello.exe...
> done.
> target sim
> Connected to the simulator.
> load
> run
> Starting program: 
> /usr/home/chris/development/rtems/bb/sis/sparc-rtems4.11/c/sis/testsuites/samples/hello/hello.exe
>  
] *** BEGIN OF TEST HELLO WORLD ***
] Hello World
] *** END OF TEST HELLO WORLD ***
> [Inferior 1 (process 42000) exited normally]
Result: passed Time: 0:00:01.017729

Passed:   1
Failed:   0
Timeouts: 0
Invalid:  0
---
Total:1

Testing time: 0:00:01.308710
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel

Possible Interruption for RTEMS Project Services

[Joel Sherrill]

The Huntsville area is in for a serious of strong storms for the next 24-36 
hours. 
Everything is on UPS but if there is serious damage like a few years ago, there
could be service interruptions.

Local news is already reporting tornadoes with winds over 100 mph within 30 
miles of 
OAR and heading this direction.

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

Re: MIPS Thread Local Storage Help Request

[Joel Sherrill]

On 4/28/2014 1:56 PM, Gedare Bloom wrote:
> On Mon, Apr 28, 2014 at 2:47 PM, Joel Sherrill
>  wrote:
>> Hi
>>
>> This is going to be interesting. MIPS TLS is broken because
>> we don't have a trap handler for this. From GCC:
>>
>> ;; Thread-Local Storage
>>
>> ;; The TLS base pointer is accessed via "rdhwr $3, $29".  No current
>> ;; MIPS architecture defines this register, and no current
>> ;; implementation provides it; instead, any OS which supports TLS is
>> ;; expected to trap and emulate this instruction.  rdhwr is part of the
>> ;; MIPS 32r2 specification, but we use it on any architecture because
>> ;; we expect it to be emulated.  Use .set to force the assembler to
>> ;; accept it.
>> ;;
>> ;; We do not use a constraint to force the destination to be $3
>> ;; because $3 can appear explicitly as a function return value.
>> ;; If we leave the use of $3 implicit in the constraints until
>> ;; reload, we may end up making a $3 return value live across
>> ;; the instruction, leading to a spill failure when reloading it.
>>
>> This code from NetBSD appears to be the core part of the
>> handler.
>>
>> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/mips/mips/locore_mips3.S?only_with_tag=MAIN
>>
> Do you mean
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/mips/mips/mips_emul.c?rev=1.26&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
> near case OP_RDHWR
>
Yeah.

And at one point I thought we had code similar to that because
the R3000 like the MongooseV needed help to be IEEE FP compliant.
And we used the NetBSD instruction trap emulator to help.
>> If someone can adapt this, then the MIPS will have working
>> TLS.
>>
>> Thanks.
>>
>> --
>> Joel Sherrill, Ph.D. Director of Research & Development
>> joel.sherr...@oarcorp.comOn-Line Applications Research
>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>> Support Available(256) 722-9985
>>
>> ___
>> rtems-devel mailing list
>> rtems-devel@rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

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

SD card libblock bdpart linker problem

[Andre Marques]

Hello,

I am currently working on an emmc driver for the Raspberry Pi, and I am 
trying to mount the SD card using libblock on RTEMS GIT HEAD.


To mount the SD card I am doing:

1. rtems_io_register_driver (by calling my driver with 
CONFIGURE_APPLICATION_EXTRA_DRIVERS on hello sample)


2. rtems_filesystem_make_dev_t to get the device file

3.  rtems_disk_io_initialize

4. rtems_disk_create_phys

Up until this point everything seems good.

Next I try to read the SD card partition table with 
rtems_bdpart_register_from_disk, and for that I add an include for 
rtems/bdpart.h


When I hit compile, the result seems to point at a linker problem 
(conflict with dummy.o):


(..)
Making all in hello
gmake[6]: Entering directory 
`/home/bison/RTEMS/arm/raspberry_pi/b-rtems4.11/arm-rtems4.11/c/raspberrypi/testsuites/samples/hello'
arm-rtems4.11-gcc -B../../../../../raspberrypi/lib/ -specs bsp_specs 
-qrtems -DHAVE_CONFIG_H -I. 
-I/home/bison/RTEMS/code/c/src/../../testsuites/samples/hello -I.. 
-mcpu=arm1176jzf-s -O2 -g -Wall -Wmissing-prototypes 
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT 
init.o -MD -MP -MF .deps/init.Tpo -c -o init.o 
/home/bison/RTEMS/code/c/src/../../testsuites/samples/hello/init.c

mv -f .deps/init.Tpo .deps/init.Po
arm-rtems4.11-gcc -B../../../../../raspberrypi/lib/ -specs bsp_specs 
-qrtems -mcpu=arm1176jzf-s -O2 -g -Wall -Wmissing-prototypes 
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs
-mcpu=arm1176jzf-s   -o hello.exe init.o
../../../../../raspberrypi/lib/librtemscpu.a(dummy.o): In function 
`_Thread_Idle_body':
/home/bison/RTEMS/arm/raspberry_pi/b-rtems4.11/arm-rtems4.11/c/raspberrypi/cpukit/libmisc/../../cpukit/../../../raspberrypi/lib/include/rtems/confdefs.h:849: 
multiple definition of `_Thread_Idle_body'
init.o:/home/bison/RTEMS/arm/raspberry_pi/b-rtems4.11/arm-rtems4.11/c/raspberrypi/testsuites/samples/hello/../../../../../raspberrypi/lib/include/rtems/confdefs.h:849: 
first defined here
../../../../../raspberrypi/lib/librtemscpu.a(dummy.o): In function 
`_Thread_Get_executing':
/home/bison/RTEMS/arm/raspberry_pi/b-rtems4.11/arm-rtems4.11/c/raspberrypi/cpukit/libmisc/../../cpukit/../../../raspberrypi/lib/include/rtems/score/thread.h:632: 
multiple definition of `__getreent'
init.o:/home/bison/RTEMS/arm/raspberry_pi/b-rtems4.11/arm-rtems4.11/c/raspberrypi/testsuites/samples/hello/../../../../../raspberrypi/lib/include/rtems/score/thread.h:632: 
first defined here
../../../../../raspberrypi/lib/librtemscpu.a(dummy.o): In function 
`_Thread_Idle_body':
/home/bison/RTEMS/arm/raspberry_pi/b-rtems4.11/arm-rtems4.11/c/raspberrypi/cpukit/libmisc/../../cpukit/../../../raspberrypi/lib/include/rtems/confdefs.h:849: 
multiple definition of `_POSIX_Threads_Initialize_user_threads_p'
init.o:/home/bison/RTEMS/arm/raspberry_pi/b-rtems4.11/arm-rtems4.11/c/raspberrypi/testsuites/samples/hello/../../../../../raspberrypi/lib/include/rtems/confdefs.h:849: 
first defined here
../../../../../raspberrypi/lib/librtemscpu.a(dummy.o):(.data+0x0): 
multiple definition of `_RTEMS_tasks_Initialize_user_tasks_p'

init.o:(.data+0x0): first defined here
../../../../../raspberrypi/lib/librtemscpu.a(dummy.o):(.rodata+0x0): 
multiple definition of `Configuration'

init.o:(.rodata+0x0): first defined here
../../../../../raspberrypi/lib/librtemscpu.a(dummy.o):(.data+0x4): 
multiple definition of `rtems_maximum_priority'

init.o:(.data+0x4): first defined here
../../../../../raspberrypi/lib/librtemscpu.a(dummy.o):(.data+0x8): 
multiple definition of `rtems_minimum_stack_size'

init.o:(.data+0x8): first defined here
../../../../../raspberrypi/lib/librtemscpu.a(dummy.o): In function 
`_Thread_Get_executing':
/home/bison/RTEMS/arm/raspberry_pi/b-rtems4.11/arm-rtems4.11/c/raspberrypi/cpukit/libmisc/../../cpukit/../../../raspberrypi/lib/include/rtems/score/thread.h:632: 
multiple definition of `Configuration_POSIX_API'
init.o:/home/bison/RTEMS/arm/raspberry_pi/b-rtems4.11/arm-rtems4.11/c/raspberrypi/testsuites/samples/hello/../../../../../raspberrypi/lib/include/rtems/test.h:73: 
first defined here
../../../../../raspberrypi/lib/librtemscpu.a(dummy.o):(.data+0xc): 
multiple definition of `Configuration_RTEMS_API'

init.o:(.data+0xc): first defined here
../../../../../raspberrypi/lib/librtemscpu.a(dummy.o):(.data+0x3c): 
multiple definition of `Device_drivers'

init.o:(.data+0x3c): first defined here
../../../../../raspberrypi/lib/librtemscpu.a(dummy.o):(.data+0x6c): 
multiple definition of `Initialization_tasks'

init.o:(.data+0x6c): first defined here
../../../../../raspberrypi/lib/librtemscpu.a(dummy.o):(.bss+0x38): 
multiple definition of `rtems_malloc_dirty_helper'
init.o:/home/bison/RTEMS/code/c/src/../../testsuites/samples/hello/init.c:47: 
first defined here
../../../../../raspberrypi/lib/librtemscpu.a(dummy.o):(.rodata+0x74): 
multiple definition of `rtems_malloc_extend_handler'

init.o:(.rodata+0xc8): first defined here
../../../../../raspberrypi/lib/l

Re: MIPS Thread Local Storage Help Request

[Gedare Bloom]

On Mon, Apr 28, 2014 at 2:47 PM, Joel Sherrill
 wrote:
> Hi
>
> This is going to be interesting. MIPS TLS is broken because
> we don't have a trap handler for this. From GCC:
>
> ;; Thread-Local Storage
>
> ;; The TLS base pointer is accessed via "rdhwr $3, $29".  No current
> ;; MIPS architecture defines this register, and no current
> ;; implementation provides it; instead, any OS which supports TLS is
> ;; expected to trap and emulate this instruction.  rdhwr is part of the
> ;; MIPS 32r2 specification, but we use it on any architecture because
> ;; we expect it to be emulated.  Use .set to force the assembler to
> ;; accept it.
> ;;
> ;; We do not use a constraint to force the destination to be $3
> ;; because $3 can appear explicitly as a function return value.
> ;; If we leave the use of $3 implicit in the constraints until
> ;; reload, we may end up making a $3 return value live across
> ;; the instruction, leading to a spill failure when reloading it.
>
> This code from NetBSD appears to be the core part of the
> handler.
>
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/mips/mips/locore_mips3.S?only_with_tag=MAIN
>

Do you mean
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/mips/mips/mips_emul.c?rev=1.26&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
near case OP_RDHWR


> If someone can adapt this, then the MIPS will have working
> TLS.
>
> Thanks.
>
> --
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherr...@oarcorp.comOn-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available(256) 722-9985
>
> ___
> rtems-devel mailing list
> rtems-devel@rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel

Re: MIPS Thread Local Storage Help Request

[Joel Sherrill]

Gedare chatted me and said he didn't see the code in the
linked assembly for rdhwr. It wasn't obvious and I should
have added a bit of commentary.

Look for CPULOCAL. The comments in the CVS log are what
tie it to rdhwr and TLS.

There may be an outer wrapper for this. I don't know.

On 4/28/2014 1:47 PM, Joel Sherrill wrote:
> Hi
>
> This is going to be interesting. MIPS TLS is broken because
> we don't have a trap handler for this. From GCC:
>
> ;; Thread-Local Storage
>
> ;; The TLS base pointer is accessed via "rdhwr $3, $29".  No current
> ;; MIPS architecture defines this register, and no current
> ;; implementation provides it; instead, any OS which supports TLS is
> ;; expected to trap and emulate this instruction.  rdhwr is part of the
> ;; MIPS 32r2 specification, but we use it on any architecture because
> ;; we expect it to be emulated.  Use .set to force the assembler to
> ;; accept it.
> ;;
> ;; We do not use a constraint to force the destination to be $3
> ;; because $3 can appear explicitly as a function return value.
> ;; If we leave the use of $3 implicit in the constraints until
> ;; reload, we may end up making a $3 return value live across
> ;; the instruction, leading to a spill failure when reloading it.
>
> This code from NetBSD appears to be the core part of the
> handler.
>
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/mips/mips/locore_mips3.S?only_with_tag=MAIN
>
> If someone can adapt this, then the MIPS will have working
> TLS.
>
> Thanks.
>

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

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

MIPS Thread Local Storage Help Request

[Joel Sherrill]

Hi

This is going to be interesting. MIPS TLS is broken because
we don't have a trap handler for this. From GCC:

;; Thread-Local Storage

;; The TLS base pointer is accessed via "rdhwr $3, $29".  No current
;; MIPS architecture defines this register, and no current
;; implementation provides it; instead, any OS which supports TLS is
;; expected to trap and emulate this instruction.  rdhwr is part of the
;; MIPS 32r2 specification, but we use it on any architecture because
;; we expect it to be emulated.  Use .set to force the assembler to
;; accept it.
;;
;; We do not use a constraint to force the destination to be $3
;; because $3 can appear explicitly as a function return value.
;; If we leave the use of $3 implicit in the constraints until
;; reload, we may end up making a $3 return value live across
;; the instruction, leading to a spill failure when reloading it.

This code from NetBSD appears to be the core part of the
handler.

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/mips/mips/locore_mips3.S?only_with_tag=MAIN

If someone can adapt this, then the MIPS will have working
TLS.

Thanks.

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

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

Re: Possible bug at newlib/libc/rtems/sys/crt0.c sigfillset

[Hesham Moustafa]

On Mon, Apr 28, 2014 at 6:32 PM, Joel Sherrill
 wrote:
>
> On 4/28/2014 11:25 AM, Hesham Moustafa wrote:
>> Thanks! These patches really help. I've already reverted back to the
>> original read/write prototypes after defining __rtems__ and it works.
>> Now newlib works normally (with the non-GPL patch you provided before
>> and my modifications). The only issues I have to make some workarounds
>> for are related to some POSIX macros. i.e,
>>
>> NAME_MAX (at newlib/libc/sys/rtems/sys/dirent.h)
>> PATH_MAX (at newlib/libc/posix/collate.c)
>>  _POSIX2_RE_DUP_MAX (at newlib/libc/posix/utils.h)
>>
>> I got undefined macro errors for these three macros, thus, I had to
>> add some #ifndef XXX statements earlier at the container files, to get
>> over there errors.
> I suspect that was for not having __rtems__ defined.  Revert them
> and try. I don't see NAME_MAX hacked on in my source so you
> must not have them committed.
>
> Also there are some header files in sys/rtems. If those are not the
> ones installed, then the build still has problems. But I suspect that
> is OK no
>
> I used the patch on your github and you got my diff.
>
> FYI all of the code in newlib/libc/machine/or1k is totally completely
> unacceptable to newlib from a license perspective.  It is GPL v3 and
> totally unacceptable to RTEMS as well.
>
Yes I got that. By "the patch you provided" I mean this one [1]. I no
longer use the patch on my github account anymore. Soon, I will submit
the new newlib patch for review and to discuss about it.

[1] http://www.doc.ic.ac.uk/~jab00/or32-newlib/newlib-patch
> And besides, two of the three files in there don't believe in libc
> at all. So we need a BSD-ish licensed setjmp/longjmp.
>>
>> On Mon, Apr 28, 2014 at 6:02 PM, Joel Sherrill
>>  wrote:
>>> Hi
>>>
>>> I am not sure I got everything fixed but it should be a lot
>>> better now. See the attached diffs.
>>>
>>> + libgcc - patterns were in the wrong order and or1k*-*-rtems*
>>>or1k*-*-* was before rtems stanza
>>> + config/or1k - moved elf.h to rtemself.h. There should be
>>>   a target OS independent config/or1k/elf.h
>>>   Also fixed or1k/rtemself.h so it defines CPP predefines
>>>   including __rtems__ which explains your compilation problem.
>>> + newlib/.../rtems/crt0 had wrong prototypes for write() and
>>>   read().
>>>
>>> These are diffs against the sources with your patches applied.
>>>
>>> Apply on top of yours.
>>>
>>> It is still building here after clobbering the tree and starting
>>> over so there may be more problems but this should be
>>> a good start. :)
>>>
>>> --joel
>>>
>>>
>>> On 4/27/2014 7:26 PM, Joel Sherrill wrote:
 This is a bug in your gcc port. You need to ensure that __rtems__ is 
 defined.

 See 
 https://github.com/heshamelmatary/or1k-rtems/blob/master/patches/gcc-4.8.2-or1k-rtems.diff
 around 220 and compare it to
 http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/arm/rtems-eabi.h;h=4bdcf0d87ba68940f338f4de3b41b9bd7a47260f;hb=HEAD

 That defines __rtems__. Without that, the .h files in newlib don't get the 
 right settings.
 
 From: rtems-devel-boun...@rtems.org [rtems-devel-boun...@rtems.org] On 
 Behalf Of Joel Sherrill [joel.sherr...@oarcorp.com]
 Sent: Sunday, April 27, 2014 7:17 PM
 To: Hesham Moustafa
 Cc: rtems-devel@rtems.org
 Subject: Re: Possible bug at newlib/libc/rtems/sys/crt0.c sigfillset

 On Apr 27, 2014 6:40 PM, Joel Sherrill  wrote:
> On Apr 27, 2014 5:12 PM, Hesham Moustafa  wrote:
>> Hi all,
>>
>> When I am trying to get newlib compiled while porting newlib to
>> rtems/or1k, I met an error that confused me. The error happens for me
>> with both: Ubuntu and Fedora. Also it arises when configuring and
>> building a standalone newlib library (with configure
>> --target=or1k-rtems4.11) or when building gcc with newlib (for the
>> same target). By commenting that line, newlib and gcc building process
>> works fine.
>>
>> The error is:
>>
>> "../../../../../../../gcc-4.8.2-or1k-rtems/newlib/libc/sys/rtems/crt0.c:74:37:
>> error: expected ‘)’ before ‘*’ token
>>  RTEMS_STUB(int, sigfillset(sigset_t *set), { return -1; })"
>>
>> By expanding the macros with -E option, I got the following expansion
>> for the corresponding function:
>>
>> int rtems_stub_sigfillset(sigset_t *set) { return -1; }; int
>> (*(sigset_t *set) = ~(0), 0) { return -1; }
>>
>> Does that make sense?
>>
>> I searched for anyone that happened to have the same problem and I
>> found this link [1] related to compiling rtems/newlib for microblaze
> This is a new architecture for RTEMS+newlib combination. I recall that 
> there is a configure script near the top of newlib and it needs an entry 
> for thus target. Or a pattern needs adjusting to distinguish or1k*-*-* 
> from the RTEMS variant.
 

*** PROFILING DONE XXX *** Message

[Jennifer Averett]

Tests now output a *** PROFILING DONE XXX *** message.
Should all *.scn files be changed to show this message,
so that automatic testing will work correctly?

--Jennifer
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel

Re: Possible bug at newlib/libc/rtems/sys/crt0.c sigfillset

[Joel Sherrill]

On 4/28/2014 11:25 AM, Hesham Moustafa wrote:
> Thanks! These patches really help. I've already reverted back to the
> original read/write prototypes after defining __rtems__ and it works.
> Now newlib works normally (with the non-GPL patch you provided before
> and my modifications). The only issues I have to make some workarounds
> for are related to some POSIX macros. i.e,
>
> NAME_MAX (at newlib/libc/sys/rtems/sys/dirent.h)
> PATH_MAX (at newlib/libc/posix/collate.c)
>  _POSIX2_RE_DUP_MAX (at newlib/libc/posix/utils.h)
>
> I got undefined macro errors for these three macros, thus, I had to
> add some #ifndef XXX statements earlier at the container files, to get
> over there errors.
I suspect that was for not having __rtems__ defined.  Revert them
and try. I don't see NAME_MAX hacked on in my source so you
must not have them committed.

Also there are some header files in sys/rtems. If those are not the
ones installed, then the build still has problems. But I suspect that
is OK no

I used the patch on your github and you got my diff.

FYI all of the code in newlib/libc/machine/or1k is totally completely
unacceptable to newlib from a license perspective.  It is GPL v3 and
totally unacceptable to RTEMS as well.

And besides, two of the three files in there don't believe in libc
at all. So we need a BSD-ish licensed setjmp/longjmp.
>
> On Mon, Apr 28, 2014 at 6:02 PM, Joel Sherrill
>  wrote:
>> Hi
>>
>> I am not sure I got everything fixed but it should be a lot
>> better now. See the attached diffs.
>>
>> + libgcc - patterns were in the wrong order and or1k*-*-rtems*
>>or1k*-*-* was before rtems stanza
>> + config/or1k - moved elf.h to rtemself.h. There should be
>>   a target OS independent config/or1k/elf.h
>>   Also fixed or1k/rtemself.h so it defines CPP predefines
>>   including __rtems__ which explains your compilation problem.
>> + newlib/.../rtems/crt0 had wrong prototypes for write() and
>>   read().
>>
>> These are diffs against the sources with your patches applied.
>>
>> Apply on top of yours.
>>
>> It is still building here after clobbering the tree and starting
>> over so there may be more problems but this should be
>> a good start. :)
>>
>> --joel
>>
>>
>> On 4/27/2014 7:26 PM, Joel Sherrill wrote:
>>> This is a bug in your gcc port. You need to ensure that __rtems__ is 
>>> defined.
>>>
>>> See 
>>> https://github.com/heshamelmatary/or1k-rtems/blob/master/patches/gcc-4.8.2-or1k-rtems.diff
>>> around 220 and compare it to
>>> http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/arm/rtems-eabi.h;h=4bdcf0d87ba68940f338f4de3b41b9bd7a47260f;hb=HEAD
>>>
>>> That defines __rtems__. Without that, the .h files in newlib don't get the 
>>> right settings.
>>> 
>>> From: rtems-devel-boun...@rtems.org [rtems-devel-boun...@rtems.org] On 
>>> Behalf Of Joel Sherrill [joel.sherr...@oarcorp.com]
>>> Sent: Sunday, April 27, 2014 7:17 PM
>>> To: Hesham Moustafa
>>> Cc: rtems-devel@rtems.org
>>> Subject: Re: Possible bug at newlib/libc/rtems/sys/crt0.c sigfillset
>>>
>>> On Apr 27, 2014 6:40 PM, Joel Sherrill  wrote:
 On Apr 27, 2014 5:12 PM, Hesham Moustafa  wrote:
> Hi all,
>
> When I am trying to get newlib compiled while porting newlib to
> rtems/or1k, I met an error that confused me. The error happens for me
> with both: Ubuntu and Fedora. Also it arises when configuring and
> building a standalone newlib library (with configure
> --target=or1k-rtems4.11) or when building gcc with newlib (for the
> same target). By commenting that line, newlib and gcc building process
> works fine.
>
> The error is:
>
> "../../../../../../../gcc-4.8.2-or1k-rtems/newlib/libc/sys/rtems/crt0.c:74:37:
> error: expected ‘)’ before ‘*’ token
>  RTEMS_STUB(int, sigfillset(sigset_t *set), { return -1; })"
>
> By expanding the macros with -E option, I got the following expansion
> for the corresponding function:
>
> int rtems_stub_sigfillset(sigset_t *set) { return -1; }; int
> (*(sigset_t *set) = ~(0), 0) { return -1; }
>
> Does that make sense?
>
> I searched for anyone that happened to have the same problem and I
> found this link [1] related to compiling rtems/newlib for microblaze
 This is a new architecture for RTEMS+newlib combination. I recall that 
 there is a configure script near the top of newlib and it needs an entry 
 for thus target. Or a pattern needs adjusting to distinguish or1k*-*-* 
 from the RTEMS variant.
>>> This can also be because the path through signal.h is skipping something 
>>> based on or1k.
>>>
>>> What source are you using as base to modify? I need to clone all your 
>>> source and try it myself.
>>>
> [1] http://sourceware.org/ml/newlib/2012/msg00529.html
>
> Regards,
> Hesham
>
> ___
> rtems-devel mailing list
> rtems-devel@rtems.org
> http://www.r

Re: Possible bug at newlib/libc/rtems/sys/crt0.c sigfillset

[Hesham Moustafa]

Thanks! These patches really help. I've already reverted back to the
original read/write prototypes after defining __rtems__ and it works.
Now newlib works normally (with the non-GPL patch you provided before
and my modifications). The only issues I have to make some workarounds
for are related to some POSIX macros. i.e,

NAME_MAX (at newlib/libc/sys/rtems/sys/dirent.h)
PATH_MAX (at newlib/libc/posix/collate.c)
 _POSIX2_RE_DUP_MAX (at newlib/libc/posix/utils.h)

I got undefined macro errors for these three macros, thus, I had to
add some #ifndef XXX statements earlier at the container files, to get
over there errors.


On Mon, Apr 28, 2014 at 6:02 PM, Joel Sherrill
 wrote:
> Hi
>
> I am not sure I got everything fixed but it should be a lot
> better now. See the attached diffs.
>
> + libgcc - patterns were in the wrong order and or1k*-*-rtems*
>or1k*-*-* was before rtems stanza
> + config/or1k - moved elf.h to rtemself.h. There should be
>   a target OS independent config/or1k/elf.h
>   Also fixed or1k/rtemself.h so it defines CPP predefines
>   including __rtems__ which explains your compilation problem.
> + newlib/.../rtems/crt0 had wrong prototypes for write() and
>   read().
>
> These are diffs against the sources with your patches applied.
>
> Apply on top of yours.
>
> It is still building here after clobbering the tree and starting
> over so there may be more problems but this should be
> a good start. :)
>
> --joel
>
>
> On 4/27/2014 7:26 PM, Joel Sherrill wrote:
>> This is a bug in your gcc port. You need to ensure that __rtems__ is defined.
>>
>> See 
>> https://github.com/heshamelmatary/or1k-rtems/blob/master/patches/gcc-4.8.2-or1k-rtems.diff
>> around 220 and compare it to
>> http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/arm/rtems-eabi.h;h=4bdcf0d87ba68940f338f4de3b41b9bd7a47260f;hb=HEAD
>>
>> That defines __rtems__. Without that, the .h files in newlib don't get the 
>> right settings.
>> 
>> From: rtems-devel-boun...@rtems.org [rtems-devel-boun...@rtems.org] On 
>> Behalf Of Joel Sherrill [joel.sherr...@oarcorp.com]
>> Sent: Sunday, April 27, 2014 7:17 PM
>> To: Hesham Moustafa
>> Cc: rtems-devel@rtems.org
>> Subject: Re: Possible bug at newlib/libc/rtems/sys/crt0.c sigfillset
>>
>> On Apr 27, 2014 6:40 PM, Joel Sherrill  wrote:
>>>
>>> On Apr 27, 2014 5:12 PM, Hesham Moustafa  wrote:
 Hi all,

 When I am trying to get newlib compiled while porting newlib to
 rtems/or1k, I met an error that confused me. The error happens for me
 with both: Ubuntu and Fedora. Also it arises when configuring and
 building a standalone newlib library (with configure
 --target=or1k-rtems4.11) or when building gcc with newlib (for the
 same target). By commenting that line, newlib and gcc building process
 works fine.

 The error is:

 "../../../../../../../gcc-4.8.2-or1k-rtems/newlib/libc/sys/rtems/crt0.c:74:37:
 error: expected ‘)’ before ‘*’ token
  RTEMS_STUB(int, sigfillset(sigset_t *set), { return -1; })"

 By expanding the macros with -E option, I got the following expansion
 for the corresponding function:

 int rtems_stub_sigfillset(sigset_t *set) { return -1; }; int
 (*(sigset_t *set) = ~(0), 0) { return -1; }

 Does that make sense?

 I searched for anyone that happened to have the same problem and I
 found this link [1] related to compiling rtems/newlib for microblaze
>>> This is a new architecture for RTEMS+newlib combination. I recall that 
>>> there is a configure script near the top of newlib and it needs an entry 
>>> for thus target. Or a pattern needs adjusting to distinguish or1k*-*-* from 
>>> the RTEMS variant.
>> This can also be because the path through signal.h is skipping something 
>> based on or1k.
>>
>> What source are you using as base to modify? I need to clone all your source 
>> and try it myself.
>>
 [1] http://sourceware.org/ml/newlib/2012/msg00529.html

 Regards,
 Hesham

 ___
 rtems-devel mailing list
 rtems-devel@rtems.org
 http://www.rtems.org/mailman/listinfo/rtems-devel
>
> --
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherr...@oarcorp.comOn-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available(256) 722-9985
>

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

Re: Possible bug at newlib/libc/rtems/sys/crt0.c sigfillset

[Joel Sherrill]

Hi

I am not sure I got everything fixed but it should be a lot
better now. See the attached diffs.

+ libgcc - patterns were in the wrong order and or1k*-*-rtems*
   or1k*-*-* was before rtems stanza
+ config/or1k - moved elf.h to rtemself.h. There should be
  a target OS independent config/or1k/elf.h
  Also fixed or1k/rtemself.h so it defines CPP predefines
  including __rtems__ which explains your compilation problem.
+ newlib/.../rtems/crt0 had wrong prototypes for write() and
  read().

These are diffs against the sources with your patches applied.

Apply on top of yours.

It is still building here after clobbering the tree and starting
over so there may be more problems but this should be
a good start. :)

--joel


On 4/27/2014 7:26 PM, Joel Sherrill wrote:
> This is a bug in your gcc port. You need to ensure that __rtems__ is defined.
>
> See 
> https://github.com/heshamelmatary/or1k-rtems/blob/master/patches/gcc-4.8.2-or1k-rtems.diff
> around 220 and compare it to 
> http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/arm/rtems-eabi.h;h=4bdcf0d87ba68940f338f4de3b41b9bd7a47260f;hb=HEAD
>
> That defines __rtems__. Without that, the .h files in newlib don't get the 
> right settings.
> 
> From: rtems-devel-boun...@rtems.org [rtems-devel-boun...@rtems.org] On Behalf 
> Of Joel Sherrill [joel.sherr...@oarcorp.com]
> Sent: Sunday, April 27, 2014 7:17 PM
> To: Hesham Moustafa
> Cc: rtems-devel@rtems.org
> Subject: Re: Possible bug at newlib/libc/rtems/sys/crt0.c sigfillset
>
> On Apr 27, 2014 6:40 PM, Joel Sherrill  wrote:
>>
>> On Apr 27, 2014 5:12 PM, Hesham Moustafa  wrote:
>>> Hi all,
>>>
>>> When I am trying to get newlib compiled while porting newlib to
>>> rtems/or1k, I met an error that confused me. The error happens for me
>>> with both: Ubuntu and Fedora. Also it arises when configuring and
>>> building a standalone newlib library (with configure
>>> --target=or1k-rtems4.11) or when building gcc with newlib (for the
>>> same target). By commenting that line, newlib and gcc building process
>>> works fine.
>>>
>>> The error is:
>>>
>>> "../../../../../../../gcc-4.8.2-or1k-rtems/newlib/libc/sys/rtems/crt0.c:74:37:
>>> error: expected ‘)’ before ‘*’ token
>>>  RTEMS_STUB(int, sigfillset(sigset_t *set), { return -1; })"
>>>
>>> By expanding the macros with -E option, I got the following expansion
>>> for the corresponding function:
>>>
>>> int rtems_stub_sigfillset(sigset_t *set) { return -1; }; int
>>> (*(sigset_t *set) = ~(0), 0) { return -1; }
>>>
>>> Does that make sense?
>>>
>>> I searched for anyone that happened to have the same problem and I
>>> found this link [1] related to compiling rtems/newlib for microblaze
>> This is a new architecture for RTEMS+newlib combination. I recall that there 
>> is a configure script near the top of newlib and it needs an entry for thus 
>> target. Or a pattern needs adjusting to distinguish or1k*-*-* from the RTEMS 
>> variant.
> This can also be because the path through signal.h is skipping something 
> based on or1k.
>
> What source are you using as base to modify? I need to clone all your source 
> and try it myself.
>
>>> [1] http://sourceware.org/ml/newlib/2012/msg00529.html
>>>
>>> Regards,
>>> Hesham
>>>
>>> ___
>>> rtems-devel mailing list
>>> rtems-devel@rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-devel

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

diff -uNr --exclude '*newlib*' gcc-4.8.2-orig/gcc/config/or1k/elf.h 
gcc-4.8.2/gcc/config/or1k/elf.h
--- gcc-4.8.2-orig/gcc/config/or1k/elf.h2014-04-28 10:45:18.320114849 
-0500
+++ gcc-4.8.2/gcc/config/or1k/elf.h 1969-12-31 18:00:00.0 -0600
@@ -1,31 +0,0 @@
-/* Definitions for rtems targeting an OpenRisc OR1K using COFF
-   ??? this is for OR1K, but the rest of the above seems bogus.
-   Copyright (C) 1996, 1997, 2005 Free Software Foundation, Inc.
-   Contributed by Joel Sherrill (j...@oarcorp.com).
-
-This file is part of GNU CC.
-
-GNU CC is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2, or (at your option)
-any later version.
-
-GNU CC is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with GNU CC; see the file COPYING.  If not, write to
-the Free Software Foundation, 59 Temple Place - Suite 330,
-Boston, MA 02111-1307, USA.  */
-
-/* Use ELF */
-#undef  OBJECT_FORMAT_ELF
-#define OBJECT_FORMAT_ELF
-
-/* or1k debug info suppor

Re: Possible bug at newlib/libc/rtems/sys/crt0.c sigfillset

[Hesham Moustafa]

On Mon, Apr 28, 2014 at 2:26 AM, Joel Sherrill
 wrote:
> This is a bug in your gcc port. You need to ensure that __rtems__ is defined.
>
> See 
> https://github.com/heshamelmatary/or1k-rtems/blob/master/patches/gcc-4.8.2-or1k-rtems.diff
> around 220 and compare it to
> http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/arm/rtems-eabi.h;h=4bdcf0d87ba68940f338f4de3b41b9bd7a47260f;hb=HEAD
>
> That defines __rtems__. Without that, the .h files in newlib don't get the 
> right settings.
Thanks, that solved the problem. Now both gcc/newlib are build successfully.
> 
> From: rtems-devel-boun...@rtems.org [rtems-devel-boun...@rtems.org] On Behalf 
> Of Joel Sherrill [joel.sherr...@oarcorp.com]
> Sent: Sunday, April 27, 2014 7:17 PM
> To: Hesham Moustafa
> Cc: rtems-devel@rtems.org
> Subject: Re: Possible bug at newlib/libc/rtems/sys/crt0.c sigfillset
>
> On Apr 27, 2014 6:40 PM, Joel Sherrill  wrote:
>>
>>
>> On Apr 27, 2014 5:12 PM, Hesham Moustafa  wrote:
>> >
>> > Hi all,
>> >
>> > When I am trying to get newlib compiled while porting newlib to
>> > rtems/or1k, I met an error that confused me. The error happens for me
>> > with both: Ubuntu and Fedora. Also it arises when configuring and
>> > building a standalone newlib library (with configure
>> > --target=or1k-rtems4.11) or when building gcc with newlib (for the
>> > same target). By commenting that line, newlib and gcc building process
>> > works fine.
>> >
>> > The error is:
>> >
>> > "../../../../../../../gcc-4.8.2-or1k-rtems/newlib/libc/sys/rtems/crt0.c:74:37:
>> > error: expected ‘)’ before ‘*’ token
>> >  RTEMS_STUB(int, sigfillset(sigset_t *set), { return -1; })"
>> >
>> > By expanding the macros with -E option, I got the following expansion
>> > for the corresponding function:
>> >
>> > int rtems_stub_sigfillset(sigset_t *set) { return -1; }; int
>> > (*(sigset_t *set) = ~(0), 0) { return -1; }
>> >
>> > Does that make sense?
>> >
>> > I searched for anyone that happened to have the same problem and I
>> > found this link [1] related to compiling rtems/newlib for microblaze
>>
>> This is a new architecture for RTEMS+newlib combination. I recall that there 
>> is a configure script near the top of newlib and it needs an entry for thus 
>> target. Or a pattern needs adjusting to distinguish or1k*-*-* from the RTEMS 
>> variant.
>
> This can also be because the path through signal.h is skipping something 
> based on or1k.
>
> What source are you using as base to modify? I need to clone all your source 
> and try it myself.
>
>> > [1] http://sourceware.org/ml/newlib/2012/msg00529.html
>> >
>> > Regards,
>> > Hesham
>> >
>> > ___
>> > rtems-devel mailing list
>> > rtems-devel@rtems.org
>> > http://www.rtems.org/mailman/listinfo/rtems-devel

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

Re: Possible bug at newlib/libc/rtems/sys/crt0.c sigfillset

[Hesham Moustafa]

On Mon, Apr 28, 2014 at 2:26 AM, Joel Sherrill
 wrote:
> This is a bug in your gcc port. You need to ensure that __rtems__ is defined.
>
> See 
> https://github.com/heshamelmatary/or1k-rtems/blob/master/patches/gcc-4.8.2-or1k-rtems.diff
> around 220 and compare it to
> http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/arm/rtems-eabi.h;h=4bdcf0d87ba68940f338f4de3b41b9bd7a47260f;hb=HEAD
>
> That defines __rtems__. Without that, the .h files in newlib don't get the 
> right settings.
> 
> From: rtems-devel-boun...@rtems.org [rtems-devel-boun...@rtems.org] On Behalf 
> Of Joel Sherrill [joel.sherr...@oarcorp.com]
> Sent: Sunday, April 27, 2014 7:17 PM
> To: Hesham Moustafa
> Cc: rtems-devel@rtems.org
> Subject: Re: Possible bug at newlib/libc/rtems/sys/crt0.c sigfillset
>
> On Apr 27, 2014 6:40 PM, Joel Sherrill  wrote:
>>
>>
>> On Apr 27, 2014 5:12 PM, Hesham Moustafa  wrote:
>> >
>> > Hi all,
>> >
>> > When I am trying to get newlib compiled while porting newlib to
>> > rtems/or1k, I met an error that confused me. The error happens for me
>> > with both: Ubuntu and Fedora. Also it arises when configuring and
>> > building a standalone newlib library (with configure
>> > --target=or1k-rtems4.11) or when building gcc with newlib (for the
>> > same target). By commenting that line, newlib and gcc building process
>> > works fine.
>> >
>> > The error is:
>> >
>> > "../../../../../../../gcc-4.8.2-or1k-rtems/newlib/libc/sys/rtems/crt0.c:74:37:
>> > error: expected ‘)’ before ‘*’ token
>> >  RTEMS_STUB(int, sigfillset(sigset_t *set), { return -1; })"
>> >
>> > By expanding the macros with -E option, I got the following expansion
>> > for the corresponding function:
>> >
>> > int rtems_stub_sigfillset(sigset_t *set) { return -1; }; int
>> > (*(sigset_t *set) = ~(0), 0) { return -1; }
>> >
>> > Does that make sense?
>> >
>> > I searched for anyone that happened to have the same problem and I
>> > found this link [1] related to compiling rtems/newlib for microblaze
>>
>> This is a new architecture for RTEMS+newlib combination. I recall that there 
>> is a configure script near the top of newlib and it needs an entry for thus 
>> target. Or a pattern needs adjusting to distinguish or1k*-*-* from the RTEMS 
>> variant.
>
> This can also be because the path through signal.h is skipping something 
> based on or1k.
>
> What source are you using as base to modify? I need to clone all your source 
> and try it myself.
>
>> > [1] http://sourceware.org/ml/newlib/2012/msg00529.html
>> >
>> > Regards,
>> > Hesham
>> >
>> > ___
>> > rtems-devel mailing list
>> > rtems-devel@rtems.org
>> > http://www.rtems.org/mailman/listinfo/rtems-devel

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

Re: [GSOC] RPi BSP RTEMS

[Joel Sherrill]

On 4/28/2014 10:01 AM, Ben Gras wrote:
> All,
>
> FWIW to anyone interested in working on the RPi BSP, I noticed the
> logic in irq.c is suspect; these tests:
>
>   if (BCM2835_REG(BCM2835_IRQ_BASIC) && 0x1)
>
> ..
>
>   else if ( BCM2835_REG(BCM2835_IRQ_BASIC) &&
> BCM2835_BIT(19))
>
> presumably intended to use bitwise ANDs. Assuming the current RPi BSP
> is your starting point, that is hopefully a little shortcut I can
> contribute.
>
Good catch Ben! Those are easy to create and overlook but hard to debug.

--joel
>
>
>
> On Mon, Apr 28, 2014 at 4:34 PM, Alan Cudmore  > wrote:
>
>
>
> On Fri, Apr 25, 2014 at 6:07 PM, Andre Marques
>  > wrote:
>
> I'm taking this conversation to the list.
>
>
> Sorry, I didn't realize that I did not reply to the list.
>  
>
> On 04/23/14 01:21, Alan Cudmore wrote:
>>
>>
>>
>> On Tue, Apr 22, 2014 at 6:09 AM, Andre Marques
>> > > wrote:
>>
>> Hello,
>>
>> I am very pleased to have the opportunity to participate
>> in GSoC with the RTEMS project!
>>
>>
>> Welcome! We are glad to have you helping RTEMS.  
>>
>>
>> Now, I have some questions:
>>
>> 1. Does anyone have any recommendation on the proposal?
>>
>>
>> I like the proposal, but there are a couple of things that
>> may change slightly:
>> 1. You may want to look into making the UART driver work in
>> interrupt driven mode, as it is currently polled.
>
> I will have a look at it.
>
>
>>  
>> 2. For the Framebuffer support, I have been talking to
>> someone off list that is making progress on implementing a
>> framebuffer driver. We may want to collaborate with this
>> person for the framebuffer. 
>>  
>
> Certainly. I was scheduling the framebuffer work for July,
> should that be re-scheduled?
>
>
> July may still work. This gives us time to see what gets
> accomplished and the work can be integrating it into the RTEMS
> tree and testing. 
>
>  
>
>
>>
>> 2. Is there any interesting documentation or code you
>> think I should be looking at right now? For the past
>> month I have been studying the RPi BSP code and the RPi
>> architecture for the emmc driver that I am doing for my
>> final project at the university.
>>
>> From what I can see, you are off to a very good start!
>>  
>>
>> 3. There is no wiki page for the Raspberry Pi BSP (at
>> least I have not found any yet). May I create one using
>> the Open Project template and link it in the Open
>> Projects page under the BSP section?
>>
>>
>> I did not create one, so please do.
>>  
>>
>>
>> 4. I will create a dedicated development blog for the
>> project very soon. How frequently should it be updated
>> until may 19?
>>
>> 5. How should the communication happen? Also I am not
>> sure if the Amar Takhar and Muhammad Adnan e-mails are
>> the correct ones.
>>
>> I will also be setting a github repository for this, and
>> I am also looking to get my own RPi and some peripherals
>> (I have one at the university right now).
>>
>>
>> I have been setting up my Pi for RTEMS development again. I
>> recently built u-boot and I am going to try to get it to boot
>> RTEMS images from a TFTP server. This may help speed up
>> development. 
>>
>> I am also trying out a FT2232H MiniMod evaluation board that
>> is supposed to work with the Raspberry Pi JTAG interface and
>> the OpenOCD project. It also serves as the USB uart
>> connector. I have it all wired up and I hope to try getting
>> it to talk to OpenOCD soon. If I get it working, I will
>> document everything. The FT2232H Minimod board was $20 USD. 
>>
>
> Nice. Looking forward to that, as I still need to look at the
> debugging part of the development.
>
>
> The FT2232H MiniMod is working so far! I am able to use the UART
> and at the same time load and run images over the JTAG interface
> using OpenOCD. Next, I plan on trying GDB. I will try to document
> the setup soon, but it just requires ~10 jumper wires to connect
> the MiniMod to the Pi GPIO header. 
>
> I need to use it, because I discovered that the RKI image no
> longer runs on the Pi. The samples such as ticker still work, so
> I'm sure it is a problem with the RKI code itself. 
>  
>
>
> Meanwhile I have set up a development blog and a google
> calendar for the project:
>
> http://asuolgsoc2014.wordpress.com/
>
>

Re: [GSOC] RPi BSP RTEMS

[Ben Gras]

All,

FWIW to anyone interested in working on the RPi BSP, I noticed the logic in
irq.c is suspect; these tests:

  if (BCM2835_REG(BCM2835_IRQ_BASIC) && 0x1)

..

  else if ( BCM2835_REG(BCM2835_IRQ_BASIC) &&
BCM2835_BIT(19))

presumably intended to use bitwise ANDs. Assuming the current RPi BSP is
your starting point, that is hopefully a little shortcut I can contribute.




On Mon, Apr 28, 2014 at 4:34 PM, Alan Cudmore wrote:

>
>
> On Fri, Apr 25, 2014 at 6:07 PM, Andre Marques <
> andre.lousa.marq...@gmail.com> wrote:
>
>>  I'm taking this conversation to the list.
>>
>>
>> Sorry, I didn't realize that I did not reply to the list.
>
>
>>  On 04/23/14 01:21, Alan Cudmore wrote:
>>
>>
>>
>>
>> On Tue, Apr 22, 2014 at 6:09 AM, Andre Marques <
>> andre.lousa.marq...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I am very pleased to have the opportunity to participate in GSoC with
>>> the RTEMS project!
>>>
>>
>>  Welcome! We are glad to have you helping RTEMS.
>>
>>>
>>> Now, I have some questions:
>>>
>>> 1. Does anyone have any recommendation on the proposal?
>>>
>>
>>  I like the proposal, but there are a couple of things that may change
>> slightly:
>> 1. You may want to look into making the UART driver work in interrupt
>> driven mode, as it is currently polled.
>>
>>
>> I will have a look at it.
>>
>>
>>
>> 2. For the Framebuffer support, I have been talking to someone off list
>> that is making progress on implementing a framebuffer driver. We may want
>> to collaborate with this person for the framebuffer.
>>
>>
>>
>> Certainly. I was scheduling the framebuffer work for July, should that be
>> re-scheduled?
>>
>
> July may still work. This gives us time to see what gets accomplished and
> the work can be integrating it into the RTEMS tree and testing.
>
>
>
>>
>>
>>> 2. Is there any interesting documentation or code you think I should be
>>> looking at right now? For the past month I have been studying the RPi BSP
>>> code and the RPi architecture for the emmc driver that I am doing for my
>>> final project at the university.
>>>
>>>  From what I can see, you are off to a very good start!
>>
>>
>>> 3. There is no wiki page for the Raspberry Pi BSP (at least I have not
>>> found any yet). May I create one using the Open Project template and link
>>> it in the Open Projects page under the BSP section?
>>>
>>
>>  I did not create one, so please do.
>>
>>
>>>
>>> 4. I will create a dedicated development blog for the project very soon.
>>> How frequently should it be updated until may 19?
>>>
>>> 5. How should the communication happen? Also I am not sure if the Amar
>>> Takhar and Muhammad Adnan e-mails are the correct ones.
>>>
>>> I will also be setting a github repository for this, and I am also
>>> looking to get my own RPi and some peripherals (I have one at the
>>> university right now).
>>>
>>
>>  I have been setting up my Pi for RTEMS development again. I recently
>> built u-boot and I am going to try to get it to boot RTEMS images from a
>> TFTP server. This may help speed up development.
>>
>>  I am also trying out a FT2232H MiniMod evaluation board that is
>> supposed to work with the Raspberry Pi JTAG interface and the OpenOCD
>> project. It also serves as the USB uart connector. I have it all wired up
>> and I hope to try getting it to talk to OpenOCD soon. If I get it working,
>> I will document everything. The FT2232H Minimod board was $20 USD.
>>
>>
>> Nice. Looking forward to that, as I still need to look at the debugging
>> part of the development.
>>
>
> The FT2232H MiniMod is working so far! I am able to use the UART and at
> the same time load and run images over the JTAG interface using OpenOCD.
> Next, I plan on trying GDB. I will try to document the setup soon, but it
> just requires ~10 jumper wires to connect the MiniMod to the Pi GPIO
> header.
>
> I need to use it, because I discovered that the RKI image no longer runs
> on the Pi. The samples such as ticker still work, so I'm sure it is a
> problem with the RKI code itself.
>
>
>>
>> Meanwhile I have set up a development blog and a google calendar for the
>> project:
>>
>> http://asuolgsoc2014.wordpress.com/
>>
>>
>> https://www.google.com/calendar/embed?src=mo5guprvls0ip24rnrjio4ogks%40group.calendar.google.com&ctz=Europe/Lisbon
>>
>> I will try to come up with more news during the weekend.
>>
>>
> Looks good.
>
> Alan
>
>
>
>>
>>   Alan
>>
>>
>>
>>>
>>> Thank you,
>>> André Marques.
>>>
>>
>>
>>
>
> ___
> rtems-devel mailing list
> rtems-devel@rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>
>
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel

Re: [GSOC] RPi BSP RTEMS

[Alan Cudmore]

On Fri, Apr 25, 2014 at 6:07 PM, Andre Marques <
andre.lousa.marq...@gmail.com> wrote:

>  I'm taking this conversation to the list.
>
>
> Sorry, I didn't realize that I did not reply to the list.


> On 04/23/14 01:21, Alan Cudmore wrote:
>
>
>
>
> On Tue, Apr 22, 2014 at 6:09 AM, Andre Marques <
> andre.lousa.marq...@gmail.com> wrote:
>
>> Hello,
>>
>> I am very pleased to have the opportunity to participate in GSoC with the
>> RTEMS project!
>>
>
>  Welcome! We are glad to have you helping RTEMS.
>
>>
>> Now, I have some questions:
>>
>> 1. Does anyone have any recommendation on the proposal?
>>
>
>  I like the proposal, but there are a couple of things that may change
> slightly:
> 1. You may want to look into making the UART driver work in interrupt
> driven mode, as it is currently polled.
>
>
> I will have a look at it.
>
>
>
> 2. For the Framebuffer support, I have been talking to someone off list
> that is making progress on implementing a framebuffer driver. We may want
> to collaborate with this person for the framebuffer.
>
>
>
> Certainly. I was scheduling the framebuffer work for July, should that be
> re-scheduled?
>

July may still work. This gives us time to see what gets accomplished and
the work can be integrating it into the RTEMS tree and testing.



>
>
>> 2. Is there any interesting documentation or code you think I should be
>> looking at right now? For the past month I have been studying the RPi BSP
>> code and the RPi architecture for the emmc driver that I am doing for my
>> final project at the university.
>>
>>  From what I can see, you are off to a very good start!
>
>
>> 3. There is no wiki page for the Raspberry Pi BSP (at least I have not
>> found any yet). May I create one using the Open Project template and link
>> it in the Open Projects page under the BSP section?
>>
>
>  I did not create one, so please do.
>
>
>>
>> 4. I will create a dedicated development blog for the project very soon.
>> How frequently should it be updated until may 19?
>>
>> 5. How should the communication happen? Also I am not sure if the Amar
>> Takhar and Muhammad Adnan e-mails are the correct ones.
>>
>> I will also be setting a github repository for this, and I am also
>> looking to get my own RPi and some peripherals (I have one at the
>> university right now).
>>
>
>  I have been setting up my Pi for RTEMS development again. I recently
> built u-boot and I am going to try to get it to boot RTEMS images from a
> TFTP server. This may help speed up development.
>
>  I am also trying out a FT2232H MiniMod evaluation board that is supposed
> to work with the Raspberry Pi JTAG interface and the OpenOCD project. It
> also serves as the USB uart connector. I have it all wired up and I hope to
> try getting it to talk to OpenOCD soon. If I get it working, I will
> document everything. The FT2232H Minimod board was $20 USD.
>
>
> Nice. Looking forward to that, as I still need to look at the debugging
> part of the development.
>

The FT2232H MiniMod is working so far! I am able to use the UART and at the
same time load and run images over the JTAG interface using OpenOCD. Next,
I plan on trying GDB. I will try to document the setup soon, but it just
requires ~10 jumper wires to connect the MiniMod to the Pi GPIO header.

I need to use it, because I discovered that the RKI image no longer runs on
the Pi. The samples such as ticker still work, so I'm sure it is a problem
with the RKI code itself.


>
> Meanwhile I have set up a development blog and a google calendar for the
> project:
>
> http://asuolgsoc2014.wordpress.com/
>
>
> https://www.google.com/calendar/embed?src=mo5guprvls0ip24rnrjio4ogks%40group.calendar.google.com&ctz=Europe/Lisbon
>
> I will try to come up with more news during the weekend.
>
>
Looks good.

Alan



>
>   Alan
>
>
>
>>
>> Thank you,
>> André Marques.
>>
>
>
>
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel

Re: BSP question: nested interrupts?

[Ben Gras]

Great, thanks. Then I know the bsp is on the right track in that regard.
Thanks for your help.
 On Apr 28, 2014 2:53 PM, "Sebastian Huber" <
sebastian.hu...@embedded-brains.de> wrote:

> On 2014-04-28 14:43, Ben Gras wrote:
>
>> Ok, so the same interrupt will never nest itself then?
>>
>
> Yes, this is normally how it works.  Otherwise you may end up in infinite
> recursion.
>
> --
> 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.
>
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel

Re: BSP question: nested interrupts?

[Sebastian Huber]

On 2014-04-28 14:43, Ben Gras wrote:

Ok, so the same interrupt will never nest itself then?


Yes, this is normally how it works.  Otherwise you may end up in infinite 
recursion.


--
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.
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel

Re: BSP question: nested interrupts?

[Ben Gras]

Ok, so the same interrupt will never nest itself then?

Good, thanks!


On Mon, Apr 28, 2014 at 2:14 PM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 2014-04-28 13:32, Ben Gras wrote:
>
>> Dear all,
>>
>> I have a question about managing interrupts in a BSP that I have not been
>> able
>> to answer satisfactorily by looking at other BSP code, nor looking
>> throught the
>> documentation or googling. Or asking on the IRC channel :)
>>
>> My question is: are BSPs expected to allow nested interrupts?
>> Specifically,
>> must bsp_interrupt_dispatch() turn interrupts on before calling
>> bsp_interrupt_handler_dispatch for everything else to work properly?
>>
>
> If you want nested interrupts, then you can do it like this BSP:
>
> http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/
> lpc24xx/irq/irq-dispatch.c
>
>
>
>> Some BSPs do this, some don't. In the Beagle BSP I can do this by masking
>> the
>> currently active interrupt and then enabling them at the CPU level; but
>> enabling all interrupts before the hw-specific handler is called won't
>> deassert
>> the irq at the peripheral so I'm having trouble seeing how that should
>> work.
>>
>
> This is the job of the interrupt controller.  It must block interrupts of
> lower or equal priority.
>
>
>> Example: if we are in a timer ISR and loop on polling the uptime ticks,
>> do we
>> expect the ticks to be able to increase? I'm wondering if any of the
>> remaining
>> failing tests are due to this. But also what the best shape of a BSP is.
>>
>> Thanks!
>>
>>
>> ___
>> rtems-devel mailing list
>> rtems-devel@rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>
>>
>
> --
> 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.
> ___
> rtems-devel mailing list
> rtems-devel@rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel

Re: BSP question: nested interrupts?

[Sebastian Huber]

On 2014-04-28 13:32, Ben Gras wrote:

Dear all,

I have a question about managing interrupts in a BSP that I have not been able
to answer satisfactorily by looking at other BSP code, nor looking throught the
documentation or googling. Or asking on the IRC channel :)

My question is: are BSPs expected to allow nested interrupts? Specifically,
must bsp_interrupt_dispatch() turn interrupts on before calling
bsp_interrupt_handler_dispatch for everything else to work properly?


If you want nested interrupts, then you can do it like this BSP:

http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/lpc24xx/irq/irq-dispatch.c



Some BSPs do this, some don't. In the Beagle BSP I can do this by masking the
currently active interrupt and then enabling them at the CPU level; but
enabling all interrupts before the hw-specific handler is called won't deassert
the irq at the peripheral so I'm having trouble seeing how that should work.


This is the job of the interrupt controller.  It must block interrupts of lower 
or equal priority.




Example: if we are in a timer ISR and loop on polling the uptime ticks, do we
expect the ticks to be able to increase? I'm wondering if any of the remaining
failing tests are due to this. But also what the best shape of a BSP is.

Thanks!


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




--
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.
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel

BSP question: nested interrupts?

[Ben Gras]

Dear all,

I have a question about managing interrupts in a BSP that I have not been
able to answer satisfactorily by looking at other BSP code, nor looking
throught the documentation or googling. Or asking on the IRC channel :)

My question is: are BSPs expected to allow nested interrupts? Specifically,
must bsp_interrupt_dispatch() turn interrupts on before calling
bsp_interrupt_handler_dispatch for everything else to work properly?

Some BSPs do this, some don't. In the Beagle BSP I can do this by masking
the currently active interrupt and then enabling them at the CPU level; but
enabling all interrupts before the hw-specific handler is called won't
deassert the irq at the peripheral so I'm having trouble seeing how that
should work.

Example: if we are in a timer ISR and loop on polling the uptime ticks, do
we expect the ticks to be able to increase? I'm wondering if any of the
remaining failing tests are due to this. But also what the best shape of a
BSP is.

Thanks!
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel

[PATCH] score: Statically initialize _ISR_Vector_table

[Sebastian Huber]

---
 c/src/lib/libbsp/mips/malta/irq/maxvectors.c  |3 +-
 c/src/lib/libbsp/mips/shared/irq/maxvectors.c |2 +-
 cpukit/sapi/include/confdefs.h|   28 -
 cpukit/score/cpu/mips/rtems/score/cpu.h   |8 +++--
 cpukit/score/cpu/nios2/Makefile.am|1 -
 cpukit/score/cpu/nios2/nios2-initialize-vectors.c |   25 --
 cpukit/score/cpu/nios2/rtems/score/cpu.h  |2 +-
 cpukit/score/cpu/no_cpu/rtems/score/cpu.h |   17 
 cpukit/score/include/rtems/score/isr.h|   14 +-
 cpukit/score/src/isr.c|   12 ++---
 testsuites/sptests/spfatal07/testcase.h   |4 ---
 testsuites/sptests/spintr_err01/init.c|2 +-
 12 files changed, 29 insertions(+), 89 deletions(-)
 delete mode 100644 cpukit/score/cpu/nios2/nios2-initialize-vectors.c

diff --git a/c/src/lib/libbsp/mips/malta/irq/maxvectors.c 
b/c/src/lib/libbsp/mips/malta/irq/maxvectors.c
index c17583e..f2aee55 100644
--- a/c/src/lib/libbsp/mips/malta/irq/maxvectors.c
+++ b/c/src/lib/libbsp/mips/malta/irq/maxvectors.c
@@ -20,5 +20,4 @@
 
 #include 
 
-unsigned int mips_interrupt_number_of_vectors = 13;
-
+uint32_t _MIPS_Interrupt_maximum_vector_number = 12;
diff --git a/c/src/lib/libbsp/mips/shared/irq/maxvectors.c 
b/c/src/lib/libbsp/mips/shared/irq/maxvectors.c
index 273253b..80f7f02 100644
--- a/c/src/lib/libbsp/mips/shared/irq/maxvectors.c
+++ b/c/src/lib/libbsp/mips/shared/irq/maxvectors.c
@@ -17,4 +17,4 @@
 #include 
 #include 
 
-unsigned int mips_interrupt_number_of_vectors = BSP_INTERRUPT_VECTOR_MAX;
+uint32_t _MIPS_Interrupt_maximum_vector_number = BSP_INTERRUPT_VECTOR_MAX;
diff --git a/cpukit/sapi/include/confdefs.h b/cpukit/sapi/include/confdefs.h
index 69c74f7..0dc9137 100644
--- a/cpukit/sapi/include/confdefs.h
+++ b/cpukit/sapi/include/confdefs.h
@@ -2245,31 +2245,6 @@ const rtems_libio_helper rtems_fs_init_helper =
 #endif
 
 /**
- * On architectures that use Simple Vectored Interrupts, it is RTEMS
- * responsibility to allocate the vector table.  This avoids reserving
- * the memory on architectures that use the Programmable Interrupt
- * Controller Vectored Interrupts.
- */
-#if (CPU_SIMPLE_VECTORED_INTERRUPTS == TRUE)
-  /*
-   *  This is a (hopefully) temporary hack.  On the mips, the number of
-   *  vectors is NOT statically defined.  But it has to be statically
-   *  defined for this to work.  This is an issue looking for a nice
-   *  solution.
-   */
-  #if defined(__mips__)
-#define CONFIGURE_INTERRUPT_VECTOR_TABLE \
-  _Configure_From_workspace( (sizeof(ISR_Handler_entry) * 256))
-  #else
-#define CONFIGURE_INTERRUPT_VECTOR_TABLE \
-  _Configure_From_workspace( \
-(sizeof(ISR_Handler_entry) * ISR_NUMBER_OF_VECTORS))
-  #endif
-#else
-  #define CONFIGURE_INTERRUPT_VECTOR_TABLE 0
-#endif
-
-/**
  * RTEMS uses two instance of an internal mutex class.  This accounts
  * for these mutexes.
  */
@@ -2298,7 +2273,6 @@ const rtems_libio_helper rtems_fs_init_helper =
  */
 #define CONFIGURE_MEMORY_FOR_SYSTEM_OVERHEAD \
   ( CONFIGURE_MEMORY_FOR_IDLE_TASK +/* IDLE and stack */ \
-CONFIGURE_INTERRUPT_VECTOR_TABLE + /* interrupt vectors */ \
 CONFIGURE_INTERRUPT_STACK_MEMORY + /* interrupt stack */ \
 CONFIGURE_API_MUTEX_MEMORY /* allocation mutex */ \
   )
@@ -2716,7 +2690,6 @@ const rtems_libio_helper rtems_fs_init_helper =
 uint32_t POSIX;
 
 /* System overhead pieces */
-uint32_t INTERRUPT_VECTOR_TABLE;
 uint32_t INTERRUPT_STACK_MEMORY;
 uint32_t MEMORY_FOR_IDLE_TASK;
 
@@ -2771,7 +2744,6 @@ const rtems_libio_helper rtems_fs_init_helper =
 CONFIGURE_MEMORY_FOR_POSIX,
 
 /* System overhead pieces */
-CONFIGURE_INTERRUPT_VECTOR_TABLE,
 CONFIGURE_INTERRUPT_STACK_MEMORY,
 CONFIGURE_MEMORY_FOR_IDLE_TASK,
 
diff --git a/cpukit/score/cpu/mips/rtems/score/cpu.h 
b/cpukit/score/cpu/mips/rtems/score/cpu.h
index b871969..42c5508 100644
--- a/cpukit/score/cpu/mips/rtems/score/cpu.h
+++ b/cpukit/score/cpu/mips/rtems/score/cpu.h
@@ -664,9 +664,11 @@ SCORE_EXTERN Context_Control_fp  _CPU_Null_fp_context;
  *  by RTEMS.
  */
 
-extern unsigned int mips_interrupt_number_of_vectors;
-#define CPU_INTERRUPT_NUMBER_OF_VECTORS  (mips_interrupt_number_of_vectors)
-#define CPU_INTERRUPT_MAXIMUM_VECTOR_NUMBER  (CPU_INTERRUPT_NUMBER_OF_VECTORS 
- 1)
+#define CPU_INTERRUPT_NUMBER_OF_VECTORS  256
+
+extern uint32_t _MIPS_Interrupt_maximum_vector_number;
+
+#define CPU_INTERRUPT_MAXIMUM_VECTOR_NUMBER  
_MIPS_Interrupt_maximum_vector_number
 
 /*
  *  Should be large enough to run all RTEMS tests.  This ensures
diff --git a/cpukit/score/cpu/nios2/Makefile.am 
b/cpukit/score/cpu/nios2/Makefile.am
index 62286cd..6004467 100644
--- a/cpukit/score/cpu/nios2/Makefile.am
+++ b/cpukit/score/cpu/nios2/Makefile.am
@@ -33,7 +33,6 @@ libscorecpu_a_SOURCES += ni