Hello,
In RTEMS each set of BSP has its own MMU implementation, for utilizing this
for high-level operations such as thread-stack protection we need a common
interface that is implemented for each BSP but is available for high-level
operations ( Something along the lines of the cache manager ), my
Hello,
The translation table setting code has _ARM_Data_synchronization_barrier()
before and after invalidating the instruction and data TLB entry, this
ensures synchronization of instructions for the TLB invalidation in case of
multiple cores. My question is, do we have to explicitly disable inter
Removed soft float files
Signed-off-by: Eshan dhawan
---
newlib/libc/machine/arm/machine/fenv-mangle.h | 53 ---
.../libc/machine/arm/machine/fenv-softfloat.h | 187 ---
newlib/libc/machine/arm/machine/fenv-vfp.h| 187 ---
newlib/libc/machine/arm/sys/fenv.h| 19
On Sat, Jul 18, 2020 at 2:36 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 17/07/2020 22:56, Eshan dhawan wrote:
>
> > +#ifdef __ARM_PCS_VFP
>
> Why do you use this define an not
>
> #ifndef __SOFTFP__
>
> like glibc?
>
OK :)
___
d
On 17/07/2020 22:56, Eshan dhawan wrote:
+#ifdef __ARM_PCS_VFP
Why do you use this define an not
#ifndef __SOFTFP__
like glibc?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Hello everyone,
This is the version 2 of the previous arm fenv patch
apologies, I forgot to add the -v2 in the git send mail
-Eshan
On Sat, Jul 18, 2020 at 2:26 AM Eshan dhawan
wrote:
> All the extra files have been removed
>
> Signed-off-by: Eshan dhawan
> ---
> newlib/libc/machine/arm/machi
All the extra files have been removed
Signed-off-by: Eshan dhawan
---
newlib/libc/machine/arm/machine/fenv-mangle.h | 53 ---
.../libc/machine/arm/machine/fenv-softfloat.h | 187 ---
newlib/libc/machine/arm/machine/fenv-vfp.h| 187 ---
newlib/libc/machine/arm/sys/fenv.h
>> > diff --git a/bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
>> > b/bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
>> > new file mode 100644
>> > index 00..e69de29bb2
>> > diff --git a/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
>> > b/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
>>
On Fri, Jul 17, 2020 at 12:53 PM Heinz Junkes
wrote:
> You are right. I was not aware of that the dhcpcd stuff is already
> included into the source of the epicsPlayground repo. Will have a look into
> it.
> Heinz
>
> FHI, Heinz Junkes
>
Thank you so much, Heinz! It will be kind of you to advice
On Fri, Jul 17, 2020 at 11:08 AM Gedare Bloom wrote:
> Is this code working? how do you test it?
>
> There are several points buried below that you might need to bring out
> to separate threads for discussion, while you work on the code.
>
> On Thu, Jul 16, 2020 at 5:34 AM Utkarsh Rai
> wrote:
>
The other 2 BSP-specific patches look fine. I didn't look too closely
at the imx-specific part.
On Thu, Jul 16, 2020 at 11:55 PM Christian Mauderer
wrote:
>
> The cache of the fdt blob is flushed after copy. Therefore it should be
> aligned.
> ---
> bsps/shared/start/bsp-fdt.c | 7 ---
> 1 f
On 17/07/2020 14:22, Richi Dubey wrote:
I found the line in the documentation: "Since the processor assignment
is independent of the thread priority the processor indices may move
from one state to the other."
This is true because the processor assignment is done by the scheduler
and it gets to
On 17/07/2020 14:15, Eshan Dhawan wrote:
On 17-Jul-2020, at 10:40 AM, Sebastian Huber
wrote:
On 17/07/2020 01:23, Eshan dhawan wrote:
int fegetexcept(void)
{
- int __unmasked;
- __unmasked = 0;
#ifndef SOFTFP_ABI
Do we need this extra define, can't we use
#ifndef __SOFTFP__
Hi,
I found the line in the documentation: "Since the processor assignment
is independent of the thread priority the processor indices may move
from one state to the other."
This is true because the processor assignment is done by the scheduler
and it gets to choose whether to allocate the highes
> On 17-Jul-2020, at 10:40 AM, Sebastian Huber
> wrote:
>
> On 17/07/2020 01:23, Eshan dhawan wrote:
>
>> int fegetexcept(void)
>> {
>> -int __unmasked;
>> -__unmasked = 0;
>> #ifndef SOFTFP_ABI
>
> Do we need this extra define, can't we use
>
> #ifndef __SOFTFP__
>
> like in g
>
> During system startup the application configuration defines which
> processor is available to RTEMS. Every configured and present processor
> gets an idle thread assigned which is managed by a scheduler. This is
> the starting point of the system. If someone calls
> rtems_scheduler_remove_proce
>
>
> > Scheduler_Node *nodes;
> > } Thread_Scheduler_control;
> >
> > Why do we have a Scheduler_Node *nodes? What does it indicate? Since the
> pointer can point to a single value, why is it being called nodes?
> >
> See cpukit/score/src/threadinitialize.c +153
Thank you for your help.
/**
17 matches
Mail list logo
