Absent answer means no.
I had the same idea. Actually I have played around with using vendor
libraries from TI and ST, and there is no problem compiling them in. I
can't see any reason CMSIS wouldn't fit in fine too. Actually from
memory the useful parts of CMSIS comprise two parts, ARM specif
On Fri, Aug 29, 2014 at 11:33 PM, Joel Sherrill
wrote:
> I will try to get to this soon. But it is a holiday weekend and tomorrow is
> my wife's birthday so I have priorities :)
>
Happy birthday to her :) I will try building on Ubuntu too which
almost does not know anything about this RTEMS/or1k
I will try to get to this soon. But it is a holiday weekend and tomorrow is my
wife's birthday so I have priorities :)
--Joel
On August 29, 2014 4:32:05 PM CDT, Hesham Moustafa
wrote:
>I have removed the entire or1k-rtems4.11-* and built a vanilla
>toolchain from latest RSB. Then I cloned late
I have removed the entire or1k-rtems4.11-* and built a vanilla
toolchain from latest RSB. Then I cloned latest RTEMS from the git
HEAD, configured and built it, and I did not come across this error.
MY configure line is:
~/rtems/configure --target=or1k-rtems4.11 --enable-rtemsbsp=or1ksim
--enable-n
On Aug 29, 2014 10:10 PM, "Joel Sherrill" wrote:
>
>
> On 8/29/2014 2:24 PM, Hesham Moustafa wrote:
> > On Fri, Aug 29, 2014 at 9:19 PM, Joel Sherrill
> > wrote:
> >> Hi
> >>
> >> I think something isn't quite right. I don't know if gcc isn't
including
> >> these or the bsp_specs isn't picking t
On 8/29/2014 2:24 PM, Hesham Moustafa wrote:
> On Fri, Aug 29, 2014 at 9:19 PM, Joel Sherrill
> wrote:
>> Hi
>>
>> I think something isn't quite right. I don't know if gcc isn't including
>> these or the bsp_specs isn't picking them up. It is a long holiday weekend
>> and I just wanted to throw
On Fri, Aug 29, 2014 at 9:24 PM, Hesham Moustafa
wrote:
> On Fri, Aug 29, 2014 at 9:19 PM, Joel Sherrill
> wrote:
>> Hi
>>
>> I think something isn't quite right. I don't know if gcc isn't including
>> these or the bsp_specs isn't picking them up. It is a long holiday weekend
>> and I just wante
On Fri, Aug 29, 2014 at 9:19 PM, Joel Sherrill
wrote:
> Hi
>
> I think something isn't quite right. I don't know if gcc isn't including
> these or the bsp_specs isn't picking them up. It is a long holiday weekend
> and I just wanted to throw this out since I don't have time to investigate.
>
> or
Hi,
Thanks for confirming that. Another note is that the output exe
program is "or1k-elf-sim" (not the same as old released which are
or32-elf-sim and sim). I will reflect this name in the README and
sim-scripts.
Thanks,
Hesham
On Fri, Aug 29, 2014 at 9:18 PM, Joel Sherrill
wrote:
> Hi
>
> Just
Hi
I think something isn't quite right. I don't know if gcc isn't including
these or the bsp_specs isn't picking them up. It is a long holiday weekend
and I just wanted to throw this out since I don't have time to investigate.
or1k-rtems4.11-gcc -B../../../../../or1ksim/lib/ -specs bsp_specs
-qr
Hi
Just a quick note to say that this built on Fedora 20 from the RSB.
--
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)
Hi
Any suggestions?
In file included from
../../../../../../../rtems/c/src/../../testsuites/samples/cdtest/main.cc:29:0:
/users/joel/rtems-4.11-work/tools/lib/gcc/or1k-rtems4.11/4.8.3/include/c++/cstdlib:
In function 'long long int std::abs(long long int)':
/users/joel/rtems-4.11-work/tools/lib/g
Hi
Since I will admit not knowing what CMSIS was until I Google'd
this, I decided to give this thread a prod. The link to ARM's
documentation on this is:
http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php
Maybe that will help.
--joel
On 8/29/
On 8/29/2014 10:38 AM, Alan Cudmore wrote:
> I was able to get the ds1307 i2c part working on the Pi. The tod.c
> driver shell was calling setRealTimeToRTEMS() but it was failing in
> rtems_clock_set because my driver was not returning the correct
> rtems_tod format.
> Now when I boot the Pi, t
On 08/28/2014 03:36 PM, Joel Sherrill wrote:
Module:rtems
Branch:master
Commit:b597c0d60ce789c3f3708108c7a5abd75eecfbdf
Changeset:
http://git.rtems.org/rtems/commit/?id=b597c0d60ce789c3f3708108c7a5abd75eecfbdf
Author:Joel Sherrill
Date: Thu Aug 28 08:44:52 2014 -0500
Rege
absent answer means NO?
Thanks,
Daniel.
On Thu, Aug 28, 2014 at 11:31 AM, Daniel Gutson
wrote:
> Hi,
>
>is there any precedent regarding a CMSIS abstraction layer
> implementation on RTEMS?
>
> Thanks,
>
>Daniel.
>
> --
>
> Daniel F. Gutson
> Chief Engineering Officer, SPD
>
>
> San
On August 29, 2014 11:54:35 AM CDT, Ralf Corsepius
wrote:
>On 08/29/2014 04:53 PM, Joel Sherrill wrote:
>
>> This is from rtbf64a which generates the "new" order
>
>== Fedora 20
>
Also, it's quite possible, the files Chris has generated are
>affected,
because he prefers to use exotic
On 08/29/2014 04:53 PM, Joel Sherrill wrote:
This is from rtbf64a which generates the "new" order
== Fedora 20
Also, it's quite possible, the files Chris has generated are affected,
because he prefers to use exotic OSes.
And Fedora 20 for me generates the same thing.
Fedora 20, again.
So
I was able to get the ds1307 i2c part working on the Pi. The tod.c
driver shell was calling setRealTimeToRTEMS() but it was failing in
rtems_clock_set because my driver was not returning the correct
rtems_tod format.
Now when I boot the Pi, the rtems time is synced to the battery backed RTC.
On 8/29/2014 8:13 AM, Hesham Moustafa wrote:
> Hi,
>
> On Fri, Aug 29, 2014 at 2:55 PM, Ralf Corsepius
> wrote:
>> On 08/29/2014 01:11 PM, Hesham Moustafa wrote:
>>> On Fri, Aug 29, 2014 at 12:58 PM, Ralf Corsepius
>>> wrote:
On 08/29/2014 10:55 AM, Hesham Moustafa wrote:
>> Does t
On 8/29/2014 3:55 AM, Hesham Moustafa wrote:
> On Fri, Aug 29, 2014 at 3:45 AM, Chris Johns wrote:
>> On 29/08/2014 12:30 am, Hesham Moustafa wrote:
>>> On Thu, Aug 28, 2014 at 4:25 PM, Joel Sherrill
>>> wrote:
On 8/28/2014 9:20 AM, Hesham Moustafa wrote:
> On Thu, Aug 28, 2014 at
Hi,
On Fri, Aug 29, 2014 at 2:55 PM, Ralf Corsepius
wrote:
> On 08/29/2014 01:11 PM, Hesham Moustafa wrote:
>>
>> On Fri, Aug 29, 2014 at 12:58 PM, Ralf Corsepius
>> wrote:
>>>
>>> On 08/29/2014 10:55 AM, Hesham Moustafa wrote:
>>>
> Does the attached patch fix the problem ?
>
I app
On 08/29/2014 01:11 PM, Hesham Moustafa wrote:
On Fri, Aug 29, 2014 at 12:58 PM, Ralf Corsepius
wrote:
On 08/29/2014 10:55 AM, Hesham Moustafa wrote:
Does the attached patch fix the problem ?
I applied the attached patch (for both HEAD, and before Joel's
preinstall.am commit), and then run
On Fri, Aug 29, 2014 at 12:58 PM, Ralf Corsepius
wrote:
> On 08/29/2014 10:55 AM, Hesham Moustafa wrote:
>
>>> Does the attached patch fix the problem ?
>>>
>> I applied the attached patch (for both HEAD, and before Joel's
>> preinstall.am commit), and then run bootstrap -p, the same behavior
>> o
On 08/29/2014 10:55 AM, Hesham Moustafa wrote:
Does the attached patch fix the problem ?
I applied the attached patch (for both HEAD, and before Joel's
preinstall.am commit), and then run bootstrap -p, the same behavior
occurs for me which is EVERY preinstall.am file is modified.
Which OS are
hello!
I have a problem.Can you help me ?
I can't find rtems-4.11-binutils-common , rtems-4.11-gcc-common
,rtems-4.11-gdb-common, rtems-4.11-newlib-common where download from
4.11/ubuntu/pool/rtems4.11/r/,
so I can't build tools for rtems because it need to depend on them .
On Fri, Aug 29, 2014 at 3:45 AM, Chris Johns wrote:
> On 29/08/2014 12:30 am, Hesham Moustafa wrote:
>>
>> On Thu, Aug 28, 2014 at 4:25 PM, Joel Sherrill
>> wrote:
>>>
>>>
>>> On 8/28/2014 9:20 AM, Hesham Moustafa wrote:
On Thu, Aug 28, 2014 at 4:12 PM, Joel Sherrill
wrote:
>
On 08/29/2014 04:58 AM, Chris Johns wrote:
This is a patch of the preinstall.am files. I have tested it on fedora
20 and OSX.
If this is ok I will push to the repo.
OK with me.
I'd suspect this to happen due to perl's hash algorithm having changed,
AFAICT (I am also Fedora perl co-maintaine
28 matches
Mail list logo
