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
__
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, sudars
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
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 ha
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
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
(arg
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 (AM3358BZCZ10
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.
T
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
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
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
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
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
flexibili
> 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 unu
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.co
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
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:
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 m
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 initia
19 matches
Mail list logo
