On Fri, Oct 24, 2014 at 1:36 AM, Sebastian Huber
sebastian.hu...@embedded-brains.de wrote:
On 23/10/14 19:41, Gedare Bloom wrote:
We might consider removing the cache manager in favor of making dcache
flush/invalidate and icache invalidate lines part of the score/cpu
port (are they the same
On October 23, 2014 1:52:47 AM PDT, Sebastian Huber
sebastian.hu...@embedded-brains.de wrote:
On 21/10/14 04:56, Gedare Bloom wrote:
On Mon, Oct 20, 2014 at 5:11 PM, Peter Dufaultdufa...@hda.com
wrote:
On Oct 20, 2014, at 16:47 , Joel
Sherrilljoel.sherr...@oarcorp.com wrote:
However,
On 23/10/14 15:16, Joel Sherrill wrote:
On October 23, 2014 1:52:47 AM PDT, Sebastian Huber
sebastian.hu...@embedded-brains.de wrote:
On 21/10/14 04:56, Gedare Bloom wrote:
On Mon, Oct 20, 2014 at 5:11 PM, Peter Dufaultdufa...@hda.com
wrote:
On Oct 20, 2014, at 16:47 , Joel
On October 23, 2014 6:38:27 AM PDT, Sebastian Huber
sebastian.hu...@embedded-brains.de wrote:
On 23/10/14 15:16, Joel Sherrill wrote:
On October 23, 2014 1:52:47 AM PDT, Sebastian Huber
sebastian.hu...@embedded-brains.de wrote:
On 21/10/14 04:56, Gedare Bloom wrote:
On Mon, Oct 20, 2014 at
On Oct 23, 2014, at 09:38 , Sebastian Huber
sebastian.hu...@embedded-brains.de wrote:
What do you mean with return errors? Should this be a fatal error or
a
linker error?
Let's take the simplest case. A CPU with no cache control. Empty stubs is
the right implementation.
Next up
We might consider removing the cache manager in favor of making dcache
flush/invalidate and icache invalidate lines part of the score/cpu
port (are they the same across cpu's in the same arch family?)
-Gedare
On Thu, Oct 23, 2014 at 12:10 PM, Peter Dufault dufa...@hda.com wrote:
On Oct 23,
On 23/10/14 19:41, Gedare Bloom wrote:
We might consider removing the cache manager in favor of making dcache
flush/invalidate and icache invalidate lines part of the score/cpu
port (are they the same across cpu's in the same arch family?)
No, the caches are highly chip specific.
--
Sebastian
Cache manager implementations are a perennial open project.
On Mon, Oct 20, 2014 at 11:19 AM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:
On 10/20/2014 10:08 AM, Sebastian Huber wrote:
On 20/10/14 16:58, Joel Sherrill wrote:
On October 20, 2014 9:41:57 AM CDT, Sebastian Huber
On 10/20/2014 12:09 PM, Gedare Bloom wrote:
Cache manager implementations are a perennial open project.
+1
In this case,we only have ten RTEMS_CPU_MODELs which are not
addressed. There are currently two blocks of code in the file. One
is protected by this:
#if defined(ppc603) ||
If you do the legwork now, they could make reasonable GCI tasks if we
decide to participate and are accepted.
-Gedare
On Mon, Oct 20, 2014 at 1:20 PM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:
On 10/20/2014 12:09 PM, Gedare Bloom wrote:
Cache manager implementations are a perennial open
On Oct 20, 2014, at 13:20 , Joel Sherrill joel.sherr...@oarcorp.com wrote:
On 10/20/2014 12:09 PM, Gedare Bloom wrote:
Cache manager implementations are a perennial open project.
+1
In this case,we only have ten RTEMS_CPU_MODELs which are not
addressed. There are currently two blocks
On Oct 20, 2014, at 16:47 , Joel Sherrill joel.sherr...@oarcorp.com wrote:
However, should unimplemented versions return an error instead of being
a NOP? That would force one to visit code that makes assumptions.
If this is OK for the mpc55xx, feel free to submit a patch turning the
On Mon, Oct 20, 2014 at 5:11 PM, Peter Dufault dufa...@hda.com wrote:
On Oct 20, 2014, at 16:47 , Joel Sherrill joel.sherr...@oarcorp.com wrote:
However, should unimplemented versions return an error instead of being
a NOP? That would force one to visit code that makes assumptions.
If this
13 matches
Mail list logo
