Re: Driver complaint to SD Host Controller Specification 3.0
Hi all,
I have procured a RPi Model B and was testing the ported driver on the
same.
This is where it hangs.
--
*** LIBBSD SDHCI 01 TEST ***
nexus0:
bcm_dma0: on nexus0
sdhci_bcm0: on nexus0
--
It hangs because it tries to look for a mbox device,
Ideally, mbox0 should be on nexus0.
I suspect the problem is with the bus handles and the IRQs
Presently, the resource structure defined in the nexus-devices.h code is as
follows :
static const rtems_bsd_device_resource rpi_mbox_res[] = {
{
.type = RTEMS_BSD_RES_MEMORY,
.start_request = 0,
.start_actual = 0x2000B880
}, {
.type = RTEMS_BSD_RES_IRQ,
.start_request = 0,
.start_actual = BCM2835_IRQ_ID_MAILBOX_0
}
};
The value of BCM2835_IRQ_ID_MAILBOX_0 is 65 in irq.h
Is this resource structure appropriate for mbox ?
In addition to that, as Andre pointed out that from the bsd mailbox code
includes framebuffer operations, which may be redundant with the current
RPI framebuffer support.
The main benefit from the FreeBSD code may be the DMA access to the
mailboxes.
Github Link
Thanks
Mudit
On Sat, Jun 4, 2016 at 9:51 AM, Chris Johns wrote:
> On 3/06/2016 10:20 PM, Sebastian Huber wrote:
>
>> On 03/06/16 13:20, Mudit Jain wrote:
>>
>>> In the latest commit I have followed the FreeBSD port guidelines given
>>> libbsd.txt using the tools to port the code.
>>>
>>
>> Sorry for being pedantic, but please follow the guidelines exactly:
>>
>>
> I will add we have to be very precise about doing this and patches can
> only be accepted if this is the case.
>
> Sebastian, I wonder if we can automate the testing for this?
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] rtems: Fix no protocol mutex release
On 06/06/16 14:05, Pavel Pisa wrote: Hello Sebastian, On Monday 06 of June 2016 13:12:52 Sebastian Huber wrote: But if the RTEMS API is getting touched then in this regard I rise again my opinion that semaphores and mutexes should be strictly separated. This would prevent confusion and help to static code analyze tools etc. in general I agree. ... That is why I suggest to separate set of SCORE and corresponding RTEMS directives for mutexes rtems_mutex_* However, I would rather consider the Classic API as frozen. We should focus on proper support for standard APIs like C11, C++11 and POSIX threads. In addition, for SMP the object identifier approach is useless for high performance applications due to three reasons I see two possible problems when actual state is unchanged 1) it would be unfortunate if the need to keep mutexes and semaphores under rtems_semaphore would block to clean stuff and separate these in SCORE level. No, the Score level is fine now. Here mutexes and semaphores are separated. In addition I entangled the different mutex variants and moved the variant selection to the API levels. This allows more efficient use if only a particular variant is of interest, e.g. in case of internal mutexes (rework not yet done). 2) classic RTEMS API is used together with BSP API variants in BSPs and drivers code. It has been (seems like) preferred API for these areas because POSIX API has been optional and sometimes POSIX is more verbose/complex (for example building prio. inherit mutexes take quite more lines - preparing attributes etc.). So some simpler primitives would be better for these areas - it can be wrapper to pthread_mutex_ with appropriate parameters - it can be based directly on supercore - should not be directly C++ synchronization, C++ support should be optional So if the RTEMS classic API is not cleaned in mutexes respect, then there should be some guideline which API subset should be used in BSPs, drivers and RTEMS subsystems. Option is to use BSD directives if BSD compatibility layer would be included in main RTEMS repo. But even that is not ideal solution. If classic RTEMS API is not suggested for BSPs anymore then it would worth to convert all mainline included code to selected preferred solution. From my point of view, classic RTEMS API is reasonable for internal subsystems implementation. Then keeping it in shape and friendly for automatic static code analysis is important. So my proposal is to define rtems_mutex_ at least as direct alias to RTEMS binary semaphore with right flags preset forces, but flags left there for future tuning. The next step is to implement rtems_mutex right way and teach original rtems_semaphore to point to the right background primitive if it is initialized with RTEMS_BINARY_SEMAPHORE. I understand that it all is big amount of work and I cannot help much. But it would worth to discus and find some consensus what is a preferred direction. 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 currently busy with the SMP implementation, so for me this is a long term topic. It is quite labour intensive to change the status quo, so we should be clear about a future direction before we start with its realization. -- 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
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 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. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] rtems: Fix no protocol mutex release
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
Re: Driver complaint to SD Host Controller Specification 3.0
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
BSP Console Error
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: BSP Console Error
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
[PATCH] RSB: update newlib version built with gcc-4.9.3
---
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
