cortex M4 support

    Hello,


    I have a A9X-V4-LIN starter kit and I am looking to boot the M4 core in combination with the A9.


    On the Freescale forums I read about the `m4boot` and `m4fastup` commands in u-boot. These seem all to be missing.
    Furthermore I also do not find a device tree file similar to `imx6sx-sdb-m4.dts` for the kernel.


    So, how can I start the M4 core on your board?

    Since I got no response, I have ported the 'm4boot' code from the NXP u-boot to your u-boot-2014.07-fsimx6sx-V1.0 version that I downloaded from your site.


    But now u-boot hangs whenever I try to write an image to the M4_BOOTROM_BASE_ADDR (0x007F8000).
    The same thing happens when I follow the instructions in the NXP Linux Reference manual when I try to tftp the image directly to that address.

    Cortex-M4 support is currently in a process of changeover. NXP/Freescale switches from MQX to FreeRTOS. And with this also the way to communicate between cores will switch from MCC to RpMsg. We will not offer support for MQX on i.MX6SoloX, we will only have support for FreeRTOS. But unfortunately, this support is not yet done. We will do a next release for SoloX in a few weeks, then based on Kernel 4.1.15.


    Our concept for running Cortex-M4 programs is also a little bit different to the way NXP has chosen. As you know, we have a split bootloader concept. First NBoot and then U-Boot. Our idea is to store an M4 image within NBoot (like you store the U-Boot image right now). Then when booting, this code is started by NBoot even before U-Boot is up and running. This results in a very early availablity of the services provided by the M4. This is why we didn't include NXP's Cortex-M4 U-Boot commands yet, we simply do not need them. These U-Boot commands are rather new anyway, on earlier CPUs with Cortex-M4 (e.g. the Vybrid CPU), M4 code was started from Linux.


    The reason why the board hangs is that there was a bad initialization for AIPS3. Unfortunately we did not find this before our fsimx6sx-V1.0 release was out. Things like TCM (Tightly Coupled Memory) are attached to AIPS3 and won't work at the moment. We have fixed this in the meantime and it will be part of our next release. But I also have attached a patch for U-Boot where you can fix this problem right now. Go to the top level directory of the U-Boot source code and call


    Code
    1. patch -p1 < 0001-Fix-AIPS3-initialization-on-i.MX6-SoloX.patch


    Please note the less-than character for input redirection. Then rebuild U-Boot.


    But from the overall situation, would it be possible for you to delay the M4 work and start with the Cortex-A9 application first? Then it would better go together with our upcoming Cortex-M4 support. Otherwise you will have to do some work now, that we will do rather soon anyway and probably in a slightly different way.



    Your F&S Support Team

    Hello,


    I had already fixed my u-boot hang by reading on the NXP community forum that the TCML area is only accessible by the A9 after the M4 clock has been reset in the CCM_CCGR3. I was testing this when you replied. Nonetheless I have also added your patch to my u-boot version.


    Furtermore I am also working with FreeRTOS images on the M4 core and the RPMsg pingpong/TTY tests are also present in the 3.14.52 kernel.


    So far, I can tftp the image and boot the M4 core from u-boot. I assume it boots since I have no debug console or output.
    Next to this I can boot Linux on the A9 and insmod the imx_rpmsg_* kernel modules.


    So far I have only tested the pingpong test which does not really seem to be working. So that is my next objective now.

    on a side note: can you put a concrete date on your upcoming release with FreeRTOS/NBoot/M4 support?
    Or is it more on a "when its stable and ready we'll release it" schedule?


    We are currently using 2x NXP MX6SX Sabre-SD and 2x Efus A9X development boards so that application development and testing can already start (since we have a deadline) until our final/target hardware with an MX6SX processor arrives (somewhere in September).
    One of the first things to tackle is the inter-processor communication, which is already working on the NXP hardware with their software packages based on the 4.1.15 kernel.
    It would make things easier if all our development boards are running on the same kernel version.

    Our release schedule is currently to push out all Linux versions with kernel 4.1.15. We'll start with regular i.MX6, then there will be i.MX6UL and then i.MX6SoloX. This also has something to do with re-designs of some boards in the UL and XS series, so we want to wait until these re-designs are available so we can add the support before the release. And due to the current holiday time, I believe the Solo-X version will not be out before end of september.


    When you are talking about final hardware, does this include the efusA9X, too? Or some other F&S board or module? Or are these efusA9X boards just for evaluation?


    Your F&S Support Team

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    Quote from fs-support_HK

    But unfortunately, this support is not yet done. We will do a next release for SoloX in a few weeks, then based on Kernel 4.1.15.


    Quote from fs-support_HK

    I believe the SoloX version will not be out before end of September.


    So basically a few means more than 8.



    With final/target hardware I mean our own design featuring an MX6 SoloX processor.
    The NXP and Efus boards were purchased so the software department can already start application development, especially the interprocessor communication part (which they currently only can with the NXP boards).