Linux/TDA2EVM5777: "Can not allocate memory" error - remoteproc

Marco Reppenhagen

Part Number: TDA2EVM5777
Other Parts Discussed in Thread: TDA2

Tool/software: Linux

Hello !

I try to use the remoteproc feature of the TI-kernel which comes with
visual SDK_2_12_02_00 (patched linux 4.4.45). I've backported sysfs support to monitor remoteproc.
My board is XC5777x with TDA2.

I build a simple programm which counts up a variable and let it run using my XDS200 JTAG debugger under CCS.
That works great, no problems (except linux is running... than the debugger got no access to the JTAG chain... but thats another problem I've almost pubished.)

Now the next step would be: Building a release... done. Copying as dra7-ipu1-fw.xem4 to lib/firmware... unbind and bind 58820000.ipu ... nothing happen, no error message in dmesg.

A cat of /sys/class/remoteproc/remoteproc0/state shows: "OFFLINE".

OK... try to start... echo "start" to the state... and I got the error message:

sh: write error: Cannot allocate memory

Something went wrong building the elf file. I've tried out the TI-Toolchain and the linaro-Toolchain delivered with the CCS. I've used no linker-script and the ones which comes with the SDK (starterpack)...
No success at all! The memory map matches the data sheet and the stuff defined in devicetree.

What I have to do is to generate a remoteproc "ELF" file... at the end of the day without using TI-middleware or bootloader and therefore I need the following stuff which I was not able to seperate out of the starterpack or SDK:

a working linker description file for TDA2-EVM5777x board. (Maybe I got them already, but I am not shure, so just to be on the safe side...)
a simple example of "really bare metal" boot-up-code WITHOUT (!) usage of TI-Library or bootloader or RTOS...
==> if needed?! How I have to configure the peripheral of OTHER CPUs then MPU? (EVEN via devicetree, too? Do you have prepared stuff? Any kind of how to?)
a recipe how to build a ELF file which is compatible with the TI remoteproc mechanism in linux.
This failed every time, no matter what I've tried out.
The only working example: "linux/targetfs/lib/firmware/ipc/ti_platforms_evmDRA7XX_ipu1/messageq_single.xem4" which is able to be loaded and after "bind" IPU1 the IPU1 begins to run, cat of state: running...

.... so: In principle it works!
I must have forgotten something important... but what?

So I need the simplest possibility (a skelleton) to run a GCC compiled Ansi-C code on M4, DSP, EVE of the TDA2 using the remoteproc mechanism.
(No CCS projects, no libraries or universal linker script and build environments, which are too complex to show how it works in principle... a simple Makefile GCC project without bootloader, OS, lib-stuff...)

Thank you, Marco.

over 8 years ago

0 Marco Reppenhagen over 8 years ago

Intellectual 790 points

Some additional informations

The reason why the created ELF Files are not able to be loaded as "remote firmware" is simple:

(1) No section called ".resource_table" have been created.

So it is possible to play a little bit around using JTAG and direct injection (GEL scripts will do everything else...) but even if a release have been build, the created ELF will not contain the resource section, which is needed to fill the resource table in the TI linux driver of the remoteproc. If this is empty, the error "remoteproc remoteproc0: Boot failed: -12" will occure.
(remoteproc_core.c -> fw_boot -> if (!rproc->table_ptr) -> return -ENOMEM;)

... Now I try to include such a ressource map:
I can not find any rsc_table_XXX.h which may contain the informations => TDA2x or DRA7... or x5777x, etc...

0 Marco Reppenhagen over 8 years ago in reply to Marco Reppenhagen

Intellectual 790 points

Back again....

( ... and maybe Alex Bashkov is able to help me?)

Well:

(1) I need a GNU linker script (.lds, not .cmd) to generate M4 and C6x code which is able to be a "firmware" used with "remoteproc". Therefor a section ".resource_table" have to be created, but I can't find what it have to look like...

(2) Du you have any kind of real "Bare Metal" startup code without ballast for me? Maybe small GNU-Examples/ Skelletons for TDA2-XC5777x?
(GCC is able to build M4 and C6x Code as well as building A15 code and linux. Why use another, propritary TI compiler? We have automated tests, nightly builds... a quality management system and my software have to fit this requirements. I need a simple strucutre, no SDK or IDE.... )

Yes, there's the "complex" visual-sdk and something you call "bare metal" starter pack. But both are designed to work under Windows and CCS - IDE.
It is not so easy to extract the things needed if you have to implement code under linux host system and want to use "FREE" compiler and "easy, minimalistic" libraries.

Everything is embedded in the sdk infrastructure, using "BIOS", "RTOS", large libs... a complex buildsystem (which do not work proper under linux anyhow...), TI-compiler, ...
We have to be "more free" in our development and are not able to use those goodies and extracting the things *really* needed is no fun at all...

So, please help me: I do not need any SDK using "use cases" or "configurability..." I need simple bare metal examples, no proprietary stuff, because we have external requirements I have to fulfil.

Thank you!

0 Alex Bashkov over 8 years ago in reply to Marco Reppenhagen

TI__Genius 13870 points

Hello Marco Reppenhagen,

1. Does the attached linker script work for you? Try it. https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/354/8446.TDA2x.lds

2. I am not sure, but if you don't get any luck here I can move this thread to the device forum for you, maybe the audience there will be of greater help with this particular EVM scenario.

Thanks,

Alex

0 Marco Reppenhagen over 8 years ago in reply to Alex Bashkov

Intellectual 790 points

Hello, thanks for fast response!

(1) I know this script and almost tried it, without success.
Maybe it is not the script... I have to build a "remote firmware" (ELF) which is used in Linux: Remoteproc should be able to write this special ELF file (with a section called ".resource_table" in it... but not generated anyhow...?!) into M4 and (later...) into C66x and start the subcores.
This is our goal...

(2) That would be nice! Thank you...

....maybe there's somebody who already build a small GNU project to build any kind of M4 or C66x firmware which will boot sucessfully using the remoteproc machanism of Linux in A15 core.

... At this moment I'm not able to do so. I'm trying to find out, how the SDK works an where to extrect the things I need for "non-proprietary build" of real bare metal code... (no fun at all...)

0 Alex Bashkov over 8 years ago in reply to Marco Reppenhagen

TI__Genius 13870 points

Marco Reppenhagen ,

Yeah, that linker script is good enough for running a bare "hello world" program on a selected core. It won't help you much with what you need, so I don't know. Let's wait for the community and what they have to say.

Thanks
Alex

0 Marco Reppenhagen over 8 years ago in reply to Alex Bashkov

Intellectual 790 points

Alex Bashkov (1239253) :

I've got news, too.

It seems like a simpe .h file can be user (included) to create the needed section.

I found something like that at:

ti_components/algorithms_codecs/ipumm/platform/ti/dce/baseimage/custom_rsc_table_omap5_ipu.h

The "secret":

#pragma DATA_SECTION(ti_ipc_remoteproc_ResourceTable, ".resource_table")

#pragma DATA_ALIGN(ti_ipc_remoteproc_ResourceTable, 4096)

struct my_resource_table ti_ipc_remoteproc_ResourceTable = {

1, /* we're the first version that implements this */

16, /* number of entries in the table */

0, 0, /* reserved, must be zero */

/* offsets to entries */

{

offsetof(struct my_resource_table, rpmsg_vdev),

offsetof(struct my_resource_table, text_cout),

offsetof(struct my_resource_table, data_cout),

.....

}

This will create the needed table... for an omap5 ;)

I will need either the information, which of the shipped files I can use on TDA2, or I will need such a file for the TDA2.

But the best would be... someone has build a very simple skeletton for bare metal coding M4 and DSP without ballast...
(Then everythings turns into: "Ahhh! That's easy!"... let's wait for the community... swarm intelligence rules.)

Marco

0 Marco Reppenhagen over 8 years ago in reply to Marco Reppenhagen

Intellectual 790 points

Thank you,

I've tried this out yesterday. (Changes have to be made; pragma isn't known in GNU toolchain an some other issues... now it compiles and a elf will be created.... more than less.)

Now there's the .resource_table section, but I'm not able to load the generated ELF via remoteproc into M4.

Since I try to bring up the M4 really bare metal, under a gnu toolchain... I got the same error message:

echo "start"> /sys/class/remoteproc/remoteproc0/state
sh: write error: Cannot allocate memory

I think this is a result of an unknown resource_table. Than the pointer to it in remoteproc_cpu.c stay "NULL" and no memory will be allocatable.

Picking up only a few parts of the complex SDK will not bring success. I've tried out a lot... but I'm still not able to reach the goal we need:

We *have to* build code from scratch, really bare metal under a non-proprietary toolchain.
The linker script above is a *must have*, but there's still something missing... it do not work at all.

What my stuff generates until now:

ELF Header:

Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00

Class: ELF32

Data: 2's complement, little endian

Version: 1 (current)

OS/ABI: UNIX - System V

ABI Version: 0

Type: EXEC (Executable file)

Machine: ARM

Version: 0x1

Entry point address: 0x80000bcd

Start of program headers: 52 (bytes into file)

Start of section headers: 530304 (bytes into file)

Flags: 0x5000202, has entry point, Version5 EABI, soft-float ABI

Size of this header: 52 (bytes)

Size of program headers: 32 (bytes)

Number of program headers: 5

Size of section headers: 40 (bytes)

Number of section headers: 26

Section header string table index: 23

Section Headers:

[Nr] Name Type Addr Off Size ES Flg Lk Inf Al

[ 0] NULL 00000000 000000 000000 00 0 0 0

[ 1] .text PROGBITS 80000000 008000 076f78 00 AX 0 0 16

[ 2] __libc_freeres_fn PROGBITS 80076f78 07ef78 000cbc 00 AX 0 0 4

[ 3] __libc_thread_fre PROGBITS 80077c34 07fc34 0000e0 00 AX 0 0 4

[ 4] .ARM.extab PROGBITS 80077d14 07fd14 000248 00 A 0 0 4

[ 5] __libc_subfreeres PROGBITS 80077f5c 07ff5c 00002c 00 A 0 0 4

[ 6] __libc_atexit PROGBITS 80077f88 07ff88 000004 00 A 0 0 4

[ 7] __libc_thread_sub PROGBITS 80077f8c 07ff8c 000004 00 A 0 0 4

[ 8] .ARM.exidx ARM_EXIDX 80077f90 07ff90 000680 00 AL 1 0 4

[ 9] .note.ABI-tag NOTE 80078610 080610 000020 00 A 0 0 4

[10] .note.gnu.build-i NOTE 80078630 080630 000024 00 A 0 0 4

[11] .data PROGBITS 80078658 080658 000ef0 00 WA 0 0 8

[12] .tdata PROGBITS 80079548 081548 000010 00 WAT 0 0 4

[13] .tbss NOBITS 80079558 081558 000018 00 WAT 0 0 4

[14] .jcr PROGBITS 80079558 081558 000004 00 WA 0 0 4

[15] .got PROGBITS 8007955c 08155c 000070 00 WA 0 0 4

[16] .bss NOBITS 800795d0 0815cc 001124 00 WA 0 0 8

[17] __libc_freeres_pt NOBITS 8007a6f4 0815cc 000018 00 WA 0 0 4

[18] .heap NOBITS 8007a70c 0815cc 000400 00 WA 0 0 1

[19] .stack NOBITS 8007ab0c 0815cc 000400 00 WA 0 0 1

[20] .resource_table PROGBITS 00003000 003000 0003d4 00 WA 0 0 4

[21] .comment PROGBITS 00000000 0815cc 000056 01 MS 0 0 1

[22] .ARM.attributes ARM_ATTRIBUTES 00000000 081622 000035 00 0 0 1

[23] .shstrtab STRTAB 00000000 081657 000128 00 0 0 1

[24] .symtab SYMTAB 00000000 081b90 00dfe0 10 25 2434 4

[25] .strtab STRTAB 00000000 08fb70 007a5d 00 0 0 1

Key to Flags:

W (write), A (alloc), X (execute), M (merge), S (strings)

I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)

O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

Program Headers:

Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align

EXIDX 0x07ff90 0x80077f90 0x80077f90 0x00680 0x00680 R 0x4

LOAD 0x000000 0x00000000 0x00000000 0x033d4 0x033d4 RW 0x8000

LOAD 0x008000 0x80000000 0x80000000 0x795cc 0x7af0c RWE 0x8000

NOTE 0x080610 0x80078610 0x80078610 0x00044 0x00044 R 0x4

TLS 0x081548 0x80079548 0x80079548 0x00010 0x00028 R 0x4

Something is still scary: I've got a lot errors like:

readelf: Warning: Corrupt ARM compact model table entry: b4040184 Compact model index: 52
readelf: Warning: Unknown ARM compact model index encountered

0 Marco Reppenhagen over 8 years ago in reply to Marco Reppenhagen

Intellectual 790 points

Now I try to fix the entry point address... Should be something near 0x0 .... is now @0x8xxxxxxx.

(I compare the results of my little build system with the elf-readout of the working example and replace my section to fit the layout in the working xem4)

Still a lot to do...

Do you have a documentation, which explains what a firmware have to look like to be able to boot via remoteproc?

The only thing I found is a documentation in the kernel of how to write drivers. This work is still done...
What about a documentation of the realized API of the TI-remoteproc driver in linux?

This would be very nice, too.

0 Marco Reppenhagen over 8 years ago in reply to Marco Reppenhagen

Intellectual 790 points

I found something and now it works a little bit...

First: Devide the problem into its parts:

1) Build M4 Code using the Gnu-toolchain

To build M4 Code, I use arm-linux-gnueabi-toolchain with this options:

CFLAGS += -lm -mthumb -mcpu=cortex-m4

Question: Do I have to use another GNU-Toolchain or options?

2) Build in "resource_table" to make "remoteprov" usable.

I used the file:
custom_rsc_table_omap5_ipu.h
as mentioned early in this thread.
(To make it work, some changes are necessary:
the #pragma are not known by GNU or will be ignored, so I used:
__attribute__((section(".resource_table"))) __attribute__ ((aligned (2))) struct my_resource_table ti_ipc_remoteproc_ResourceTable =...
to produce the needed "rexouce_table".

Question: Is there a well tested "bare GNU"-compatible version of this file available?

3) use a working startup-code

Well, in a galaxy far, far away... a file named:
startup_ARMCM4.S
was found... bound in... and do not do the expected :(

Question: All I did was "putting" this stuff together with the small main-file and its included custom_rsc_table_omap5_ipu like this (in a Makefile):

$(CC) $(LDFLAGS) -o main.o startup.S main.c $(LDLIBS$(LDLIBS-$(@))) $(CFLAGS) -I $(INCLUDE_PATH) -static
(I renamed the startup-code in startup.S). No comiler errors... but still no working code on the machine. But: It can be loaded as a firmare! A little success...
Now: Maybe the startup.S is wrong, or I have to customize the devicetree file, doing something else the "dra7-evm-infoadas.dtb" do usually?

So in all in nutshell: A simple GNU-Toolchain Makefile project, which is showing HOW TO build a firmware the SIMPLEST WAY... bare metal... would be very welcome.
Otherwise there are too many things to take care about: I've no more time to create a own SDK without an existing Board Support: At this moment, this is limited to some "Make it work on your own"-stuff and propretary Environments (CCS and its examples - uses Sys/BIOS strongly! And visual-sdk... is bound to exactly the mechanism of "use-case" and "algorithms"... but nothing fullfill our requiremtents:
A simple example to getting startet building a bare metal Firmware for remoteproc in Linux only using the GNU-toolchain in a very simple Makefile project... and of course: Using the adequate startup-Code, without this little assembler stub, nothing will work and the one I found: Maybe it's OK, but it is not working, anyhow...)

Processors

Processors forum

Linux/TDA2EVM5777: "Can not allocate memory" error - remoteproc