Re: RTEMS BSD Net on Atmel SAM Board

[Isaac Gutekunst]

On 06/01/2016 07:18 PM, Pavel Pisa wrote:

Hello Isaac,

On Wednesday 01 of June 2016 23:09:39 Isaac Gutekunst wrote:

I believe I solved all my problems. Not enough memory. After updating the
linker script to use SDRAM, everything appears to be working well! (Knock
on wood).


I think that SAM V71 setup with 2 MB of external SDRAM is not much
above minimal limit for use of RTEMS with BSD networking.
If the single chip solution with only 128kB of internal SRAM
is considered (may be with additional 128kB which can be borrow
for some buffer from the instruction TCM) then it cannot
be used with libBSD based networking. So it would worth
to consider lwIP. I hope that it would be integrated to
the RTEMS file operations API as part of this year GSoC.
So this option worth to be considered to support
networking on the small systems.


Hi Pavel,

Thanks for the info.

We will definitely be adding the largest SDRAM chip we can find to our final 
board, so I imagine we will be okay.

Based on the weirdness I've experienced, not having enough RAM doesn't 
necessarily result in a nice error message. What do you think is a good amount 
of RAM to give the stack, and how can I be sure it's enough?

Isaac



On the other hand, BSD based networking is much more
capable.

Best wishes,

Pavel


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

Re: RTEMS BSD Net on Atmel SAM Board

[Isaac Gutekunst]

I believe I solved all my problems. Not enough memory. After updating the 
linker script to use SDRAM, everything appears to be working well! (Knock on 
wood).

I've also been reminded that the ping shell command has a memory leak. It 
expects the kernel to free up memory after the command exits. It also appears 
as if doing
a ping -i .001 quickly swamps the system. I feel that it's also running out of 
memory. I'll look into it more tomorrow.


Consider my Ethernet woes solved for now. I'm still curious about these memory 
leaks in ping though.


Isaac


On 06/01/2016 02:06 PM, Isaac Gutekunst wrote:

A brief update: I've updated my configuration from a different example to be a 
bit more complete. It looks like it can't communicate with the PHY.

#if (defined (RTEMS_SET_ETHERNET_ADDRESS))
  static char ethernet_address[6] = { 0x00, 0x04, 0x9F, 0x00, 0x5B, 0x21 };
#endif


static struct rtems_bsdnet_ifconfig netdriver_config = {
RTEMS_BSP_NETWORK_DRIVER_NAME,  /* name */
RTEMS_BSP_NETWORK_DRIVER_ATTACH,/* attach function */
NULL,   /* No more interfaces */
#if (defined (RTEMS_USE_BOOTP))
NULL,   /* BOOTP supplies IP address */
NULL,   /* BOOTP supplies IP net mask */
#else
"192.168.0.140",/* IP address */
"255.255.255.0",/* IP net mask */
#endif /* !RTEMS_USE_BOOTP */
#if (defined (RTEMS_SET_ETHERNET_ADDRESS))
ethernet_address,   /* Ethernet hardware address */
#else
NULL,   /* Driver supplies hardware address */
#endif
0,  /* Use default driver parameters */
0,  /* mtu */
0,  /* rbuf_count */
0,  /* xbuf_count */
0,  /* port */
39   /* irq */
};



struct rtems_bsdnet_config rtems_bsdnet_config = {
_config,
NULL,
0,  /* Default network task priority */
16 * 1024, /* Default mbuf capacity */
16 * 1024, /* Default mbuf cluster capacity */
"rtems",/* Host name */
"nodomain.com", /* Domain name */
"192.168.0.14", /* Gateway */
"192.168.0.1",  /* Log host */
{"192.168.0.1"  },  /* Name server(s) */
{"192.168.0.1"  },  /* NTP server(s) */
0,  /* efficiency */
0,  /* udp TX buffer */
0,  /* udp RX buffer */
0,  /* tcp TX buffer */
0,  /* tcp RX buffer */
};


I also added the network shell commands and can ping myself on 192.168.0.140. 
ifconfig atsamv0 shows:

* atsam0 *
Ethernet Address: 48:11:40:20:45:01
Address:192.168.0.140   Broadcast Address:192.168.0.255   Net mask:255.255.255.0
Flags: Up Broadcast Running Simplex Multicast
Send queue limit:50   length:0Dropped:0
-E- TimeOut ReadPhy


This matches the slow blinking of both LEDs at about 0.5Hz.

Isaac

On 06/01/2016 11:46 AM, Isaac Gutekunst wrote:

Hi All,

I'm trying to bring up tHE Atmel SAMV71 Explained Ultra board with networking, 
and can't figure out how to. Does anyone have any quick pointers?



Isaac



To limit potential email traffic, this is my setup as of now:

I've compiled the BSP with --enable-networking, verified by sprinkling #error 
messages in the generated header files that it really was compiled with 
--enable-networkinG.


I've copied the following from the networking supplement:

static struct rtems_bsdnet_ifconfig netdriver_config = {
  RTEMS_BSP_NETWORK_DRIVER_NAME,
  RTEMS_BSP_NETWORK_DRIVER_ATTACH
};

struct rtems_bsdnet_config rtems_bsdnet_config = {
  _config,
  NULL,
};



In Init, I call

rtems_bsdnet_initialize_network ();


My overall configuration #defines are as follows:

#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER

#define CONFIGURE_USE_IMFS_AS_BASE_FILESYSTEM
#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS   64
#define CONFIGURE_IMFS_MEMFILE_BYTES_PER_BLOCK512
#define CONFIGURE_MAXIMUM_DRIVERS  20

#define CONFIGURE_SWAPOUT_TASK_PRIORITY2

#define CONFIGURE_INIT_TASK_STACK_SIZE   RTEMS_MINIMUM_STACK_SIZE
#define CONFIGURE_EXTRA_TASK_STACKS  RTEMS_MINIMUM_STACK_SIZE
#define CONFIGURE_RTEMS_INIT_TASKS_TABLE

#define CONFIGURE_MAXIMUM_TASKS  rtems_resource_unlimited (20)
#define CONFIGURE_MAXIMUM_BARRIERS   rtems_resource_unlimited (10)
#define CONFIGURE_MAXIMUM_SEMAPHORES rtems_resource_unlimited (20)
#defi

Re: RTEMS BSD Net on Atmel SAM Board

[Isaac Gutekunst]

A brief update: I've updated my configuration from a different example to be a 
bit more complete. It looks like it can't communicate with the PHY.

#if (defined (RTEMS_SET_ETHERNET_ADDRESS))
  static char ethernet_address[6] = { 0x00, 0x04, 0x9F, 0x00, 0x5B, 0x21 };
#endif


static struct rtems_bsdnet_ifconfig netdriver_config = {
RTEMS_BSP_NETWORK_DRIVER_NAME,  /* name */
RTEMS_BSP_NETWORK_DRIVER_ATTACH,/* attach function */
NULL,   /* No more interfaces */
#if (defined (RTEMS_USE_BOOTP))
NULL,   /* BOOTP supplies IP address */
NULL,   /* BOOTP supplies IP net mask */
#else
"192.168.0.140",/* IP address */
"255.255.255.0",/* IP net mask */
#endif /* !RTEMS_USE_BOOTP */
#if (defined (RTEMS_SET_ETHERNET_ADDRESS))
ethernet_address,   /* Ethernet hardware address */
#else
NULL,   /* Driver supplies hardware address */
#endif
0,  /* Use default driver parameters */
0,  /* mtu */
0,  /* rbuf_count */
0,  /* xbuf_count */
0,  /* port */
39   /* irq */
};



struct rtems_bsdnet_config rtems_bsdnet_config = {
_config,
NULL,
0,  /* Default network task priority */
16 * 1024, /* Default mbuf capacity */
16 * 1024, /* Default mbuf cluster capacity */
"rtems",/* Host name */
"nodomain.com", /* Domain name */
"192.168.0.14", /* Gateway */
"192.168.0.1",  /* Log host */
{"192.168.0.1"  },  /* Name server(s) */
{"192.168.0.1"  },  /* NTP server(s) */
0,  /* efficiency */
0,  /* udp TX buffer */
0,  /* udp RX buffer */
0,  /* tcp TX buffer */
0,  /* tcp RX buffer */
};


I also added the network shell commands and can ping myself on 192.168.0.140. 
ifconfig atsamv0 shows:

* atsam0 *
Ethernet Address: 48:11:40:20:45:01
Address:192.168.0.140   Broadcast Address:192.168.0.255   Net mask:255.255.255.0
Flags: Up Broadcast Running Simplex Multicast
Send queue limit:50   length:0Dropped:0
-E- TimeOut ReadPhy


This matches the slow blinking of both LEDs at about 0.5Hz.

Isaac

On 06/01/2016 11:46 AM, Isaac Gutekunst wrote:

Hi All,

I'm trying to bring up tHE Atmel SAMV71 Explained Ultra board with networking, 
and can't figure out how to. Does anyone have any quick pointers?



Isaac



To limit potential email traffic, this is my setup as of now:

I've compiled the BSP with --enable-networking, verified by sprinkling #error 
messages in the generated header files that it really was compiled with 
--enable-networkinG.


I've copied the following from the networking supplement:

static struct rtems_bsdnet_ifconfig netdriver_config = {
  RTEMS_BSP_NETWORK_DRIVER_NAME,
  RTEMS_BSP_NETWORK_DRIVER_ATTACH
};

struct rtems_bsdnet_config rtems_bsdnet_config = {
  _config,
  NULL,
};



In Init, I call

rtems_bsdnet_initialize_network ();


My overall configuration #defines are as follows:

#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER

#define CONFIGURE_USE_IMFS_AS_BASE_FILESYSTEM
#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS   64
#define CONFIGURE_IMFS_MEMFILE_BYTES_PER_BLOCK512
#define CONFIGURE_MAXIMUM_DRIVERS  20

#define CONFIGURE_SWAPOUT_TASK_PRIORITY2

#define CONFIGURE_INIT_TASK_STACK_SIZE   RTEMS_MINIMUM_STACK_SIZE
#define CONFIGURE_EXTRA_TASK_STACKS  RTEMS_MINIMUM_STACK_SIZE
#define CONFIGURE_RTEMS_INIT_TASKS_TABLE

#define CONFIGURE_MAXIMUM_TASKS  rtems_resource_unlimited (20)
#define CONFIGURE_MAXIMUM_BARRIERS   rtems_resource_unlimited (10)
#define CONFIGURE_MAXIMUM_SEMAPHORES rtems_resource_unlimited (20)
#define CONFIGURE_MAXIMUM_MESSAGE_QUEUES rtems_resource_unlimited (4)
#define CONFIGURE_MAXIMUM_PARTITIONS rtems_resource_unlimited (2)
#define CONFIGURE_MAXIMUM_USER_EXTENSIONS8
#define CONFIGURE_MAXIMUM_TIMERS 8
#define CONFIGURE_UNIFIED_WORK_AREAS

#if 1
#define CONFIGURE_MAXIMUM_POSIX_KEYS 16
#define CONFIGURE_MAXIMUM_POSIX_KEY_VALUE_PAIRS  16
#define CONFIGURE_MAXIMUM_POSIX_THREADS  10
#define CONFIGURE_MAXIMUM_POSIX_CONDITION_VARIABLES  20
#define CONFIGURE_MAXIMUM_POSIX_MUTEXES  40
#endif

#define CONFIGUR

RTEMS BSD Net on Atmel SAM Board

[Isaac Gutekunst]

Hi All,

I'm trying to bring up tHE Atmel SAMV71 Explained Ultra board with networking, 
and can't figure out how to. Does anyone have any quick pointers?



Isaac



To limit potential email traffic, this is my setup as of now:

I've compiled the BSP with --enable-networking, verified by sprinkling #error 
messages in the generated header files that it really was compiled with 
--enable-networkinG.


I've copied the following from the networking supplement:

static struct rtems_bsdnet_ifconfig netdriver_config = {
  RTEMS_BSP_NETWORK_DRIVER_NAME,
  RTEMS_BSP_NETWORK_DRIVER_ATTACH
};

struct rtems_bsdnet_config rtems_bsdnet_config = {
  _config,
  NULL,
};



In Init, I call

rtems_bsdnet_initialize_network ();


My overall configuration #defines are as follows:

#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER

#define CONFIGURE_USE_IMFS_AS_BASE_FILESYSTEM
#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS   64
#define CONFIGURE_IMFS_MEMFILE_BYTES_PER_BLOCK512
#define CONFIGURE_MAXIMUM_DRIVERS  20

#define CONFIGURE_SWAPOUT_TASK_PRIORITY2

#define CONFIGURE_INIT_TASK_STACK_SIZE   RTEMS_MINIMUM_STACK_SIZE
#define CONFIGURE_EXTRA_TASK_STACKS  RTEMS_MINIMUM_STACK_SIZE
#define CONFIGURE_RTEMS_INIT_TASKS_TABLE

#define CONFIGURE_MAXIMUM_TASKS  rtems_resource_unlimited (20)
#define CONFIGURE_MAXIMUM_BARRIERS   rtems_resource_unlimited (10)
#define CONFIGURE_MAXIMUM_SEMAPHORES rtems_resource_unlimited (20)
#define CONFIGURE_MAXIMUM_MESSAGE_QUEUES rtems_resource_unlimited (4)
#define CONFIGURE_MAXIMUM_PARTITIONS rtems_resource_unlimited (2)
#define CONFIGURE_MAXIMUM_USER_EXTENSIONS8
#define CONFIGURE_MAXIMUM_TIMERS 8
#define CONFIGURE_UNIFIED_WORK_AREAS

#if 1
#define CONFIGURE_MAXIMUM_POSIX_KEYS 16
#define CONFIGURE_MAXIMUM_POSIX_KEY_VALUE_PAIRS  16
#define CONFIGURE_MAXIMUM_POSIX_THREADS  10
#define CONFIGURE_MAXIMUM_POSIX_CONDITION_VARIABLES  20
#define CONFIGURE_MAXIMUM_POSIX_MUTEXES  40
#endif

#define CONFIGURE_MICROSECONDS_PER_TICK  1000


#define CONFIGURE_UNIFIED_WORK_AREAS
#define CONFIGURE_UNLIMITED_OBJECTS

#define CONFIGURE_INIT

#define CONFIGURE_APPLICATION_NEEDS_LIBBLOCK 1

#include 

#include 
#define CONFIGURE_SHELL_COMMANDS_INIT
#define CONFIGURE_SHELL_COMMANDS_ALL
#include 

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

Re: GSOC2016: Improvements in RTEMS Tracing Framework

[Isaac Gutekunst]

Hi Vivek,

This is looking good!

I somewhat sketchy solution for getting binary files off a target is to print 
them as intel hex, and copy them from the terminal. If the Zynq bsp supports 
networking, you could setup a TFTP server. My ugly trace implementation 
implements the lttng-live protocol for getting the CTF stream off the target.

See 
https://github.com/lttng/lttng-tools/blob/master/doc/live-reading-protocol.txt

Chris, do you think it's worth going down this path yet? I think this is the 
best long term solution, as it makes RTEMS targets with networking support 
remotely traceable with babeltrace and Trace Compass.

I'm a little confused how the BSD, old style, and lwip networking stacks 
differ, and whether it would be possible to target all three easily. My 
understanding is that the existing stack, and the BSD stack both integrate into 
the RTEMS filesystem (have file descriptors), while LWIP has some super ugly 
macros that redefine read/write/etc.

Isaac




On 05/16/2016 02:41 PM, vivek kukreja wrote:

Hello all,

Thanks for the prompt answer regarding libBSD drivers Chris. I found a few 
links and have setup Qemu for Xilinx Zynq A9.  I will try to build drivers for 
USB and Ethernet and run a few examples on qemu by next week.

I have made some rudimentary changes in rtems-tld and rtrace shell utiltiy to 
print traces in CTF. I tested these changes on fileio.exe example for both 
sparc/erc32 and arm/xilinx_zynq_a9_qemu(tested on qemu). I am working on 
producing metadata in TSDL format as required by CTF 1.9. I will send patches 
for review this week.

Once we have trace in CTF we can write Babeltrace scripts for testing the 
output. However, CTF bitstream is produced on target and pulling it on host is 
tricky. Is there any solution apart from copy-pasting from terminal?

Also, I'm trying to trace user-extensions by running multiple applications on 
Qemu for better understanding. These traces will be converted to CTF next.
Any comments regarding my project plan or progress are welcome.

Regards,
Vivek

On Tue, May 10, 2016 at 2:40 PM, vivek kukreja > wrote:

Hello Chris, Joel, Isaac,

Sorry for the delay in getting back. I was ill for the last couple days.

Here is a quick status update,

* Setup my work environment. Earlier I was using RTEMS version 4.11 because 
I could not download the source code for 4.12 from GIT in my university 
network. I have not moved to the new version.

* Compiled the Xilinx Qemu BSP. I am unable to find help on how to run the 
BSP on Qemu however. I will send another mail to ask for help on the list.

* Prepared some documents to plan the project and track progress. Please 
take a look at these documents, and recommend any changes.
https://drive.google.com/open?id=0B2FBdgOy1yWXWE44RnhNLXUwLVU

* Started studying Babeltrace to understand its capabilities.

In the rest of the week, I will

* Study the source code for scheduler events tracing in User Extensions.

* Ensure that I have the BSP running on Qemu.

* Port my experimental changes in RTEMS TLD to the version 4.12 and share 
patches with you, to get some feedback.

On Wed, Apr 27, 2016 at 6:45 PM, vivek kukreja > wrote:

Hello all

Thank you for your help and support. My proposal for Tracing tool
improvements has been accepted in GSOC 2016.

I will be occupied with university exams for the rest of this week. I
will update the RTEMS page over the weekend. I will be able to commit
full-time to the project in the coming weeks during my vacations.

I am thrilled to start working on this project!

Regards,
Vivek




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

Re: (offlist) Re: GSoC 2016 Interested in Tracing was Re:

[Isaac Gutekunst]

Hi Vivek,

Let's get Chris involved in this discussion. He is the main mentor here and 
knows more about the direction the project should go.

 
On 03/17/2016 11:27 AM, vivek kukreja wrote:


Hello Isaac,
Thanks for your suggestions on my proposal. I will use your personal email for 
future correspondence. I have a few questions:
Can you please share some use-cases for tracing that developers are interested 
in?
I would like to understand the features you require at Vecna and the flow of 
how tracing should work for your purpose.

Our needs are only one factor. We need to consider the overall needs of the 
RTEMS community. That being said, I'll be happy to explain some more a little 
later.



Also can you give an overview about the lttng-live functionality you have 
implemented and how its used? And how it can be improved using CTF?



Take a look at the links I added to your document proposal:

Specifically:

https://github.com/lttng/lttng-tools/blob/master/doc/live-reading-protocol.txt


I would highly recommended reading the beginning of this document to understand 
what CTF really is.
http://diamon.org/ctf/#specification

I would also suggest building a barebones C program that can read a CTF stream 
given a super simple metadata file.Once you understand what CTF is, and how the 
metadata describes
it, this shouldn't take more than a day or two. That being said, it could take 
quite a long time for the concepts to make sense.

This program should not parse or read metadata at all, just interpret the 
stream assuming a fixed metadata file.
I did this exercise, and it was really helpful in intuitively understanding CTF.

lttng-live is a protocol that talks to a trace server over TCP (sometimes 
called relay daemon), and asks it for trace streams. It sends some messages and 
gets
some replies from the server, and then starts receiving the trace stream.



Isaac





Regards,
Vivek


On 17-Mar-2016, at 17:54, Isaac Gutekunst <isaac.guteku...@vecna.com> wrote:

I Vivek,

Thanks for the proposal. I am looking it over now!

Welcome to the program and hello!

A bit about me: I'm an embedded firmware engineer at Vecna Technologis 
(vecna.com). We are using RTEMS
here for our next generation robotics platform. We are also committed to 
helping RTEMS through open source
contributions, including mentoring GSoC students.

I'm really excited that you are interested in trace. There are a lot of 
fascinating and fundamental concepts lurking
within. There is also a huge opportunity to provide a feature which brings 
RTEMS closer to feature parity with some
of the most expensive commercial RTOSs. That's pretty awesome! I'm personally 
really excited because this functionality
has immediate use cases for our robotic work here. I've already done a decent 
amount of unreleased work adding
lttng-live functionality to one of our projects. It's super alpha quality, and 
written in C++ which might limit its
usefulness.

I also have a system for emitting trace messages into a different buffer (not 
the RTEMS Capture Engine), since I needed
to test it on Linux.


Chris: Does the current capture engine allow simultaneous reading and writing 
of trace data? This is an important feature for
us at Vecna, and I imagine would be useful to others. Especially with 
lttng-live support.

Chris: Should most communication be typically be done on the rtems-devel 
mailing list?

Another note:

You seem to have received the wrong email address. For GSoC I will either be 
using this email (from work),
or iguteku...@gmail.com (personal email associated with the GSoC website).

Isaac


On 03/17/2016 04:10 AM, vivek kukreja wrote:
Hi Chris,
Sorry for the delay. I was caught up with my college assessments.
First draft of my proposal is up and open for comments. I'm going
through the Capturing Engine documentation now and the Project
description will be modified once i hear your suggestions.

Also git services are working now since i will be using a different
internet connection henceforth.
I will setup RTEMS using the latest git repo and see if the error in
the fileio tracing example is resolved and send a patch for the
missing include statement at the earliest.

Regards,
Vivek


From: Chris Johns <chr...@rtems.org>
Sent: 16 March 2016 10:18
To: Vivek Kukreja; guteku...@gmail.com
Cc: Gedare Bloom
Subject: Re: GSoC 2016 Interested in Tracing was Re:

Hi,

I have reviewed your document but I could no actual proposal in the
Google Document https://goo.gl/8jRfyV.

I have updated the proposal template so please check it against your one.

I suggest you fill in each section answering the questions provided.
g and fundamental concepts lurking

within. There is also a huge opportunity to provide a feature which brings 
RTEMS closer to feature parity with some
of the most expensive commercial RTOSs. That's pretty awesome! I'm personally 
really exc

Thanks.
Chris


On 15/03/2016 00:22, Vivek Kukreja 

Re: IMFS_GENERIC_INITIALIZER deprecated?

[Isaac Gutekunst]

On 03/07/2016 02:44 PM, Sebastian Huber wrote:



- Am 7. Mrz 2016 um 20:07 schrieb Joel Sherrill j...@rtems.org:


On Mon, Mar 7, 2016 at 12:04 PM, Isaac Gutekunst <isaac.guteku...@vecna.com>
wrote:


Hi Developers,

We have used IMFS_GENERIC_INITIALIZER as part of some code that makes IMFS
nodes for devices.


The IMFS generic nodes have no stable API yet. For an examples see:

cpukit/dev/i2c/i2c-bus.c
cpukit/dev/i2c/i2c-dev.c
That's what I based my implementation on.. Silly of me not to check 
these file first. Thanks, that was enough to get this to work again.


Isaac


cpukit/libblock/src/blkdev-imfs.c





Can't you use the POSIX mknod() or the wrapper method rtems_io_register_
name()?


This stuff has a high overhead and doesn't give you access to all filesystem 
handlers.


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

IMFS_GENERIC_INITIALIZER deprecated?

[Isaac Gutekunst]

Hi Developers,

We have used IMFS_GENERIC_INITIALIZER as part of some code that makes 
IMFS nodes for devices.


It used to live in cpukit/libfs/src/imfs/imfs.h

This function doesn't seem to be around in master anymore. What is the 
suggested workaround/way to do filesystem based devices moving forward?



Isaac

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

Re: GSoC 2016 Interested in Tracing was Re:

[Isaac Gutekunst]

Hi Vivek,

Chris is definitely the person most knowledgeable in this area.





On 03/03/2016 11:45 AM, Joel Sherrill wrote:



On Thu, Mar 3, 2016 at 10:25 AM, Vivek Kukreja > wrote:

Hi everyone


I am Vivek Kukreja, currently pursuing Masters from India. I'm
interested in applying for GSOC this year. I am a skilled C
Programmer and have strong understanding of OS concepts. I'm
interested in system programming and kernel development.


I am interested to work on topics under Tracing. I am intrigued by
the topic. I think this will be a good place to start for me.


That's a good area that needs work. Chris Johns is the core person in
this area. He is in
Sydney and will likely comment once he is awake. :)

I gave a presentation at the Flight Software Workshop in 2014 on the
RTEMS ecosystem.
Tracing was included in that presentation and Chris helped with the
slides. The slides are
here:

http://flightsoftware.jhuapl.edu/files/2014/Presentations/Day-2/Session-3/2-RTEMSProjectEcosystem.pdf

There is a video of my presentation if you want to see it. But this
presentation covers the
background and status.

I have gone through Getting Started documentation and setup RTEMS on
my machine. I have tried running the provided examples. I tried to
run the tracing example, but am facing some problem during
compilation (wrapper compilation error). I will continue looking
into it, and report if I can't solve the problem on my own.


Focus first on doing the GSoC Hello World and adding yourself to the
list of students.
Then ask specific questions about those examples.

Please tell me about the open projects under the Tracing Tool. I
request you to please give me some pointers to get started.


Chris is the person to make sure the task list is current and in priority.

But I know there is work to be done on generation of method trace wrappers,
getting trace data off target (tcp/ip, etc), and producing Common Trace
Format
and integrating with the Linux Trace Toolkit.

My understanding is that the Linux Trace Toolkit can also dynamically
interact (bidirectionally) with the target system. I don't know what that
entails but it is desirable. But it requires having basic integration solved
first.


I have done some work on the side trying to understand the lttng-live 
trace protocol


The Linux Trace Toolkit has one component that runs on a potentially 
remote system, and captures trace information.


A different system can connect to the system being traced using the 
lttng-live protocol.


See 
https://github.com/lttng/lttng-tools/blob/master/doc/live-reading-protocol.txt


It is a fairly straightforward binary protocol with a handshake, and a 
few interactions before raw CTF is sent back in a request/response manner.



The lttng-live relay daemon is what provides this service.

The code for that can be seen here:

https://github.com/lttng/lttng-tools/tree/master/src/common/relayd


I've done some work to implement the lttng-live protocol as a proof of 
concept as part of some development here.


I'd be interested in providing some help to make RTEMS Trace Capture 
Engine support storing logs in CTF format, and making them available via 
lttng-live.



Hope this helps as well,

Isaac







I hope that helps.

--joel

Regards,

Vivek



___
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: RTEMS User Level Tracing?

[Isaac Gutekunst]

Sorry for the even longer delay between replies. I've been on vacation.

I think clarifying a few things will be helpful.

barectf takes a yaml file describing a bunch of data types that can be 
logged. The python tool will generate a c file that has function like

log_my_data_type(MyDataType* data, Stream * stream);

and a CTF descriptor

Calling that function will serialize data, and send it down stream. 
Stream is conceptual trace output buffer. Barectf interacts with the 
stream through a a set of functions, like write_bytes, and 
is_stream_full? ( I made up these names for clarity).


The bytes written to stream will be in CTF format. Therefore, putting 
them in a file with the generated descriptor will allow you to read the 
stream with babeltrace or another tool that supports CTF files.


The README on the GitHub page is actually quite good at getting you up 
to speed quickly for areas where my explanation is lacking.


So I'm thinking barectuf could be stuck into RTEMS and used as the 
serialization mechanism for all trace facilities. For the trace linker, 
we could define a set of data types for function entry, function exit, 
etc. Rather than using printk to send out the trace, we would use barectf.



I've also spent some time looking at the lttng-live protocol. If RTEMS 
did adopt barectf, or another CTF serialization solution, it would open 
up the possibility of connecting to an running RTEMS application 
directly via TCP/IP using babeltrace or tracecompass and see traces in 
real time.


The lttng-live protocol is not overly complicated, and probably could be 
implemented in a few weeks. I've almost done with a rough proof of 
concept server that has a single hard coded stream and send pre-captured 
trace data.





On 01/03/16 18:49, Chris Johns wrote:
> On 12/22/15 02:38, Isaac Gutekunst wrote:
>>
>>
>> On 12/20/2015 08:02 PM, Chris Johns wrote:
>>> On 19/12/2015 6:36 AM, isaac.gutekunst wrote:
>>>>
>>>> We're interested in trace some application data in our RTEMS project.
>>>> Here's a bunch of background and thoughts:
>>>>
>>>> I've read the following pages:
>>>>  * https://devel.rtems.org/wiki/Developer/Tracing
>>>>  * https://devel.rtems.org/wiki/Developer/Tracing/Trace_Linker
>>>>
>>>> I think I have an understanding of the current system as documented.
>>>> Tracing user defined data types seems to be missing. I'm looking for
>>>> something more like barectf. Is there any such support available, 
or any

>>>> plans to support it? I don't want to reinvent the wheel.
>>>
>>> User defined data is not directly support but can be added if you add a
>>> custom generator. There is not a great deal of documentation about how
>>> to do this. An example generator is:
>>>
>>> https://git.rtems.org/rtems-tools/tree/linkers/rtld-trace-buffer.ini
>>>
>> Cool. I'll take a closer look at this.
>>> You could add anything specific you want. It is not a great 
solution but

>>> tracing into data being passed by pointers is difficult.
>>>
>> Definitely. You quickly come to the great serialization problem, and are
>> bound to reinvent the wheel a few times.
>
> Yes and SMP makes this even more complicated. We need to ensure we 
have a low overhead solution. Work in this area has been done by Joel 
and Jennifer.

>
I haven't figured out what the Capture Engine does exactly. Does it 
simply buffer the printk output?


Apologies for not looking into the code myself. It looks like the 
Capture Engine outputs data in some format that babletrace can 
understand and convert into CTF.


I'm proposing that we integrate barectf into the Capture Engine (or 
elsewhere), so the Capture Engine directly outputs CTF. However, I may 
be confused about what's going on.


I'm presuming that the instrumented application has calls to functions 
inserted for entry and exit to the functions a user wants to trace. 
These functions generate some data, and then the Capture Engine stores 
this and makes it available later.


I'm unclear about what this data is, and how it gets to the capture 
engine. Where is the code for this located?

>>> You would need to use the various options to get a copy of the trace
>>> wrapper file and then get the generator to see the headers and various
>>> data you want.
>>>
>>>> If there isn't support already, maybe some parts of the trace
>>>> infrastructure can be reused, notably the backed for storing the data,
>>>> and/or sending it out over the network. Are there plans to make the
>>>> Trace Linker natively output CTF data?
>>>
>>> We would like to support CTF output. Getting this done wo

Re: RTEMS User Level Tracing?

[Isaac Gutekunst]

On 12/20/2015 08:02 PM, Chris Johns wrote:

On 19/12/2015 6:36 AM, isaac.gutekunst wrote:


We're interested in trace some application data in our RTEMS project.
Here's a bunch of background and thoughts:

I've read the following pages:
 * https://devel.rtems.org/wiki/Developer/Tracing
 * https://devel.rtems.org/wiki/Developer/Tracing/Trace_Linker

I think I have an understanding of the current system as documented.
Tracing user defined data types seems to be missing. I'm looking for
something more like barectf. Is there any such support available, or any
plans to support it? I don't want to reinvent the wheel.


User defined data is not directly support but can be added if you add a
custom generator. There is not a great deal of documentation about how
to do this. An example generator is:

  https://git.rtems.org/rtems-tools/tree/linkers/rtld-trace-buffer.ini


Cool. I'll take a closer look at this.

You could add anything specific you want. It is not a great solution but
tracing into data being passed by pointers is difficult.

Definitely. You quickly come to the great serialization problem, and are bound to reinvent the 
wheel a few times.

You would need to use the various options to get a copy of the trace
wrapper file and then get the generator to see the headers and various
data you want.


If there isn't support already, maybe some parts of the trace
infrastructure can be reused, notably the backed for storing the data,
and/or sending it out over the network. Are there plans to make the
Trace Linker natively output CTF data?


We would like to support CTF output. Getting this done would need
developer funding.


We would like tracing for at least user defined data, and will be developing that 
functionality. If we could do so in a way that helps the existing RTEMS trace, we'd love to.





Perhaps barectf could be used for this purpose.


I do not know what this. Do you have a reference?


https://github.com/efficios/barectf

It takes in a YAML file, and generates a C file with functions that allow tracing user defined 
structs. It will output those to a custom "backend" in serialized form. The documentation is 
pretty good. I've used in briefly in a bare metal PIC32 project with success.


A potential plan of action:
1) Make a barectf backend for RTEMS. (This could re-use existing features). Probably 
package/make it available via RSB.

2) Update the trace linker to use it (I don't really know what this means just 
yet).
3) Make a mechanism/ document a standard way to integrate trace with a user application. I'd 
imagine this could involve a RSB package, although it's rather simple (yaml file becomes a C 
and H file that needs to be linked against a 'backend').


4) For the ARM architecture, using the ITM to output data could be very useful. This could fit 
somewhere into this picture.


I would be doing most or all of the work here, unless of course anyone wants to 
help.

I'm looking for ideas and suggestions. If there is some functionality of direction you'd like 
us to pursue, let me know.


Thanks,

Isaac


Chris
___
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: Random lwIP Crashes in _POSIX_Mutex_Lock_support()

[Isaac Gutekunst]

On 10/23/2015 08:50 AM, Joel Sherrill wrote:



On October 23, 2015 7:02:34 AM CDT, Joel Sherrill <joel.sherr...@oarcorp.com> 
wrote:



On October 22, 2015 1:37:18 PM CDT, Isaac Gutekunst
<isaac.guteku...@vecna.com> wrote:

I think I may have some information that's actually useful.

I've managed to actually execute some tests and lots of them are
failing.

sp01 and sp02 fail quite quickly, as an assertion fails.

assertion "first != _Chain_Tail( _queues[ index ] )" failed:

file


"../../cpukit/../../../stm32f7x/lib/
include/rtems/score/schedulerpriorityimpl.h", line
166, function: _Scheduler_priority_Ready_queue_first

This failure is common to many of the failed tests so far. What does
this mean?



Does hello run?



Yes

Yes. Here are the results of running all the samples:


RTEMS Testing - Tester, v0.2.0
[1/9] p:0 f:0 t:0 i:0 | arm/stm32f7x: base_sp.exe
[2/9] p:1 f:0 t:0 i:0 | arm/stm32f7x: capture.exe
[3/9] p:1 f:1 t:0 i:0 | arm/stm32f7x: fileio.exe
[4/9] p:2 f:1 t:0 i:0 | arm/stm32f7x: hello.exe
[5/9] p:3 f:1 t:0 i:0 | arm/stm32f7x: minimum.exe
[6/9] p:4 f:1 t:0 i:0 | arm/stm32f7x: nsecs.exe
[7/9] p:4 f:2 t:0 i:0 | arm/stm32f7x: paranoia.exe
[8/9] p:5 f:2 t:0 i:0 | arm/stm32f7x: ticker.exe
[9/9] p:5 f:3 t:0 i:0 | arm/stm32f7x: unlimited.exe
Passed: 5
Failed: 4
Timeouts: 0
Invalid: 0
Total: 9
Average test time: 0:00:13.072150
Testing time : 0:01:57.649357



Sorry to follow up so quickly.  Set your console driver to polling mode. Run 
hello. It should work before you move on. There should be no interrupts at all.

Then turn console interrupts on and get it running again. There should only be 
console interrupts.

Then move on to ticker. Clock tick and console if not in polled.


Ticker does not seem to work. This is a concrete area to investigate. I have 
some suspicions.


Did all interrupt handlers get installed using RTEMS ISR installation method? 
Are there any which do not use this?
I think they all use the RTEMS method. There might be some lurking in the HAL code from ST. If 
so, that's a bit scary and could maybe explain a lot.


For all RTEMS standard tests, there should be no drivers except those 
explicitly configured. All other devices may need to be tickled to be quiet but 
usually are not touched or referenced.

If the minimum test has driver symbols in it, it shouldn't. :)


We'll clean that up.

Isaac

On 10/22/2015 09:16 AM, Jay Doyle wrote:



On 10/22/2015 01:40 AM, Sebastian Huber wrote:



On 21/10/15 15:48, Jay Doyle wrote:



On 10/21/2015 09:35 AM, Sebastian Huber wrote:



On 21/10/15 15:08, Isaac Gutekunst wrote:



On 10/21/2015 09:00 AM, Sebastian Huber wrote:



On 21/10/15 14:56, Isaac Gutekunst wrote:

On 10/21/2015 08:24 AM, Sebastian Huber wrote:



On 21/10/15 14:13, Isaac Gutekunst wrote:

Thanks for the reply.

On 10/21/2015 01:50 AM, Sebastian Huber wrote:



On 20/10/15 16:02, Isaac Gutekunst wrote:

[...]




As far as I can tell this would only occur if the caller

of

pthread_mutex_lock was in a
"bad"
state. I don't believe it is in an interrupt context, and
don't know what other bad states
could exist.


We have

#define _CORE_mutex_Check_dispatch_for_seize(_wait) \
(!_Thread_Dispatch_is_enabled() \
  && (_wait) \
  && (_System_state_Get() >= SYSTEM_STATE_UP))

What is the thread dispatch disable level and the system

state

at this point?

In case the thread dispatch disable level is not zero, then
something is probably broken
in the
operating system code which is difficult to find. Could be

a

general memory corruption
problem
too. Which RTEMS version do you use?



The thread dispatch disable level is usually -1 or -2.
(0xFFFE or 0xFFD).


A negative value is very bad, but easy to detect via manual
instrumentation (only an hand full
of spots touch this variable) or hardware
breakpoints/watchpoints. Looks the rest of
_Per_CPU_Information all right?


It looks like it's only the thread_dispatch_disable_level

that's

broken.

We'll go and grep for all places for all the places it's

touched,

and look for something.

The problem with watchpoints is they fire exceptionally often,

and

putting in a conditional
watchpoint slows the code to a crawl, but that may be worth

it.


Here are some printouts of the relevant structs right after a

crash:


$4 = {
   cpu_per_cpu = {},
   isr_nest_level = 0,
   thread_dispatch_disable_level = 4294967295,
   executing = 0xc01585c8,
   heir = 0xc0154038,
   dispatch_necessary = true,
   time_of_last_context_switch = {
 sec = 2992,
 frac = 10737447432380511034
   },
   Stats = {}
}


No, this doesn't look good. According to the stack trace you

are

in

thread context. However, we
have executing != heir and dispatch_necessary == true. This is

a

broken state itself. I guess,
something is wrong with the interrupt level so that a context
switch is blocked. On ARMv7-M
this is done via the system call exception.


This is a

Re: Random lwIP Crashes in _POSIX_Mutex_Lock_support()

[Isaac Gutekunst]

We finally have a culprit. Enabling the CAN driver causes the same tests to 
fail.

Thank you everyone for all the help! We actually have something to go on now.

Isaac
On 10/23/2015 09:37 AM, Joel Sherrill wrote:



On 10/23/2015 8:01 AM, Isaac Gutekunst wrote:

On 10/23/2015 08:50 AM, Joel Sherrill wrote:



On October 23, 2015 7:02:34 AM CDT, Joel Sherrill <joel.sherr...@oarcorp.com> 
wrote:



On October 22, 2015 1:37:18 PM CDT, Isaac Gutekunst
<isaac.guteku...@vecna.com> wrote:

I think I may have some information that's actually useful.

I've managed to actually execute some tests and lots of them are
failing.

sp01 and sp02 fail quite quickly, as an assertion fails.

assertion "first != _Chain_Tail( _queues[ index ] )" failed:

file


"../../cpukit/../../../stm32f7x/lib/
include/rtems/score/schedulerpriorityimpl.h", line
166, function: _Scheduler_priority_Ready_queue_first

This failure is common to many of the failed tests so far. What does
this mean?



Does hello run?



Yes

Yes. Here are the results of running all the samples:


RTEMS Testing - Tester, v0.2.0
[1/9] p:0 f:0 t:0 i:0 | arm/stm32f7x: base_sp.exe
[2/9] p:1 f:0 t:0 i:0 | arm/stm32f7x: capture.exe
[3/9] p:1 f:1 t:0 i:0 | arm/stm32f7x: fileio.exe
[4/9] p:2 f:1 t:0 i:0 | arm/stm32f7x: hello.exe
[5/9] p:3 f:1 t:0 i:0 | arm/stm32f7x: minimum.exe
[6/9] p:4 f:1 t:0 i:0 | arm/stm32f7x: nsecs.exe
[7/9] p:4 f:2 t:0 i:0 | arm/stm32f7x: paranoia.exe
[8/9] p:5 f:2 t:0 i:0 | arm/stm32f7x: ticker.exe
[9/9] p:5 f:3 t:0 i:0 | arm/stm32f7x: unlimited.exe
Passed: 5
Failed: 4
Timeouts: 0
Invalid: 0
Total: 9
Average test time: 0:00:13.072150
Testing time : 0:01:57.649357



Sorry to follow up so quickly.  Set your console driver to polling mode. Run 
hello. It
should work before you move on. There should be no interrupts at all.

Then turn console interrupts on and get it running again. There should only be 
console
interrupts.

Then move on to ticker. Clock tick and console if not in polled.


Ticker does not seem to work. This is a concrete area to investigate. I have 
some suspicions.


Once this works, all of the standard tests should work.




Did all interrupt handlers get installed using RTEMS ISR installation method? 
Are there any
which do not use this?

I think they all use the RTEMS method. There might be some lurking in the HAL 
code from ST. If
so, that's a bit scary and could maybe explain a lot.


This would break things in an interesting way.

Any method marked as an interrupt handler via the gcc attribute would be
suspect. But theymay have their own infrastructure as well.



For all RTEMS standard tests, there should be no drivers except those 
explicitly configured.
All other devices may need to be tickled to be quiet but usually are not 
touched or referenced.

If the minimum test has driver symbols in it, it shouldn't. :)


We'll clean that up.

Isaac

On 10/22/2015 09:16 AM, Jay Doyle wrote:



On 10/22/2015 01:40 AM, Sebastian Huber wrote:



On 21/10/15 15:48, Jay Doyle wrote:



On 10/21/2015 09:35 AM, Sebastian Huber wrote:



On 21/10/15 15:08, Isaac Gutekunst wrote:



On 10/21/2015 09:00 AM, Sebastian Huber wrote:



On 21/10/15 14:56, Isaac Gutekunst wrote:

On 10/21/2015 08:24 AM, Sebastian Huber wrote:



On 21/10/15 14:13, Isaac Gutekunst wrote:

Thanks for the reply.

On 10/21/2015 01:50 AM, Sebastian Huber wrote:



On 20/10/15 16:02, Isaac Gutekunst wrote:

[...]




As far as I can tell this would only occur if the caller

of

pthread_mutex_lock was in a
"bad"
state. I don't believe it is in an interrupt context, and
don't know what other bad states
could exist.


We have

#define _CORE_mutex_Check_dispatch_for_seize(_wait) \
 (!_Thread_Dispatch_is_enabled() \
   && (_wait) \
   && (_System_state_Get() >= SYSTEM_STATE_UP))

What is the thread dispatch disable level and the system

state

at this point?

In case the thread dispatch disable level is not zero, then
something is probably broken
in the
operating system code which is difficult to find. Could be

a

general memory corruption
problem
too. Which RTEMS version do you use?



The thread dispatch disable level is usually -1 or -2.
(0xFFFE or 0xFFD).


A negative value is very bad, but easy to detect via manual
instrumentation (only an hand full
of spots touch this variable) or hardware
breakpoints/watchpoints. Looks the rest of
_Per_CPU_Information all right?


It looks like it's only the thread_dispatch_disable_level

that's

broken.

We'll go and grep for all places for all the places it's

touched,

and look for something.

The problem with watchpoints is they fire exceptionally often,

and

putting in a conditional
watchpoint slows the code to a crawl, but that may be worth

it.


Here are some printouts of the relevant structs right after a

crash:


$4 = {
cpu_per_cpu = {},
isr_nest_level = 0,
thread_dispatch_disable_level = 4294967295,
executing = 0xc

Re: Random lwIP Crashes in _POSIX_Mutex_Lock_support()

[Isaac Gutekunst]

I think I may have some information that's actually useful.

I've managed to actually execute some tests and lots of them are failing.

sp01 and sp02 fail quite quickly, as an assertion fails.

assertion "first != _Chain_Tail( _queues[ index ] )" failed: file 
"../../cpukit/../../../stm32f7x/lib/ include/rtems/score/schedulerpriorityimpl.h", line 
166, function: _Scheduler_priority_Ready_queue_first


This failure is common to many of the failed tests so far. What does this mean?


Isaac

On 10/22/2015 09:16 AM, Jay Doyle wrote:



On 10/22/2015 01:40 AM, Sebastian Huber wrote:



On 21/10/15 15:48, Jay Doyle wrote:



On 10/21/2015 09:35 AM, Sebastian Huber wrote:



On 21/10/15 15:08, Isaac Gutekunst wrote:



On 10/21/2015 09:00 AM, Sebastian Huber wrote:



On 21/10/15 14:56, Isaac Gutekunst wrote:

On 10/21/2015 08:24 AM, Sebastian Huber wrote:



On 21/10/15 14:13, Isaac Gutekunst wrote:

Thanks for the reply.

On 10/21/2015 01:50 AM, Sebastian Huber wrote:



On 20/10/15 16:02, Isaac Gutekunst wrote:

[...]




As far as I can tell this would only occur if the caller of
pthread_mutex_lock was in a
"bad"
state. I don't believe it is in an interrupt context, and
don't know what other bad states
could exist.


We have

#define _CORE_mutex_Check_dispatch_for_seize(_wait) \
   (!_Thread_Dispatch_is_enabled() \
 && (_wait) \
 && (_System_state_Get() >= SYSTEM_STATE_UP))

What is the thread dispatch disable level and the system state
at this point?

In case the thread dispatch disable level is not zero, then
something is probably broken
in the
operating system code which is difficult to find. Could be a
general memory corruption
problem
too. Which RTEMS version do you use?



The thread dispatch disable level is usually -1 or -2.
(0xFFFE or 0xFFD).


A negative value is very bad, but easy to detect via manual
instrumentation (only an hand full
of spots touch this variable) or hardware
breakpoints/watchpoints. Looks the rest of
_Per_CPU_Information all right?


It looks like it's only the thread_dispatch_disable_level that's
broken.

We'll go and grep for all places for all the places it's touched,
and look for something.

The problem with watchpoints is they fire exceptionally often, and
putting in a conditional
watchpoint slows the code to a crawl, but that may be worth it.

Here are some printouts of the relevant structs right after a crash:

$4 = {
  cpu_per_cpu = {},
  isr_nest_level = 0,
  thread_dispatch_disable_level = 4294967295,
  executing = 0xc01585c8,
  heir = 0xc0154038,
  dispatch_necessary = true,
  time_of_last_context_switch = {
sec = 2992,
frac = 10737447432380511034
  },
  Stats = {}
}


No, this doesn't look good. According to the stack trace you are in
thread context. However, we
have executing != heir and dispatch_necessary == true. This is a
broken state itself. I guess,
something is wrong with the interrupt level so that a context
switch is blocked. On ARMv7-M
this is done via the system call exception.


This is a bit beyond my RTEMS knowledge. What would you advise
looking into?


I would try to instrument the code to figure out where the thread
dispatch disable level goes negative.



We just did.  I added a check in _ARMV7M_Interrupt_service_leave to
see if the _Thread_Dispatch_disable_level is positive before the
decrementing it and this eventually fails.

I'm not sure if this tells us much because I think the call itself
correct.  In this particular case it is processing an I2C interrupt.
I will try to see if we can capture information about the sequence of
changes to the _Thread_Dispatch_disable_level just before the point in
which we know something is clearly wrong (i.e., decreasing it below
zero.)


Since the isr_nest_level is 0, I don't think its a problem with the spots that 
use
_ARMV7M_Interrupt_service_leave(). Did you check the interrupt priorities? See 
also

https://lists.rtems.org/pipermail/users/2015-June/029155.html


Thanks for the pointer to this posting.  It seems like a very similar situation 
to what we are
experiencing -- especially considering that we invoke an RTEMS call in our 
ethernet isr.
Unfortunately, all our interrupts use the default interrupt priority level set 
in the bsp
header file as:

#define BSP_ARMV7M_IRQ_PRIORITY_DEFAULT (13 << 4)

which should be mean that they are all non-NMIs unless we explicitly set their 
interrupt level
lower.




___
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: Per-BSP confdefs (or resource allocation)

[Isaac Gutekunst]

On 10/22/2015 10:30 AM, Joel Sherrill wrote:



On 10/22/2015 8:55 AM, Isaac Gutekunst wrote:

On 10/22/2015 01:33 AM, Sebastian Huber wrote:



On 21/10/15 21:53, Isaac Gutekunst wrote:

Hi Devel,

I looked for a while, but couldn't find a way to specify what resources 
(semaphores, tasks,
etc) a BSP requires for an empty project (empty Init function).


There is no useful support for this and this is a constant source of problems.

One way out of this situation would be to use self-contained objects for the 
drivers.



I took a look at this page:
https://docs.rtems.org/doc-current/share/rtems/html/bsp_howto/Initialization-Code-The-RTEMS-Configuration-Table.html

but couldn't glean the correct method.

What is the preferred way to do so?

Our BSP uses a number of resources for hardware drivers, including UART, CAN, 
SPI, I2C and
Ethernet.




In case an empty project includes all these drivers, then something is wrong 
with this BSP.


That's good to know. Is it advisable to have all the drivers disabled by 
default? Of course, at
minimum a BSP needs a console driver.


Technically a BSP doesn't even need that. Many applications field without one.
The clock tick is technically also optional but that is almost universally 
required
by applications. The minimum BSP technically only needs to startup and shutdown.

But if you want to link/run all the tests, you need a console, clock tick, and
benchmark timer driver.

I have seen bspstart.c or other initialization files pull in more than minimum
required. I have also seen bugs in Makefile.am that result in the entire BSP
being a binary blob always linked in.
I'm not sure whether our Makefile.am is done correctly. As we move forward with getting it 
merged into mainline, I'm sure we'll get some useful feedback.





Our console driver does use one task, and one or more mutexes. Is this 
something we should try
hard to change?


Why does it use so many resources? The termios framework provides all the
buffering internally and confdefs.h accounts for them.


I was a bit confused. Talking to Jay and looking at the code, the termios console does not use 
any additional kernel resources.


We do use additional resources to expose serial ports via a raw interface (IMFS) to bypass the 
termios overhead. The kernel drivers for these are still in our branch, not mainline.



It looks like for our case, the two areas that use additional resources are for two new "device 
classes", CAN and raw UART that aren't present in the kernel. If we get these new drivers 
merged into the RTEMS kernel at some point (perhaps after living in the BSP for a while, to 
shake out bugs), we can update confdefs.h to account for those resources since at that point, 
they will have the potential to be used in other BSPs.



Isaac


--joel



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

Selecting Tests to run/Missing tests

[Isaac Gutekunst]

Hi All,

I'm trying to run the RTEMS tests for our new BSP. I've managed to get close, but am missing 
something. In general, I'm trying to figure out how the build system decides what tests to build.


Below is a bunch of information about what I've tried. It might be irrelevant, so if there is 
something obvious, just don't bother reading and let me know :)



Details
---

I run configure with --enable tests, and have disabled a bunch of tests that don't compile. See 
the list further down. The file does have effect.


../rtems/configure --enable-rtemsbsp="stm32f7x" --enable-maintainer-mode --enable-tests 
--target=arm-rtems4.11 --prefix=/other/rtems/lib-rtems --disable-networking --enable-rtems-debug


In the install path, I have a bunch of tests exes.

They are specifically located in

/other/rtems/lib-rtems/arm-rtems4.11/stm32f7x/lib/rtems-4.12/tests/

psxtmbarrier01.doc  psxtmmutex01.exe  psxtmsem03.doc
psxtmbarrier01.exe  psxtmmutex02.doc  psxtmsem03.exe
psxtmbarrier02.doc  psxtmmutex02.exe  psxtmsem04.doc
psxtmbarrier02.exe  psxtmmutex03.doc  psxtmsem04.exe
psxtmbarrier03.doc  psxtmmutex03.exe  psxtmsem05.doc
psxtmbarrier03.exe  psxtmmutex04.doc  psxtmsem05.exe
psxtmbarrier04.doc  psxtmmutex04.exe  psxtmsleep01.doc
psxtmbarrier04.exe  psxtmmutex05.doc  psxtmsleep01.exe
psxtmcond01.doc psxtmmutex05.exe  psxtmsleep02.doc
psxtmcond01.exe psxtmmutex06.doc  psxtmsleep02.exe
psxtmcond02.doc psxtmmutex06.exe  psxtmthread01.doc
psxtmcond02.exe psxtmmutex07.doc  psxtmthread01.exe
psxtmcond03.doc psxtmmutex07.exe  psxtmthread02.doc
psxtmcond03.exe psxtmnanosleep01.doc  psxtmthread02.exe
psxtmcond04.doc psxtmnanosleep01.exe  psxtmthread03.doc
psxtmcond04.exe psxtmnanosleep02.doc  psxtmthread03.exe
psxtmcond05.doc psxtmnanosleep02.exe  psxtmthread04.doc
psxtmcond05.exe psxtmrwlock01.doc psxtmthread04.exe
psxtmcond06.doc psxtmrwlock01.exe psxtmthread05.doc
psxtmcond06.exe psxtmrwlock02.doc psxtmthread05.exe
psxtmcond07.doc psxtmrwlock02.exe psxtmthread06.doc
psxtmcond07.exe psxtmrwlock03.doc psxtmthread06.exe
psxtmcond08.doc psxtmrwlock03.exe rhdeadlockbrk.adoc
psxtmcond08.exe psxtmrwlock04.doc rhdeadlockbrk.exe
psxtmcond09.doc psxtmrwlock04.exe rhilatency.adoc
psxtmcond09.exe psxtmrwlock05.doc rhilatency.exe
psxtmcond10.doc psxtmrwlock05.exe rhmlatency.adoc
psxtmcond10.exe psxtmrwlock06.doc rhmlatency.exe
psxtmkey01.doc  psxtmrwlock06.exe rhsemshuffle.adoc
psxtmkey01.exe  psxtmrwlock07.doc rhsemshuffle.exe
psxtmkey02.doc  psxtmrwlock07.exe rhtaskpreempt.adoc
psxtmkey02.exe  psxtmsem01.docrhtaskpreempt.exe
psxtmmq01.doc   psxtmsem01.exerhtaskswitch.adoc
psxtmmq01.exe   psxtmsem02.docrhtaskswitch.exe
psxtmmutex01.docpsxtmsem02.exe

This is missing a bunch of tests.


This is the contents of libbsp/arm/stm32f7x/make/custom/stm32f7x-testsuite.tcfg

fsdosfsname01
jffs2_fserror
jffs2_fslink
jffs2_fspatheval
jffs2_fspermission
jffs2_fsrdwr
jffs2_fsscandir01
jffs2_fssymlink
jffs2_fstime
devfs01
devfs02
devfs03
devfs04
termios02
termios03
termios04
stringto01
math
mathf
tar03
mathl
complex
sptimecounter01
spfatal26
spinternalerror01
fsnofs01


--
Isaac Gutekunst
Embedded Systems Software Engineer
isaac.guteku...@vecna.com
www.vecna.com
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Add STM32 HAL Files for F4 and F7

[Isaac Gutekunst]

I haven't actually looked at every file individually, but AFIK yes.

Isaac

On 10/21/2015 11:55 AM, Gedare Bloom wrote:

Isaac,

Is all the code attached licensed under a 2/3-bsd?

Gedare

On Wed, Oct 14, 2015 at 4:54 PM, Joel Sherrill
<joel.sherr...@oarcorp.com> wrote:



On 10/14/2015 3:35 PM, Gedare Bloom wrote:


I don't have a problem on the surface of it, but can we get a clear
statement of the licensing for the included code?



The patch is huge but includes the license in pdf and rtf format.
Based on the one source file I looked at, the license is BSD
w/advertising. I am not sure if this is the same with all files.

This is a cut and paste from a file added:

+  *  COPYRIGHT(c) 2015 STMicroelectronics
+  *
+  * Redistribution and use in source and binary forms, with or without
modification,
+  * are permitted provided that the following conditions are met:
+  *   1. Redistributions of source code must retain the above copyright
notice,
+  *  this list of conditions and the following disclaimer.
+  *   2. Redistributions in binary form must reproduce the above copyright
notice,
+  *  this list of conditions and the following disclaimer in the
documentation
+  *  and/or other materials provided with the distribution.
+  *   3. Neither the name of STMicroelectronics nor the names of its
contributors
+  *  may be used to endorse or promote products derived from this
software
+  *  without specific prior written permission.
+  *
+  * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
IS"
+  * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
THE
+  * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE
+  * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
LIABLE
+  * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL
+  * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR
+  * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER
+  * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY,
+  * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE
+  * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+  *






On Mon, Sep 28, 2015 at 4:25 PM, Isaac Gutekunst
<isaac.guteku...@vecna.com> wrote:


Hi Devel,

As mentioned earlier, Vecna has developed two BSP families using the HAL
code provide by ST as a foundation. The code isn't perfect, but it let us
get up to speed very fast, and provides a consistent abstraction across a
number of processors.

I formatted a giant patch with all the relevant files needed for the new
BSP
that will be arriving later. The plan is to get this code approved and
merged, and then add the BSP piece by piece to reduce the amount of code
coming in at once.


This includes some HAL files that we aren't using in the BSP just yet.
Let
me know if we should remove them. It's a rather absurd amount of code :)


As before, I can't get git-send-email to work. In addition, the patches
are
giant, so I've inserted links to files in Google Drive.

https://drive.google.com/open?id=0BxaqNLUoI5onZ3lUUDNrYXlyX1U
https://drive.google.com/open?id=0BxaqNLUoI5onM3JsenRJRkotWm8



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



--
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: Selecting Tests to run/Missing tests

[Isaac Gutekunst]

Thanks Joel, that pushed me in the right direction.

All the missing tests where living in the build tree, not the install tree.

I've now gotten to the point where none of the tests run, but that's another problem for 
another email.


On 10/21/2015 01:57 PM, Joel Sherrill wrote:



On 10/21/2015 12:30 PM, Isaac Gutekunst wrote:

Hi All,

I'm trying to run the RTEMS tests for our new BSP. I've managed to get close, 
but am missing
something. In general, I'm trying to figure out how the build system decides 
what tests to
build.

Below is a bunch of information about what I've tried. It might be irrelevant, 
so if there is
something obvious, just don't bother reading and let me know :)


There is not as much magic as you might suspect. :)

Comments scattered below.


Details
---

I run configure with --enable tests, and have disabled a bunch of tests that 
don't compile. See
the list further down. The file does have effect.

../rtems/configure --enable-rtemsbsp="stm32f7x" --enable-maintainer-mode 
--enable-tests
--target=arm-rtems4.11 --prefix=/other/rtems/lib-rtems --disable-networking 
--enable-rtems-debug


(1) You can configure for no tests, samples only, or all tests.

The set of tests built varies based on if things like networking,
posix, and SMP are enabled.


In the install path, I have a bunch of tests exes.

They are specifically located in

/other/rtems/lib-rtems/arm-rtems4.11/stm32f7x/lib/rtems-4.12/tests/

psxtmbarrier01.doc  psxtmmutex01.exe  psxtmsem03.doc
psxtmbarrier01.exe  psxtmmutex02.doc  psxtmsem03.exe
psxtmbarrier02.doc  psxtmmutex02.exe  psxtmsem04.doc
psxtmbarrier02.exe  psxtmmutex03.doc  psxtmsem04.exe
psxtmbarrier03.doc  psxtmmutex03.exe  psxtmsem05.doc
psxtmbarrier03.exe  psxtmmutex04.doc  psxtmsem05.exe
psxtmbarrier04.doc  psxtmmutex04.exe  psxtmsleep01.doc
psxtmbarrier04.exe  psxtmmutex05.doc  psxtmsleep01.exe
psxtmcond01.doc psxtmmutex05.exe  psxtmsleep02.doc
psxtmcond01.exe psxtmmutex06.doc  psxtmsleep02.exe
psxtmcond02.doc psxtmmutex06.exe  psxtmthread01.doc
psxtmcond02.exe psxtmmutex07.doc  psxtmthread01.exe
psxtmcond03.doc psxtmmutex07.exe  psxtmthread02.doc
psxtmcond03.exe psxtmnanosleep01.doc  psxtmthread02.exe
psxtmcond04.doc psxtmnanosleep01.exe  psxtmthread03.doc
psxtmcond04.exe psxtmnanosleep02.doc  psxtmthread03.exe
psxtmcond05.doc psxtmnanosleep02.exe  psxtmthread04.doc
psxtmcond05.exe psxtmrwlock01.doc  psxtmthread04.exe
psxtmcond06.doc psxtmrwlock01.exe  psxtmthread05.doc
psxtmcond06.exe psxtmrwlock02.doc  psxtmthread05.exe
psxtmcond07.doc psxtmrwlock02.exe  psxtmthread06.doc
psxtmcond07.exe psxtmrwlock03.doc  psxtmthread06.exe
psxtmcond08.doc psxtmrwlock03.exe  rhdeadlockbrk.adoc
psxtmcond08.exe psxtmrwlock04.doc  rhdeadlockbrk.exe
psxtmcond09.doc psxtmrwlock04.exe  rhilatency.adoc
psxtmcond09.exe psxtmrwlock05.doc  rhilatency.exe
psxtmcond10.doc psxtmrwlock05.exe  rhmlatency.adoc
psxtmcond10.exe psxtmrwlock06.doc  rhmlatency.exe
psxtmkey01.docpsxtmrwlock06.exe  rhsemshuffle.adoc
psxtmkey01.exepsxtmrwlock07.doc  rhsemshuffle.exe
psxtmkey02.docpsxtmrwlock07.exe  rhtaskpreempt.adoc
psxtmkey02.exepsxtmsem01.doc  rhtaskpreempt.exe
psxtmmq01.docpsxtmsem01.exe  rhtaskswitch.adoc
psxtmmq01.exepsxtmsem02.doc  rhtaskswitch.exe
psxtmmutex01.docpsxtmsem02.exe

This is missing a bunch of tests.


I don't see any sp* or tm* tests. Are they in the tree itself?
I always run using a find command and not from an install point.
It is possible that only some tests install themselves but I
don't know what the rationale for primarily POSIX tests doing
that would be.


This is the contents of libbsp/arm/stm32f7x/make/custom/stm32f7x-testsuite.tcfg


This file specifies the files which are known not to link. Usually this
is because the test takes too much code or data space for the target board.

All of these tests seem to be failing to do something related to devfs and multiple definitions 
of some symbols. I'll post a followup later once I get at least some tests to run.




fsdosfsname01
jffs2_fserror
jffs2_fslink
jffs2_fspatheval
jffs2_fspermission
jffs2_fsrdwr
jffs2_fsscandir01
jffs2_fssymlink
jffs2_fstime
devfs01
devfs02
devfs03
devfs04
termios02
termios03
termios04
stringto01
math
mathf
tar03
mathl
complex
sptimecounter01
spfatal26
spinternalerror01
fsnofs01





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

Per-BSP confdefs (or resource allocation)

[Isaac Gutekunst]

Hi Devel,

I looked for a while, but couldn't find a way to specify what resources (semaphores, tasks, 
etc) a BSP requires for an empty project (empty Init function).


I took a look at this page: 
https://docs.rtems.org/doc-current/share/rtems/html/bsp_howto/Initialization-Code-The-RTEMS-Configuration-Table.html 
but couldn't glean the correct method.


What is the preferred way to do so?

Our BSP uses a number of resources for hardware drivers, including UART, CAN, SPI, I2C and 
Ethernet.



--
Isaac Gutekunst
Embedded Systems Software Engineer
isaac.guteku...@vecna.com
www.vecna.com
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Per-BSP confdefs (or resource allocation)

[Isaac Gutekunst]

Let me clarify. I don't think I explained my predicament very well.


None of the tests will run because the base application for our BSP requires resources that 
aren't available.


On the application side we're fine.

We have a couple of applications running correctly, by specifying configuration in the main C 
file using the standard method (#defining options and including condefs.h).


Isaac

On 10/21/2015 04:00 PM, Joel Sherrill wrote:



On 10/21/2015 2:53 PM, Isaac Gutekunst wrote:

Hi Devel,

I looked for a while, but couldn't find a way to specify what resources 
(semaphores, tasks,
etc) a BSP requires for an empty project (empty Init function).

I took a look at this page:
https://docs.rtems.org/doc-current/share/rtems/html/bsp_howto/Initialization-Code-The-RTEMS-Configuration-Table.html

but couldn't glean the correct method.

What is the preferred way to do so?

Our BSP uses a number of resources for hardware drivers, including UART, CAN, 
SPI, I2C and
Ethernet.




Starting out, the easiest thing to do is turn on unified workspace
and unlimited resources.

#define CONFIGURE_UNLIMITED_OBJECTS
#define CONFIGURE_UNIFIED_WORK_AREAS

This sets things up as a single pool of memory for malloc and RTEMS
and does not place a limit on how many objects you can create. You
keep going until you run out of work space.

After that, you will need to figure out how many objects each driver
really uses and consider that the base set which an application
configuration must account for. There isn't really any system for
this built in.

Is there any hackish way to setup the tests to allocate more resources?



--joel


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

Re: Random lwIP Crashes in _POSIX_Mutex_Lock_support()

[Isaac Gutekunst]

On 10/21/2015 08:24 AM, Sebastian Huber wrote:



On 21/10/15 14:13, Isaac Gutekunst wrote:

Thanks for the reply.

On 10/21/2015 01:50 AM, Sebastian Huber wrote:



On 20/10/15 16:02, Isaac Gutekunst wrote:

[...]




As far as I can tell this would only occur if the caller of pthread_mutex_lock was in a 
"bad"
state. I don't believe it is in an interrupt context, and don't know what other 
bad states
could exist.


We have

#define _CORE_mutex_Check_dispatch_for_seize(_wait) \
   (!_Thread_Dispatch_is_enabled() \
 && (_wait) \
 && (_System_state_Get() >= SYSTEM_STATE_UP))

What is the thread dispatch disable level and the system state at this point?

In case the thread dispatch disable level is not zero, then something is 
probably broken in the
operating system code which is difficult to find. Could be a general memory 
corruption problem
too. Which RTEMS version do you use?



The thread dispatch disable level is usually -1 or -2.
(0xFFFE or 0xFFD).


A negative value is very bad, but easy to detect via manual instrumentation 
(only an hand full
of spots touch this variable) or hardware breakpoints/watchpoints. Looks the 
rest of
_Per_CPU_Information all right?


It looks like it's only the thread_dispatch_disable_level that's broken.

We'll go and grep for all places for all the places it's touched, and look for 
something.

The problem with watchpoints is they fire exceptionally often, and putting in a conditional 
watchpoint slows the code to a crawl, but that may be worth it.


Here are some printouts of the relevant structs right after a crash:

$4 = {
  cpu_per_cpu = {},
  isr_nest_level = 0,
  thread_dispatch_disable_level = 4294967295,
  executing = 0xc01585c8,
  heir = 0xc0154038,
  dispatch_necessary = true,
  time_of_last_context_switch = {
sec = 2992,
frac = 10737447432380511034
  },
  Stats = {}
}



This might be excessive information, but the executing struct looks good too:

p *(cpu_self->executing)
$6 = ((null) ?) {
  Object = {
Node = {
  next = 0xc0153558,
  previous = 0xc0004568
},
id = 184614914,
name = {
  name_p = 0x0,
  name_u32 = 0
}
  },
  current_state = 0,
  current_priority = 240,
  real_priority = 240,
  priority_generation = 0,
  priority_restore_hint = false,
  resource_count = 0,
  Wait = {
Node = {
  Chain = {
next = 0xc015b764,
previous = 0xc015b760
  },
  RBTree = {
Node = {
  rbe_left = 0xc015b764,
  rbe_right = 0xc015b760,
  rbe_parent = 0xc0158644,
  rbe_color = 134262661
}
  }
},
id = 1124139010,
count = 3222636040,
return_argument = 0x8032101 <_User_extensions_Fatal_visitor>,
return_argument_second = {
  mutable_object = 0xc0158644,
  immutable_object = 0xc0158644
},
option = 1461858615,
return_code = 0,
timeout_code = 116,
queue = 0x0,
flags = 1028,
operations = 0x80966d0 <_Thread_queue_Operations_default>,
spare_heads = 0xc015b760
  },
  Timer = {
Node = {
  next = 0xc015304c,
  previous = 0xc014f9ec
},
state = WATCHDOG_INACTIVE,
initial = 78,
delta_interval = 64,
start_time = 2991580,
stop_time = 2991580,
routine = 0x8031cdd <_Thread_Timeout>,
id = 0,
user_data = 0xc01585c8
  },
  is_preemptible = true,
  is_fp = true,
  Scheduler = {
node = 0xc0158784
  },
  cpu_time_budget = 18,
  budget_algorithm = THREAD_CPU_BUDGET_ALGORITHM_NONE,
  budget_callout = 0x0,
  cpu_time_used = {
sec = 22,
frac = 11951614103676580982
  },
  Start = {
entry_point = 0x808c149 ,
prototype = THREAD_START_POINTER,
pointer_argument = 0x0,
numeric_argument = 0,
is_preemptible = true,
budget_algorithm = THREAD_CPU_BUDGET_ALGORITHM_NONE,
budget_callout = 0x0,
isr_level = 0,
initial_priority = 240,
core_allocated_stack = true,
Initial_stack = {
  size = 4096,
  area = 0xc01690f0
},
stack = 0xc01690f0,
tls_area = 0x0
  },
  Post_switch_actions = {
Chain = {
  Head = {
Node = {
  next = 0xc01586b0,
  previous = 0x0
},
fill = 0xc01586ac
  },
  Tail = {
fill = 0xc01586b0,
Node = {
  next = 0x0,
  previous = 0xc01586ac
}
  }
}
  },
  Registers = {
register_r4 = 3222651512,
register_r5 = 0,
register_r6 = 0,
register_r7 = 3222708080,
register_r8 = 0,
register_r9 = 0,
register_r10 = 0,
register_r11 = 0,
register_lr = 0x802f269 <_Thread_Do_dispatch+124>,
register_sp = 0xc0169f70,
isr_nest_level = 1,
register_d8 = 0,
register_d9 = 0,
register_d10 = 0,
register_d11 = 0,
register_d12 = 0,
register_d13 = 0,
register_d14 = 0,
register_d15 = 0
  },
  libc_reent = 0xc0158890,
  API_Extensions = {0xc0158794, 0xc01587c0},
  task_variables = 0x0,

Re: Random lwIP Crashes in _POSIX_Mutex_Lock_support()

[Isaac Gutekunst]

On 10/21/2015 09:00 AM, Sebastian Huber wrote:



On 21/10/15 14:56, Isaac Gutekunst wrote:

On 10/21/2015 08:24 AM, Sebastian Huber wrote:



On 21/10/15 14:13, Isaac Gutekunst wrote:

Thanks for the reply.

On 10/21/2015 01:50 AM, Sebastian Huber wrote:



On 20/10/15 16:02, Isaac Gutekunst wrote:

[...]




As far as I can tell this would only occur if the caller of pthread_mutex_lock 
was in a
"bad"
state. I don't believe it is in an interrupt context, and don't know what other 
bad states
could exist.


We have

#define _CORE_mutex_Check_dispatch_for_seize(_wait) \
   (!_Thread_Dispatch_is_enabled() \
 && (_wait) \
 && (_System_state_Get() >= SYSTEM_STATE_UP))

What is the thread dispatch disable level and the system state at this point?

In case the thread dispatch disable level is not zero, then something is 
probably broken
in the
operating system code which is difficult to find. Could be a general memory 
corruption
problem
too. Which RTEMS version do you use?



The thread dispatch disable level is usually -1 or -2.
(0xFFFE or 0xFFD).


A negative value is very bad, but easy to detect via manual instrumentation 
(only an hand full
of spots touch this variable) or hardware breakpoints/watchpoints. Looks the 
rest of
_Per_CPU_Information all right?


It looks like it's only the thread_dispatch_disable_level that's broken.

We'll go and grep for all places for all the places it's touched, and look for 
something.

The problem with watchpoints is they fire exceptionally often, and putting in a 
conditional
watchpoint slows the code to a crawl, but that may be worth it.

Here are some printouts of the relevant structs right after a crash:

$4 = {
  cpu_per_cpu = {},
  isr_nest_level = 0,
  thread_dispatch_disable_level = 4294967295,
  executing = 0xc01585c8,
  heir = 0xc0154038,
  dispatch_necessary = true,
  time_of_last_context_switch = {
sec = 2992,
frac = 10737447432380511034
  },
  Stats = {}
}


No, this doesn't look good. According to the stack trace you are in thread 
context. However, we
have executing != heir and dispatch_necessary == true. This is a broken state 
itself. I guess,
something is wrong with the interrupt level so that a context switch is 
blocked. On ARMv7-M
this is done via the system call exception.


This is a bit beyond my RTEMS knowledge. What would you advise looking into?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Random lwIP Crashes in _POSIX_Mutex_Lock_support()

[Isaac Gutekunst]

Hi Devel,

I'm pretty sure this is a devel question, not users.


I'm working with a colleague at Vecna to port lwIP to the STM32F7 BSP we've 
developed.

We have a basic HTTP server that prints out the current list of tasks. We refresh the page at a 
very high rate, and after about 1-30 minutes, get a crash.


Every time the exception is thrown after _CORE_mutex_Check_dispatch_for_seize( wait )  on line 
254 of coremuteximpl.h. Every time this is inside a pthread_mutex_lock() call.



Here is the full backtrace:

stm32f_fatal_error_handler() at hal-fatal-error-handler.c:126 0x800af92 
_User_extensions_Fatal_visitor() at userextiterate.c:123 0x803212c  
_User_extensions_Iterate() at userextiterate.c:166 0x80321c0
_User_extensions_Fatal() at userextimpl.h:254 0x802a85e 
_Terminate() at interr.c:44 0x802a888   
_CORE_mutex_Seize_body() at coremuteximpl.h:255 0x8068df0   
_POSIX_Mutex_Lock_support() at mutexlocksupp.c:57 0x806907e 
pthread_mutex_lock() at mutexlock.c:40 0x8068bee
sys_arch_sem_wait() at sys_arch.c:485 0x808da8a 
sys_arch_mbox_fetch() at sys_arch.c:357 0x808d804   
sys_timeouts_mbox_fetch() at timers.c:532 0x80883ce 
tcpip_thread() at tcpip.c:95 0x808c170  
_Thread_Handler() at threadhandler.c:102 0x806bbe8  
_User_extensions_Thread_exitted() at userextimpl.h:244 0x806bb60
bsp_section_work_begin() at 0xc016a12c  


However, the lwip code calling pthread_mutex_lock varies, but is consistently 
from lwIP.


Does this ring any bells?

As far as I can tell this would only occur if the caller of pthread_mutex_lock was in a "bad" 
state. I don't believe it is in an interrupt context, and don't know what other bad states 
could exist.


Thanks,

--
Isaac Gutekunst
Embedded Systems Software Engineer
isaac.guteku...@vecna.com
www.vecna.com
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Per-task file descriptors and eventually a "real" shell

[Isaac Gutekunst]

Hi Ian,

That's exciting! I clearly should have looked a bit harder before posting. Is there any special 
config? Or is it sufficient to instantiate another shell with a different file descriptor for IO?


Isaac

On 10/04/2015 09:22 PM, Ian Caddy wrote:

Hi Isaac,

On 3/10/2015 4:24 AM, Isaac Gutekunst wrote:

Hey,


The hack would be that file descriptors 0,1 and 2 are not part of a
global namespace of file descriptors, and potentially refer to different
actual IO devices on a per task basis.

The motivation here would be creating a more functional shell and
support easy IO redirection for logging, and running multiple shell
instances, perhaps via multiple telnet and serial sessions.



Maybe I am missing something, but we do all this currently with the shell.

We have a serial port access, and we have multiple telnet / ssh access to our 
devices providing
multiple shells with no problems.

We also redirect the stdio for all the application tasks to print to an 
application log instead
on the shell.  This is all completely doable now, as as far as I know newlib 
provides a per
task stdin, etc.

Just start your task and point them where you want them to go.

regards,

Ian Caddy


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

Per-task file descriptors and eventually a "real" shell

[Isaac Gutekunst]

Hey,

I've been trying to figure out whether RTEMS would support a real shell with IO redirection, 
signals (at least Ctrl-C), and launching of "processes".


Processes can simply be functions added to a table, like the current shell, or loaded using the 
run-time linker.


What seems to be lacking (or maybe I'm wrong), is per task file descriptors. In order to do IO 
redirection, you would want to spawn a task and open and close file descriptors for IO 
redirection. Since RTEMS does not support multiple addresses spaces, and therefore fork(), the 
traditional fork() method would not work.


Perhaps, there could be a new variant of rtems_task_create or rtems_task_start that provides 
alternative file descriptors for stdin, stdout, and stderr.


The task creation process would close stdout and stderr for the task, and then dup2 the passed 
in file descriptors performing the IO redirection.


The hack would be that file descriptors 0,1 and 2 are not part of a global namespace of file 
descriptors, and potentially refer to different actual IO devices on a per task basis.


The motivation here would be creating a more functional shell and support easy IO redirection 
for logging, and running multiple shell instances, perhaps via multiple telnet and serial 
sessions.


Thoughts?

Isaac
--
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: Math lib inclusion in BSP not required if CAN drivers are considered

[Isaac Gutekunst]

Hi Pavel,

Thanks for the detailed reply. I guess you aren't as "horribly out of time" as you said, or 
perhaps are no even more out of time :)


We will definitely take a good look at the LinCAN source for baud rate 
calculations.

The more I think about it, the more I think it's worth to port LinCAN to RTEMS, even though it 
wouldn't be the most trivial. Then we wouldn't have yet another CAN implementation that is 
subtly different than LinCAN.


Here is the file in question:

https://github.com/vecnatechnologies/rtems/blob/stm32-bsp-rebase-fixes/c/src/lib/libbsp/arm/shared/stm32f/can/hal-can.c

Since I wrote it, I think it makes a lot of sense. However, I'll take a look at the LinCAN code 
some more and see if I can understand it.



Again, thanks for the email.

Isaac



On 09/30/2015 06:08 PM, Pavel Pisa wrote:

Hello Sudarshan,

On Friday 25 of September 2015 19:13:53 sudarshan.rajagopalan wrote:

On 2015-09-25 12:21, Daniel Gutson wrote:

El 25/9/2015 13:17, "sudarshan.rajagopalan"

 escribió:
  > On 2015-09-25 11:06, Daniel Gutson wrote:
  >> On Thu, Sep 24, 2015 at 4:49 PM, sudarshan.rajagopalan
  >>
  >>  wrote:
  >>> Hey all,
  >>>
  >>> We are developing a new BSP that uses math.h in few of the BSP

files. I do

  >> May I ask why do you need floating point operations in a kernel?

At

  >> least, what sort of operations and why not move them upwards.
  >
  > We are doing floating point operations in one of the device drivers

as part of the BSP - to perform buadrate calculation, to be specific,
which involes inverse operations and using roundf().


If this is part of CAN driver baudrate calculation then floating point
is usually not required and can be sometimes harmfull because you need
to find best matching ratio of integer numbers which are send to controller
registers. See Linux SocketCAN implementation

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/can/dev.c?id=refs/tags/v4.3-rc3#n74

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/can/netlink.h?id=refs/tags/v4.3-rc3#n46

I have proposed it with structures defining CAN controller
parameters many years ago and it seems that it has been enough
for all controllers supported by Linux drivers.

I suggest to not reinvent the wheel and use solution compatible
with this one because you can use values already tested in the
Linux kernel.

As for the License, actual Linux code has been updated and enhanced
by more people and is strict GPLv2 only. The main change is movement
of sample point computation to the separate function can_update_spt()
and change of sample point specification from 1/100 (%) to 1/1000
fractions.

You can find simpler version in LinCAN driver code

http://sourceforge.net/p/ortcan/lincan/ci/can-usb1/tree/embedded/app/usbcan/lpc17xx_can.c#l90

http://sourceforge.net/p/ortcan/lincan/ci/can-usb1/tree/embedded/app/usbcan/can/can_bittiming.h

where LinCAN is released under license crated specially to be compatible
with RTEMS as well.

Generally, Volkswagen SocketCAN is intended to be available under BSD license
in these parts where it does not directly interact with Linux kernel
structures so I expect that there is no problem when some of Linux
specific enhancements for bitrate calculation are reintroduced in
our code. I check that directly with Linux CAN maintainers
(Oliver Hartkopp, etc.).

I have even userspace test code for these computations and some examples.
I am horribly out of time this and next week but I can clean a dust from
my memory and prepared files after this time and send the utility sources.

But please, if you intend to have generic RTEMS CAN infrastructure,
do not introduce floating point computation to CAN drivers and try
to check if computations introduced by us initially for embedded system
less applications and then selected by Linux kernel community can be used
in RTEMS. It would really simplify new drivers and CAN HW introduction
because you can use already elaborated values instead to reading complex
chip manuals.

Unfortuantelly, I cannot allocate time to RTEMS CAN as I would like.
We have no project at university or company which would backup
the work and there are still even higher priority "hobby" projects
investments on my list - i.e. move forward (with my student) TMS570
BSP networking, QEMU CAN support and some motion control experimental
stuff on RPi, Linux and our conceptually new solution for motor
control current sensing, FPGA D-Q vector control and its combination
with predictive control algorithms.

Best wishes,

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

[PATCH] Add STM32 HAL Files for F4 and F7

[Isaac Gutekunst]

Hi Devel,

As mentioned earlier, Vecna has developed two BSP families using the HAL code provide by ST as 
a foundation. The code isn't perfect, but it let us get up to speed very fast, and provides a 
consistent abstraction across a number of processors.


I formatted a giant patch with all the relevant files needed for the new BSP that will be 
arriving later. The plan is to get this code approved and merged, and then add the BSP piece by 
piece to reduce the amount of code coming in at once.



This includes some HAL files that we aren't using in the BSP just yet. Let me know if we should 
remove them. It's a rather absurd amount of code :)



As before, I can't get git-send-email to work. In addition, the patches are giant, so I've 
inserted links to files in Google Drive.


https://drive.google.com/open?id=0BxaqNLUoI5onZ3lUUDNrYXlyX1U
https://drive.google.com/open?id=0BxaqNLUoI5onM3JsenRJRkotWm8



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

[Isaac Gutekunst]

Hi Sebastian,

The license is standard BSD. Every file includes this 3-clause header

 **
  * @attention
  *
  *  COPYRIGHT(c) 2015 STMicroelectronics
  *
  * Redistribution and use in source and binary forms, with or without 
modification,
  * are permitted provided that the following conditions are met:
  *   1. Redistributions of source code must retain the above copyright notice,
  *  this list of conditions and the following disclaimer.
  *   2. Redistributions in binary form must reproduce the above copyright 
notice,
  *  this list of conditions and the following disclaimer in the 
documentation
  *  and/or other materials provided with the distribution.
  *   3. Neither the name of STMicroelectronics nor the names of its 
contributors
  *  may be used to endorse or promote products derived from this software
  *  without specific prior written permission.
  *
  * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
  * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 
ARE
  * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
  * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
  * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
  * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
LIABILITY,
  * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE 
USE
  * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  *
  **
  */


https://lists.rtems.org/pipermail/users/2015-June/029027.html

An update regarding the meeting we had in June: We where unable to get conclusive information 
from the FAE regarding licensing, and where not able to make further contact.


If you recall the conversation back in June, the main issue is that the code is downloaded as a 
zip file that contains an overarching license that is NOT okay. However, many of the sub 
folders contain additional release notes that state the BSD 3-clause license.




I did NOT accept an EULA in order to download it.

We believe the top level licenses does not pollute the nested licenses. Having talked to a 
number of people with legal experience, it is extremely clear that each file is BSD licensed. 
In addition, there is no competitive advantage lost by allowing their HAL code to be used in 
open source projects, and everything to be gained by having RTEMS support their chips. With 
this reasoning, there is practically no risk using the code, as we are doing something mutually 
beneficial for all parties.


Note: This is not legal advise, just my personal reasoning.

Isaac


On 09/21/2015 01:33 AM, Sebastian Huber wrote:

Hello Isaac,

what is the license of the ST code? The last time I looked at this code
it had a license incompatible to open source projects.


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

New BSP Advice

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

[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

Trouble creating RSB Package: error copying tree

[Isaac Gutekunst]

Hi Devel,

I've been working on porting CANFestival to RTEMS. I ended up creating 
some changes to CANFestival to allow it to be built against an RTEMS BSP.


All was going well except a strange ldconfig error, when I tried to fix 
it by removing the build directory (rtems_source_builder/rtems/build). 
Now I get the following error:


error: copying tree: 
/other/rtems/rtems-source-builder/rtems/build/tmp/canfestival-8bfe0ac00cdb-arm-rtems4.11-1-root-isaac.gutekunst 
- 
/other/rtems/rtems-source-builder/rtems/build/tmp/sb-isaac.gutekunst/4.11/net/canfestival: 
[Errno 2] No such file or directory: 
'/other/rtems/rtems-source-builder/rtems/build/tmp/canfestival-8bfe0ac00cdb-arm-rtems4.11-1-root-isaac.gutekunst'


I tried re-building ntp, the package I based my bset and cfg files off 
of, and it doesn't build correctly, but gets much farther along.


Any idea what's going on ?

Thanks,

Isaac

--
Isaac Gutekunst
Embedded Systems Software Engineer
isaac.guteku...@vecna.com
www.vecna.com
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] RTEMS CAN Rough Draft Implementation

[Isaac Gutekunst]

Hi All,

Here is the RTEMS CAN driver framework I've been talking about. Please 
give me feedback, and don't worry about being harsh. I want to commit 
something of value.



Concerns


* Usage of return codes.
* General higher level error handling.
* Changing can bit rate.
* In general, changing CAN parameters at runtime.
* Task model: Should there really be an RX and TX task required by the 
RTEMS driver? Is the method of starting and stopping tasks acceptable?


The motivation for this is that the CAN controller we are using, (STM32 
BxCAN) requires you to re-initialize the device to change parameters. 
This is a bit awkward with first calling open, and then IOCTL to 
configure the bus. Any thoughts?


Thanks,

Isaac


P.S. I'm having trouble with git send-email. Something is not quite 
right with our mail server here. I've attached the patch instead.


--
Isaac Gutekunst
Embedded Systems Software Engineer
isaac.guteku...@vecna.com
www.vecna.com
From a151795883f68dbff91d3044bbf8d629b4b6996f Mon Sep 17 00:00:00 2001
From: Isaac Gutekunst isaac.guteku...@vecna.com
Date: Mon, 24 Aug 2015 09:45:27 -0400
Subject: [PATCH] cpukit: Create CAN Driver framework

---
 cpukit/dev/Makefile.am|   6 +
 cpukit/dev/can/can.c  | 510 ++
 cpukit/dev/include/dev/can/can-internal.h | 208 
 cpukit/dev/include/dev/can/can.h  |  86 +
 cpukit/dev/preinstall.am  |  13 +
 cpukit/score/cpu/arm/rtems/score/cpu.h|   2 +-
 6 files changed, 824 insertions(+), 1 deletion(-)
 create mode 100644 cpukit/dev/can/can.c
 create mode 100644 cpukit/dev/include/dev/can/can-internal.h
 create mode 100644 cpukit/dev/include/dev/can/can.h

diff --git a/cpukit/dev/Makefile.am b/cpukit/dev/Makefile.am
index 47a1585..cffcf25 100644
--- a/cpukit/dev/Makefile.am
+++ b/cpukit/dev/Makefile.am
@@ -11,6 +11,11 @@ include_dev_i2c_HEADERS += include/dev/i2c/gpio-nxp-pca9535.h
 include_dev_i2c_HEADERS += include/dev/i2c/i2c.h
 include_dev_i2c_HEADERS += include/dev/i2c/switch-nxp-pca9548a.h
 
+include_dev_candir = $(includedir)/dev/can
+include_dev_can_HEADERS =
+include_dev_can_HEADERS += include/dev/can/can.h
+include_dev_can_HEADERS += include/dev/can/can-internal.h
+
 include_linuxdir = $(includedir)/linux
 include_linux_HEADERS =
 include_linux_HEADERS += include/linux/i2c.h
@@ -24,6 +29,7 @@ libdev_a_SOURCES += i2c/gpio-nxp-pca9535.c
 libdev_a_SOURCES += i2c/i2c-bus.c
 libdev_a_SOURCES += i2c/i2c-dev.c
 libdev_a_SOURCES += i2c/switch-nxp-pca9548a.c
+libdev_a_SOURCES += can/can.c
 
 include $(srcdir)/preinstall.am
 include $(top_srcdir)/automake/local.am
diff --git a/cpukit/dev/can/can.c b/cpukit/dev/can/can.c
new file mode 100644
index 000..2610498
--- /dev/null
+++ b/cpukit/dev/can/can.c
@@ -0,0 +1,510 @@
+/**
+ * @file can.c
+ *
+ * @ingroup can
+ * @brief Control Area Network  (can) Driver API
+ *
+ * @brief RTEMS can driver. Exposes a posix interface to the can bus
+ * similar to lincan.
+ *
+ */
+
+/*
+ * Copyright (c) 2015 Vecna Technologies, Inc.
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.com/license/LICENSE.
+ */
+
+
+#if HAVE_CONFIG_H
+  #include config.h
+#endif
+
+#include dev/can/can-internal.h
+
+
+#include rtems/imfs.h
+
+#include stdlib.h
+#include string.h
+#include stdbool.h
+#include fcntl.h
+
+#define CAN_QUEUE_LEN 10
+#define CAN_TASK_PRIORITY 70
+
+static bool free_busses[10] = {true};
+
+int get_free_bus_number(
+  void
+)
+{
+  int i;
+  for (i = 1; i  10; i++) {
+if (true == free_busses[i]) {
+  free_busses[i] = false;
+  return i;
+}
+  }
+  return -1; 
+}
+
+void can_bus_obtain(can_bus *bus)
+{
+  rtems_status_code sc;
+
+  sc = rtems_semaphore_obtain(bus-mutex, RTEMS_WAIT, RTEMS_NO_TIMEOUT);
+  _Assert(sc == RTEMS_SUCCESSFUL);
+  (void) sc;
+}
+
+void can_bus_release(can_bus *bus)
+{
+  rtems_status_code sc;
+
+  sc = rtems_semaphore_release(bus-mutex);
+  _Assert(sc == RTEMS_SUCCESSFUL);
+  (void) sc;
+}
+
+int can_bus_change_baudrate(
+  can_bus * bus, 
+  uint32_t baud
+) 
+{
+  can_bus_obtain(bus);
+  bus-de_init(bus);
+  bus-init(bus, baud);
+  can_bus_release(bus);
+  return 0;
+}
+
+int can_bus_set_filter(
+  can_bus * bus, 
+  can_filter * filter
+) 
+{
+  int err;
+  _Assert(filter);
+  can_bus_obtain(bus);
+  err =  bus-set_filter(bus, filter);
+  can_bus_release(bus);
+  return err;
+}
+
+
+int can_bus_init_default(
+  can_bus * bus,
+  long baud
+)
+{
+  (void) bus;
+  (void) baud;
+  return 0;
+  return -EIO;
+}
+
+int can_bus_de_init_default(
+  can_bus * bus
+)
+{
+  (void) bus;
+  return -EIO;
+}
+
+int can_bus_set_filter_default(  
+  can_bus * bus,
+  can_filter * filter
+)
+{
+  (void) bus;
+  (void) filter;
+  return -EIO;
+}
+int can_bus_get_num_filters_default(  
+  can_bus * bus
+)
+{
+  (void) bus;
+  return -EIO;
+}
+
+int can_bus_transfer(can_bus *bus, can_msg *msgs

Porting CANFestival to RTEMS

[Isaac Gutekunst]

Hi

I'm thinking about porting CANFestival to RTEMS. I think it should be 
relatively doable do to the posix support, and because the core files 
don't have any platform specific code as far as I can tell.


Has anyone had any experience porting CANFestival so far, are could 
offer some advice?


So far I've made a copy of the UNIX time and lincan drivers and renamed 
them to can_rtems and timers_rtems as well as a couple of other directories.


I've gotten to the point where I need to link against an RTEMS BSP, and 
don't really know what to do. I want to include rtems.h and generate a 
static library that I can link with my application, or if I'm really 
lucky, run the existing examples on RTEMS.


Regarding CAN drivers, I have written a simplistic CAN driver framework 
based on lincan and the current cpukit/dev/i2c style IMFS driver. This 
should be easy to support in CANFestival, and could pave the way for 
supporting lincan directly at some point.



Thanks,

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

Re: Porting ethernet driver from FREEBSD to rtems-libbsd

[Isaac Gutekunst]

I'm going to chime in since this sounds like a similar problem I've
experienced on a PIC32.

I wanted to reword what Ragunath said in my own words to see if I
understand it.

1) The RX ISR fires, vectoring the code to the ISR entry.
2) The code in the ISR disables interrupts, creates an event to be handled
by RTEMS (in a non interrupt context)
3) At some point (dispatch function), interrupts are enabled
4) Since the RTEMS task responsible for performing non-generic handling
hasn't run, the hardware condition that created the initial interrupt has
not been cleared. Therefore, the interrupt controller vectors to the ISR
entry again, repeating the cycle.


In this case, the fundamental problem is that an ISR will continue firing
until the condition causing it is resolved. In the case of an RX interrupt,
that usually would mean reading data from a SFR or buffer. I'm not familiar
with this specific case, but it sounds awfully similar.

Does this sound right?

If so, it seems like a rather fundamental problem I haven't been able to
resolve. I'm hoping someone has found a reasonable solution that I wasn't
smart enough to figure out my self.

Isaac

On Thu, May 28, 2015 at 8:01 AM, Sebastian Huber 
sebastian.hu...@embedded-brains.de wrote:

 It depends on the capabilities of the interrupt controller. Maybe you have
 to drop the support for nested interrupts. The bsp_interrupt_dispatch()
 function for a state of the art interrupt controller looks like this
 (arm-gic-irq.c):

 void bsp_interrupt_dispatch(void)
 {
   volatile gic_cpuif *cpuif = GIC_CPUIF;
   uint32_t icciar = cpuif-icciar;
   rtems_vector_number vector = GIC_CPUIF_ICCIAR_ACKINTID_GET(icciar);
   rtems_vector_number spurious = 1023;

   if (vector != spurious) {
 uint32_t psr = _ARMV4_Status_irq_enable();

 bsp_interrupt_handler_dispatch(vector);

 _ARMV4_Status_restore(psr);

 cpuif-icceoir = icciar;

   }
 }

 On 28/05/15 13:50, ragu nath wrote:

 Hi Sebastian,

 The problem is with rx interrupt. We are enabling rx interrupt before
 it is processed. The rtems server task do not get an opportunity to
 run.

 I found this might be the logical explanation of the issue.
 bsp_interrupt_dispatch() calls bsp_interrupt_server_trigger which
 disables the rx interrupt and creates BSP_INTERRUPT_EVENT .  For this
 event, bsp_interrupt_server_task() was supposed to call the actual
 interrupt handler and then enable the rx interrupt. But before the
 event is processed, we enable the rx interrupt in dispatch function.
 So again rx interrupt is generated and event is created and the cycle
 goes on. Server task is never executed in turn actual interrupt
 handler is never executed.

 Since we enable the interrupt, it occurs again and again as we never
 handle it.

 Is there any other possibility that I might need to look into?


 Thanks,
 Ragunath

 On Thu, May 28, 2015 at 4:58 PM, Sebastian Huber
 sebastian.hu...@embedded-brains.de wrote:

 Hello,

 the bsp_interrupt_dispatch() is quite complicated in the beagle BSP. Is
 the
 interrupt controller of this chip really that broken? Sane interrupt
 controllers block interrupts of equal or lower priority relative to the
 currently pending interrupt.


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

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

Re: Porting ethernet driver from FREEBSD to rtems-libbsd

[Isaac Gutekunst]

That explains a lot and makes a lot of sense. I was thinking about only
disabling the entire interrupt controller.

Thanks!

Isaac

On Thu, May 28, 2015 at 8:34 AM, Sebastian Huber 
sebastian.hu...@embedded-brains.de wrote:

 This interrupt server task is a hack. It works for proper interrupt
 controllers. You must be able to disable a single interrupt source in the
 interrupt controller.

 On 28/05/15 14:23, Isaac Gutekunst wrote:

 I'm going to chime in since this sounds like a similar problem I've
 experienced on a PIC32.

 I wanted to reword what Ragunath said in my own words to see if I
 understand it.

 1) The RX ISR fires, vectoring the code to the ISR entry.
 2) The code in the ISR disables interrupts, creates an event to be
 handled by RTEMS (in a non interrupt context)
 3) At some point (dispatch function), interrupts are enabled
 4) Since the RTEMS task responsible for performing non-generic handling
 hasn't run, the hardware condition that created the initial interrupt has
 not been cleared. Therefore, the interrupt controller vectors to the ISR
 entry again, repeating the cycle.


 Yes, this is how it works on the beagle BSP.  With the ARM GIC it works
 like this:

 1) The RX ISR fires, vectoring the code to the ISR entry.
 2) The code in the ISR disables exactly this interrupt source, creates an
 event to be handled by RTEMS (in a non interrupt context)
 3) The interrupt server thread eventually calls the real ISR routine which
 clears the interrupt condition.
 4) The interrupt server thread enables exactly this interrupt source.



 In this case, the fundamental problem is that an ISR will continue firing
 until the condition causing it is resolved. In the case of an RX interrupt,
 that usually would mean reading data from a SFR or buffer. I'm not familiar
 with this specific case, but it sounds awfully similar.

 Does this sound right?

 If so, it seems like a rather fundamental problem I haven't been able to
 resolve. I'm hoping someone has found a reasonable solution that I wasn't
 smart enough to figure out my self.

 Isaac

 On Thu, May 28, 2015 at 8:01 AM, Sebastian Huber 
 sebastian.hu...@embedded-brains.de mailto:
 sebastian.hu...@embedded-brains.de wrote:

 It depends on the capabilities of the interrupt controller. Maybe
 you have to drop the support for nested interrupts. The
 bsp_interrupt_dispatch() function for a state of the art interrupt
 controller looks like this (arm-gic-irq.c):

 void bsp_interrupt_dispatch(void)
 {
   volatile gic_cpuif *cpuif = GIC_CPUIF;
   uint32_t icciar = cpuif-icciar;
   rtems_vector_number vector = GIC_CPUIF_ICCIAR_ACKINTID_GET(icciar);
   rtems_vector_number spurious = 1023;

   if (vector != spurious) {
 uint32_t psr = _ARMV4_Status_irq_enable();

 bsp_interrupt_handler_dispatch(vector);

 _ARMV4_Status_restore(psr);

 cpuif-icceoir = icciar;

   }
 }

 On 28/05/15 13:50, ragu nath wrote:

 Hi Sebastian,

 The problem is with rx interrupt. We are enabling rx interrupt
 before
 it is processed. The rtems server task do not get an
 opportunity to
 run.

 I found this might be the logical explanation of the issue.
 bsp_interrupt_dispatch() calls bsp_interrupt_server_trigger which
 disables the rx interrupt and creates BSP_INTERRUPT_EVENT .
For this
 event, bsp_interrupt_server_task() was supposed to call the actual
 interrupt handler and then enable the rx interrupt. But before the
 event is processed, we enable the rx interrupt in dispatch
 function.
 So again rx interrupt is generated and event is created and
 the cycle
 goes on. Server task is never executed in turn actual interrupt
 handler is never executed.

 Since we enable the interrupt, it occurs again and again as we
 never handle it.

 Is there any other possibility that I might need to look into?


 Thanks,
 Ragunath

 On Thu, May 28, 2015 at 4:58 PM, Sebastian Huber
 sebastian.hu...@embedded-brains.de
 mailto:sebastian.hu...@embedded-brains.de wrote:

 Hello,

 the bsp_interrupt_dispatch() is quite complicated in the
 beagle BSP. Is the
 interrupt controller of this chip really that broken? Sane
 interrupt
 controllers block interrupts of equal or lower priority
 relative to the
 currently pending interrupt.


 -- Sebastian Huber, embedded brains GmbH

 Address : Dornierstr. 4, D-82178 Puchheim, Germany
 Phone   : +49 89 189 47 41-16 tel:%2B49%2089%20189%2047%2041-16
 Fax : +49 89 189 47 41-09 tel:%2B49%2089%20189%2047%2041-09
 E-Mail  : sebastian.hu...@embedded-brains.de
 mailto:sebastian.hu...@embedded-brains.de
 PGP : Public key available on request.

 Diese

Re: [PATCH] Beagle BSP Improvements (GPIO driver)

[Isaac Gutekunst]

-specific :) i.e. add  #if IS_AM335X around code that should
only execute there. this BSP can be compiled for 2 different SOCs.
   - let it control all GPIO's - there are 4 banks of 32 each on the
AM335x, but you only let the user control GPIO1. there should be a
clean interface to control them all (clean means mostly: without
duplicating code)
   - as Gedare mentioned on IRC, copy the RPi API. this is a first
(second?) step to finding a generalized GPIO API.
   - don't add beagleboard.h, but add your definitions to
libcpu/arm/shared/include/am335x.h
   - the code should use a more consistent indenting style, and make
variable names more descriptive than 'tmp'.
   - don't leave the configure changes in like in acinclude.m4

bonus:
   - add DM3730 (beagleboard) support.

Good luck!


On Fri, Apr 17, 2015 at 7:51 PM, Ketul Shah ketulshah1...@gmail.com
wrote:

Hello,

I have proposed in GSoC on Beagle BSP Improvements. As starting I
started
working for gpio driver development . At this stage I am able to
demonstrate
USR LEDs pattern.

Videos of that can be found here on YouTube.
https://youtu.be/B3mSsfo-PAQ 
https://youtu.be/M1aKpOhUvv4.

Herewith I have attached patch.txt file. Alternatively you can have
https://gist.github.com/ketul93/2e0d2c4b8b586be62e1d that includes the
newly
added files code. I would be happy to hear your reviews and changes on
my
work.

And also I have been updating my work on
https://github.com/ketul93/RTEMS-on-BBB repo.

It would be great to have your comments on my proposal.

Thanks and regards,
ketul

___
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




--
Isaac Gutekunst
Embedded Systems Software Engineer
isaac.guteku...@vecna.com
www.vecna.com
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel