On 10/09/2021 10:49, Sebastian Huber wrote:
The Cache Manager directives are available via . Document most
of them in the Classic API Guide.
Not documented are the following directive since the API is not yet
stable:
* rtems_cache_coherent_allocate()
* rtems_cache_coherent_free()
* rtems_cache
Hello Andrei,
I modified the flags, could you please check if this fixed the problem?
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgerich
Gedare told me just to change the ID when I submitted the other I sent you
in discord. Sorry for things bouncing back and forth.
On Mon, 13 Sept 2021 at 23:44, Joel Sherrill wrote:
> On Sun, Sep 12, 2021 at 7:02 PM zack leung
> wrote:
> >
> > Thread id is now a Hex value.
> > Updates #4203
> >
On Mon, Sep 13, 2021 at 6:54 PM Chris Johns wrote:
>
> On 13/9/21 11:20 pm, Joel Sherrill wrote:
> > Hi
> >
> > If building a bset tar file, does it matter if the installation prefix
> > is writable?
> >
> > ../source-builder/sb-set-builder --bset-tar-file --log=l-i386.txt
> > --prefix=/rtems/tool
On 13/9/21 11:20 pm, Joel Sherrill wrote:
> Hi
>
> If building a bset tar file, does it matter if the installation prefix
> is writable?
>
> ../source-builder/sb-set-builder --bset-tar-file --log=l-i386.txt
> --prefix=/rtems/tools 5/rtems-i386
> RTEMS Source Builder - Set Builder, 5 (c7870f6e6199
On Sun, Sep 12, 2021 at 7:02 PM zack leung wrote:
>
> Thread id is now a Hex value.
> Updates #4203
> ---
> cpukit/score/cpu/i386/cpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
> index 77b7a7161c..06af57418d 1
On Wed, Aug 25, 2021 at 7:42 AM Matt Joyce wrote:
>
> Added implementation of the pthread_cond_clockwait()
> method to cpukit/posix/src/condclockwait.c. Additional
> logic added to condwaitsupp.c to implement the new
> method. Pthread_cond_clockwait() has been added to the
> Issue 8 POSIX Standard
Hello,
I guess this is mostly a question for Sebastian.
While you were away, a bunch of us figured out that gcc for CM4 is using the
wrong instruction set for multilib (?).
Can you take a look at issue #4504 please? (I’m pretty sure I didn’t express
that correctly, but I have put all of the
psxdevctl is supposed to return the value in errno. Before, it was
returning -1 and setting errno. Changed the tests to reflect these
changes. Added code from RRADE's posix_devctl.c.
Closes #4505
---
cpukit/libcsupport/src/posix_devctl.c | 80 ++
testsuites/psxtes
psxdevctl is supposed to return the value in errno. Before, it was
returning -1 and setting errno. Changed the tests to reflect these
changes. Added code from RRADE's posix_devctl.c.
Closes #4506
---
cpukit/libcsupport/src/posix_devctl.c | 80 ++
testsuites/psxtes
Adds patch to add sanitation to the padding of bits and size_t types for
AArch64 tools builds with newlib. These changes have been made in ARM, but
newlib has yet to pull them. This can be removed once newlib has pulled
the code.
Updates #4510
---
rtems/config/tools/rtems-gcc-head-newlib-head.cfg
Hi,
These patches add some of the code that we are waiting for newlib to
pull.
Thanks,
Ryan
Ryan Long (2):
rtems-gcc-10-newlib-head.cfg: Add newlib patch
rtems-gcc-head-newlib-head.cfg: Add newlib patch
rtems/config/tools/rtems-gcc-10-newlib-head.cfg | 3 +++
rtems/config/tools/rtems-gcc
Adds patch to add sanitation to the padding of bits and size_t types for
AArch64 tools builds with newlib. These changes have been made in ARM, but
newlib has yet to pull them. This can be removed once newlib has pulled
the code.
Updates #4510
---
rtems/config/tools/rtems-gcc-10-newlib-head.cfg |
Hi
If building a bset tar file, does it matter if the installation prefix
is writable?
../source-builder/sb-set-builder --bset-tar-file --log=l-i386.txt
--prefix=/rtems/tools 5/rtems-i386
RTEMS Source Builder - Set Builder, 5 (c7870f6e6199)
error: prefix is not writable: /rtems/tools
It does if
On 13/09/2021 10:43, Chris Johns wrote:
On 13/9/21 4:38 pm, Sebastian Huber wrote:
This approach is not limited to memory mapped register blocks.
I think it is.
I would like to understand how bus types other than "memory" are specified for a
generic device driver that needs to handle bus varia
On 13/9/21 4:38 pm, Sebastian Huber wrote:
> This approach is not limited to memory mapped register blocks.
I think it is.
I would like to understand how bus types other than "memory" are specified for a
generic device driver that needs to handle bus variability. I am concerned this
is bespoke to
16 matches
Mail list logo