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
On 23/10/14 18:12, Daniel Gutson wrote:
On Thu, Oct 23, 2014 at 5:47 AM, Sebastian Huber
wrote:
>Hello Daniel,
Hi Sebastian,
>
>I never notice a problem with this driver. It should only write to the FIFO
>in case it is completely empty. Did you observe problems?
no, I didn't (actually I
Running the leon3 with grsim fails due to the patch
bsp/sparc: Ensure that data cache snooping is enabled
It looks like cache snooping is disabled when it is ran for all
the tests. Where is this supposed to be set at with this change?
jennifer
___
de
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 04:50 , Sebastian Huber
> wrote:
>
>> What does it mean "as far as possible"?
>
> I removed the as far as possible.
>
> --
I think Sebastian means:
"Implement POSIX ctime and mtime updates (as far as possible given FAT
restrictions):"
I don't think he's remove "the
On Thu, Oct 23, 2014 at 5:47 AM, Sebastian Huber
wrote:
> Hello Daniel,
Hi Sebastian,
>
> I never notice a problem with this driver. It should only write to the FIFO
> in case it is completely empty. Did you observe problems?
no, I didn't (actually I found this while looking for a serial bug
> 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 20/10/14 19:10, Gedare Bloom wrote:
What does it mean "as far as possible"?
I removed the as far as possible.
--
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...@em
Hello Daniel,
I never notice a problem with this driver. It should only write to the FIFO in
case it is completely empty. Did you observe problems?
On 21/10/14 19:32, Daniel Gutson wrote:
Hi,
in the writing interrupt mode (ns16550_write_support_int), we have
for (i = 0; i < out; ++
On 10/10/14 15:35, Jennifer Averett wrote:
Smpfatal08 fails to build on the head with the following configuration:
Should be fixed now:
http://git.rtems.org/rtems/commit/?id=b4420323ae542d42f5a3569f61c3fa1200802cf9
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puc
14 matches
Mail list logo
