ANN: RTEMS open class in Munich/Germany, 15.-17. June 2015
Hello, we are currently planning another open RTEMS class in Munich/Germany to start on June 15th, 2015. Maybe you or some of your colleagues like to join in? See our updated website http://www.embedded-brains.de/en/rtems-real-time-operating-system/rtems-training-courses/ for more details. Please send us an email or use the website form if you and/or your colleagues are interested to attend, so we can reserve seats for you. wkr, Thomas Doerfler. -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 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
GSOC 2015: Raspberry Pi Low Level Peripherals and SD Card
Hello everyone, My GSoC proposal entitled "Raspberry Pi Low Level Peripherals and SD Card" can be found for review at: https://docs.google.com/document/d/11K0qU3OsbSMhNYkTTWt4kitAbd6uuJBcMfA_07Lg6j8 One issue I would like to discuss here is related to the SD card support, which as exposed on the proposal the GPIOs to which the SD card is connected internally do not have SPI hardware capabilities, meaning that to access the card via SPI mode it would have to be bit-banged on those GPIOs (a problem on performance). This is more detailed on the proposal, but another alternative would be to use the SD mode instead, with the help of the PI's EMMC module, and the SD simplified specifications as documentation for the SD protocol. I have already used this setup with success in the past, and it should have better performance. In this setup the FreeBSD SD/MMC stack may be used (such as the one Sebastian Huber ported last year -> https://git.rtems.org/sebh/rtems-libusb.git/tree/rtems/freebsd/dev/mmc?id=3c82a1500da3192de2504a1360e065fd84a1f3a0) which implements the SD protocol also based on the simplified specs. This would help avoiding implementing the protocol from scratch (which is sort of what I did in my previous effort with the SD card and the PI) and would be better for maintenance probably. My issue is then on the feasibily (licence wise) of having the FreeBSD SD stack or having code based on the SD Simplified Specs on the RTEMS tree. In SPI mode an implementation of the protocol can be found in libchip/i2c/spi-sd-card.*, which could in that case be used/improved further during the project, if it is decided it is best to use SPI mode. This uses the libi2c API, which is deprecated for I2C but, as I understand, still stands as the API for SPI (information about that would also be appreciated). Thanks, André Marques. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] sparc: Ensure interrupt service after ISR enable
---
cpukit/score/cpu/sparc/rtems/score/sparc.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/cpukit/score/cpu/sparc/rtems/score/sparc.h
b/cpukit/score/cpu/sparc/rtems/score/sparc.h
index ac8c510..45df6ff 100644
--- a/cpukit/score/cpu/sparc/rtems/score/sparc.h
+++ b/cpukit/score/cpu/sparc/rtems/score/sparc.h
@@ -320,7 +320,14 @@ static inline uint32_t sparc_disable_interrupts(void)
static inline void sparc_enable_interrupts(uint32_t psr)
{
register uint32_t _psr __asm__("g1") = psr; /* input to trap handler */
- __asm__ volatile ( "ta %0\n" :: "i" (SPARC_SWTRAP_IRQEN), "r" (_psr));
+
+ /*
+ * The trap instruction has a higher trap priority than the interrupts
+ * according to "The SPARC Architecture Manual: Version 8", Table 7-1
+ * "Exception and Interrupt Request Priority and tt Values". Add a nop to
+ * prevent a trap instruction right after the interrupt enable trap.
+ */
+ __asm__ volatile ( "ta %0\nnop\n" :: "i" (SPARC_SWTRAP_IRQEN), "r" (_psr));
}
/**
--
1.8.4.5
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] sparc: Ensure interrupt service after ISR enable
Looks good. Please apply it.
danielh
On 03/25/2015 11:42 AM, Sebastian Huber wrote:
---
cpukit/score/cpu/sparc/rtems/score/sparc.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/cpukit/score/cpu/sparc/rtems/score/sparc.h
b/cpukit/score/cpu/sparc/rtems/score/sparc.h
index ac8c510..45df6ff 100644
--- a/cpukit/score/cpu/sparc/rtems/score/sparc.h
+++ b/cpukit/score/cpu/sparc/rtems/score/sparc.h
@@ -320,7 +320,14 @@ static inline uint32_t sparc_disable_interrupts(void)
static inline void sparc_enable_interrupts(uint32_t psr)
{
register uint32_t _psr __asm__("g1") = psr; /* input to trap handler */
- __asm__ volatile ( "ta %0\n" :: "i" (SPARC_SWTRAP_IRQEN), "r" (_psr));
+
+ /*
+ * The trap instruction has a higher trap priority than the interrupts
+ * according to "The SPARC Architecture Manual: Version 8", Table 7-1
+ * "Exception and Interrupt Request Priority and tt Values". Add a nop to
+ * prevent a trap instruction right after the interrupt enable trap.
+ */
+ __asm__ volatile ( "ta %0\nnop\n" :: "i" (SPARC_SWTRAP_IRQEN), "r" (_psr));
}
/**
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2015: Review Proposal for Configuration GUI
Attaching the google docs link as well: https://docs.google.com/document/d/1OOKr9px9yYtAjUvLJM1_Js4xxsg_fXxnN3AWaf3IUp0/edit?usp=sharing Thanks! Anand On Wed, Mar 25, 2015 at 8:49 AM, Anand Krishnan wrote: > Dear Mentors and students, > > It'd be great if you could review my proposal. I am planning to build a > Configuration GUI for RTEMS - used for configuring RTEMS during waf build. > > > http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/anandkp92/5629499534213120 > > Any comments and reviews are welcome! > > Thank You, > Anand > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Fwd: Recursive calloc() due to optimization
A nice surprise with GCC 5:
Forwarded Message
Subject:Recursive calloc() due to optimization
Date: Wed, 25 Mar 2015 12:32:58 +0100
From: Sebastian Huber
To: gcc-h...@gcc.gnu.org
Hello,
I updated to GCC 5 and now it turns the RTEMS calloc() implementation into
Disassembly of section .text:
:
0: fb01 f000 mul.w r0, r1, r0
4: 2101movsr1, #1
6: f7ff bffe b.w 0
a: bf00nop
on ARM. How can I disable this optimization? I tried
__attribute__((__optimize__("-fno-builtin")))
void *calloc(
size_t nelem,
size_t elsize
)
{
char *cptr;
size_t length;
length = nelem * elsize;
cptr = malloc( length );
if ( cptr )
memset( cptr, '\0', length );
return cptr;
}
but this doesn't work. It this one of the -fno-tree-* options?
--
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: GSOC 2015: Review Proposal for Configuration GUI
Dear, How can i share my proposal on RTEMS table with mentors? or just upload it in Google Summer of Code account. It's the first time to apply please help me. Best Reagrds On Wed, Mar 25, 2015 at 1:15 PM, Anand Krishnan wrote: > Attaching the google docs link as well: > https://docs.google.com/document/d/1OOKr9px9yYtAjUvLJM1_Js4xxsg_fXxnN3AWaf3IUp0/edit?usp=sharing > > Thanks! > Anand > > On Wed, Mar 25, 2015 at 8:49 AM, Anand Krishnan > wrote: > >> Dear Mentors and students, >> >> It'd be great if you could review my proposal. I am planning to build a >> Configuration GUI for RTEMS - used for configuring RTEMS during waf build. >> >> >> http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/anandkp92/5629499534213120 >> >> Any comments and reviews are welcome! >> >> Thank You, >> Anand >> > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2015: Review Proposal for Configuration GUI
Hi, Create an account on RTEMS page, login using it to the tracking page and then you will find the link at the bottom of the page to edit the page. Go to that and edit the table and paste the link to your proposal google doc. Make sure it's visible to your mentors or make it public. All the best, Regards, Anand On Wed, Mar 25, 2015, 7:03 PM abd el-hamed Amer wrote: > Dear, > > How can i share my proposal on RTEMS table with mentors? or just upload it > in Google Summer of Code account. It's the first time to apply please help > me. > > Best Reagrds > > On Wed, Mar 25, 2015 at 1:15 PM, Anand Krishnan > wrote: > >> Attaching the google docs link as well: >> https://docs.google.com/document/d/1OOKr9px9yYtAjUvLJM1_Js4xxsg_fXxnN3AWaf3IUp0/edit?usp=sharing >> >> Thanks! >> Anand >> >> On Wed, Mar 25, 2015 at 8:49 AM, Anand Krishnan >> wrote: >> >>> Dear Mentors and students, >>> >>> It'd be great if you could review my proposal. I am planning to build a >>> Configuration GUI for RTEMS - used for configuring RTEMS during waf build. >>> >>> >>> http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/anandkp92/5629499534213120 >>> >>> Any comments and reviews are welcome! >>> >>> Thank You, >>> Anand >>> >> >> >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel >> > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2015: Review Proposal for Configuration GUI
Dear Anand, Thanks a lot, How can i set it to be visible to mentors(I just know mentor name)? Regards, Abdelhamid On Wed, Mar 25, 2015 at 3:41 PM, Anand Krishnan wrote: > Hi, > > Create an account on RTEMS page, login using it to the tracking page and > then you will find the link at the bottom of the page to edit the page. Go > to that and edit the table and paste the link to your proposal google doc. > Make sure it's visible to your mentors or make it public. > > All the best, > Regards, > Anand > > On Wed, Mar 25, 2015, 7:03 PM abd el-hamed Amer < > eng.abdoamer2...@gmail.com> wrote: > >> Dear, >> >> How can i share my proposal on RTEMS table with mentors? or just upload >> it in Google Summer of Code account. It's the first time to apply please >> help me. >> >> Best Reagrds >> >> On Wed, Mar 25, 2015 at 1:15 PM, Anand Krishnan >> wrote: >> >>> Attaching the google docs link as well: >>> https://docs.google.com/document/d/1OOKr9px9yYtAjUvLJM1_Js4xxsg_fXxnN3AWaf3IUp0/edit?usp=sharing >>> >>> Thanks! >>> Anand >>> >>> On Wed, Mar 25, 2015 at 8:49 AM, Anand Krishnan >>> wrote: >>> Dear Mentors and students, It'd be great if you could review my proposal. I am planning to build a Configuration GUI for RTEMS - used for configuring RTEMS during waf build. http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/anandkp92/5629499534213120 Any comments and reviews are welcome! Thank You, Anand >>> >>> >>> ___ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel >>> >> >> ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2015: Review proposal for Beagle BSP improvements: Booting without U-boot
Looks pretty good. I have the same basic comment I give most students, which is that you should try to flesh out some more details about what exactly you will be doing, i.e. what code you might be able to use, what your software architecture may look like, draw some diagrams to clarify concepts, and so on. Gedare On Tue, Mar 24, 2015 at 11:43 PM, Jarielle Catbagan wrote: > Hello all: > > Below is the link to my proposal. Please feel free to make any > comments and/or suggestions. > > https://docs.google.com/document/d/1pGQ60e5A4JcXl9_gkBEutIgb6AhiQ00MPJN6J1rSKT8/edit?usp=sharing > > Thank you! > > Best Regards, > > Jarielle Catbagan > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2015: Raspberry Pi Low Level Peripherals and SD Card
On Wed, Mar 25, 2015 at 4:49 AM, André Marques wrote: > Hello everyone, > > My GSoC proposal entitled "Raspberry Pi Low Level Peripherals and SD Card" > can be found for review at: > > https://docs.google.com/document/d/11K0qU3OsbSMhNYkTTWt4kitAbd6uuJBcMfA_07Lg6j8 > > One issue I would like to discuss here is related to the SD card support, > which as exposed on the proposal the GPIOs to which the SD card is connected > internally do not have SPI hardware capabilities, meaning that to access the > card via SPI mode it would have to be bit-banged on those GPIOs (a problem > on performance). This is more detailed on the proposal, but another > alternative would be to use the SD mode instead, with the help of the PI's > EMMC module, and the SD simplified specifications as documentation for the > SD protocol. I have already used this setup with success in the past, and it > should have better performance. In this setup the FreeBSD SD/MMC stack may > be used (such as the one Sebastian Huber ported last year -> > https://git.rtems.org/sebh/rtems-libusb.git/tree/rtems/freebsd/dev/mmc?id=3c82a1500da3192de2504a1360e065fd84a1f3a0) Is this code in the libbsd.git now? > which implements the SD protocol also based on the simplified specs. This > would help avoiding implementing the protocol from scratch (which is sort of > what I did in my previous effort with the SD card and the PI) and would be > better for maintenance probably. > > My issue is then on the feasibily (licence wise) of having the FreeBSD SD > stack or having code based on the SD Simplified Specs on the RTEMS tree. > FreeBSD code should be fine. The complexity of getting libbsd working could be the real stumbling block. But I think others will be working on the same problem too, so there may be some ability to share knowledge. > In SPI mode an implementation of the protocol can be found in > libchip/i2c/spi-sd-card.*, which could in that case be used/improved further > during the project, if it is decided it is best to use SPI mode. This uses > the libi2c API, which is deprecated for I2C but, as I understand, still > stands as the API for SPI (information about that would also be > appreciated). > It's just the no one has replaced it yet! There seem to be multiple efforts going on now to get more driver-like frameworks into RTEMS. > Thanks, > André Marques. > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2015: Review Proposal for Configuration GUI
If you copied from the template and used the same sharing settings, it should just work. Gedare On Wed, Mar 25, 2015 at 9:52 AM, abd el-hamed Amer wrote: > Dear Anand, > > Thanks a lot, How can i set it to be visible to mentors(I just know mentor > name)? > > Regards, > Abdelhamid > > On Wed, Mar 25, 2015 at 3:41 PM, Anand Krishnan wrote: >> >> Hi, >> >> Create an account on RTEMS page, login using it to the tracking page and >> then you will find the link at the bottom of the page to edit the page. Go >> to that and edit the table and paste the link to your proposal google doc. >> Make sure it's visible to your mentors or make it public. >> >> All the best, >> Regards, >> Anand >> >> >> On Wed, Mar 25, 2015, 7:03 PM abd el-hamed Amer >> wrote: >>> >>> Dear, >>> >>> How can i share my proposal on RTEMS table with mentors? or just upload >>> it in Google Summer of Code account. It's the first time to apply please >>> help me. >>> >>> Best Reagrds >>> >>> On Wed, Mar 25, 2015 at 1:15 PM, Anand Krishnan >>> wrote: Attaching the google docs link as well: https://docs.google.com/document/d/1OOKr9px9yYtAjUvLJM1_Js4xxsg_fXxnN3AWaf3IUp0/edit?usp=sharing Thanks! Anand On Wed, Mar 25, 2015 at 8:49 AM, Anand Krishnan wrote: > > Dear Mentors and students, > > It'd be great if you could review my proposal. I am planning to build a > Configuration GUI for RTEMS - used for configuring RTEMS during waf build. > > > http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/anandkp92/5629499534213120 > > Any comments and reviews are welcome! > > Thank You, > Anand ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel >>> >>> > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2015: Raspberry Pi Low Level Peripherals and SD Card
On March 25, 2015 9:17:51 AM CDT, Gedare Bloom wrote: >On Wed, Mar 25, 2015 at 4:49 AM, André Marques > wrote: >> Hello everyone, >> >> My GSoC proposal entitled "Raspberry Pi Low Level Peripherals and SD >Card" >> can be found for review at: >> >> >https://docs.google.com/document/d/11K0qU3OsbSMhNYkTTWt4kitAbd6uuJBcMfA_07Lg6j8 >> >> One issue I would like to discuss here is related to the SD card >support, >> which as exposed on the proposal the GPIOs to which the SD card is >connected >> internally do not have SPI hardware capabilities, meaning that to >access the >> card via SPI mode it would have to be bit-banged on those GPIOs (a >problem >> on performance). This is more detailed on the proposal, but another >> alternative would be to use the SD mode instead, with the help of the >PI's >> EMMC module, and the SD simplified specifications as documentation >for the >> SD protocol. I have already used this setup with success in the past, >and it >> should have better performance. In this setup the FreeBSD SD/MMC >stack may >> be used (such as the one Sebastian Huber ported last year -> >> >https://git.rtems.org/sebh/rtems-libusb.git/tree/rtems/freebsd/dev/mmc?id=3c82a1500da3192de2504a1360e065fd84a1f3a0) >Is this code in the libbsd.git now? > >> which implements the SD protocol also based on the simplified specs. >This >> would help avoiding implementing the protocol from scratch (which is >sort of >> what I did in my previous effort with the SD card and the PI) and >would be >> better for maintenance probably. >> >> My issue is then on the feasibily (licence wise) of having the >FreeBSD SD >> stack or having code based on the SD Simplified Specs on the RTEMS >tree. >> >FreeBSD code should be fine. The complexity of getting libbsd working >could be the real stumbling block. But I think others will be working >on the same problem too, so there may be some ability to share >knowledge. The USB stack works at least for removable media and the TCP/IP stack has been reported to do GigE wirespeed on a couple of platforms. It just doesn't have all the target support the old stack already does. And it is larger than the old stack. There may be room for two implementations if the license and portability are ok. >> In SPI mode an implementation of the protocol can be found in >> libchip/i2c/spi-sd-card.*, which could in that case be used/improved >further >> during the project, if it is decided it is best to use SPI mode. This >uses >> the libi2c API, which is deprecated for I2C but, as I understand, >still >> stands as the API for SPI (information about that would also be >> appreciated). >> >It's just the no one has replaced it yet! There seem to be multiple >efforts going on now to get more driver-like frameworks into RTEMS. > >> Thanks, >> André Marques. >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel >___ >devel mailing list >devel@rtems.org >http://lists.rtems.org/mailman/listinfo/devel --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
GSOC 2015 Proposal Review: Monkey HTTP server
Dear community members, I successfully uploaded my proposal for GSOC 2015 at http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/sujayraaj/5629499534213120 I welcome you all for any reviews/suggestions/criticism for the same. The proposal is public. With regards, Sujay Raj ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
GSOC and ESA SOCIS
Hi Only two days left to apply to GSOC. The ESA SOCIS application period is now open. If you are qualified based on their rules, please apply to both the SOCIS and GSOC. Get those applications in! -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC and ESA SOCIS
P.S. mentors feel free to sign-up for GSoC. We have lots of interesting project proposals this year, does one catch your eye? https://devel.rtems.org/wiki/GSoC/2015 On Wed, Mar 25, 2015 at 12:24 PM, Joel Sherrill wrote: > Hi > > Only two days left to apply to GSOC. > > The ESA SOCIS application period is now open. If you are qualified > based on their rules, please apply to both the SOCIS and GSOC. > > Get those applications in! > > -- > Joel Sherrill, Ph.D. Director of Research & Development > joel.sherr...@oarcorp.comOn-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available(256) 722-9985 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
dosfs on targets without iconv
Hi newlib has the iconv header files but on the h8300 at least the code is not built. The dosfs still uses it so you get undefined symbols in those tests. Is it possible to build the dosfs without iconv support easily? Or should I just disable these tests for that target. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2015: Raspberry Pi Low Level Peripherals and SD Card
On 25-03-2015 14:17, Gedare Bloom wrote: On Wed, Mar 25, 2015 at 4:49 AM, André Marques wrote: Hello everyone, My GSoC proposal entitled "Raspberry Pi Low Level Peripherals and SD Card" can be found for review at: https://docs.google.com/document/d/11K0qU3OsbSMhNYkTTWt4kitAbd6uuJBcMfA_07Lg6j8 One issue I would like to discuss here is related to the SD card support, which as exposed on the proposal the GPIOs to which the SD card is connected internally do not have SPI hardware capabilities, meaning that to access the card via SPI mode it would have to be bit-banged on those GPIOs (a problem on performance). This is more detailed on the proposal, but another alternative would be to use the SD mode instead, with the help of the PI's EMMC module, and the SD simplified specifications as documentation for the SD protocol. I have already used this setup with success in the past, and it should have better performance. In this setup the FreeBSD SD/MMC stack may be used (such as the one Sebastian Huber ported last year -> https://git.rtems.org/sebh/rtems-libusb.git/tree/rtems/freebsd/dev/mmc?id=3c82a1500da3192de2504a1360e065fd84a1f3a0) Is this code in the libbsd.git now? It is not, only on Sebastian's repository. It was anounced here along with an USB host stack: https://lists.rtems.org/pipermail/devel/2014-August/007873.html which implements the SD protocol also based on the simplified specs. This would help avoiding implementing the protocol from scratch (which is sort of what I did in my previous effort with the SD card and the PI) and would be better for maintenance probably. My issue is then on the feasibily (licence wise) of having the FreeBSD SD stack or having code based on the SD Simplified Specs on the RTEMS tree. FreeBSD code should be fine. The complexity of getting libbsd working could be the real stumbling block. But I think others will be working on the same problem too, so there may be some ability to share knowledge. In SPI mode an implementation of the protocol can be found in libchip/i2c/spi-sd-card.*, which could in that case be used/improved further during the project, if it is decided it is best to use SPI mode. This uses the libi2c API, which is deprecated for I2C but, as I understand, still stands as the API for SPI (information about that would also be appreciated). It's just the no one has replaced it yet! There seem to be multiple efforts going on now to get more driver-like frameworks into RTEMS. If any actual effort is currently going or planned for a new SPI API it would be interesting to know so it can be taken into account, so it does not come as a surprise mid-GSoC. Thanks, André Marques. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2015: Raspberry Pi Low Level Peripherals and SD Card
On 03/25/2015 05:41 PM, André Marques wrote: On 25-03-2015 14:17, Gedare Bloom wrote: On Wed, Mar 25, 2015 at 4:49 AM, André Marques wrote: Hello everyone, My GSoC proposal entitled "Raspberry Pi Low Level Peripherals and SD Card" can be found for review at: https://docs.google.com/document/d/11K0qU3OsbSMhNYkTTWt4kitAbd6uuJBcMfA_07Lg6j8 One issue I would like to discuss here is related to the SD card support, which as exposed on the proposal the GPIOs to which the SD card is connected internally do not have SPI hardware capabilities, meaning that to access the card via SPI mode it would have to be bit-banged on those GPIOs (a problem on performance). This is more detailed on the proposal, but another alternative would be to use the SD mode instead, with the help of the PI's EMMC module, and the SD simplified specifications as documentation for the SD protocol. I have already used this setup with success in the past, and it should have better performance. In this setup the FreeBSD SD/MMC stack may be used (such as the one Sebastian Huber ported last year -> https://git.rtems.org/sebh/rtems-libusb.git/tree/rtems/freebsd/dev/mmc?id=3c82a1500da3192de2504a1360e065fd84a1f3a0) Is this code in the libbsd.git now? It is not, only on Sebastian's repository. It was anounced here along with an USB host stack: https://lists.rtems.org/pipermail/devel/2014-August/007873.html Hmm.. the libbsd code was updated to FreeBSD 9.x as a base. Maybe he merged this code at that point. which implements the SD protocol also based on the simplified specs. This would help avoiding implementing the protocol from scratch (which is sort of what I did in my previous effort with the SD card and the PI) and would be better for maintenance probably. My issue is then on the feasibily (licence wise) of having the FreeBSD SD stack or having code based on the SD Simplified Specs on the RTEMS tree. FreeBSD code should be fine. The complexity of getting libbsd working could be the real stumbling block. But I think others will be working on the same problem too, so there may be some ability to share knowledge. In SPI mode an implementation of the protocol can be found in libchip/i2c/spi-sd-card.*, which could in that case be used/improved further during the project, if it is decided it is best to use SPI mode. This uses the libi2c API, which is deprecated for I2C but, as I understand, still stands as the API for SPI (information about that would also be appreciated). It's just the no one has replaced it yet! There seem to be multiple efforts going on now to get more driver-like frameworks into RTEMS. If any actual effort is currently going or planned for a new SPI API it would be interesting to know so it can be taken into account, so it does not come as a surprise mid-GSoC. Thanks, André Marques. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- -- Joel Sherrill Ask me about RTEMS: a free RTOS Support and Training Available ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
SD/MMC FreeBSD status check and SPI/i2c API
On 03/25/2015 05:41 PM, André Marques wrote: It is not, only on Sebastian's repository. It was anounced here along with an USB host stack: https://lists.rtems.org/pipermail/devel/2014-August/007873.html Any updates on this? And is the new i2c API the recommended one for SPI as well now? --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2015: Review proposal for Beagle BSP improvements: Booting without U-boot
On 26/03/2015 1:14 am, Gedare Bloom wrote: > Looks pretty good. I have the same basic comment I give most students, > which is that you should try to flesh out some more details about what > exactly you will be doing, i.e. what code you might be able to use, > what your software architecture may look like, draw some diagrams to > clarify concepts, and so on. A couple of areas that are good to consider are portability and drivers. Portability tends to come down to a portable set of files, architecture specific files, and target specific files. Drivers can be portable if managed. Then there is file systems and networking. I can help with JFFS where I have a BSD type license on reading a JFFS file system [1]. DOSFS is easy with the FatFS [2]. I am currently using both on a Zynq. Chris [1] https://ftp.rtems.org/pub/rtems/people/chrisj/jffs2-boot/ [2] http://elm-chan.org/fsw/ff/00index_e.html ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 12/42] libcrypt/crypt-md5.c: Fix overflow issues
On March 24, 2015 8:37:57 AM CDT, Daniel Gutson wrote: >In order to avoid code duplication and ease future bugfixing, I suggest >to have a conditional casting and leave the core code alone, something >like > >#ifdef __rtems__ >#define cast(x) ((unsigned long int)x) >#else >#define cast(x) (x) >#endif > >...cast(final[ 0] << 16)... > >#undef cast Good suggestion. The big concern is really just making sure changes made to the imported code is clear. I suppose this does it as well. >El 23/03/2015 11:52, "Joel Sherrill" >escribió: > >--- > cpukit/libcrypt/crypt-md5.c | 12 > 1 file changed, 12 insertions(+) > >diff --git a/cpukit/libcrypt/crypt-md5.c b/cpukit/libcrypt/crypt-md5.c >index c60dcf8..78ae0bc 100644 >--- a/cpukit/libcrypt/crypt-md5.c >+++ b/cpukit/libcrypt/crypt-md5.c >@@ -133,6 +133,17 @@ crypt_md5_r(const char *pw, const char *salt, >struct crypt_data *data) > >p = passwd + strlen(passwd); > >+#if defined(__rtems__) >+ l = ((long int) final[ 0]<<16) | ((long int) final[ 6]<<8) | >final[12]; >+ _crypt_to64(p, l, 4); p += 4; >+ l = ((long int) final[ 1]<<16) | ((long int) final[ 7]<<8) | >final[13]; >+ _crypt_to64(p, l, 4); p += 4; >+ l = ((long int) final[ 2]<<16) | ((long int) final[ 8]<<8) | >final[14]; >+ _crypt_to64(p, l, 4); p += 4; >+ l = ((long int) final[ 3]<<16) | ((long int) final[ 9]<<8) | >final[15]; >+ _crypt_to64(p, l, 4); p += 4; >+ l = ((long int) final[ 4]<<16) | ((long int) final[10]<<8) | >final[ 5]; >+#else >l = (final[ 0]<<16) | (final[ 6]<<8) | final[12]; >_crypt_to64(p, l, 4); p += 4; >l = (final[ 1]<<16) | (final[ 7]<<8) | final[13]; >@@ -142,6 +153,7 @@ crypt_md5_r(const char *pw, const char *salt, >struct crypt_data *data) >l = (final[ 3]<<16) | (final[ 9]<<8) | final[15]; >_crypt_to64(p, l, 4); p += 4; >l = (final[ 4]<<16) | (final[10]<<8) | final[ 5]; >+#endif >_crypt_to64(p, l, 4); p += 4; >l = final[11]; >_crypt_to64(p, l, 2); p += 2; >-- >1.9.3 > >___ >devel mailing list >devel@rtems.org >http://lists.rtems.org/mailman/listinfo/devel --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Pushing all but one patch
On March 24, 2015 8:41:35 AM CDT, Daniel Gutson wrote: > >El 24/03/2015 10:34, "Joel Sherrill" >escribió: >> >> >> >> On 3/24/2015 8:29 AM, Daniel Gutson wrote: >>> >>> >>> El 24/03/2015 10:17, "Joel Sherrill" >escribió: >>> > >>> > Hi >>> > >>> > I am pushing all but the one patch that was commented on. >>> > I will try the suggested alternative approach to eliminating >>> > the warning before pushing some solution. >>> >>> I'm just back from a trip and I am not sure what that remaining >patch is or its related warning. Is the one shown in the mail with >subject "Last warnings" from yesterday? Please point me to it if not >since I'd like to help. >> >> Gedare had a question if I have picked the right way to address one >warning. >> >> The last warning is in the sh1 BSP and I think it has something to do >with the >> way it defines its driver macros. >> >> I am seriously down to the last warnings!! It is a matter of ignoring >some that >> are gcc false positives, knowing a newer gcc doesn't flag some and >fixing >> that very painful intptr_t inttypes.h issue. > >Thanks, I'll take a look. This one is fixed and committed to newlib. I am building all RTEMS BSPs with new RSB tools now. :) >> >>> Anyway I'm accessing from a smartphone without access to the source >code until tomorrow. >> >> I do that myself a lot. Sometimes it isn't a smart thing to do. :) > >I have the additional difficulty that I'm answering hiding from my wife >since I'm still technically in my honeymoon until tomorrow :) Ouch!! And congratulations!! Spring break here. I am helping my wife finish her third book. Proofreading time at the end. But I am also tending to long builds and answering student questions for GSoC and SOCIS. >> >> >> >>> Thanks! >>> >>>Daniel. >>> >>> > >>> > -- >>> > Joel Sherrill, Ph.D. Director of Research & >Development >>> > joel.sherr...@oarcorp.comOn-Line Applications Research >>> > Ask me about RTEMS: a free RTOS Huntsville AL 35805 >>> > Support Available(256) 722-9985 >>> > >>> > ___ >>> > devel mailing list >>> > devel@rtems.org >>> > http://lists.rtems.org/mailman/listinfo/devel >> >> >> -- >> Joel Sherrill, Ph.D. Director of Research & Development >> joel.sherr...@oarcorp.comOn-Line Applications Research >> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >> Support Available(256) 722-9985 --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Tracing task id.
Hi, Is there are bit in the Id that could be reserved and used to record the interrupt nesting state when tracing ? This saves having to find a bit somewhere else in record to capture this piece of information. I am thinking about testing the irq nesting level and if set recording this. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 12/42] libcrypt/crypt-md5.c: Fix overflow issues
El 25/03/2015 21:41, "Joel Sherrill" escribió: > > > > On March 24, 2015 8:37:57 AM CDT, Daniel Gutson < daniel.gut...@tallertechnologies.com> wrote: > >In order to avoid code duplication and ease future bugfixing, I suggest > >to have a conditional casting and leave the core code alone, something > >like > > > >#ifdef __rtems__ > >#define cast(x) ((unsigned long int)x) > >#else > >#define cast(x) (x) > >#endif > > > >...cast(final[ 0] << 16)... > > > >#undef cast > > Good suggestion. The big concern is really just making sure changes made to the imported code is clear. I suppose this does it as well. Is this really RTEMS-specific? If it isn't, what about contributing it to the original code? > > > >El 23/03/2015 11:52, "Joel Sherrill" > >escribió: > > > >--- > > cpukit/libcrypt/crypt-md5.c | 12 > > 1 file changed, 12 insertions(+) > > > >diff --git a/cpukit/libcrypt/crypt-md5.c b/cpukit/libcrypt/crypt-md5.c > >index c60dcf8..78ae0bc 100644 > >--- a/cpukit/libcrypt/crypt-md5.c > >+++ b/cpukit/libcrypt/crypt-md5.c > >@@ -133,6 +133,17 @@ crypt_md5_r(const char *pw, const char *salt, > >struct crypt_data *data) > > > >p = passwd + strlen(passwd); > > > >+#if defined(__rtems__) > >+ l = ((long int) final[ 0]<<16) | ((long int) final[ 6]<<8) | > >final[12]; > >+ _crypt_to64(p, l, 4); p += 4; > >+ l = ((long int) final[ 1]<<16) | ((long int) final[ 7]<<8) | > >final[13]; > >+ _crypt_to64(p, l, 4); p += 4; > >+ l = ((long int) final[ 2]<<16) | ((long int) final[ 8]<<8) | > >final[14]; > >+ _crypt_to64(p, l, 4); p += 4; > >+ l = ((long int) final[ 3]<<16) | ((long int) final[ 9]<<8) | > >final[15]; > >+ _crypt_to64(p, l, 4); p += 4; > >+ l = ((long int) final[ 4]<<16) | ((long int) final[10]<<8) | > >final[ 5]; > >+#else > >l = (final[ 0]<<16) | (final[ 6]<<8) | final[12]; > >_crypt_to64(p, l, 4); p += 4; > >l = (final[ 1]<<16) | (final[ 7]<<8) | final[13]; > >@@ -142,6 +153,7 @@ crypt_md5_r(const char *pw, const char *salt, > >struct crypt_data *data) > >l = (final[ 3]<<16) | (final[ 9]<<8) | final[15]; > >_crypt_to64(p, l, 4); p += 4; > >l = (final[ 4]<<16) | (final[10]<<8) | final[ 5]; > >+#endif > >_crypt_to64(p, l, 4); p += 4; > >l = final[11]; > >_crypt_to64(p, l, 2); p += 2; > >-- > >1.9.3 > > > >___ > >devel mailing list > >devel@rtems.org > >http://lists.rtems.org/mailman/listinfo/devel > > --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Updated rtems GSOC table with my proposal for Nested Mutexes problem
Hello Sir, I have updated https://devel.rtems.org/wiki/GSoC/2015 with my proposal for Nested Mutexes project. Please guide on what can I add to my proposal for following points: 1. Future improvement to the projects. 2. Deliverable part of the report. Also provide me with complete review of the proposal and what changes are required to it. I am also attaching a copy of proposal with this mail. Thanks, Saurabh Gadia GSOC2015_GADIA_NestedMutexes.docx Description: MS-Word 2007 document ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
