Re: About cache enabling in LWIP port of BBB in RTEMS

2015-09-17 Thread Marcos Díaz 
Hi,
How did you see the revision number? if you are using u-boot you can pause
the start and write printenv and enter to see that:

board=am335x
board_name=A335BNLT
board_rev=00C0

This is in my version.
Please tell me so I can check if is the revision, or perhaps is something
else in u-boot initialization.

For the question Joel asked there is a way:
http://dumb-looks-free.blogspot.com.ar/2014/05/beaglebone-black-bbb-revision-serial.html
apparently, in the eeprom thorugh i2c it is recorded. But first we must
confirm that is a problem from the revisions, since Ragu has the problem in
a rev C.
Greetings

On Wed, Sep 16, 2015 at 7:22 PM, Joel Sherrill 
wrote:

>
>
> On 9/16/2015 2:41 PM, ragu nath wrote:
>
>> Hi Marcos,
>>
>> Great news! I did not  find any solution to the issue. I have a REV C
>> board from element14. Is this the same board you are using?  In my board I
>> saw the issue.
>>
>> Does this have anything to do with the patch you submitted [PATCH]
>> Beaglebone: fix missing clobber in inline assembly.
>> https://lists.rtems.org/pipermail/devel/2015-September/012531.html
>> I have not yet tested with this patch.
>>
>> The freebsd driver is working with cache disabled.  If possible pls check
>> if it is working with cache enabled in your board.
>>
>
> If this is a board revision related issue, is there a way programmatically
> to
> know which revision the board is? That way the BSP could auto-detect the
> right
> thing to do. Otherwise, we may be looking at a BSP variant or a build
> option.
> I would rather avoid those if we can auto-detect.
>
> --joel
>
>
>> Thanks,
>> Ragunath
>>
>>
>> On Mon, Sep 14, 2015 at 7:22 PM, Marcos Díaz <
>> marcos.d...@tallertechnologies.com > marcos.d...@tallertechnologies.com>> wrote:
>>
>> Hi Ragu,
>> I wanted to know if you were able to see something else about the
>> problem we had in the BBB when using LWIP and enabling cache ( the program
>> freezes).
>> I can tell you that here we were using BBB rev. A5C and had this
>> problem, but now we could test this with a BBB Rev C, and it successfully
>> works with cache enabled (using the same sdcard in both boards, one works
>> and the other doesn't).
>> Greetings
>>
>> --
>>
>> __
>>
>> 
>>
>> *
>> *
>>
>> Marcos Díaz
>>
>> Software Engineer
>>
>> *
>> *
>>
>> San Lorenzo 47, 3rd Floor, Office 5
>>
>> Córdoba, Argentina
>>
>> *
>> *
>>
>> Phone:+54 351 4217888 / +54 351 4218211/ +54 351 7617452
>>
>> Skype:markdiaz22
>>
>>
>>
>>
>>
>> --
>> ragu
>>
>
> --
> 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
>



-- 

__




Marcos Díaz

Software Engineer


San Lorenzo 47, 3rd Floor, Office 5

Córdoba, Argentina


Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452

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

Re: About cache enabling in LWIP port of BBB in RTEMS

2015-09-17 Thread Joel Sherrill 


On September 17, 2015 8:26:41 AM CDT, "Marcos Díaz" 
 wrote:
>Hi,
>
>How did you see the revision number? if you are using u-boot you can
>pause the start and write printenv and enter to see that:
>
>
>board=am335x
>board_name=A335BNLT 
>board_rev=00C0
>
>
>This is in my version.
>
>Please tell me so I can check if is the revision, or perhaps is
>something else in u-boot initialization.
>
>
>For the question Joel asked there is a way:
>
>http://dumb-looks-free.blogspot.com.ar/2014/05/beaglebone-black-bbb-revision-serial.html
>
>apparently, in the eeprom thorugh i2c it is recorded. But first we must
>confirm that is a problem from the revisions, since Ragu has the
>problem in a rev C.

Does the SoC itself have a revision number we can read? It may be that newer 
boards have a newer CPU.

>Greetings
>
>
>On Wed, Sep 16, 2015 at 7:22 PM, Joel Sherrill
> wrote:
>
>
>
>On 9/16/2015 2:41 PM, ragu nath wrote:
>
>Hi Marcos,
>
>Great news! I did not  find any solution to the issue. I have a REV C
>board from element14. Is this the same board you are using?  In my
>board I saw the issue.
>
>Does this have anything to do with the patch you submitted [PATCH]
>Beaglebone: fix missing clobber in inline assembly.
>https://lists.rtems.org/pipermail/devel/2015-September/012531.html
>I have not yet tested with this patch.
>
>The freebsd driver is working with cache disabled.  If possible pls
>check if it is working with cache enabled in your board.
>
>
>If this is a board revision related issue, is there a way
>programmatically to
>know which revision the board is? That way the BSP could auto-detect
>the right
>thing to do. Otherwise, we may be looking at a BSP variant or a build
>option.
>I would rather avoid those if we can auto-detect.
>
>--joel
>
>
>Thanks,
>Ragunath
>
>
>On Mon, Sep 14, 2015 at 7:22 PM, Marcos Díaz
>> wrote:
>
>Hi Ragu,
>I wanted to know if you were able to see something else about the
>problem we had in the BBB when using LWIP and enabling cache ( the
>program freezes).
>I can tell you that here we were using BBB rev. A5C and had this
>problem, but now we could test this with a BBB Rev C, and it
>successfully works with cache enabled (using the same sdcard in both
>boards, one works and the other doesn't).
>Greetings
>
>--
>
>__
>
>
>
>*
>*
>
>Marcos Díaz
>
>Software Engineer
>
>*
>*
>
>San Lorenzo 47, 3rd Floor, Office 5
>
>Córdoba, Argentina
>
>*
>*
>
>Phone:+54 351 4217888 / +54 351 4218211/ +54 351 7617452
>
>Skype:markdiaz22
>
>
>
>
>
>--
>ragu
>
>
>-- 
>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
>
>
>
>
>-- 
>
>__
>
> 
>
>
>Marcos Díaz
>
>Software Engineer
>
>
>San Lorenzo 47, 3rd Floor, Office 5
>
>Córdoba, Argentina 
>
>
>Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452
>
>Skype: markdiaz22

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

Re: About cache enabling in LWIP port of BBB in RTEMS

2015-09-17 Thread Marcos Díaz 
Yes, in my case the older (that doesn't work) revision is a
XAM3359AZCZ100

And the rev C (that works well with cache) is
AM3358BZCZ100

On Thu, Sep 17, 2015 at 10:32 AM, Joel Sherrill 
wrote:

>
>
> On September 17, 2015 8:26:41 AM CDT, "Marcos Díaz" <
> marcos.d...@tallertechnologies.com> wrote:
> >Hi,
> >
> >How did you see the revision number? if you are using u-boot you can
> >pause the start and write printenv and enter to see that:
> >
> >
> >board=am335x
> >board_name=A335BNLT
> >board_rev=00C0
> >
> >
> >This is in my version.
> >
> >Please tell me so I can check if is the revision, or perhaps is
> >something else in u-boot initialization.
> >
> >
> >For the question Joel asked there is a way:
> >
> >
> http://dumb-looks-free.blogspot.com.ar/2014/05/beaglebone-black-bbb-revision-serial.html
> >
> >apparently, in the eeprom thorugh i2c it is recorded. But first we must
> >confirm that is a problem from the revisions, since Ragu has the
> >problem in a rev C.
>
> Does the SoC itself have a revision number we can read? It may be that
> newer boards have a newer CPU.
>
> >Greetings
> >
> >
> >On Wed, Sep 16, 2015 at 7:22 PM, Joel Sherrill
> > wrote:
> >
> >
> >
> >On 9/16/2015 2:41 PM, ragu nath wrote:
> >
> >Hi Marcos,
> >
> >Great news! I did not  find any solution to the issue. I have a REV C
> >board from element14. Is this the same board you are using?  In my
> >board I saw the issue.
> >
> >Does this have anything to do with the patch you submitted [PATCH]
> >Beaglebone: fix missing clobber in inline assembly.
> >https://lists.rtems.org/pipermail/devel/2015-September/012531.html
> >I have not yet tested with this patch.
> >
> >The freebsd driver is working with cache disabled.  If possible pls
> >check if it is working with cache enabled in your board.
> >
> >
> >If this is a board revision related issue, is there a way
> >programmatically to
> >know which revision the board is? That way the BSP could auto-detect
> >the right
> >thing to do. Otherwise, we may be looking at a BSP variant or a build
> >option.
> >I would rather avoid those if we can auto-detect.
> >
> >--joel
> >
> >
> >Thanks,
> >Ragunath
> >
> >
> >On Mon, Sep 14, 2015 at 7:22 PM, Marcos Díaz
> > >> wrote:
> >
> >Hi Ragu,
> >I wanted to know if you were able to see something else about the
> >problem we had in the BBB when using LWIP and enabling cache ( the
> >program freezes).
> >I can tell you that here we were using BBB rev. A5C and had this
> >problem, but now we could test this with a BBB Rev C, and it
> >successfully works with cache enabled (using the same sdcard in both
> >boards, one works and the other doesn't).
> >Greetings
> >
> >--
> >
> >__
> >
> >
> >
> >*
> >*
> >
> >Marcos Díaz
> >
> >Software Engineer
> >
> >*
> >*
> >
> >San Lorenzo 47, 3rd Floor, Office 5
> >
> >Córdoba, Argentina
> >
> >*
> >*
> >
> >Phone:+54 351 4217888 / +54 351 4218211/ +54 351 7617452
> >
> >Skype:markdiaz22
> >
> >
> >
> >
> >
> >--
> >ragu
> >
> >
> >--
> >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
> >
> >
> >
> >
> >--
> >
> >__
> >
> >
> >
> >
> >Marcos Díaz
> >
> >Software Engineer
> >
> >
> >San Lorenzo 47, 3rd Floor, Office 5
> >
> >Córdoba, Argentina
> >
> >
> >Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452
> >
> >Skype: markdiaz22
>
> --joel
>



-- 

__




Marcos Díaz

Software Engineer


San Lorenzo 47, 3rd Floor, Office 5

Córdoba, Argentina


Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452

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

New BSP Advice

2015-09-17 Thread Isaac Gutekunst 

Hey RTEMS Developers,

Vecna has recently reached the final stretch of our BSP development 
effort for the STM32F4 and STM32F7 families of processors. We would love 
to contribute it back and where wondering what we should do to get that 
process moving. I understand many of you are busy with the 4.11 effort, 
and if you can't offer much help at the moment, we understand. On our 
end, we are performing internal peer review through the GitHub 
interface, and are hoping to wrap things up in about two weeks. 
Outstanding areas are the LWIP port which is not visible in the pull 
request.


The in progress code is viewable here: 
https://github.com/vecnatechnologies/rtems/pull/4



Kind Regards,

Isaac Gutekunst
Embedded Systems Software Engineer
isaac.guteku...@vecna.com
www.vecna.com

Cambridge Research Laboratory
Vecna Technologies, Inc.
36 Cambridge Park Drive
Cambridge, MA 02140
Office: (617) 864-0636 x3069
Fax: (617) 864-0638
http://vecna.com

Better Technology, Better World (TM)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: About cache enabling in LWIP port of BBB in RTEMS

2015-09-17 Thread Joel Sherrill 



On 9/17/2015 8:43 AM, Marcos Díaz wrote:

Yes, in my case the older (that doesn't work) revision is a
XAM3359AZCZ100

And the rev C (that works well with cache) is
AM3358BZCZ100


Can we determine that in software?


On Thu, Sep 17, 2015 at 10:32 AM, Joel Sherrill mailto:joel.sherr...@oarcorp.com>> wrote:



On September 17, 2015 8:26:41 AM CDT, "Marcos Díaz" 
mailto:marcos.d...@tallertechnologies.com>> wrote:
>Hi,
>
>How did you see the revision number? if you are using u-boot you can
>pause the start and write printenv and enter to see that:
>
>
>board=am335x
>board_name=A335BNLT
>board_rev=00C0
>
>
>This is in my version.
>
>Please tell me so I can check if is the revision, or perhaps is
>something else in u-boot initialization.
>
>
>For the question Joel asked there is a way:
>

>http://dumb-looks-free.blogspot.com.ar/2014/05/beaglebone-black-bbb-revision-serial.html
>
>apparently, in the eeprom thorugh i2c it is recorded. But first we must
>confirm that is a problem from the revisions, since Ragu has the
>problem in a rev C.

Does the SoC itself have a revision number we can read? It may be that 
newer boards have a newer CPU.

 >Greetings
 >
 >
 >On Wed, Sep 16, 2015 at 7:22 PM, Joel Sherrill
 >mailto:joel.sherr...@oarcorp.com>> wrote:
 >
 >
 >
 >On 9/16/2015 2:41 PM, ragu nath wrote:
 >
 >Hi Marcos,
 >
 >Great news! I did not  find any solution to the issue. I have a REV C
 >board from element14. Is this the same board you are using?  In my
 >board I saw the issue.
 >
 >Does this have anything to do with the patch you submitted [PATCH]
 >Beaglebone: fix missing clobber in inline assembly.
 >https://lists.rtems.org/pipermail/devel/2015-September/012531.html
 >I have not yet tested with this patch.
 >
 >The freebsd driver is working with cache disabled.  If possible pls
 >check if it is working with cache enabled in your board.
 >
 >
 >If this is a board revision related issue, is there a way
 >programmatically to
 >know which revision the board is? That way the BSP could auto-detect
 >the right
 >thing to do. Otherwise, we may be looking at a BSP variant or a build
 >option.
 >I would rather avoid those if we can auto-detect.
 >
 >--joel
 >
 >
 >Thanks,
 >Ragunath
 >
 >
 >On Mon, Sep 14, 2015 at 7:22 PM, Marcos Díaz
 >mailto:marcos.d...@tallertechnologies.com>
 >>> wrote:
 >
 >Hi Ragu,
 >I wanted to know if you were able to see something else about the
 >problem we had in the BBB when using LWIP and enabling cache ( the
 >program freezes).
 >I can tell you that here we were using BBB rev. A5C and had this
 >problem, but now we could test this with a BBB Rev C, and it
 >successfully works with cache enabled (using the same sdcard in both
 >boards, one works and the other doesn't).
 >Greetings
 >
 >--
 >
 >__
 >
 >
 >
 >*
 >*
 >
 >Marcos Díaz
 >
 >Software Engineer
 >
 >*
 >*
 >
 >San Lorenzo 47, 3rd Floor, Office 5
 >
 >Córdoba, Argentina
 >
 >*
 >*
 >
 >Phone:+54 351 4217888 / +54 351 4218211/ +54 351 7617452
 >
 >Skype:markdiaz22
 >
 >
 >
 >
 >
 >--
 >ragu
 >
 >
 >--
 >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
 >
 >
 >
 >
 >--
 >
 >__
 >
 >
 >
 >
 >Marcos Díaz
 >
 >Software Engineer
 >
 >
 >San Lorenzo 47, 3rd Floor, Office 5
 >
 >Córdoba, Argentina
 >
 >
 >Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452
 >
 >Skype: markdiaz22

--joel




--

__



*
*

Marcos Díaz

Software Engineer

*
*

San Lorenzo 47, 3rd Floor, Office 5

Córdoba, Argentina

*
*

Phone:+54 351 4217888 / +54 351 4218211/ +54 351 7617452

Skype:markdiaz22




--
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:[PATCH] [RTEMS] Update RTEMS thread model

2015-09-17 Thread Aurelio Remonda 
> It is printing the "real time" but the time is set to a date early
> in the RTEMS development history. Look at the year. That's about the
> time the test was initially written.
>
> It is likely running faster than "real time" because it is a simulator.
> The numbers not ending in "5" is a bit unusual. The test consists of
> four tasks:
>
> + one runs every 5 seconds
> + one every 10
> + one every 15
> + IDLE
>
> It exits when one notices it has gone over 30 seconds.

Thank you Joel! I have another question if you don't mind: where i can find the 
realview_pbx_a9_qemu.exp file?
I can't find it in dejagnu/boards.

I did try making one (basically a copy of rtems-i386-qemu.exp with 
modifications), though. However, when I try:
make check 'RUNTESTFLAGS= SIM=realview_pbx_a9_qemu 
RTEMS_MAKEFILE_PATH=/home/aurelio-remonda/test-gcc/install-svn/arm-rtems4.11/realview_pbx_a9_qemu/
 RTEMS_CONFIG_OBJ=/home/aurelio-remonda/test-gcc/rtems-testing/gcc/ 
--target_board=rtems-arm-realview_pbx_a9_qemu{-march=armv7-a/-mthumb/-mfpu=neon/-mfloat-abi=hard}'

I get a lot of 'compilation failed to produce executable' messages. The log 
tells me 'No libgloss support for this target'. At the end I get this:


=== libstdc++ Summary ===

# of expected passes2676
# of unexpected failures3162
# of expected failures  6
# of unresolved testcases   3129
# of unsupported tests  808
runtest completed at Tue Sep 15 11:59:24 2015


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

Adding RTEMS shell commands in BSP and application

2015-09-17 Thread sudarshan.rajagopalan 
 
Hey guys,

 I was working on adding user shell commands in RTEMS. Was able to
successfully do it. Right now, we want to add few BSP specific shell
commands and few application specific shell commands. The BSP shell
commands will be added to the BSP, compiled and built. And also give the
flexibility to user application to add application specific commands
later on. One way to do it: 

int bsp1(int argc, char **argv){ 
} 

int bsp2(int argc, char **argv){ 
} 

rtems_shell_cmd_t BSP1_Command = {
 "test1", /* name */
 "test1", /* usage */
 "user", /* topic */
 bsp1, /* command */
 NULL, /* alias */
 NULL /* next */
}; 

rtems_shell_cmd_t BSP2_Command = {
 "test2", /* name */
 "test2", /* usage */
 "user", /* topic */
 bsp2, /* command */
 NULL, /* alias */
 NULL /* next */
}; 

#define SHELL_USER_COMMANDS \
&BSP2_Command, \
&BSP1_Command 

and the same in application code for APP1_Command and APP2_Command. And
initialize the shell in the application code: 

#define CONFIGURE_SHELL_USER_COMMANDS \
 SHELL_USER_COMMANDS, \ 
 &APP1_Command, \ 
 &APP2_Command 

#define CONFIGURE_SHELL_COMMANDS_INIT 
... 
#include  

Would this be the right way or are there any better ways to do it?
Please let me know I didn't make myself clear on this. 

Thanks and Regards, 
Sudarshan Rajagopalan 
sudarshan.rajagopa...@vecna.com

 Cambridge Research Laboratory
 Vecna Technologies, Inc.
 36 Cambridge Park Drive
 Cambridge, MA 02140
http://vecna.com [1]

 Better Technology, Better World (TM) 
 

Links:
--
[1] http://vecna.com
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: About cache enabling in LWIP port of BBB in RTEMS

2015-09-17 Thread Marcos Díaz 
Yes, sorry about that, There are two registers we can check to see the
different revision numbers. I will check it myself once i confirm that the
different revisions are the problem (i'm not sure because of what Ragu
said). Thanks!

On Thu, Sep 17, 2015 at 11:12 AM, Joel Sherrill 
wrote:

>
>
> On 9/17/2015 8:43 AM, Marcos Díaz wrote:
>
>> Yes, in my case the older (that doesn't work) revision is a
>> XAM3359AZCZ100
>>
>> And the rev C (that works well with cache) is
>> AM3358BZCZ100
>>
>
> Can we determine that in software?
>
> On Thu, Sep 17, 2015 at 10:32 AM, Joel Sherrill > > wrote:
>>
>>
>>
>> On September 17, 2015 8:26:41 AM CDT, "Marcos Díaz" <
>> marcos.d...@tallertechnologies.com > marcos.d...@tallertechnologies.com>> wrote:
>> >Hi,
>> >
>> >How did you see the revision number? if you are using u-boot you can
>> >pause the start and write printenv and enter to see that:
>> >
>> >
>> >board=am335x
>> >board_name=A335BNLT
>> >board_rev=00C0
>> >
>> >
>> >This is in my version.
>> >
>> >Please tell me so I can check if is the revision, or perhaps is
>> >something else in u-boot initialization.
>> >
>> >
>> >For the question Joel asked there is a way:
>> >
>> >
>> http://dumb-looks-free.blogspot.com.ar/2014/05/beaglebone-black-bbb-revision-serial.html
>> >
>> >apparently, in the eeprom thorugh i2c it is recorded. But first we
>> must
>> >confirm that is a problem from the revisions, since Ragu has the
>> >problem in a rev C.
>>
>> Does the SoC itself have a revision number we can read? It may be
>> that newer boards have a newer CPU.
>>
>>  >Greetings
>>  >
>>  >
>>  >On Wed, Sep 16, 2015 at 7:22 PM, Joel Sherrill
>>  >mailto:joel.sherr...@oarcorp.com>>
>> wrote:
>>  >
>>  >
>>  >
>>  >On 9/16/2015 2:41 PM, ragu nath wrote:
>>  >
>>  >Hi Marcos,
>>  >
>>  >Great news! I did not  find any solution to the issue. I have a REV
>> C
>>  >board from element14. Is this the same board you are using?  In my
>>  >board I saw the issue.
>>  >
>>  >Does this have anything to do with the patch you submitted [PATCH]
>>  >Beaglebone: fix missing clobber in inline assembly.
>>  >https://lists.rtems.org/pipermail/devel/2015-September/012531.html
>>  >I have not yet tested with this patch.
>>  >
>>  >The freebsd driver is working with cache disabled.  If possible pls
>>  >check if it is working with cache enabled in your board.
>>  >
>>  >
>>  >If this is a board revision related issue, is there a way
>>  >programmatically to
>>  >know which revision the board is? That way the BSP could auto-detect
>>  >the right
>>  >thing to do. Otherwise, we may be looking at a BSP variant or a
>> build
>>  >option.
>>  >I would rather avoid those if we can auto-detect.
>>  >
>>  >--joel
>>  >
>>  >
>>  >Thanks,
>>  >Ragunath
>>  >
>>  >
>>  >On Mon, Sep 14, 2015 at 7:22 PM, Marcos Díaz
>>  >> marcos.d...@tallertechnologies.com>
>>  > marcos.d...@tallertechnologies.com>>> wrote:
>>  >
>>  >Hi Ragu,
>>  >I wanted to know if you were able to see something else about the
>>  >problem we had in the BBB when using LWIP and enabling cache ( the
>>  >program freezes).
>>  >I can tell you that here we were using BBB rev. A5C and had this
>>  >problem, but now we could test this with a BBB Rev C, and it
>>  >successfully works with cache enabled (using the same sdcard in both
>>  >boards, one works and the other doesn't).
>>  >Greetings
>>  >
>>  >--
>>  >
>>  >__
>>  >
>>  >
>>  >
>>  >*
>>  >*
>>  >
>>  >Marcos Díaz
>>  >
>>  >Software Engineer
>>  >
>>  >*
>>  >*
>>  >
>>  >San Lorenzo 47, 3rd Floor, Office 5
>>  >
>>  >Córdoba, Argentina
>>  >
>>  >*
>>  >*
>>  >
>>  >Phone:+54 351 4217888 / +54 351 4218211/ +54 351 7617452
>>  >
>>  >Skype:markdiaz22
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >--
>>  >ragu
>>  >
>>  >
>>  >--
>>  >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
>>  >
>>  >
>>  >
>>  >
>>  >--
>>  >
>>  >__
>>  >
>>  >
>>  >
>>  >
>>  >Marcos Díaz
>>  >
>>  >Software Engineer
>>  >
>>  >
>>  >San Lorenzo 47, 3rd Floor, Office 5
>>  >
>>  >Córdoba, Argentina

Re: [PATCH] [RTEMS] Update RTEMS thread model

2015-09-17 Thread Joel Sherrill 



On 9/17/2015 9:36 AM, Aurelio Remonda wrote:

It is printing the "real time" but the time is set to a date early
in the RTEMS development history. Look at the year. That's about the
time the test was initially written.

It is likely running faster than "real time" because it is a simulator.
The numbers not ending in "5" is a bit unusual. The test consists of
four tasks:

+ one runs every 5 seconds
+ one every 10
+ one every 15
+ IDLE

It exits when one notices it has gone over 30 seconds.


Thank you Joel! I have another question if you don't mind: where i can find the 
realview_pbx_a9_qemu.exp file?
I can't find it in dejagnu/boards.

I did try making one (basically a copy of rtems-i386-qemu.exp with 
modifications), though. However, when I try:
make check 'RUNTESTFLAGS= SIM=realview_pbx_a9_qemu 
RTEMS_MAKEFILE_PATH=/home/aurelio-remonda/test-gcc/install-svn/arm-rtems4.11/realview_pbx_a9_qemu/
 RTEMS_CONFIG_OBJ=/home/aurelio-remonda/test-gcc/rtems-testing/gcc/ 
--target_board=rtems-arm-realview_pbx_a9_qemu{-march=armv7-a/-mthumb/-mfpu=neon/-mfloat-abi=hard}'


Apparently Sebastian either hasn't run the tests on this or hasn't pushed
the board file for this BSP.

I think there may be one also missing for the xilinx on qemu.

Sebastian?

The files are largely copies with the sim script name changed. Copy
one, fix, use it, and submit it if Sebastian doesn't have one to push. :)


I get a lot of 'compilation failed to produce executable' messages. The log 
tells me 'No libgloss support for this target'. At the end I get this:


This is because you are testing against a DejaGNU configuration file
that assumes arm-eabi not arm-rtems.



=== libstdc++ Summary ===

# of expected passes2676
# of unexpected failures3162
# of expected failures  6
# of unresolved testcases   3129
# of unsupported tests  808
runtest completed at Tue Sep 15 11:59:24 2015


___
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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: New BSP Advice

2015-09-17 Thread Joel Sherrill 



On 9/17/2015 9:09 AM, Isaac Gutekunst wrote:

Hey RTEMS Developers,

Vecna has recently reached the final stretch of our BSP development
effort for the STM32F4 and STM32F7 families of processors. We would love
to contribute it back and where wondering what we should do to get that
process moving. I understand many of you are busy with the 4.11 effort,
and if you can't offer much help at the moment, we understand. On our
end, we are performing internal peer review through the GitHub
interface, and are hoping to wrap things up in about two weeks.
Outstanding areas are the LWIP port which is not visible in the pull
request.

The in progress code is viewable here:
https://github.com/vecnatechnologies/rtems/pull/4


Normally, you just submit patches to the devel mailing list. We don't
tend to review github pull requests. Just not part of the workflow
and we want everything centrally recorded.

Is the BSP a variant of an existing one or a completely new one?

Normally any BSPs outside the BSP itself are submitted for review
first. Then the BSP is put up for review.

We still don't have a collection of LWIP drivers. I will start
another thread for that.



Kind Regards,

Isaac Gutekunst
Embedded Systems Software Engineer
isaac.guteku...@vecna.com
www.vecna.com

Cambridge Research Laboratory
Vecna Technologies, Inc.
36 Cambridge Park Drive
Cambridge, MA 02140
Office: (617) 864-0636 x3069
Fax: (617) 864-0638
http://vecna.com

Better Technology, Better World (TM)
___
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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

LWIP NIC Driver Collection

2015-09-17 Thread Joel Sherrill 

Hi

As LWIP drivers show up and we likely need documentation for
LWIP on RTEMS, I am thinking we need a new repo for this.

Even for a case like the Beagle, we could have instructions
and a pointer.

For more open licensed drivers, we could directly include them.

Any thoughts, comments?

--
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: New BSP Advice

2015-09-17 Thread Isaac Gutekunst 

We will send in a patch at some point.

The BSPs are two new BSP based off the existing STM32F4 BSP. The 
motivation is to keep the old BSP that includes only RTEMS contributed 
code. The new BSP includes lots of 3rd party ST code to make development 
and supporting multiple processors easier.


The change will probably be broken into a few pieces:

ADD STM32 HAL code
Add Shared STM32F7 and STM32F4 code.
Add each BSP
Add CAN driver to RTEMS
Add CAN driver implementation to the BSPs


The reason fro breaking up the HAL code into a separate commit is that 
it adds hundreds of files that make it hard to find the relevant new 
code written by Vecna.


Thanks for the info,

Isaac


On 09/17/2015 11:53 AM, Joel Sherrill wrote:



On 9/17/2015 9:09 AM, Isaac Gutekunst wrote:

Hey RTEMS Developers,

Vecna has recently reached the final stretch of our BSP development
effort for the STM32F4 and STM32F7 families of processors. We would love
to contribute it back and where wondering what we should do to get that
process moving. I understand many of you are busy with the 4.11 effort,
and if you can't offer much help at the moment, we understand. On our
end, we are performing internal peer review through the GitHub
interface, and are hoping to wrap things up in about two weeks.
Outstanding areas are the LWIP port which is not visible in the pull
request.

The in progress code is viewable here:
https://github.com/vecnatechnologies/rtems/pull/4


Normally, you just submit patches to the devel mailing list. We don't
tend to review github pull requests. Just not part of the workflow
and we want everything centrally recorded.

Is the BSP a variant of an existing one or a completely new one?

Normally any BSPs outside the BSP itself are submitted for review
first. Then the BSP is put up for review.

We still don't have a collection of LWIP drivers. I will start
another thread for that.



Kind Regards,

Isaac Gutekunst
Embedded Systems Software Engineer
isaac.guteku...@vecna.com
www.vecna.com

Cambridge Research Laboratory
Vecna Technologies, Inc.
36 Cambridge Park Drive
Cambridge, MA 02140
Office: (617) 864-0636 x3069
Fax: (617) 864-0638
http://vecna.com

Better Technology, Better World (TM)
___
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: About cache enabling in LWIP port of BBB in RTEMS

2015-09-17 Thread Marcos Díaz 
Ragu,
I would like you to confirm which revision you have, for this I printed the
following registers in the BBB:

0x44E10600 and 0x44E10604

The first will print something like:
1b94402e for BBB rev A5C (XAM3359AZCZ100) ( 1b means rev.A of the
microcontroller)
2b94402e for BBB rev C  (AM3358BZCZ100) (2b means rev B of the
microcontroller)

The second register will print something like:

20ff0383 for A5c (this means that this is AM3359)
20fd0383 for C (this means it is an AM3358).

Please let me know which are this values in your Board.

Thanks!



On Thu, Sep 17, 2015 at 11:44 AM, Marcos Díaz <
marcos.d...@tallertechnologies.com> wrote:

> Yes, sorry about that, There are two registers we can check to see the
> different revision numbers. I will check it myself once i confirm that the
> different revisions are the problem (i'm not sure because of what Ragu
> said). Thanks!
>
> On Thu, Sep 17, 2015 at 11:12 AM, Joel Sherrill  > wrote:
>
>>
>>
>> On 9/17/2015 8:43 AM, Marcos Díaz wrote:
>>
>>> Yes, in my case the older (that doesn't work) revision is a
>>> XAM3359AZCZ100
>>>
>>> And the rev C (that works well with cache) is
>>> AM3358BZCZ100
>>>
>>
>> Can we determine that in software?
>>
>> On Thu, Sep 17, 2015 at 10:32 AM, Joel Sherrill <
>>> joel.sherr...@oarcorp.com > wrote:
>>>
>>>
>>>
>>> On September 17, 2015 8:26:41 AM CDT, "Marcos Díaz" <
>>> marcos.d...@tallertechnologies.com >> marcos.d...@tallertechnologies.com>> wrote:
>>> >Hi,
>>> >
>>> >How did you see the revision number? if you are using u-boot you can
>>> >pause the start and write printenv and enter to see that:
>>> >
>>> >
>>> >board=am335x
>>> >board_name=A335BNLT
>>> >board_rev=00C0
>>> >
>>> >
>>> >This is in my version.
>>> >
>>> >Please tell me so I can check if is the revision, or perhaps is
>>> >something else in u-boot initialization.
>>> >
>>> >
>>> >For the question Joel asked there is a way:
>>> >
>>> >
>>> http://dumb-looks-free.blogspot.com.ar/2014/05/beaglebone-black-bbb-revision-serial.html
>>> >
>>> >apparently, in the eeprom thorugh i2c it is recorded. But first we
>>> must
>>> >confirm that is a problem from the revisions, since Ragu has the
>>> >problem in a rev C.
>>>
>>> Does the SoC itself have a revision number we can read? It may be
>>> that newer boards have a newer CPU.
>>>
>>>  >Greetings
>>>  >
>>>  >
>>>  >On Wed, Sep 16, 2015 at 7:22 PM, Joel Sherrill
>>>  >mailto:joel.sherr...@oarcorp.com>>
>>> wrote:
>>>  >
>>>  >
>>>  >
>>>  >On 9/16/2015 2:41 PM, ragu nath wrote:
>>>  >
>>>  >Hi Marcos,
>>>  >
>>>  >Great news! I did not  find any solution to the issue. I have a
>>> REV C
>>>  >board from element14. Is this the same board you are using?  In my
>>>  >board I saw the issue.
>>>  >
>>>  >Does this have anything to do with the patch you submitted [PATCH]
>>>  >Beaglebone: fix missing clobber in inline assembly.
>>>  >https://lists.rtems.org/pipermail/devel/2015-September/012531.html
>>>  >I have not yet tested with this patch.
>>>  >
>>>  >The freebsd driver is working with cache disabled.  If possible pls
>>>  >check if it is working with cache enabled in your board.
>>>  >
>>>  >
>>>  >If this is a board revision related issue, is there a way
>>>  >programmatically to
>>>  >know which revision the board is? That way the BSP could
>>> auto-detect
>>>  >the right
>>>  >thing to do. Otherwise, we may be looking at a BSP variant or a
>>> build
>>>  >option.
>>>  >I would rather avoid those if we can auto-detect.
>>>  >
>>>  >--joel
>>>  >
>>>  >
>>>  >Thanks,
>>>  >Ragunath
>>>  >
>>>  >
>>>  >On Mon, Sep 14, 2015 at 7:22 PM, Marcos Díaz
>>>  >>> marcos.d...@tallertechnologies.com>
>>>  >> marcos.d...@tallertechnologies.com>>> wrote:
>>>  >
>>>  >Hi Ragu,
>>>  >I wanted to know if you were able to see something else about the
>>>  >problem we had in the BBB when using LWIP and enabling cache ( the
>>>  >program freezes).
>>>  >I can tell you that here we were using BBB rev. A5C and had this
>>>  >problem, but now we could test this with a BBB Rev C, and it
>>>  >successfully works with cache enabled (using the same sdcard in
>>> both
>>>  >boards, one works and the other doesn't).
>>>  >Greetings
>>>  >
>>>  >--
>>>  >
>>>  >__
>>>  >
>>>  >
>>>  >
>>>  >*
>>>  >*
>>>  >
>>>  >Marcos Díaz
>>>  >
>>>  >Software Engineer
>>>  >
>>>  >*
>>>  >*
>>>  >
>>>  >San Lorenzo 47, 3rd Floor, Office 5
>>>  >
>>>  >Córdoba, Argentina
>>>  >

broken gcc 5.2

2015-09-17 Thread Daniel Gutson 
Hi,

  we are working towards compiling RTEMS for gcc 5.2 (since we are
working in a fork of the latter).

We found a bug that Sebastian previously found, which I reported here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
Not only it causes calloc() to call itself (recursively), but the
(arguably) optimization severely breaks the semantic as shown in the
bug report.

Andres will fix it and will let you know about the progress.

Thanks,

   Daniel.

-- 

Daniel F. Gutson
Chief Engineering Officer, SPD

San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina

Phone:   +54 351 4217888 / +54 351 4218211
Skype:dgutson
LinkedIn: http://ar.linkedin.com/in/danielgutson
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: About cache enabling in LWIP port of BBB in RTEMS

2015-09-17 Thread ragu nath 
Hi Marcos,

The following are the details from by board

###from uboot
board=am335x
board_name=A335BNLT
board_rev=00A5

### reg dump
0x44E10600 2b94402e

0x44E10604 20fd0383

###linux dump
hexdump -e '8/1 "%c"' "/sys/bus/i2c/devices/0-0050/eeprom" -s
0A5

Thanks,
Ragunath



On Fri, Sep 18, 2015 at 12:35 AM, Marcos Díaz <
marcos.d...@tallertechnologies.com> wrote:

> Ragu,
> I would like you to confirm which revision you have, for this I printed
> the following registers in the BBB:
>
> 0x44E10600 and 0x44E10604
>
> The first will print something like:
> 1b94402e for BBB rev A5C (XAM3359AZCZ100) ( 1b means rev.A of the
> microcontroller)
> 2b94402e for BBB rev C  (AM3358BZCZ100) (2b means rev B of the
> microcontroller)
>
> The second register will print something like:
>
> 20ff0383 for A5c (this means that this is AM3359)
> 20fd0383 for C (this means it is an AM3358).
>
> Please let me know which are this values in your Board.
>
> Thanks!
>
>
>
> On Thu, Sep 17, 2015 at 11:44 AM, Marcos Díaz <
> marcos.d...@tallertechnologies.com> wrote:
>
>> Yes, sorry about that, There are two registers we can check to see the
>> different revision numbers. I will check it myself once i confirm that the
>> different revisions are the problem (i'm not sure because of what Ragu
>> said). Thanks!
>>
>> On Thu, Sep 17, 2015 at 11:12 AM, Joel Sherrill <
>> joel.sherr...@oarcorp.com> wrote:
>>
>>>
>>>
>>> On 9/17/2015 8:43 AM, Marcos Díaz wrote:
>>>
 Yes, in my case the older (that doesn't work) revision is a
 XAM3359AZCZ100

 And the rev C (that works well with cache) is
 AM3358BZCZ100

>>>
>>> Can we determine that in software?
>>>
>>> On Thu, Sep 17, 2015 at 10:32 AM, Joel Sherrill <
 joel.sherr...@oarcorp.com > wrote:



 On September 17, 2015 8:26:41 AM CDT, "Marcos Díaz" <
 marcos.d...@tallertechnologies.com >>> marcos.d...@tallertechnologies.com>> wrote:
 >Hi,
 >
 >How did you see the revision number? if you are using u-boot you
 can
 >pause the start and write printenv and enter to see that:
 >
 >
 >board=am335x
 >board_name=A335BNLT
 >board_rev=00C0
 >
 >
 >This is in my version.
 >
 >Please tell me so I can check if is the revision, or perhaps is
 >something else in u-boot initialization.
 >
 >
 >For the question Joel asked there is a way:
 >
 >
 http://dumb-looks-free.blogspot.com.ar/2014/05/beaglebone-black-bbb-revision-serial.html
 >
 >apparently, in the eeprom thorugh i2c it is recorded. But first we
 must
 >confirm that is a problem from the revisions, since Ragu has the
 >problem in a rev C.

 Does the SoC itself have a revision number we can read? It may be
 that newer boards have a newer CPU.

  >Greetings
  >
  >
  >On Wed, Sep 16, 2015 at 7:22 PM, Joel Sherrill
  >mailto:joel.sherr...@oarcorp.com>>
 wrote:
  >
  >
  >
  >On 9/16/2015 2:41 PM, ragu nath wrote:
  >
  >Hi Marcos,
  >
  >Great news! I did not  find any solution to the issue. I have a
 REV C
  >board from element14. Is this the same board you are using?  In my
  >board I saw the issue.
  >
  >Does this have anything to do with the patch you submitted [PATCH]
  >Beaglebone: fix missing clobber in inline assembly.
  >
 https://lists.rtems.org/pipermail/devel/2015-September/012531.html
  >I have not yet tested with this patch.
  >
  >The freebsd driver is working with cache disabled.  If possible
 pls
  >check if it is working with cache enabled in your board.
  >
  >
  >If this is a board revision related issue, is there a way
  >programmatically to
  >know which revision the board is? That way the BSP could
 auto-detect
  >the right
  >thing to do. Otherwise, we may be looking at a BSP variant or a
 build
  >option.
  >I would rather avoid those if we can auto-detect.
  >
  >--joel
  >
  >
  >Thanks,
  >Ragunath
  >
  >
  >On Mon, Sep 14, 2015 at 7:22 PM, Marcos Díaz
   marcos.d...@tallertechnologies.com>
  >>> marcos.d...@tallertechnologies.com>>> wrote:
  >
  >Hi Ragu,
  >I wanted to know if you were able to see something else about the
  >problem we had in the BBB when using LWIP and enabling cache ( the
  >program freezes).
  >I can tell you that here we were using BBB rev. A5C and had this
  >problem, but now we could test this with a BBB Rev C, and it
  >succes

Re: About cache enabling in LWIP port of BBB in RTEMS

2015-09-17 Thread Joel Sherrill 

Can of of you guys start a table/spreadsheet about board
and SoC revisions and when we think it is broken and when
it works?

I emailed the BB project lead and he didn't know anything
off hand but suggested subscribing to beaglebo...@googlegroups.com
and asking there. Someone there may actually have an answer.

--joel

On 9/17/2015 2:05 PM, Marcos Díaz wrote:

Ragu,
I would like you to confirm which revision you have, for this I printed the 
following registers in the BBB:

0x44E10600 and 0x44E10604

The first will print something like:
1b94402e for BBB rev A5C (XAM3359AZCZ100) ( 1b means rev.A of the 
microcontroller)
2b94402e for BBB rev C  (AM3358BZCZ100) (2b means rev B of the microcontroller)

The second register will print something like:

20ff0383 for A5c (this means that this is AM3359)
20fd0383 for C (this means it is an AM3358).

Please let me know which are this values in your Board.

Thanks!



On Thu, Sep 17, 2015 at 11:44 AM, Marcos Díaz mailto:marcos.d...@tallertechnologies.com>> wrote:

Yes, sorry about that, There are two registers we can check to see the 
different revision numbers. I will check it myself once i confirm that the 
different revisions are the problem (i'm not sure because of what Ragu said). 
Thanks!

On Thu, Sep 17, 2015 at 11:12 AM, Joel Sherrill mailto:joel.sherr...@oarcorp.com>> wrote:



On 9/17/2015 8:43 AM, Marcos Díaz wrote:

Yes, in my case the older (that doesn't work) revision is a
XAM3359AZCZ100

And the rev C (that works well with cache) is
AM3358BZCZ100


Can we determine that in software?

On Thu, Sep 17, 2015 at 10:32 AM, Joel Sherrill mailto:joel.sherr...@oarcorp.com> >> wrote:



 On September 17, 2015 8:26:41 AM CDT, "Marcos Díaz" 
mailto:marcos.d...@tallertechnologies.com> 
>> wrote:
 >Hi,
 >
 >How did you see the revision number? if you are using u-boot 
you can
 >pause the start and write printenv and enter to see that:
 >
 >
 >board=am335x
 >board_name=A335BNLT
 >board_rev=00C0
 >
 >
 >This is in my version.
 >
 >Please tell me so I can check if is the revision, or perhaps 
is
 >something else in u-boot initialization.
 >
 >
 >For the question Joel asked there is a way:
 >
 
>http://dumb-looks-free.blogspot.com.ar/2014/05/beaglebone-black-bbb-revision-serial.html
 >
 >apparently, in the eeprom thorugh i2c it is recorded. But 
first we must
 >confirm that is a problem from the revisions, since Ragu has 
the
 >problem in a rev C.

 Does the SoC itself have a revision number we can read? It may 
be that newer boards have a newer CPU.

  >Greetings
  >
  >
  >On Wed, Sep 16, 2015 at 7:22 PM, Joel Sherrill
  >mailto:joel.sherr...@oarcorp.com> 
>> wrote:
  >
  >
  >
  >On 9/16/2015 2:41 PM, ragu nath wrote:
  >
  >Hi Marcos,
  >
  >Great news! I did not  find any solution to the issue. I 
have a REV C
  >board from element14. Is this the same board you are using?  
In my
  >board I saw the issue.
  >
  >Does this have anything to do with the patch you submitted 
[PATCH]
  >Beaglebone: fix missing clobber in inline assembly.
  
>https://lists.rtems.org/pipermail/devel/2015-September/012531.html
  >I have not yet tested with this patch.
  >
  >The freebsd driver is working with cache disabled.  If 
possible pls
  >check if it is working with cache enabled in your board.
  >
  >
  >If this is a board revision related issue, is there a way
  >programmatically to
  >know which revision the board is? That way the BSP could 
auto-detect
  >the right
  >thing to do. Otherwise, we may be looking at a BSP variant 
or a build
  >option.
  >I would rather avoid those if we can auto-detect.
  >
  >--joel
  >
  >
  >Thanks,
  >Ragunath
  >

Re: About cache enabling in LWIP port of BBB in RTEMS

2015-09-17 Thread Marcos Díaz 
I can only tell you about the boards i tested:

I have a revision A5C board with an XAM3359AZCZ100 microcontroller. The use
of cache together with ethernet makes this break.

I have a revision C board with an AM3358BZCZ100. This does work with cache
and ethernet.

Apparently Ragu has a rev A5 with an AM3358BZCZ100. Cache doesn't work for
him.

After reading this document:

http://elinux.org/Beagleboard:BeagleBoneBlack#Board_Revisions_and_Changes

I can say that the boards I have match with that descripcion. Revisions A4,
A4A, A4B have an AM3352 processor,
rev A5A A5B A5C A6 A6A have an XAM3359, and revisions B and C have an
AM3358 processor.

I'm not very sure about what Ragu has, since there it says he has a rev A5
(not mentioned in the document) but with the processor of the newer
revisions (AM3358).

In Ragu's case the checking of the registers for the processor revision
wont do any help, since he has the same processor that in my case works Ok,
but his doesn't.

Hope this clarifies.



On Thu, Sep 17, 2015 at 5:02 PM, Joel Sherrill 
wrote:

> Can of of you guys start a table/spreadsheet about board
> and SoC revisions and when we think it is broken and when
> it works?
>
> I emailed the BB project lead and he didn't know anything
> off hand but suggested subscribing to beaglebo...@googlegroups.com
> and asking there. Someone there may actually have an answer.
>
> --joel
>
> On 9/17/2015 2:05 PM, Marcos Díaz wrote:
>
>> Ragu,
>> I would like you to confirm which revision you have, for this I printed
>> the following registers in the BBB:
>>
>> 0x44E10600 and 0x44E10604
>>
>> The first will print something like:
>> 1b94402e for BBB rev A5C (XAM3359AZCZ100) ( 1b means rev.A of the
>> microcontroller)
>> 2b94402e for BBB rev C  (AM3358BZCZ100) (2b means rev B of the
>> microcontroller)
>>
>> The second register will print something like:
>>
>> 20ff0383 for A5c (this means that this is AM3359)
>> 20fd0383 for C (this means it is an AM3358).
>>
>> Please let me know which are this values in your Board.
>>
>> Thanks!
>>
>>
>>
>> On Thu, Sep 17, 2015 at 11:44 AM, Marcos Díaz <
>> marcos.d...@tallertechnologies.com > marcos.d...@tallertechnologies.com>> wrote:
>>
>> Yes, sorry about that, There are two registers we can check to see
>> the different revision numbers. I will check it myself once i confirm that
>> the different revisions are the problem (i'm not sure because of what Ragu
>> said). Thanks!
>>
>> On Thu, Sep 17, 2015 at 11:12 AM, Joel Sherrill <
>> joel.sherr...@oarcorp.com > wrote:
>>
>>
>>
>> On 9/17/2015 8:43 AM, Marcos Díaz wrote:
>>
>> Yes, in my case the older (that doesn't work) revision is a
>> XAM3359AZCZ100
>>
>> And the rev C (that works well with cache) is
>> AM3358BZCZ100
>>
>>
>> Can we determine that in software?
>>
>> On Thu, Sep 17, 2015 at 10:32 AM, Joel Sherrill <
>> joel.sherr...@oarcorp.com  > joel.sherr...@oarcorp.com >> wrote:
>>
>>
>>
>>  On September 17, 2015 8:26:41 AM CDT, "Marcos Díaz" <
>> marcos.d...@tallertechnologies.com > marcos.d...@tallertechnologies.com> > marcos.d...@tallertechnologies.com > marcos.d...@tallertechnologies.com>>> wrote:
>>  >Hi,
>>  >
>>  >How did you see the revision number? if you are using
>> u-boot you can
>>  >pause the start and write printenv and enter to see
>> that:
>>  >
>>  >
>>  >board=am335x
>>  >board_name=A335BNLT
>>  >board_rev=00C0
>>  >
>>  >
>>  >This is in my version.
>>  >
>>  >Please tell me so I can check if is the revision, or
>> perhaps is
>>  >something else in u-boot initialization.
>>  >
>>  >
>>  >For the question Joel asked there is a way:
>>  >
>>  >
>> http://dumb-looks-free.blogspot.com.ar/2014/05/beaglebone-black-bbb-revision-serial.html
>>  >
>>  >apparently, in the eeprom thorugh i2c it is recorded.
>> But first we must
>>  >confirm that is a problem from the revisions, since
>> Ragu has the
>>  >problem in a rev C.
>>
>>  Does the SoC itself have a revision number we can read?
>> It may be that newer boards have a newer CPU.
>>
>>   >Greetings
>>   >
>>   >
>>   >On Wed, Sep 16, 2015 at 7:22 PM, Joel Sherrill
>>   >> joel.sherr...@oarcorp.com>  joel.sherr...@oarcorp.com>>> wrote:
>>   >
>>   >
>>   >
>>   >On 9/16/2015 2:41 PM, ragu nath wrote:

Re: Adding RTEMS shell commands in BSP and application

2015-09-17 Thread Ian Caddy 

Hi,

You did not indicate which version of RTEMS you are using.

We use 4.10 and add our application shell commands programmatically. 
For example:


rtems_shell_add_cmd("findnb", "nameblock", "findnb# list 
nameblocks", main_findnb);



regards,

Ian Caddy


On 17/09/2015 10:35 PM, sudarshan.rajagopalan wrote:

Hey guys,

I was working on adding user shell commands in RTEMS. Was able to
successfully do it. Right now, we want to add few BSP specific shell
commands and few application specific shell commands. The BSP shell
commands will be added to the BSP, compiled and built. And also give the
flexibility to user application to add application specific commands
later on. One way to do it:
int bsp1(int argc, char **argv){
}
int bsp2(int argc, char **argv){
}
rtems_shell_cmd_t BSP1_Command = {
   "test1",  /* name */
   "test1",   /* usage */
   "user",   /* topic */
   bsp1, /* command */
   NULL, /* alias */
   NULL  /* next */
};
rtems_shell_cmd_t BSP2_Command = {
   "test2",  /* name */
   "test2",   /* usage */
   "user",   /* topic */
   bsp2,/* command */
   NULL, /* alias */
   NULL  /* next */
};
#define SHELL_USER_COMMANDS \
&BSP2_Command, \
&BSP1_Command
and the same in application code for APP1_Command and APP2_Command. And
initialize the shell in the application code:
#define CONFIGURE_SHELL_USER_COMMANDS \
 SHELL_USER_COMMANDS,  \
 &APP1_Command,\
 &APP2_Command
#define CONFIGURE_SHELL_COMMANDS_INIT
...
#include 
Would this be the right way or are there any better ways to do it?
Please let me know I didn't make myself clear on this.
Thanks and Regards,
Sudarshan Rajagopalan
sudarshan.rajagopa...@vecna.com 

Cambridge Research Laboratory
Vecna Technologies, Inc.
36 Cambridge Park Drive
Cambridge, MA 02140
http://vecna.com

Better Technology, Better World (TM)


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



--
Ian Caddy
Goanna Technologies Pty Ltd
+61 8 9444 2634


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

Re: Adding RTEMS shell commands in BSP and application

2015-09-17 Thread Chris Johns 
On 18/09/2015 11:01 am, Ian Caddy wrote:
> 
> We use 4.10 and add our application shell commands programmatically. For
> example:
> 
> rtems_shell_add_cmd("findnb", "nameblock", "findnb# list
> nameblocks", main_findnb);
> 

I do the same thing on 4.11.

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