On Fri, Oct 24, 2014 at 1:36 AM, Sebastian Huber
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 across cpu's in the same ar
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
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 wrote:
>
>> On Oct 23, 2014, at 09:38 ,
> On Oct 23, 2014, at 09:38 , Sebastian Huber
> 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 is just enab
On October 23, 2014 6:38:27 AM PDT, Sebastian Huber
wrote:
>On 23/10/14 15:16, Joel Sherrill wrote:
>>
>>
>> On October 23, 2014 1:52:47 AM PDT, Sebastian Huber
> wrote:
>>> On 21/10/14 04:56, Gedare Bloom wrote:
On Mon, Oct 20, 2014 at 5:11 PM, Peter Dufault
>>> wrote:
>>
On
On 23/10/14 15:16, Joel Sherrill wrote:
On October 23, 2014 1:52:47 AM PDT, Sebastian Huber
wrote:
On 21/10/14 04:56, Gedare Bloom wrote:
On Mon, Oct 20, 2014 at 5:11 PM, Peter Dufault
wrote:
On Oct 20, 2014, at 16:47 , Joel
Sherrill wrote:
However, should unimplemented versions re
On October 23, 2014 1:52:47 AM PDT, Sebastian Huber
wrote:
>On 21/10/14 04:56, Gedare Bloom wrote:
>> On Mon, Oct 20, 2014 at 5:11 PM, Peter Dufault
>wrote:
>>> >
>>On Oct 20, 2014, at 16:47 , Joel
>Sherrill wrote:
>>
> >>>However, should unimplemented versions return an error i
On 21/10/14 04:56, Gedare Bloom wrote:
On Mon, Oct 20, 2014 at 5:11 PM, Peter Dufault wrote:
>
>>On Oct 20, 2014, at 16:47 , Joel Sherrill wrote:
>>
>>>However, should unimplemented versions return an error instead of being
>>>a NOP? That would force one to visit code that makes assumptions
On Mon, Oct 20, 2014 at 5:11 PM, Peter Dufault wrote:
>
>> On Oct 20, 2014, at 16:47 , Joel Sherrill 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, fe
> On Oct 20, 2014, at 16:47 , Joel Sherrill 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
> warning off for it.
On October 20, 2014 3:41:06 PM CDT, Peter Dufault wrote:
>
>> On Oct 20, 2014, at 13:20 , Joel Sherrill
>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 whic
> On Oct 20, 2014, at 13:20 , Joel Sherrill 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 of code in the
On 10/20/2014 12:29 PM, Gedare Bloom wrote:
> If you do the legwork now, they could make reasonable GCI tasks if we
> decide to participate and are accepted.
And in this case, by the time I did the legwork, I could fix them.
The legwork is 97.5% of this. :)
Find the manual for the CPU, look up HI
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
wrote:
>
> On 10/20/2014 12:09 PM, Gedare Bloom wrote:
>> Cache manager implementations are a perennial open project.
> +1
>
> In th
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) || defined(ppc60
Cache manager implementations are a perennial open project.
On Mon, Oct 20, 2014 at 11:19 AM, Joel Sherrill
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
>>> wrote:
Since nobo
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
>> wrote:
>>> Since nobody missed the unimplemented cache manager functions in
>>> several years
>>> it should be safe so simply remove this #warning
On 20/10/14 16:58, Joel Sherrill wrote:
On October 20, 2014 9:41:57 AM CDT, Sebastian Huber
wrote:
Since nobody missed the unimplemented cache manager functions in
several years
it should be safe so simply remove this #warning.
You didn't notice it for qoriq or e500 so years is an exaggera
On October 20, 2014 9:41:57 AM CDT, Sebastian Huber
wrote:
>Since nobody missed the unimplemented cache manager functions in
>several years
>it should be safe so simply remove this #warning.
You didn't notice it for qoriq or e500 so years is an exaggeration for some
models.
Take a look at t
Since nobody missed the unimplemented cache manager functions in several years
it should be safe so simply remove this #warning.
--
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 : seba
20 matches
Mail list logo
