Running the Processor SDK Linux "Big Data Example" on the BeagleBoard X15

BeagleBoard-X15
1

Hi folks,

Has anyone else attempted to run http://processors.wiki.ti.com/index.php/Processor_SDK_Big_Data_IPC_Examples on the X15?

I built out the binaries on my build host but it appears as though either

The WIKI gives an account of how the CMEM area is allocated:

`
The DSP side memory layout can be found in the file host_linux/simple_buffer_example/shared//config.bld.

Also note the addition of the following section in host_linux/simple_buffer_example/shared//rsc_table_dsp.h.

Please note the reserved carve-out in the DSP resource table:

/* NOTE: Make sure this matches what is configured in the linux device tree */
define DSP_CMEM_IOBUFS 0xA0000000
define PHYS_CMEM_IOBUFS 0xA0000000
define DSP_CMEM_IOBUFS_SIZE (SZ_1M * 192)

The CMEM area allocated from this region is used for the big data buffers.

Also…

NOTE: The size of the big data buffer is configurable compile time by changing value of the define BIGDATA_SIZE in shared/AppCommon.h

`

In troubleshooting this, my question at the moment is - is there any way I can see how this reserved carved-out is configured in the linux device tree as per the WIKI recommendation on the 3rd line? I guess the WIKI assumes I have that know-how already which, sadly, I don’t.

I haven’t changed anything in the config.bld or rsc_table_dsp.h yet so the values correspond to the WIKI.

The config.bld shows both EXT_CODE and EXT_DATA being allocated a length of 0x1000000 so I’m not sure which one is causing my error. It probably doesn’t matter too much at this point:

var evmDRA7XX_ExtMemMapDsp = {
EXT_CODE: {
name: “EXT_CODE”,
base: 0x95000000,
len: 0x00100000,
space: “code”,
access: “RWX”
},
EXT_DATA: {
name: “EXT_DATA”,
base: 0x95100000,
len: 0x00100000,
space: “data”,
access: “RW”
},

Any help much appreciated.

Thanks,

Dermot

2

I built out the binaries on my build host but it appears as though either… the DSP memory layout needs to be tweaked to match the device tree or there’s a bigger difference between the X15 memory and the EVM (for which the examples are designed, I guess).

3

I got some good information at this link: http://processors.wiki.ti.com/index.php/Linux_IPC_on_AM57xx so that’s something to start with:

Cortex M4 IPU Physical Addresses

The physical location where the M4 code/data will actually reside is defined by the CMA carveout. To change this location, you must change the definition of the carveout. The M4 carveouts are defined in the Linux dts file. For example for the AM57xx EVM:

linux/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi

               ipu2_cma_pool: ipu2_cma@95800000 {
                       compatible = "shared-dma-pool";
                       reg = <0x0 95800000 0x0 0x3800000>;
                       reusable;
                       status = "okay";
               };

               ipu1_cma_pool: ipu1_cma@9d000000 {
                       compatible = "shared-dma-pool";
                       reg = <0x0 9d000000 0x0 0x2000000>;
                       reusable;
                       status = "okay";
               };
       };

You are able to change both the size and location. Be careful not to overlap any other carveouts!

NoteNote: The two location entries for a given carveout must be identical!

Additionally, when you change the carveout location, there is a corresponding change that must be made to the resource table. For starters, if you’re making a memory change you will need a custom resource table. The resource table is a large structure that is the “bridge” between physical memory and virtual memory. This structure is utilized for configuring the IPUx_MMU (not the Unicache MMU). There is detailed information available in the article IPC Resource customTable.

Once you’ve created your custom resource table, you must update the address of PHYS_MEM_IPC_VRING to be the same base address as your corresponding CMA.

#if defined(VAYU_IPU_1)
#define PHYS_MEM_IPC_VRING      0x9D000000
#elif defined (VAYU_IPU_2)
#define PHYS_MEM_IPC_VRING      0x95800000
#endif

NoteNote: The PHYS_MEM_IPC_VRING definition from the resource table must match the address of the associated CMA carveout!

4

Hi Dermot,

I have been able to run the big data example successfully on my beagle x15 and I didn’t had to change any addresses.
Did you also build the DSP part of the big data example (.xe66 file) and installed the file into /lib/firmware?
It could be the reason for you error message. The preinstalled firmware for the DSP1 is not suitable for the Big Data example I guess, and so there is not enough shared memory available.

To install the xe66 file see also http://processors.wiki.ti.com/index.php/Processor_Training:_Multimedia (“Changing the remotecore binary at runtime”).
For a quick test you can use my binary attached (without guarante :wink:

A good point for debugging is to check the syslog and look for output of the “remoteproc” driver. You can see whether the DSP firmware has been loaded and the DSP is running or crashed.
Then you can check the debug prints of the DSP firmware at the file /sys/kernel/debug/remoteproc/remoteproc2/trace0 (only there when the DSP firmware is running.

Joerg

5

sorry, forgot the attachement.
You have to copy or link the file into /lib/firmware.
The filename dra7-dsp1-fw.xe66 is “hard coded” and must not be changed.

Joerg

dra7-dsp1-fw.xe66 (4.27 MB)

6

Thanks for your reply, Joerg!

I’ve been able to get other IPC sample code running, eg. MessageQ, ping, etc. some weeks ago. Although, I actually had to revert to the 4.1 SDK because the DSP1 core built out by the 4.2 SDK for the MessageQ example was crashing due to an issue in the SDK itself.

I’ll try using your core anyway just to see - can you tell me which SDK version you used in building out the Big Data example?

Regards,
Dermot

7

I used the 4.02 SDK version for the examples.

8

Well, I tried your DSP image and got the very same result as with my image. The only other thing I’m wondering is whether you booted into the SDK Arago Linux or used some other distro?

My device tree (./linux-4.9.41+gitAUTOINC+e3a80a1c5c-ge3a80a1c5c/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi) contains the following:

dsp1_cma_pool: dsp1_cma@99000000 {
compatible = “shared-dma-pool”;
reg = <0x0 0x99000000 0x0 0x4000000>;
reusable;
status = “okay”;
};

I also confirmed that the DSP1 core is running OK from looking at the /sys/kernel/debug/remoteproc/remoteproc2/trace0 file.

I also tried reducing BIGDATA_SIZE in shared/AppCommon.h from 16384 to 4096 but the result is the same CMEM error as originally reported.

I might try building everything from the 4.02 SDK just to see what (if anything) changes. I may also log a ticket on E2E but usually they’ll direct requests to this forum once “X15” get mentioned…

9

For the tests used a prebuilt imageDebian 9.0 2017-07-02 which runs a (Patched) Kernel 4.9.35-ti-r44 so i had not to deal with the device tree until now (going through the TI examples is enough pain :wink:

The dts in this image looks the same as yours…

We also had to stop and disable the preinstalled ti multicore daemon (systemctl stop ti-mct-daemon.service and systemctl disable ti-mct-daemon.service) to be able to work with the shared regions.

10

Thanks for the reply, Joerg.

Yes, I had stopped and disabled the MCT daemon also. That gets mentioned in the Big Data IPC WIKI:
http://processors.wiki.ti.com/index.php/Processor_SDK_Big_Data_IPC_Examples

One other thing I’m wondering - if you do “cat /proc/cmem” what do you see? I see nothing when I do this (empty file) so I’m wondering if this may be pointing towards a root cause.

But you’re right - working through these IPC examples is not for the faint-hearted! :slight_smile:

11

Update - I created another microSD card using create-sdcard.sh using prebuilt images. This card seemed to populate /sys/firmware/devicetree/base/cmem OK and also populated /proc/cmem so that was a step in the right direction.

I then copied the app and the .xe66 image over to the X15 and ran the application but it hung after posting “remoteproc remoteproc2: request_firmware failed: -2”. This error was posted during boot also when the DSP cores were being booted.

So, I decided to give your image a try, Joerg. It booted OK on DSP1 and the application consequently ran fine.

As a result, I’m going to upgrade my SDK to see if I can build out a successful .xe66 image using 4.02 or greater. I’m mindful of the fact that the MessageQ app image for DSP1 built out by the 4.02 SDK doesn’t run either (known bug) so I might just go straight to 4.03 instead and see what happens…I’ll post an update here once I find out. I’ll log an E2E ticket to see if the TI folks can recreate the IPC DSP1 issue with the Big Data IPC example.

Thanks for your core, Joerg! It really helped with my troubleshootinf process…

12

Update - I’ve installed SDK 4.03 and tried building out the IPC Big Data Example. The make fails due to xdc.tools.configuro: extraneous arguments ignored: '-b …'
xdctools_3_50_03_33 consequently fails to open input file ‘ti.platforms.evmDRA7XX:dsp’ and it all goes pear-shaped after that.

Joerg - just wondering if you encountered this issue during your build attempts? I didn’t encounter it with SDK 4.01.

13

Yes. This is an annoying and misleading error message. If I remember correctly you have to check the *_INSTALL_DIR variables in the makefiles or product.mak files.

14

Another issue which was causing havoc was that a recent Ubuntu update pointed /bin/sh to “dash” which, of course, doesn’t support the source command…as a result, Makefiles weren’t able to source env setup scripts, etc.

I’ve decided to rebuild my entire build host before going any further…I’ve lost confidence in it at this point so I want to reset the clock.

15

I use Linux Mint 18.3 with dash as default shell and had no problems with until now. But I am no shell guru.
Hope your rebuild will resolve that problems.

regards,
Joerg