[PATCH] RSB: update newlib version built with gcc-4.9.3

[Hesham Almatary]

---
 rtems/config/tools/rtems-gcc-4.9.3-newlib-2.4.0-1.cfg | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/rtems/config/tools/rtems-gcc-4.9.3-newlib-2.4.0-1.cfg 
b/rtems/config/tools/rtems-gcc-4.9.3-newlib-2.4.0-1.cfg
index 596a4a7..42f6cfa 100644
--- a/rtems/config/tools/rtems-gcc-4.9.3-newlib-2.4.0-1.cfg
+++ b/rtems/config/tools/rtems-gcc-4.9.3-newlib-2.4.0-1.cfg
@@ -3,10 +3,10 @@
 #
 
 %define gcc_version4.9.3
-%define newlib_version 2.4.0
+%define newlib_version 2.4.0.20160527
 
 %hash md5 gcc-%{gcc_version}.tar.bz2 6f831b4d251872736e8e9cc09746f327
-%hash sha512 newlib-2.4.0.tar.gz 
c60665e793dce2368a5baf23560beb50f641e1831854d702d1d7629fb6e9200cf814527f29796792a3d2dff81afee4255723df99ceb0732f99dd9580a17d2ac0
+%hash sha512 newlib-2.4.0.20160527.tar.gz 
09d0c8ac2a657e910eebfeeb7e5fcc6956591223fe499ed4717b5e719287148fc35e80835821fb5b6b586e371100737a7765a03c43f0c194cf67892484132d3f
 
 #
 # The gcc/newlib build instructions.
-- 
2.8.0.rc3

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: BSP Console Error

[Hesham Almatary]

Hi Habeeb,

You can debug deeper and try to single step in
_Linker_set__Sysinit_rtems_libio_post_driver function and see where it
fails. Also building with -O0 might help until you are sure it's
working, you can re-enable optimization. Regarding the stack, there is
a CONFIGURE_STACK_CHECKER_ENABLED option that you can add, I sometimes
found it useful to catch stack corruption.

On Wed, Jun 8, 2016 at 4:47 AM, Olufowobi, Habeeb
 wrote:
> Hi,
>
> I have been able to build my new BSP and currently trying run HelloWorld
> with OpenOCD and gdb.
>
> Following is the error message I'm getting when I run hello.exe and not sure
> how to debug this error.
>
> Any idea about this issue and how to debug it?
>
> #0  0x47ee in _Terminate (
> the_source=the_source@entry=RTEMS_FATAL_SOURCE_EXCEPTION,
> is_internal=is_internal@entry=false, the_error=536874968)
> at
> ../../../../../../../rtems.git/c/src/../../cpukit/score/src/interr.c:52
> #1  0x3d16 in rtems_fatal (
> source=source@entry=RTEMS_FATAL_SOURCE_EXCEPTION,
> error=)
> at
> ../../../../../../../rtems.git/c/src/../../cpukit/sapi/src/fatal2.c:34
> #2  0x786e in _ARM_Exception_default (frame=)
> at
> ../../../../../../../../../rtems.git/c/src/../../cpukit/score/cpu/arm/arm-exception-default.c:24
> #3  
> #4  0x in bsp_start_vector_table_begin ()
> #5  0xf2d0 in _Linker_set__Sysinit_rtems_libio_post_driver ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> Regards,
> Habeeb



-- 
Hesham
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

BSP Console Error

[Olufowobi, Habeeb]

Hi,

I have been able to build my new BSP and currently trying run HelloWorld
with OpenOCD and gdb.

Following is the error message I'm getting when I run hello.exe and not
sure how to debug this error.

Any idea about this issue and how to debug it?

#0  0x47ee in _Terminate (
the_source=the_source@entry=RTEMS_FATAL_SOURCE_EXCEPTION,
is_internal=is_internal@entry=false, the_error=536874968)
at
../../../../../../../rtems.git/c/src/../../cpukit/score/src/interr.c:52
#1  0x3d16 in rtems_fatal (
source=source@entry=RTEMS_FATAL_SOURCE_EXCEPTION,
error=)
at
../../../../../../../rtems.git/c/src/../../cpukit/sapi/src/fatal2.c:34
#2  0x786e in _ARM_Exception_default (frame=)
at
../../../../../../../../../rtems.git/c/src/../../cpukit/score/cpu/arm/arm-exception-default.c:24
#3  
#4  0x in bsp_start_vector_table_begin ()
#5  0xf2d0 in _Linker_set__Sysinit_rtems_libio_post_driver ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Regards,
Habeeb
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Driver complaint to SD Host Controller Specification 3.0

[Sebastian Huber]

On 04/06/16 06:09, Mudit Jain wrote:


Apologies regarding that.


No need to apology, but please try to improve the guideline if something 
is unclear. If you don't understand something or there is something 
unclear or not reasonable, then please ask questions.




Some of the lines that showed '-' were because changes were committed 
on the old changes which were not right.


However, I have created a new branch where the commits are much cleaner.

https://github.com/spark1729/rtems-libbsd/commits/RPI_SD



No newline at end of file:

https://github.com/spark1729/rtems-libbsd/commit/1e8e641775d4d6435a3d155206621c52b90e1eee#diff-71442c70cefab28213f6e8080c5a9519R781

Modification out of __rtems__ block:

https://github.com/spark1729/rtems-libbsd/commit/1e8e641775d4d6435a3d155206621c52b90e1eee#diff-a9a272cfca9ab384d48a0627dcb506f2R63

This BUS_SPACE_PHYSADDR() seems to be a candidate for a more general header.

Coding style:

https://github.com/spark1729/rtems-libbsd/commit/1e8e641775d4d6435a3d155206621c52b90e1eee#diff-5241dafbec607e4b3db0d47fd8ae4148R195

--
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...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rtems: Fix no protocol mutex release

[Sebastian Huber]

On 07/06/16 09:48, Chris Johns wrote:

On 07/06/2016 17:31, Sebastian Huber wrote:

Yes, its definitely worth to discuss this. My preferred solution would
be to go away from the objects and treat the Classic objects as a legacy
component.


I am not sure about the term legacy component but I see what you are 
saying. For new application user have a range of alternatives to 
choose from and these are not fully proven or in a release. I am not 
sure what sort of footprint they have as I have not seen any real data 
so are they suitable for small memory devices?


The C++11 non-recursive mutex with full SMP support and priority 
inheritance (OMIP in the future) needs on a 32-bit machine 16 bytes 
(could be 12 bytes, if we use an MCS lock instead of the ticket lock). 
Initialization is a simple memset().




The Classic API has a wide user base and there is a lot of code using 
it and some has a long life cycle. I do not see the Classic API going 
away in the near, medium or long term. If there is a way to improve 
the existing Classic API via a separate mutex then we should consider 
it. I think this is a good idea. It is cleaner and less likely to 
cause the errors we are seeing.


I didn't ever mention to remove the Classic API. My point is that the 
Classic API has some inherent weaknesses by design that makes it 
unsuitable for use in high performance SMP systems and low end systems. 
It leads also to complex configuration issues for device driver 
resources that frequently pop up on the mailing list.


--
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...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel