On Apr 23, 2015, at 10:27 AM, Joel Sherrill wrote:
On 4/19/2015 2:17 PM, QIAO YANG wrote:
Here is a modified patch for mailbox. If there's still anything against the
convention, please point it out and I'll correct it immediately. The mailbox
implementation might also be needed by other r
On Apr 23, 2015, at 10:20 AM, Alan Cudmore wrote:
Hi Qiao,
Functionally, this code looks good to me. It builds without warnings for the Pi and Pi2, and I was able to make the calls to init the frame buffer on the Pi B+.
When you did the frame buffer test, what was your MMU table entry for th
Hi All,
First time emailing this list.
I'll chime in as a interested party with development experience.
I agree wholeheartedly with Joel.
Having a single API for all GPIO access would be great.
A few additional things to consider:
- Sometimes applications will want 'blindingly fast' access
- Gedare Bloom schrieb:
> Why do we have these two functions with similar names and commented to
> have the same functionality?
They have different commments, but yes the naming is not that brilliant.
> If one is for SMP and the other for UP,
> should they be unified or is there a good rea
- Hesham ALMatary schrieb:
> On Fri, Apr 24, 2015 at 6:38 PM, Sebastian Huber
> wrote:
> >
> > - Hesham ALMatary schrieb:
> >> ^^
> >> s/already/only
> >>
> >> Both are working fine with or1k. Let me know which is better. I'd
> >> suggest getting rid of the static declaration as sparc (
Get rid of _CPU_cache_invalidate_instruction_range declaration
as it doesn't make sense here.
---
c/src/lib/libcpu/shared/include/cache.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/c/src/lib/libcpu/shared/include/cache.h
b/c/src/lib/libcpu/shared/include/cache.h
index d9df423..2699791 100
On Fri, Apr 24, 2015 at 6:38 PM, Sebastian Huber
wrote:
>
> - Hesham ALMatary schrieb:
>> ^^
>> s/already/only
>>
>> Both are working fine with or1k. Let me know which is better. I'd
>> suggest getting rid of the static declaration as sparc (the only other
>> CPU that empty-implements the sam
- Hesham ALMatary schrieb:
> ^^
> s/already/only
>
> Both are working fine with or1k. Let me know which is better. I'd
> suggest getting rid of the static declaration as sparc (the only other
> CPU that empty-implements the same function) implements it without
> "static".
>
Providing an em
- Hesham ALMatary schrieb:
> Gedare,
>
> The corresponding function declaration and implementation are included
> from libcpu/shared. There are two solutions to fix this for the all
> broken BSPs:
> 1- Get rid of _CPU_cache_invalidate_instruction_range declaration at
> libcpu/shared/include/
^^
s/already/only
Both are working fine with or1k. Let me know which is better. I'd
suggest getting rid of the static declaration as sparc (the only other
CPU that empty-implements the same function) implements it without
"static".
On Fri, Apr 24, 2015 at 6:20 PM, Hesham ALMatary
wrote:
> Gedar
Gedare,
The corresponding function declaration and implementation are included
from libcpu/shared. There are two solutions to fix this for the all
broken BSPs:
1- Get rid of _CPU_cache_invalidate_instruction_range declaration at
libcpu/shared/include/cache.h, since this functions is already called
On 4/24/2015 12:07 PM, Hesham ALMatary wrote:
> Hi,
>
> I believe this commit is the one which broke it [1], I'm going to
> discard the usage of the shared cache_manager.c file and provide or1k
> with private stubs.
>
> [1]
> https://github.com/RTEMS/rtems/commit/26c142e5ad4a63ad42baa17159c1821a
On 4/24/2015 11:48 AM, Ben Gras wrote:
> All,
>
> Big improvement. The video shows that the bit logic for setting &
> clearing is likely sound - for the first byte at least ;-). Good test.
>
> My comments about the code are
> - gpio_select_pin write a whole 0 byte instead of updating a single
>
Wouldn't it be better to fix the or1k function declarations unless
there is going to be or1k-specific implementation provided?
On Fri, Apr 24, 2015 at 1:07 PM, Hesham ALMatary
wrote:
> Hi,
>
> I believe this commit is the one which broke it [1], I'm going to
> discard the usage of the shared cach
Hi,
I believe this commit is the one which broke it [1], I'm going to
discard the usage of the shared cache_manager.c file and provide or1k
with private stubs.
[1]
https://github.com/RTEMS/rtems/commit/26c142e5ad4a63ad42baa17159c1821afe473a00
On Fri, Apr 24, 2015 at 5:16 PM, Joel Sherrill
wrot
All,
Big improvement. The video shows that the bit logic for setting &
clearing is likely sound - for the first byte at least ;-). Good test.
My comments about the code are
- gpio_select_pin write a whole 0 byte instead of updating a single
bit, as we talked about on IRC
- gedare's suggestion
Hi
Multiple BSPs failed to build in my overnight sweep. All
bfin and or1k BSPs plus 18 m68k failed with this:
../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:340:1:
error: static declaration of '_CPU_cache_invalidate_instruction_range'
follows non-static declaratio
Why do we have these two functions with similar names and commented to
have the same functionality? If one is for SMP and the other for UP,
should they be unified or is there a good reason to have separate
functions?
On Fri, Apr 24, 2015 at 2:42 AM, Sebastian Huber wrote:
> Module:rtems
> Bra
On Fri, Apr 24, 2015 at 3:13 AM, Sebastian Huber
wrote:
>
>
> On 24/04/15 09:11, Chris Johns wrote:
>>>
>>> >For the tools I propose to use GCC 4.9.3 (should get released soon) and
>>> >the next Newlib snapshot.
>>> >
>>
>> Snapshot name ?
>
>
> Its not available yet, but we are close to the end o
On 24/04/15 09:11, Chris Johns wrote:
>For the tools I propose to use GCC 4.9.3 (should get released soon) and
>the next Newlib snapshot.
>
Snapshot name ?
Its not available yet, but we are close to the end of the month.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-8
On 24/04/2015 5:02 pm, Sebastian Huber wrote:
> With the fix for the POSIX thread join (it took only three years to fix
> the bug) I am done with 4.11. Everything else can wait after the branch.
Excellent and yes.
>
> For the tools I propose to use GCC 4.9.3 (should get released soon) and
> the
With the fix for the POSIX thread join (it took only three years to fix
the bug) I am done with 4.11. Everything else can wait after the branch.
For the tools I propose to use GCC 4.9.3 (should get released soon) and
the next Newlib snapshot.
On 24/04/15 02:39, Chris Johns wrote:
Hello,
I w
22 matches
Mail list logo
