Hi,
The issue of recursive calls of callocs was fixed in RTEMS mainline adding
-fno-builtin in the calloc.c compilation, but we made a gcc patch in order
to use -fno-builtin-calloc instead of -fno-builtin, this is more specific
and disables only calloc builtin optimization.
Currently there is an o
Are manuals on docs.rtems.org automatically regenerated or need to be
hand-built?
On Wed, Nov 4, 2015 at 2:54 PM, Gedare Bloom wrote:
> Module:rtems-source-builder
> Branch:master
> Commit:6bef80f0260923d7274dc1bf3fe193df025772e8
> Changeset:
> http://git.rtems.org/rtems-source-build
On Thu, Nov 5, 2015 at 11:52 AM, Sebastian Huber
wrote:
>
>
> On 05/11/15 15:50, Daniel Gutson wrote:
>>
>> On Thu, Nov 5, 2015 at 11:41 AM, Sebastian Huber
>> wrote:
>>>
>>> >Hello,
>>> >
>>> >I would like to add the tools for RTEMS 4.12 to the RSB. The question is
>>> >which GCC version should
Hi Sebastian,
I see no problem with using the newer GCC assuming our development
cycle is probably still at least 1yr+. Until we get good automation
this is the case. Also, we are planning to apply to Google Code-In,
and bumping the tool versions could be a set of tasks. If you would
like to do on
On 05/11/15 15:50, Daniel Gutson wrote:
On Thu, Nov 5, 2015 at 11:41 AM, Sebastian Huber
wrote:
>Hello,
>
>I would like to add the tools for RTEMS 4.12 to the RSB. The question is
>which GCC version should we use? Since our release process is so slow I tend
>to use GCC 6 since it includes su
On Thu, Nov 5, 2015 at 11:41 AM, Sebastian Huber
wrote:
> Hello,
>
> I would like to add the tools for RTEMS 4.12 to the RSB. The question is
> which GCC version should we use? Since our release process is so slow I tend
> to use GCC 6 since it includes support for OpenMP and C++11 threads out of
Hello,
I would like to add the tools for RTEMS 4.12 to the RSB. The question is
which GCC version should we use? Since our release process is so slow I
tend to use GCC 6 since it includes support for OpenMP and C++11 threads
out of the box. I use it currently for development and it works quite
On 05/11/15 15:17, Martin Galvan wrote:
The LPC1768 variants have a gpio.h file whose name clashes with the gpio.h from
the new GPIO API. This results on the BSPs failing to compile.
This patch renames the LPC1768 gpio.* files to lpc-gpio.*, as it's done on other
BSPs (e.g. Beaglebone).
Closes
The LPC1768 variants have a gpio.h file whose name clashes with the gpio.h from
the new GPIO API. This results on the BSPs failing to compile.
This patch renames the LPC1768 gpio.* files to lpc-gpio.*, as it's done on other
BSPs (e.g. Beaglebone).
Closes #2441.
---
c/src/lib/libbsp/arm/lpc176x/M
On Wed, Nov 4, 2015 at 7:33 PM, Pavel Pisa wrote:
> So it is important what are intended use cases.
> The one where RTEMS image starts from address 0
> is simple and should no use POM nor VIM interrupt bypassing.
> But it requires integration with HAL startup for now.
This should probably go on a
Should be fixed now.
--
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äft
11 matches
Mail list logo
