_
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> _______
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
On Fri, Aug 28, 2015 at 12:33 PM, sudarshan.rajagopalan
wrote:
> On 2015-08-27 17:06, Joel Sherrill wrote:
>>
>> On 8/27/2015 3:58 PM, Daniel Gutson wrote:
>>>
>>> On Thu, Aug 27, 2015 at 3:53 PM, sudarshan.rajagopalan
>>> wrote:
>>>>
&
On Fri, Aug 28, 2015 at 2:31 PM, sudarshan.rajagopalan
wrote:
> On 2015-08-28 12:18, sudarshan.rajagopalan wrote:
>>
>> On 2015-08-28 11:30, Daniel Gutson wrote:
>>>
>>> On Fri, Aug 28, 2015 at 12:20 PM, Gedare Bloom wrote:
>>>>
>>>> C
e eq\n" /* IF bit 2 of LR is zero... (PSR.Z == 1) */
> + "mrseq r0, msp\n"/* THEN we were using MSP. */
> +"addeq r0, %[cpufsz]\n" /* THEN, set r0 = old MSP. */
> +"mrsne r0, psp\n"/* ELSE it's not zero; we
On Mon, Aug 31, 2015 at 2:34 PM, Gedare Bloom wrote:
> I'd approve 2 patches in case you want to give credit. First patch
> with Sudarshan's fix, and Martin's improvement second.
+1
>
> On Mon, Aug 31, 2015 at 1:28 PM, Daniel Gutson
> wrote:
>> Side questio
El 31/7/2015 3:28, "Chris Johns" escribió:
>
> On 31/07/2015 4:11 pm, Sebastian Huber wrote:
> > For synchronization objects use the self-contained objects available via
> > Newlib .
> >
> >
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=ecaef05f6601f1e8acb78fb65b411a258f3998
Is there any reason to not declare these variables as unsigned (int)? IIUC
strlen returns an unsigned integral. Sign-correctnesd doesn't hurt and I
saw many bugs caused by the lack of it (the last one being pushed few says
ago in the Chromium beowser).
El 1/9/2015 18:41, "Joel Sherrill" escribió:
El 1/9/2015 23:10, "Joel Sherrill" escribió:
>
>
>
> On September 1, 2015 8:33:54 PM CDT, Daniel Gutson <
daniel.gut...@tallertechnologies.com> wrote:
> >Is there any reason to not declare these variables as unsigned (int)?
> >IIUC strlen returns an uns
terested in this last one. Is this an XFail? Could you please
post both the dejagnu test and the output?
We use move semantics everywhere and I'd want to be sure it's working OK.
Specially since this doesn't seem to be related to concurrency but just
algorithms.
Thanks,
Daniel.
El 2/9/2015 5:28, "Sebastian Huber"
escribió:
>
>
>
> On 02/09/15 02:50, Chris Johns wrote:
>>
>> On 1/09/2015 8:52 pm, Daniel Gutson wrote:
>>>
>>> >
>>> >El 31/7/2015 3:28, "Chris Johns" >> ><mailto:chr.
El 2/9/2015 11:14, "Joel Sherrill" escribió:
>
>
>
> On 8/31/2015 5:47 AM, Cudmore, Alan P. (GSFC-5820) wrote:
>>
>> Having a floating point configuration of the BSP makes sense. I was able
>> to rebuild the BSP with the hardware floating point compiler option and
it
>> works.
>>
>> I did get a fl
El 2/9/2015 11:58, "Martin Galvan"
escribió:
>
> On 02/09/2015 15:00, Sebastian Huber wrote:
> > I deleted the test tree. It will take a couple of days before I create a
> > new one. I think it makes more sense if you run the tests yourself, so
> > that you can debug them. I use the realview_pbx_a
* Fill the remaining space with whitespace (if necessary). */
>> + for (; i < BYTES_PER_ROW; ++i) {
>> +strncat(line_buffer, " ", HEX_FMT_LENGTH);
>> + }
>> +
>> + /* Append a bar. */
>> + strncat(line_buffer, "|"
On Thu, Sep 3, 2015 at 5:44 PM, Joel Sherrill wrote:
> Should be committed now.
>
> I guess one of us should have compiled it. :)
Don't worry, Martin will buy some beers because of this.
Cheers.
Daniel.
>
> --joel
>
> On 9/3/2015 3:25 PM, Martin Galvan wrote:
sk
trying to access something marked as owned by another task is because there
is a bug and an action shall be taken (e.g. restart the offending task). Is
there already any kind of hardware support for this?
Thanks,
Daniel.
> >
> > The ARMv7-A and some PowerPC BSPs have write pr
Update:
fix sent https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01184.html
Waiting for review.
Daniel.
On Thu, Aug 13, 2015 at 7:02 PM, Daniel Gutson
wrote:
> I have been desperately busy to fix this, though we are indeed
> interested in the fix since we'll use C++14 soon.
>
(arguably) optimization severely breaks the semantic as shown in the
bug report.
Andres will fix it and will let you know about the progress.
Thanks,
Daniel.
--
Daniel F. Gutson
Chief Engineering Officer, SPD
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: +54 351 4217888
On Fri, Sep 18, 2015 at 5:10 AM, Sebastian Huber
wrote:
> Hello Daniel,
>
> there was a discussion about this on this mailing list. I think the result
> was that GCC is working as intended:
>
> https://lists.rtems.org/pipermail/devel/2015-July/011879.html
Yes. Semantic is cha
_V = -O0 -g -mfloat-abi=hard -mfpu=fpv4-sp-d16
>
> Thanks and Regards,
> Sudarshan
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
--
Daniel F. Gutson
Chief Engineering Officer, SPD
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Arge
El 25/9/2015 13:17, "sudarshan.rajagopalan"
escribió:
>
> On 2015-09-25 11:06, Daniel Gutson wrote:
>>
>> On Thu, Sep 24, 2015 at 4:49 PM, sudarshan.rajagopalan
>> wrote:
>>>
>>> Hey all,
>>>
>>> We are developing a new BSP th
Now that muser-mode is default the multilib definitions does not require to
specify that switch any more. Add UT699 to multilib after recent patches. Add
AT697F multilib since there are many LEON2 users running RTEMS.
To gcc/ChangeLog:
gcc/
* config/sparc/t-rtems: Remove -muser-mode, add
On 09/28/2015 02:36 PM, Sebastian Huber wrote:
On 28/09/15 14:33, Sebastian Huber wrote:
On 28/09/15 14:13, Daniel Hellstrom wrote:
Now that muser-mode is default the multilib definitions does not require to
specify that switch any more. Add UT699 to multilib after recent patches. Add
AT697F
On 09/28/2015 03:37 PM, Sebastian Huber wrote:
On 28/09/15 15:20, Daniel Hellstrom wrote:
Which multilibs do we have after this change?
.;
soft;@msoft-float
v8;@mcpu=v8
leon3;@mcpu=leon3
leon3v7;@mcpu=leon3v7
leon;@mcpu=leon
leon/ut699;@mcpu=leon@mfix-ut699
leon/at697f;@mcpu=leon@mfix
On 09/28/2015 03:49 PM, Sebastian Huber wrote:
On 28/09/15 15:39, Daniel Hellstrom wrote:
On 09/28/2015 03:37 PM, Sebastian Huber wrote:
On 28/09/15 15:20, Daniel Hellstrom wrote:
Which multilibs do we have after this change?
.;
soft;@msoft-float
v8;@mcpu=v8
leon3;@mcpu=leon3
leon3v7
dback from us.
>
> --
> 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.
>
&
On Wed, Oct 7, 2015 at 8:22 PM, Chris Johns wrote:
> On 7/10/2015 11:00 pm, Daniel Gutson wrote:
>>
>> FWIW no need from feedback from us.
>>
>
> Can we assume this is an ok from you?
Yes.
>
> Chris
--
Daniel F. Gutson
Chief Engineering Officer, SPD
Sa
_
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
--
Daniel F. Gutson
Chief Engineering Officer, SPD
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: +54 351 4217888 / +54 351 4218211
Skype:dguts
On Wed, Oct 21, 2015 at 6:02 PM, Joel Sherrill
wrote:
>
>
> On 10/21/2015 3:52 PM, Daniel Gutson wrote:
>>
>> On Wed, Oct 21, 2015 at 3:41 PM, Joel Sherrill
>> wrote:
>>>
>>> Hi
>>>
>>> lm32, moxie, and nios2 all have generic is
threads out of
> the box. I use it currently for development and it works quite good at least
> on ARM and PowerPC.
Out of curiosity: OpenMP on ARM? Could you detail the core name?
Thanks,
Daniel.
ps: we're successfully using gcc 5.2 with custom patches that make
RTEMS compile
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
.
--
Daniel Cederman
Software Engineer
Cobham Gaisler
F : +46 (0) 31 421407
daniel.ceder...@gaisler.com
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
The PSR register holds condition codes, the FPU enable bit, and similar,
which needs to be restored properly when switching task.
---
c/src/lib/libbsp/sparc/shared/irq_asm.S | 8
1 file changed, 8 insertions(+)
diff --git a/c/src/lib/libbsp/sparc/shared/irq_asm.S
b/c/src/lib/libbsp/spar
When I think a bit more of it, one probably should update the PSR after
the heir has been acquired, as the task could potentially be acquired
and released again with a new PSR by another core before the swap.
On 2015-11-12 11:27, Daniel Cederman wrote:
Hello,
I experienced a bug when using
semaphore cannot be acquired.
Thanks,
Daniel.
On Tue, Jun 23, 2015 at 11:53 AM, Ketul Shah wrote:
> Sorry wrong attachment. Kindly review the recent one.
>
> Thanks.
>
> Best Regards,
> Ketul
>
> On 23 June 2015 at 20:20, Ketul Shah wrote:
>>
>> Hello a
We must not load registers (e.g. PSR) from the heir context area before
the heir stopped execution.
---
c/src/lib/libbsp/sparc/shared/irq_asm.S | 30 +-
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/c/src/lib/libbsp/sparc/shared/irq_asm.S
b/c/src/lib/
We must not load registers (e.g. PSR) from the heir context area before
the heir stopped execution.
With this patch the write to PSR is divided into two steps. We first update
the current window pointer and then we restore the status registers and
enable traps. This allows us to move the first wri
I was unsure if the ET bit was always set or not for newly created task
contexts, or if this was the first place that traps got enabled for a
new task. If it is always set we can remove that instruction.
On 2015-11-16 11:27, Sebastian Huber wrote:
On 16/11/15 11:06, Daniel Cederman wrote
Ok, then I will remove that line. I like the assert idea and will add
that to the patch. Thank you for your comments and help!
On 2015-11-16 13:52, Sebastian Huber wrote:
On 16/11/15 13:14, Daniel Cederman wrote:
I was unsure if the ET bit was always set or not for newly created
task contexts
We must not load registers (e.g. PSR) from the heir context area before
the heir stopped execution.
With this patch the write to PSR is divided into two steps. We first update
the current window pointer and then we restore the status registers and
enable traps. This allows us to move the first wri
Yes, definitely. Would you mind doing it? Daniel is away from office
this week and I do not have access.
On 2015-11-16 15:57, Sebastian Huber wrote:
Looks good, we should probably apply it to the 4.11 branch as well.
--
Daniel Cederman
Software Engineer
Cobham Gaisler
Sorry the off-topic email.
Who is planning to attend the expo at EW, so we could meet?
Thanks,
Daniel.
--
Daniel F. Gutson
Chief Engineering Officer, SPD
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: +54 351 4217888 / +54 351 4218211
Skype:dgutson
LinkedIn: http
We must not load registers (e.g. PSR) from the heir context area before
the heir stopped execution.
With this patch the write to PSR is divided into two steps. We first update
the current window pointer and then we restore the status registers and
enable traps. This allows us to move the first wri
Great, thanks!
On 2015-11-17 09:01, Sebastian Huber wrote:
Thanks, I check in this patch on the 4.11 branch.
--
Daniel Cederman
Software Engineer
Cobham Gaisler
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
El 17/11/2015 6:58, "Thomas Dörfler"
escribió:
>
> Hello Daniel,
Hello Thomas,
>
> I am not quite sure whether you mean the "embedded world" trade fair in
Nuermberg, 23.-25.February 2016.
Yes.
>
> Our company will be there. We are located at stand 538,
El 17/11/2015 8:51, "Thomas Dörfler"
escribió:
>
> Hello Daniel,
>
> Expo and conference are in the same building complex. And we will be part
of the expo.
Ah ok, thanks. See you there.
Daniel.
>
> wkr,
>
> Thomas.
>
>
>
> Am 17.11.2015 um
Hi Sebastian,
sorry for top-posting. How does the lack of this function affect
current RTEMS behavior? What's the impact of not having this? We lived
without this till now, how mandatory is this update?
Thanks!
Daniel.
On Wed, Nov 25, 2015 at 4:35 AM, Sebastian Huber
wrote:
&
ers.
>
> The RSB should support out of tree configurations if set up correctly. This
> means you could maintain and release a configuration file the RSB can use to
> build a GPL package.
>
>
> Chris
> _______
> devel mailing list
>
uot;...GNU General Public
License as published by the Free Software Foundation; either version
2..." so I'm confused: why should we ask for a dual license? Isn't
GPLv2 indeed the same RTEMS uses?
Please explain me.
Thanks!
Daniel.
--
Daniel F. Gutson
Chief Engineering Officer,
On Sun, Dec 6, 2015 at 11:36 PM, Joel Sherrill wrote:
>
> On Dec 6, 2015 8:06 PM, "Daniel Gutson"
> wrote:
>>
>> In the f2fs/jffs2 thread a point about licensing arose.
>> Martin mentioned that the original code is part of Linux, assuming
>> that i
Hi folks,
I'm confused about the latest patches: does newlib contain a (full)
network stack which we don't use?
Thanks,
Daniel.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
+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äftliche Mitteilung im Sinne des EHUG.
>>
>>
>> __
.. according to the maximum number of termios ports which is
8. Since LEON3 uses PnP to find how many UARTs there are
present we must make sure worst case work.
The current maximum of 4 free nodes caused for example the
GR712RC with its 6 UARTs to fail during devfs02 test.
---
c/src/lib/libbsp/sp
On SMP rtems_interrupt_lock_context must be used. Most tests fail with a
NULL pointer exception when exiting, except on NGMP where main memory is
at 0x.
---
c/src/lib/libbsp/sparc/leon3/console/console.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/c/src/li
2 code? For example LEON2
UART.STATUS.TH bit is named TE in in APBUART since they signal different things, I can see you are renaming from _THE into _TE in the LEON2 driver. I think I would prefer to just change the LEON3
console driver into APBUART_ something.
Daniel
On 06/30/2014 09:30
PATCHv2: BSP_fatal_halt renamed to _BSP_Fatal_halt
The Fatal_halt handler now have two options, either halt
as before or enter system error state to return to
debugger or simulator. The exit-code is now also
propagated to the debugger which is very useful for
testing.
The CPU_Fatal_halt handler w
PATCHv2: BSP_fatal_exit defined in header
Instead of calling the system call TA instruction directly it
is better paractise to isolate the trap implementation to the
system call functions.
BSP_fatal_exit() is added.
---
c/src/lib/libbsp/sparc/erc32/Makefile.am |1 +
c/src/lib/libbs
Without the source the error code does not say that much.
Let it be up to the CPU/BSP to determine the error code
reported on fatal shutdown.
This patch does not change the current behaviour, just
adds the option to handle the source of the fatal halt.
---
cpukit/score/cpu/arm/rtems/score/cpu.h
PATCHv2: unreachable code after SMP secondary CPU init or boot_card
calls, is now removed instead of cleaned-up.
---
c/src/lib/libbsp/sparc/erc32/include/bsp.h |2 --
c/src/lib/libbsp/sparc/leon2/include/bsp.h |2 --
c/src/lib/libbsp/sparc/leon3/include/bsp.h |2 --
c/src/l
By removing the bsp_reset() mechanism and instead relying on the
CPU_Fatal_halt() routine SMP and single-core can halt by updating
the _Internal_errors_What_happened structure and set the state to
SYSTEM_STATE_TERMINATED (the generic way). This will be better
for test scripts and debugger that can
NGMP is a new BSP and is SMP capable which requires the
mcpu=leon3 flag. The LEON4 CPU is backwards compatible
with the LEON3.
---
c/src/lib/libbsp/sparc/leon3/make/custom/ngmp.cfg |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/c/src/lib/libbsp/sparc/leon3/make/custom/ng
In order to support older toolchains and LEON3 v7 systems the
-mcpu=leon3 flag can not be used in the LEON3 BSP. The SMP
kernel however requires -mcpu=leon3 for the CAS support only
present in GCC-4.8 and GCC-4.9.
---
.../libbsp/sparc/leon3/make/custom/leon3smp.cfg|8
1 files chan
Adds functions to request cache operations on a set of cores.
Daniel Cederman (3):
score: Use consistent type for SMP messages
score: Add function to send a SMP message to a set of CPUs
score: Add SMP support to the cache manager
c/src/lib/libcpu/shared/src/cache_manager.c | 166
Adds functions that allows the user to specify which cores that should
perform the cache operation. SMP messages are sent to all the specified
cores and the caller waits until all cores have acknowledged that they
have flushed their cache. Implementation is shown using both function
pointers and fu
---
cpukit/score/include/rtems/score/smpimpl.h |2 +-
cpukit/score/src/smp.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cpukit/score/include/rtems/score/smpimpl.h
b/cpukit/score/include/rtems/score/smpimpl.h
index e2fee39..ba16c8f 100644
---
Make _SMP_Broadcast_message() use the function to send a message to all CPUs
except itself.
---
cpukit/score/include/rtems/score/smpimpl.h | 10 ++
cpukit/score/src/smp.c | 15 ---
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/cpukit/s
A secondary processor might miss changes done to the trap table
if the instruction cache is not flushed. Once interrupts are enabled
any other required cache flushes can be ordered via the cache
manager.
---
c/src/lib/libbsp/sparc/leon3/startup/bspsmp.c |9 +
cpukit/score/cpu/sparc/rte
When entering up state, but before enabling interrupts,
the icaches are flushed to make sure that changes to the trap
table are visible. After up state the SMP cache manager is
used to order cache flushes whenever the trap table is altered.
Daniel Cederman (2):
bsp/sparc: Flush icache before
Changes to the trap table might be missed by other cores.
If the system state is up, the other cores can be notified
using SMP messages that they need to flush their icache.
If the up state has not been reached there is no need to
notify other cores. They will do an automatic flush of the
icache ju
Check that data cache snooping exists and is enabled on all cores.
---
c/src/lib/libbsp/shared/include/fatal.h |1 +
c/src/lib/libbsp/sparc/leon3/include/leon.h | 10 ++
c/src/lib/libbsp/sparc/leon3/startup/bspsmp.c |8 ++--
3 files changed, 17 insertions(+), 2 deleti
The flush instruction on LEON flushes both the data and the instruction
cache. Flushing of just the instruction cache can be done by setting
the "flush instruction cache" bit in the cache control register.
---
c/src/lib/libbsp/sparc/leon3/include/cache_.h |4 +++-
c/src/lib/libbsp/sparc/leon3/
ut not on LEON3. LEON3 must handle SMP too.
I don't see needing the symbol BSP_fatal_exit().
True, after updating this patch there is only one caller at the moment. Perhaps
I should remove bsp_reset() from LEON2 and ERC32 instead and rely on
CPU_Fatal_halt() on all BSPs?
On 7/3/2014 2:29
l_error. I don't
see this invoked anywhere. Does this code need to be eliminated?
Can someone confirm me on this?
It is invoked from score/cpu/powerpc/rtems/score/cpu.h, but I guess this is not
what you meant.
DanielH
--joel
On 7/3/2014 2:29 AM, Daniel Hellstrom wrote:
Without the source th
t and handle them differently. The BSP makes sure that only one CPU ends up in the
On 7/3/2014 2:29 AM, Daniel Hellstrom wrote:
PATCHv2: BSP_fatal_halt renamed to _BSP_Fatal_halt
The Fatal_halt handler now have two options, either halt
as before or enter system error state to return to
debugg
On 07/03/2014 05:00 PM, Joel Sherrill wrote:
On 7/3/2014 2:29 AM, Daniel Hellstrom wrote:
By removing the bsp_reset() mechanism and instead relying on the
CPU_Fatal_halt() routine SMP and single-core can halt by updating
the _Internal_errors_What_happened structure and set the state to
On 07/04/2014 08:25 AM, Sebastian Huber wrote:
On 2014-07-03 09:29, Daniel Hellstrom wrote:
By removing the bsp_reset() mechanism and instead relying on the
CPU_Fatal_halt() routine SMP and single-core can halt by updating
the _Internal_errors_What_happened structure and set the state to
ondary cpus. I could rename
it to _SPARC_Start_multitasking and place it in score/cpu instead, as
was done for ARM7VM?
Daniel Cederman
Software Engineer
Aeroflex Gaisler AB
Aeroflex Microelectronic Solutions – HiRel
Kungsgatan 12
SE-411 19 Gothenburg, Sweden
Phone: +46 31 7758665
ceder.
t changed after that, so that is no
problem. But other traps are set after the secondary processors are
started, but before we can send IPIs. These changes might be missed.
Daniel Cederman
Software Engineer
Aeroflex Gaisler AB
Aeroflex Microelectronic Solutions – HiRel
Kungsgatan 12
SE-411 19 G
them instead of function ids.
Daniel Cederman
Software Engineer
Aeroflex Gaisler AB
Aeroflex Microelectronic Solutions – HiRel
Kungsgatan 12
SE-411 19 Gothenburg, Sweden
Phone: +46 31 7758665
ceder...@gaisler.com
www.Aeroflex.com/Gaisler
On 2014-07-04 08:38, Sebastian Huber wrote:
On 2014-07-0
On 07/04/2014 11:52 AM, Sebastian Huber wrote:
On 2014-07-03 11:37, Daniel Cederman wrote:
/**
+ * @brief Sends a SMP message to a set of processors.
+ *
+ * The sending processor may be part of the set.
+ *
+ * @param[in] cpus The set of target processors of the message.
+ * @param[in
needed for
pthread_setaffinity_np if the number of cpus cannot exceed a hardcoded
constant? I recall that there was a discussion on the list about cpu
sets, but I'm not finding anything searching.
Daniel Cederman
Software Engineer
Aeroflex Gaisler AB
Aeroflex Microelectronic Solutions – HiRel
Kung
On 07/04/2014 04:20 PM, Joel Sherrill wrote:
On Jul 4, 2014 3:47 AM, Daniel Hellstrom wrote:
>
> On 07/03/2014 04:55 PM, Joel Sherrill wrote:
> > I am wondering if I don't have a vision for what this
> > series of patches is trying to accomplish in whole.
> * m
Broadcast and single send had different types so I picked the one with a
defined length since we are doing bit operations on it. But I can change
to unsigned long instead.
Daniel Cederman
Software Engineer
Aeroflex Gaisler AB
Aeroflex Microelectronic Solutions – HiRel
Kungsgatan 12
SE-411 19
dangerous.
Daniel Cederman
Software Engineer
Aeroflex Gaisler AB
Aeroflex Microelectronic Solutions – HiRel
Kungsgatan 12
SE-411 19 Gothenburg, Sweden
Phone: +46 31 7758665
ceder...@gaisler.com
www.Aeroflex.com/Gaisler
On 2014-07-07 08:53, Sebastian Huber wrote:
I think instruction cache operations
interrupts or tasks.
Added an extra error message to differentiate between the main processor
not having data cache snooping enabled and a secondary processor not having
data cache snooping enabled.
Daniel Cederman (7):
score: Add function to send a SMP message to a set of CPUs
score: Rename
Check that data cache snooping exists and is enabled on all cores.
---
c/src/lib/libbsp/shared/include/fatal.h |2 ++
c/src/lib/libbsp/sparc/leon3/include/leon.h | 10 ++
c/src/lib/libbsp/sparc/leon3/startup/bspsmp.c |8 ++--
3 files changed, 18 insertions(+), 2 delet
---
cpukit/score/include/rtems/score/smpimpl.h | 15 +++
cpukit/score/src/smp.c | 16
2 files changed, 31 insertions(+)
diff --git a/cpukit/score/include/rtems/score/smpimpl.h
b/cpukit/score/include/rtems/score/smpimpl.h
index e2fee39..d49f88f
The flush instruction on LEON flushes both the data and the instruction
cache. Flushing of just the instruction cache can be done by setting
the "flush instruction cache" bit in the cache control register.
---
c/src/lib/libbsp/sparc/leon3/include/cache_.h |5 -
c/src/lib/libbsp/sparc/leon3
Changes to the trap table might be missed by other cores.
If the system state is up, the other cores can be notified
using SMP messages that they need to flush their icache.
If the up state has not been reached there is no need to
notify other cores. They will do an automatic flush of the
icache ju
Change message type to unsigned long to match other SMP message functions.
---
cpukit/score/include/rtems/score/smpimpl.h |4 ++--
cpukit/score/src/smp.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/cpukit/score/include/rtems/score/smpimpl.h
b/
Adds functions that allows the user to specify which cores that should
perform the cache operation. SMP messages are sent to all the specified
cores and the caller waits until all cores have acknowledged that they
have flushed their cache. If CPU_CACHE_NO_INSTRUCTION_CACHE_SNOOPING is
defined the i
A secondary processor might miss changes done to the trap table
if the instruction cache is not flushed. Once interrupts are enabled
any other required cache flushes can be ordered via the cache
manager.
---
c/src/lib/libbsp/sparc/leon3/startup/bspsmp.c |9 +
cpukit/score/cpu/sparc/rte
On 2014-07-09 16:38, Gedare Bloom wrote:
On Wed, Jul 9, 2014 at 3:02 AM, Daniel Cederman wrote:
Changes to the trap table might be missed by other cores.
If the system state is up, the other cores can be notified
using SMP messages that they need to flush their icache.
If the up state has
On 2014-07-09 16:40, Gedare Bloom wrote:
On Wed, Jul 9, 2014 at 3:02 AM, Daniel Cederman wrote:
The flush instruction on LEON flushes both the data and the instruction
cache. Flushing of just the instruction cache can be done by setting
the "flush instruction cache" bit in the cac
n 2014-07-09 09:02, Daniel Cederman wrote:
Check that data cache snooping exists and is enabled on all cores.
---
c/src/lib/libbsp/shared/include/fatal.h |2 ++
c/src/lib/libbsp/sparc/leon3/include/leon.h | 10 ++
c/src/lib/libbsp/sparc/leon3/startup/bspsmp.c |8 ++--
3
I'm currently working on adding tests. Thank you for your other comments!
On 2014-07-09 09:41, Sebastian Huber wrote:
The new cache manager functions should have tests, see also
http://git.rtems.org/rtems/tree/testsuites/sptests/spcache01/init.c
On 2014-07-09 09:02, Daniel Cederman
Check that data cache snooping exists and is enabled on all cores.
---
c/src/lib/libbsp/shared/include/fatal.h |2 ++
c/src/lib/libbsp/sparc/leon3/include/leon.h | 10 ++
c/src/lib/libbsp/sparc/leon3/startup/bspsmp.c | 14 --
3 files changed, 24 insertions(+), 2
Invokes SMP cache management routines under different scenarios.
---
testsuites/smptests/Makefile.am |1 +
testsuites/smptests/configure.ac |1 +
testsuites/smptests/smpcache01/Makefile.am| 19 ++
testsuites/smptests/smpcache01/init.c | 291 +++
Changes to the trap table might be missed by other cores.
If the system state is up, the other cores can be notified
using SMP messages that they need to flush their icache.
If the up state has not been reached there is no need to
notify other cores. They will do an automatic flush of the
icache ju
Adds functions that allows the user to specify which cores that should
perform the cache operation. SMP messages are sent to all the specified
cores and the caller waits until all cores have acknowledged that they
have flushed their cache. If CPU_CACHE_NO_INSTRUCTION_CACHE_SNOOPING is
defined the i
Added commment on why I'm using BSP_fatal_exit instead of bsp_fatal
and that it is required to flush the instruction cache also in
single processor configuration.
Rewrote cache manager so that it announces the operation and then
releases the lock to avoid deadlocks.
Added test program that invoke
101 - 200 of 730 matches
Mail list logo
