MCC shared memory address

The Linux driver for mcc and M4 linker files use 0xBFF00000 memory address, but I cannot find the type of memory is being referenced, i.e SRAM, DDR. Any ideas?

DDR RAM starts at 0x80000000 and goes to 512M or 1G which goes to 0xBF800000, According to manual section 2.2 IMX 6SX 8000_0000 to FFFF_FFFF is the MMDC xDDR controller.

 

For a 1G its 1024*1024*1024*4 which is 0x40000000 so 0xbff00000 is the last 1M of memory. So for the basic it needs to change to 1024*1024*512 0x20000000 which is 0x9ff00000. For shared RAM address in the linker files for the m4.

I'm working on a new mcc linux driver to allow multiple endpoints via devfs and use epoll/poll instead of using two threads. Read thread and a write/process thread. I.e like the example debug driver.

 

OK, have the basicks working with MCC. Created a new MCC driver for Linux (rpmsg will soon replace mcc. The driver exposes 3 devices to user space:
1. tty; going to write another driver that calls into the device space to expose a tty interface. This way, which rpmsg comes out, the tty driver does not change (except for the device)
2. General messages
3. General messages; but plan is to create a Ethernet interface to allow M4 apps to communicate to A9 via tcpip sockets, this makes easier to get files, ie. tftp send messages to M4 tasks. Just do it via sockets..

Now it is possible to have tty interface and general message interface running at the same time.
# ls m4*
m4mcc0 m4mcc1 m4mcc2
#

Let me know if you want the code. The driver is not a loadable module due to the mcc API not be exported.

 

Dear @tcmichals, we, and I guess also the community, are very interested in your code. Congratulations for all the stuff you're developing!

 

Here is a google drive link
The KConfig, Makefile are not final, it was just a quick patch. mccmulti.c is the kernel driver; must compiled with the kernel. mccUser.cpp is simple epoll app testing the driver. In process of going a python version with asyncio.

I'm in the middle of getting lwIP working on M4; then work on the kernel driver. The tty driver will just open /dev/m4mcc using filp_open, flip_close, with a thread running on the vfs_read and using tty to write. This can be a loadable module.

 

Great stuff! Yesterday I found it then, and shared it on social media. You're definitely onto something man!

 

Making progress, have a basic lwIP ported and running on M4. Working on MCC Ethernet driver for lwIP. Here is a basic diagram.

 

Posted this on the NXP user community.
Summary:
Trying to use multiple threads accessing the mcc API is causing some issues. Looks like the remotes/origin/imx_3.14.52_1.1.0_ga has a some changes for issues with MU wake ups but; comments like this:
/*
* suspect that there is bug here. TEn flag is not
* changed immediately, after the ATRn is filled up.
*
*/
might be some more issues..

 

After looking at the web site closer and having issues with MCC multi threading, moving to rpmsg and using FreeRTOS.

 

That should be a better option, however since its the first release I'm sure there will be bugs!

 

True, but now it is more wide spread; https://community.freescale.com/thread/382870

 

Patched the kernel to include rpmsg and example ping pong apps. Uploaded the example Free RTOS rpmsg (had to change the memory addresses to get it to load to DRAM and TCL) and it works!!!

Now, working on updating all the drivers I did; openAMP.org includes all the linux drivers to allow rpc of rpmsgs. RPC is a way to expose "endpoints" to user space.
So, goal is to:
- expose (1) user space endpoint
-added a tty interface to endpoint
- Update lwip (which is already done via FreeRTOS) and add the TCP/IP stack.

 

Have multiple rpmsg endpoints working using FreeRTOS. Able to have a user space program read/write to a rpmsg endpoint and have a tty enabled device also.
FreeROTS:
create two threads, (1) tty rpmsg (1) for rpmsg0 to send messages between FreeRTOS and Linux.
In Linux there is a /dev/ttyRPMSG and a /dev/rpmsg0
The /dev/rpmsg0 supports read/write/poll/ioctl it is close to the openAPM proxy driver with all of the command removed. Have updated the user to use epoll to validate poll API is working.
Next; get lwip working; this will allow simple command like ping tftp to work to transfer files. One issue is the MTU size will be about 256 bytes.

 

Created a github repo https://github.com/tcmichals/rpmsg-freertos and https://github.com/tcmichals/rpmsg-neo

I will be making updates and code changes there along with Wiki how to.

 

• https://github.com/tcmichals/rpmsg-freertos, I just have not had time to merge my code back in.
  
• NXP's FreeRTOS will work out of the box, but I opted not to use cmake, and created my own make system.
  • The basic directory structure is
    • apps
      • helloworld
      • rpmsg (requires modified kernel and rpmsg-neo)
      • rpmsgLWIP (requires modified kernel rpmsg-neo with Ethernet still working on it)
    • lwip
    • Neo
      • extended drivers, board support etc. Keeps NXP separate.
    • NXP
      • Packaged FreeRTOS
    • FreeRTOS
      • Latest RTOS
• The current Neo Linux kernel needs several patches to get rpmsg up and running.
• Also ported rpmsg to QX 4.1.0 and it also works with rpmsg-neo Udoo team is working on updating packages)

Do you want to use FreeRTOS or MQX?

 

I subscribe to @tcmichals for this matter. Regarding this he's definitely a better Virgil than me

 

Yes, kernel and Arduino.

NXP, has change its software direction and some of the licensing.

I'm moving forward with FreeRTOS, and keeping the NXP in a different directory, so, can use the latest FreeRTOS version, tracing tools, etc.