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;
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 brain
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
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
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
co
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
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 th
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
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 Oirscho
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
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
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
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 headin
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 v
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
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
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
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; i
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 pa
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/listi
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 iss
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
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/e
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
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
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
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 i
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 <
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, thi
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 4
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 bee
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 expec
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? Specifi
---
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/Makef
34 matches
Mail list logo
