On 06/10/2014 09:34 AM, Sebastian Huber wrote:
On 2014-06-09 11:06, Daniel Hellstrom wrote:
On 06/05/2014 04:54 PM, Sebastian Huber wrote:
On 2014-06-04 20:48, Daniel Hellstrom wrote:
On 06/04/2014 11:51 AM, Sebastian Huber wrote:
On 2014-06-04 11:23, Daniel Hellstrom wrote:
Instead of
Hi,
Have you seen a fix or update on this issue?
Regards,
Daniel
On 05/29/2013 07:30 PM, Jiri Gaisler wrote:
On 05/29/2013 01:42 PM, Ralf Kirchner wrote:
Hi All,
I noticed a strange problem with gdb version 7.6 (our current RPM version)
Printing variables in in gdb is not possible.
I have t
On 06/05/2014 04:54 PM, Sebastian Huber wrote:
On 2014-06-04 20:48, Daniel Hellstrom wrote:
On 06/04/2014 11:51 AM, Sebastian Huber wrote:
On 2014-06-04 11:23, Daniel Hellstrom wrote:
Instead of calling the system call TA instruction directly it
is better paractise to isolate the trap
On 06/04/2014 11:51 AM, Sebastian Huber wrote:
On 2014-06-04 11:23, Daniel Hellstrom wrote:
Instead of calling the system call TA instruction directly it
is better paractise to isolate the trap implementation to the
system call functions.
The BSP_fatal_return() should always exist, regardless
On 06/04/2014 11:50 AM, Sebastian Huber wrote:
On 2014-06-04 11:23, Daniel Hellstrom wrote:
diff --git a/cpukit/score/cpu/sparc/rtems/score/cpu.h
b/cpukit/score/cpu/sparc/rtems/score/cpu.h
index ce5ea60..b625bb9 100644
--- a/cpukit/score/cpu/sparc/rtems/score/cpu.h
+++ b/cpukit/score/cpu
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 was split up into two, since
the only the LEON3 suppo
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
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
Instead of calling the system call TA instruction directly it
is better paractise to isolate the trap implementation to the
system call functions.
The BSP_fatal_return() should always exist, regardless of SPARC
CPU.
---
c/src/lib/libbsp/sparc/erc32/Makefile.am |1 +
c/src/lib/libbsp
---
c/src/lib/libbsp/sparc/shared/start/start.S |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/c/src/lib/libbsp/sparc/shared/start/start.S
b/c/src/lib/libbsp/sparc/shared/start/start.S
index d54c5a0..8ebd56f 100644
--- a/c/src/lib/libbsp/sparc/shared/start/start.S
+++
---
c/src/lib/libbsp/sparc/leon3/configure.ac |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/c/src/lib/libbsp/sparc/leon3/configure.ac
b/c/src/lib/libbsp/sparc/leon3/configure.ac
index fd3b0a4..3fe1e48 100644
--- a/c/src/lib/libbsp/sparc/leon3/configure.ac
+++ b/c/src/l
---
c/src/lib/libbsp/sparc/leon2/configure.ac |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/c/src/lib/libbsp/sparc/leon2/configure.ac
b/c/src/lib/libbsp/sparc/leon2/configure.ac
index 6c7e25d..610a049 100644
--- a/c/src/lib/libbsp/sparc/leon2/configure.ac
+++ b/c/src/l
The GRETH doesn't support IP fragments.
---
c/src/libchip/network/greth.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/c/src/libchip/network/greth.c b/c/src/libchip/network/greth.c
index e957dc3..ccf2017 100644
--- a/c/src/libchip/network/greth.c
+++ b/c/src/libchip/
---
cpukit/NEWS |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
delete mode 100644 cpukit/NEWS
diff --git a/cpukit/NEWS b/cpukit/NEWS
deleted file mode 100644
index 205fecd..000
--- a/cpukit/NEWS
+++ /dev/null
@@ -1,7 +0,0 @@
-Major changes since rtems-4.7.0:
-
-2007-05-09
---
c/src/lib/libbsp/sparc/leon3/include/leon.h |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/c/src/lib/libbsp/sparc/leon3/include/leon.h
b/c/src/lib/libbsp/sparc/leon3/include/leon.h
index bda28f2..f2ac8e0 100644
--- a/c/src/lib/libbsp/sparc/leon3/include/leon.h
++
---
c/src/lib/libbsp/sparc/leon3/include/leon.h | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/c/src/lib/libbsp/sparc/leon3/include/leon.h
b/c/src/lib/libbsp/sparc/leon3/include/leon.h
index f2ac8e0..9bcbe60 100644
--- a/c/src/lib/libbsp/sparc/leon3/incl
The last optimization missed was incorrect in regards to
PSR write instruction delay must be 3 instructions.
New optimizations:
* align to 32-byte cache line.
* rearrange code into three "blocks" of 4 instructions that
is executed by syscall 2 and 3. This is to optimize for
16/32 byte cach
:
This looks OK as best I can tell.
On 5/23/2014 8:52 AM, Daniel Hellstrom wrote:
---
c/src/lib/libcpu/sparc/syscall/syscall.S | 27 +++
1 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/c/src/lib/libcpu/sparc/syscall/syscall.S
b/c/src/lib/libcpu/sparc
The exit SPARC system call doesn't have a function entry
point like the others do. This is probably why people use
TA 0x0 instruction directly for shutting down the system.
---
c/src/lib/libcpu/sparc/syscall/syscall.S | 13 +
cpukit/score/cpu/sparc/rtems/score/sparc.h | 25 ++
---
c/src/lib/libcpu/sparc/syscall/syscall.S | 27 +++
1 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/c/src/lib/libcpu/sparc/syscall/syscall.S
b/c/src/lib/libcpu/sparc/syscall/syscall.S
index aa69f45..2d53ebe 100644
--- a/c/src/lib/libcpu/sparc/syscall/
On 05/23/2014 03:17 PM, Joel Sherrill wrote:
On 5/23/2014 7:26 AM, Daniel Hellstrom wrote:
---
c/src/lib/libbsp/sparc/leon3/include/leon.h |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/c/src/lib/libbsp/sparc/leon3/include/leon.h
b/c/src/lib/libbsp/sparc/leon3
The same smp fatal code is used in percpu
_Per_CPU_State_change(). In order to determine which CPU
requested a fatal shutdown and which CPU responds to it a
unique code should be used.
A unique code makes it also possible to handle the CPUs
differently in the fatal exception handler.
---
cpukit/s
---
c/src/lib/libbsp/sparc/leon3/include/leon.h |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/c/src/lib/libbsp/sparc/leon3/include/leon.h
b/c/src/lib/libbsp/sparc/leon3/include/leon.h
index bda28f2..d21f054 100644
--- a/c/src/lib/libbsp/sparc/leon3/include/leon.h
+
On 05/21/2014 10:01 AM, Sebastian Huber wrote:
Hello Gedare,
thanks for your review.
On 2014-05-20 16:58, Gedare Bloom wrote:
@@ -54,7 +58,15 @@ SYM(_CPU_Context_switch):
> ld [%g6 + SPARC_PER_CPU_ISR_DISPATCH_DISABLE], %o4
> ! save it a bit later so we do not waste a co
Both patches in this series looks good. Thanks!
Haven't tested it though. Please merge it since we will temporary branch from
mainline the coming days for the SMP project.
DanielH
On 05/14/2014 10:57 AM, Sebastian Huber wrote:
Use the register %g4 for the data content since it must be an eve
On 05/14/2014 10:31 AM, Sebastian Huber wrote:
On 2014-05-14 09:37, Daniel Hellstrom wrote:
Hello Sebastian,
I think the patch is correct, however I would rather see that you use g4
instead of g2 to increment, that way you don't need the move either.
Ok, see follow up patch.
Ok, t
ers, which should cause
illegal-instruction trap to happen. %g5 can not be used together with LDD or
STD.
Thanks,
Daniel Hellstrom
On 05/13/2014 02:34 PM, Sebastian Huber wrote:
Use __bss_start available via %g4 to clear the BSS section. The usage
of _edata resulted in a copy of [_edata, __bss_start
Looks good! It is wrong to call it LEON3 since the IP is named GPTIMER and not
bound to a specific revision of the CPU.
Thanks!
Daniel
On 05/09/2014 02:29 PM, Sebastian Huber wrote:
From: Christian Mauderer
This enables re-use for other BSPs
---
c/src/lib/libbsp/sparc/leon3/clock/ckinit.c
Looks good.
Thanks,
Daniel
On 03/06/2014 01:40 PM, Sebastian Huber wrote:
---
c/src/lib/libbsp/sparc/shared/include/grlib.h | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/c/src/lib/libbsp/sparc/shared/include/grlib.h
b/c/src/lib/libbsp/sparc/shared/
On 02/24/2014 04:58 PM, Sebastian Huber wrote:
On 2014-02-24 16:45, Daniel Hellstrom wrote:
On 02/24/2014 04:16 PM, Sebastian Huber wrote:
On 2014-02-24 15:20, Daniel Hellstrom wrote:
Sebastian, I think it's a good solution to rely on the GPTIMER[0].timer0 as a
fallback.
Looks good
On 02/24/2014 04:16 PM, Sebastian Huber wrote:
On 2014-02-24 15:20, Daniel Hellstrom wrote:
Sebastian, I think it's a good solution to rely on the GPTIMER[0].timer0 as a
fallback.
Looks good to me, and should work on the TSIM/GRSIM and LEON3 hardware.
Assuming that the frequency has
Sebastian, I think it's a good solution to rely on the GPTIMER[0].timer0 as a
fallback.
Looks good to me, and should work on the TSIM/GRSIM and LEON3 hardware.
Assuming that the frequency has been initialized to 1MHz for secondary GPTIMER
may be wrong when invoked from a boot loader, however t
On 02/21/2014 11:42 AM, Sebastian Huber wrote:
Hello Daniel,
On 2014-02-21 11:10, Daniel Hellstrom wrote:
Hello,
The problem is that the wrong timer is allocated. In the following code the
second GPTIMER core is searched for (idx=1), which most LEON systems don't
have. The sta
On 02/23/2014 10:50 AM, Sebastian Huber wrote:
On 02/22/2014 11:56 PM, Joel Sherrill wrote:
On Feb 22, 2014 4:27 PM, Daniel Hellstrom wrote:
>
>I guess the quick fix until its sorted out would be to depend on GPTIMER[0].timer0 (system clock timer) and remove the AMBA scanning. If Seb
of this
>morning, leon3 still did not run on tsim or grsim.
>
>On Feb 21, 2014 4:39 AM, Sebastian Huber
> wrote:
>Hello Daniel,
>
>On 2014-02-21 11:10, Daniel Hellstrom wrote:
>> Hello,
>>
>> The problem is that the wrong timer is allocated. In the following
running at a frequency of a multiple
of 1MHz, but the prescaler does not have to be a multiple of 8.
Best Regards,
Daniel Hellstrom
Software Section Head
Aeroflex Gaisler AB
Aeroflex Microelectronic Solutions – HiRel
Kungsgatan 12
SE-411 19 Gothenburg, Sweden
Phone: +46 31 7758657
dan...@gaisler.com
www
On 02/18/2014 02:58 PM, Sebastian Huber wrote:
On 2014-02-18 14:49, Daniel Hellstrom wrote:
Is this needed for CPU0 also?
I don't know. In which state are the caches after a power-on-reset?
It is the boot loaders job to initialize hardware and to load RTEMS into RAM before jumping
Hello,
Is this needed for CPU0 also? Otherwise I think it would be enough to
invalidate the caches when the other cache parameters to save one instruction,
they are modified in leon3_secondary_cpu_initialize():
- sparc_leon3_set_cctrl( 0x8F );
+ sparc_leon3_set_cctrl( 0xEF );
Regards,
On 02/12/2014 02:33 PM, Sebastian Huber wrote:
On 2014-02-12 12:11, Daniel Hellstrom wrote:
I'm not familiar with this, but indeed it look a bit wrong. The timer resources
on LEON is not per-CPU, they area shared and we never know how many timers are
available. Most systems have at leas
Hello,
I'm not familiar with this, but indeed it look a bit wrong. The timer resources on LEON is not per-CPU, they area shared and we never know how many timers are available. Most systems have at least two
timers. In case of a multi-processor system the LEON3 usually configured which timer it
8,7 @@ int ambapp_find_by_idx(struct ambapp_dev *dev, int index,
void *pcount)
int *pi = pcount;
if (pi) {
-if (*pi-- == 0)
+if ((*pi)-- == 0)
return (int)dev;
else
return 0;
--
Daniel Hellstrom
Software Section Head
Aeroflex Gaisler AB
Aeroflex Microelectronic
n times for all as a reference point.
--
Daniel Hellstrom
Software Section Head
Aeroflex Gaisler AB
Aeroflex Microelectronic Solutions – HiRel
Kungsgatan 12
SE-411 19 Gothenburg, Sweden
Phone: +46 31 7758657
dan...@gaisler.com
www.Aeroflex.com/Gaisler
___
_CPU_Context_switch_to_first_task_smp() branches to
done_flushing which requires o3 to be initalized with
"self per-CPU control", this adds initialization of
o3. This problem only affects SMP, see commit
f8ad6c6f7f8b591e were usage of o3 was intruduced.
---
c/src/lib/libbsp/sparc/shared/irq_asm.S
Hello,
I will try to go through and comment the patches next week. I have glanced them
through and I have some comments.
Thanks,
Daniel
On 11/26/2013 09:19 AM, Sebastian Huber wrote:
---
c/src/lib/libbsp/sparc/leon3/console/console.c | 170 ++--
1 files changed, 98 in
On 11/12/2013 10:57 AM, Sebastian Huber wrote:
On 2013-11-11 14:14, Daniel Hellstrom wrote:
On 11/11/2013 11:25 AM, Sebastian Huber wrote:
On 2013-11-11 02:22, Gedare Bloom wrote:
I think perhaps the scheduler was changed and no longer matches the assumptions
of this test..
Yes, this is the
On 11/11/2013 11:31 AM, Sebastian Huber wrote:
Hello Daniel,
On 2013-11-10 17:11, Daniel Hellstrom wrote:
Hello,
Thanks Gedare and Sebastian for your input on SMP01, this was a
misunderstanding on my part. Please drop the SMP01 patch.
I will make another try to give feedback on the SMP
On 11/11/2013 11:25 AM, Sebastian Huber wrote:
On 2013-11-11 02:22, Gedare Bloom wrote:
I think perhaps the scheduler was changed and no longer matches the assumptions
of this test..
Yes, this is the case. I didn't look at the test and relied on the "END OF
TEST" messages which normally indi
By adding an extra check which CPU the tasks are actually run at
and a printout if wrong we can avoid a silent error.
---
testsuites/smptests/smp06/init.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/testsuites/smptests/smp06/init.c b/testsuites/smptests/s
Hello,
This is my findings from running some of the SMP test. The SMP06 test
seems to be correct since it matches smp06.scn file, but after reading
the test source and documentation I'm not fully convinced. I hope I'm
wrong here. And I don't know exectly how the scheduler behavior shuold
be,
checking against .scn/.doc files and verifying
the acutual exection on a quad-core LEON hardware.
Regards,
Daniel
On 11/01/2013 08:39 AM, Daniel Hellstrom wrote:
Okay, thanks! I will look into SMP01 again an come back.
Daniel
On 10/31/2013 04:01 PM, Sebastian Huber wrote:
Hello Daniel
Okay, thanks! I will look into SMP01 again an come back.
Daniel
On 10/31/2013 04:01 PM, Sebastian Huber wrote:
Hello Daniel,
thanks for the patches. I checked in all except the one modifying
smptests/smp01. Here we should first figure out what is wrong.
On 2013-10-31 14:58, Daniel
On 10/31/2013 03:17 PM, Sebastian Huber wrote:
On 2013-10-31 14:58, Daniel Hellstrom wrote:
Switch to using 32-bit variable that works better on a
32-bit CPU. This does not solve the general SMP case
though, would perhaps better to use an atomic set
here.
In case a CPU doesn't support a
---
c/src/lib/libbsp/sparc/leon3/smp/smp_leon3.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/c/src/lib/libbsp/sparc/leon3/smp/smp_leon3.c
b/c/src/lib/libbsp/sparc/leon3/smp/smp_leon3.c
index ec2b4a8..262116f 100644
--- a/c/src/lib/libbsp/sparc/leon3/smp/smp_leon3.c
+
Basically the shared-irq handler overwrite the SMP/MP traphandler
previously initialized with set_vector(). That caused IPIs to enter
BSP spurious handler.
---
c/src/lib/libbsp/sparc/shared/irq/irq-shared.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/c/src/lib/libb
Switch to using 32-bit variable that works better on a
32-bit CPU. This does not solve the general SMP case
though, would perhaps better to use an atomic set
here.
---
testsuites/smptests/smp01/init.c |6 +++---
testsuites/smptests/smp01/system.h |2 +-
testsuites/smptests/smp01/tasks.c
---
c/src/lib/libbsp/sparc/leon3/smp/smp_leon3.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/c/src/lib/libbsp/sparc/leon3/smp/smp_leon3.c
b/c/src/lib/libbsp/sparc/leon3/smp/smp_leon3.c
index f7b70f3..ec2b4a8 100644
--- a/c/src/lib/libbsp/sparc/leon3/smp/smp_leon3.c
++
There is no point having interrupts enabled before reaching
boot_card() that disables interrupt. We better have it off
all the time.
It is required to turn off interrupt on secondary CPUs in an
SMP system.
---
c/src/lib/libbsp/sparc/shared/start.S |4 ++--
1 files changed, 2 insertions(+), 2
n for this
change from bool to int.
On Thu, Oct 31, 2013 at 9:58 AM, Daniel Hellstrom wrote:
Switch to using 32-bit variable that works better on a
32-bit CPU. This does not solve the general SMP case
though, would perhaps better to use an atomic set
here.
Signed-off-by: Daniel Hell
On 10/31/2013 03:09 PM, Gedare Bloom wrote:
On Thu, Oct 31, 2013 at 9:58 AM, Daniel Hellstrom wrote:
Basically the shared-irq handler overwrite the SMP/MP traphandler
previously initialized with set_vector(). That caused IPIs to enter
BSP spurious handler.
Signed-off-by: Daniel Hellstrom
ts however we must take care by
software acking, and we can not mix edge with level. The IPI is edge in the RTEMS case and we could potentially miss an IPI by clearing.
On Thu, Oct 31, 2013 at 9:58 AM, Daniel Hellstrom wrote:
Signed-off-by: Daniel Hellstrom
---
c/src/lib/libbsp/sparc
There is no point having interrupts enabled before reaching
boot_card() that disables interrupt. We better have it off
all the time.
It is required to turn off interrupt on secondary CPUs in an
SMP system.
Signed-off-by: Daniel Hellstrom
---
c/src/lib/libbsp/sparc/shared/start.S |4 ++--
1
Switch to using 32-bit variable that works better on a
32-bit CPU. This does not solve the general SMP case
though, would perhaps better to use an atomic set
here.
Signed-off-by: Daniel Hellstrom
---
testsuites/smptests/smp01/init.c |6 +++---
testsuites/smptests/smp01/system.h |2
Basically the shared-irq handler overwrite the SMP/MP traphandler
previously initialized with set_vector(). That caused IPIs to enter
BSP spurious handler.
Signed-off-by: Daniel Hellstrom
---
c/src/lib/libbsp/sparc/shared/irq/irq-shared.c |5 +
1 files changed, 5 insertions(+), 0
Signed-off-by: Daniel Hellstrom
---
c/src/lib/libbsp/sparc/leon3/smp/smp_leon3.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/c/src/lib/libbsp/sparc/leon3/smp/smp_leon3.c
b/c/src/lib/libbsp/sparc/leon3/smp/smp_leon3.c
index f7b70f3..ec2b4a8 100644
--- a/c/src/lib
Hello,
I will send a couple of RTEMS patches, the sad thing is that I haven't got
RTEMS SMP up running yet but I think they are good anyway and can't see that
they should hurt. Besides I want to share the code.
Regards,
Daniel
---
c/src/lib/libbsp/sparc/leon3/smp/smp_leon3.c |3 +--
c
Signed-off-by: Daniel Hellstrom
---
c/src/lib/libbsp/sparc/leon3/smp/smp_leon3.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/c/src/lib/libbsp/sparc/leon3/smp/smp_leon3.c
b/c/src/lib/libbsp/sparc/leon3/smp/smp_leon3.c
index ec2b4a8..262116f 100644
--- a/c/src/lib
On 10/31/2013 02:44 PM, Sebastian Huber wrote:
On 2013-10-31 14:34, Daniel Hellstrom wrote:
On 10/31/2013 01:34 PM, Sebastian Huber wrote:
On 2013-10-31 13:21, Daniel Hellstrom wrote:
On 10/31/2013 12:38 PM, Sebastian Huber wrote:
On 2013-10-31 12:30, Daniel Hellstrom wrote:
I see that the
On 10/31/2013 01:34 PM, Sebastian Huber wrote:
On 2013-10-31 13:21, Daniel Hellstrom wrote:
On 10/31/2013 12:38 PM, Sebastian Huber wrote:
On 2013-10-31 12:30, Daniel Hellstrom wrote:
I see that the cpu_set_word_t is set to 32-bit which suites most CPUs, there is
probably a good reason for it
On 10/31/2013 01:34 PM, Sebastian Huber wrote:
On 2013-10-31 13:21, Daniel Hellstrom wrote:
On 10/31/2013 12:38 PM, Sebastian Huber wrote:
On 2013-10-31 12:30, Daniel Hellstrom wrote:
I see that the cpu_set_word_t is set to 32-bit which suites most CPUs, there is
probably a good reason for it
I couldn't help my self, I just had to search for a 16-bit SMP machine.. ;) Not that it matters at this point, but actually there are 16-bit dual-cores:
http://www.maximintegrated.com/datasheet/index.mvp/id/6140
Daniel
On 10/31/2013 01:21 PM, Daniel Hellstrom wrote:
On 10/31/2013 12:
On 10/31/2013 12:38 PM, Sebastian Huber wrote:
On 2013-10-31 12:30, Daniel Hellstrom wrote:
I see that the cpu_set_word_t is set to 32-bit which suites most CPUs, there is
probably a good reason for it but would it make sens to make it dependent on
the architecture? So that 64-bit machines have
Hello Jennifer,
I think it looks good. I have small comments and nitpicks ;)
I see that the cpu_set_word_t is set to 32-bit which suites most CPUs, there is probably a good reason for it but would it make sens to make it dependent on the architecture? So that 64-bit machines
have it sized to 64
On 10/25/2013 02:40 PM, Sebastian Huber wrote:
On 2013-10-25 14:23, Daniel Hellstrom wrote:
Interrupts are enabled in _Thread_Handler() the first time.
However on a SMP machine the secondary CPUs have enabled global
CPU interrupt in order to receive IPIs during the boot sequence.
This is a
On 10/24/2013 04:08 PM, Sebastian Huber wrote:
On 2013-10-24 15:42, Daniel Hellstrom wrote:
I can see from the running on the LEON SMP hardware and analysing with GRMON
that the init task is started and begins its execution on CPU1 before CPU0 (the
booting CPU) has finished the RTEMS
On 10/24/2013 03:52 PM, Joel Sherrill wrote:
On 10/24/2013 8:42 AM, Daniel Hellstrom wrote:
Hello,
I can see from the running on the LEON SMP hardware and analysing with GRMON
that the init task is started and begins its execution on CPU1 before CPU0 (the
booting CPU) has finished the RTEMS
On 10/24/2013 03:50 PM, Sebastian Huber wrote:
Hello Daniel,
which RTEMS version do you use?
Based on the d2c5bff7dc5a93d5369e83e5c412c3b424dee781 commit, I haven't rebased
the last three weeks. Have this been fixed?
Daniel
___
rtems-devel mailin
On 10/24/2013 03:41 PM, Sebastian Huber wrote:
On 2013-10-24 15:15, Daniel Hellstrom wrote:
From code analysis and testing SMP on LEON I can see that when installing a
trap handler the cache is not invalidated correctly on other CPUs then the CPU
installing the new trap handler. In the single
On 10/24/2013 03:33 PM, Gedare Bloom wrote:
On Thu, Oct 24, 2013 at 9:15 AM, Daniel Hellstrom wrote:
Hello,
From code analysis and testing SMP on LEON I can see that when installing a
trap handler the cache is not invalidated correctly on other CPUs then the
CPU installing the new trap
boot_card() may create READY tasks that
might also be executed is my guess if more than two CPUs are present.
It seems to me that this is a platform independent problem, or how have PPC,
Intel and ARM solved this?
Any insights on this?
Regards,
D
r CPU?
What do think about this issue?
Regards,
Daniel Hellstrom
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
On 09/19/2013 02:46 PM, Ralf Corsepius wrote:
On 09/19/2013 02:27 PM, Daniel Hellstrom wrote:
On 09/18/2013 08:52 PM, Chris Johns wrote:
Daniel Hellstrom wrote:
---
For RTEMS 4.10 branch.
cpukit/libfs/src/devfs/devfs_mknod.c |9 +++--
1 files changed, 7 insertions(+), 2
On 09/18/2013 08:52 PM, Chris Johns wrote:
Daniel Hellstrom wrote:
---
For RTEMS 4.10 branch.
cpukit/libfs/src/devfs/devfs_mknod.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/cpukit/libfs/src/devfs/devfs_mknod.c
b/cpukit/libfs/src/devfs/devfs_mknod.c
---
For RTEMS 4.10 branch.
cpukit/libfs/src/devfs/devfs_mknod.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/cpukit/libfs/src/devfs/devfs_mknod.c
b/cpukit/libfs/src/devfs/devfs_mknod.c
index d8e5a30..6df84a4 100644
--- a/cpukit/libfs/src/devfs/devfs_mknod.c
+
83 matches
Mail list logo
