On 10/08/2021 16:50, Sebastian Huber wrote:
On 10/08/2021 16:46, Gedare Bloom wrote:
This is a good cleanup. The naming seems a bit off to me, but it's all
internal so we can always adjust it later. (I think it should be
singular "Priority_Flag", but really it's not just a flag, it's
something l
Sorry, I put in newlib and this stupid mail program put in newly.
> On 2021-August-10, at 15:48, Mr. Andrei Chichak wrote:
>
> From what I can figure out, there seems to be a problem with the
> out-of-the-box build of newly that the STM32F4 uses.
>
> memset() goes for a few ARM instructions an
From what I can figure out, there seems to be a problem with the out-of-the-box
build of newly that the STM32F4 uses.
memset() goes for a few ARM instructions and then seems to intentionally branch
into, what the map file indicates is, the middle of fflush().
newly would have been built with th
Hi everyone,
I was able to successfully build LLVM from source using "ninja" instead of
"make" after a couple of failed attempts because I kept running out of
resources.
Is there anything else I am supposed to do as far building LLVM is
concerned? Or will every user first have to clone the llvm re
On 10/08/2021 16:46, Gedare Bloom wrote:
This is a good cleanup. The naming seems a bit off to me, but it's all
internal so we can always adjust it later. (I think it should be
singular "Priority_Flag", but really it's not just a flag, it's
something like the "Priority_Discipline" -- I can't thin
ok
On Tue, Aug 10, 2021 at 8:34 AM Sebastian Huber
wrote:
>
> In SMP configurations, on 64-bit architectures use plain atomic
> operations to set/get the priority value of a scheduler node. On 32-bit
> architectures use an ISR lock. Using a sequence lock has no real
> benefit since it uses atom
This is a good cleanup. The naming seems a bit off to me, but it's all
internal so we can always adjust it later. (I think it should be
singular "Priority_Flag", but really it's not just a flag, it's
something like the "Priority_Discipline" -- I can't think what is the
right word however for how yo
looks good, maybe one small clarification:
On Tue, Aug 10, 2021 at 4:44 AM Sebastian Huber
wrote:
>
> The rtems_partition_return_buffer() wrongly accepted which were exactly
> at the buffer area end. Use the buffer area limit address for the range
> checking.
>
> Close #4490.
> ---
> cpukit/inc
In SMP configurations, on 64-bit architectures use plain atomic
operations to set/get the priority value of a scheduler node. On 32-bit
architectures use an ISR lock. Using a sequence lock has no real
benefit since it uses atomic read-modify-write operations for both the
read and the write lock.
Use an enum instead of a boolean to indicated if a priority should be
appended or prepended to its priority group. This makes the code more
expressive and it a bit more efficient since a branch in
_Scheduler_Node_set_priority() is avoided.
---
cpukit/include/rtems/posix/muteximpl.h| 2 +-
The master branch works for me. I tried the raspberrypi and
raspberrypi2 BSPS and they work fine. I built the beagleboneblack BSP
but did not run it.
When this one line patch is installed, SMP works too:
https://lists.rtems.org/pipermail/devel/2021-August/068832.html
Alan
On Mon, Aug 9, 2021 at 1
The rtems_partition_return_buffer() wrongly accepted which were exactly
at the buffer area end. Use the buffer area limit address for the range
checking.
Close #4490.
---
cpukit/include/rtems/monitor.h| 2 +-
cpukit/include/rtems/rtems/partdata.h | 9 -
cpukit/libmisc/monitor/m
12 matches
Mail list logo
