Re: New BSP Advice

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

LWIP NIC Driver Collection

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

New BSP Advice

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

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

> 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

Adding RTEMS shell commands in BSP and application

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

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

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

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

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 > >

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

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

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

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

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

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

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

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" < >

Re: New BSP Advice

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.

broken gcc 5.2

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

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

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

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

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

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

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

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

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

Re: Adding RTEMS shell commands in BSP and application

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,