0

I have compiled a simple binary file (hello.bin) and stored it on a memory card.

I am running a NXP Sabre dev kit with i.mx 6 quad processor. I have started up U-boot and am trying to access the binary file and make it run.

The hello.bin is availiable because the following command works:

=> fatload mmc 1:4 0x20005000 hello.bin
reading hello.bin

The way I understand it the file should be loaded into RAM at the address 0x20005000

So I want to test that the binary is there

=> md 0x20005000
20005000: 464c457f 00010101 00000000 00000000    .ELF............
20005010: 00280002 00000001 00010315 00000034    ..(.........4...
20005020: 000028f4 05000400 00200034 00280009    .(......4. ...(.
20005030: 00240025 70000001 00000454 00010454    %.$....pT...T...

Looks all right, as the starting bits are matching the file I copied to SD-card.

When I try to start the binary, the device reports undefined instruction:

=> go 0x20005000
## Starting application at 0x20005000 ...
undefined instruction
pc : [<20005158>]          lr : [<4ff71403>]
reloc pc : [<e7897158>]    lr : [<17803403>]
sp : 4f56dd50  ip : 00000000     fp : 00000002
r10: 4f56f938  r9 : 4f56deb0     r8 : 4ffc3c40
r7 : 4ff713d9  r6 : 00000002     r5 : 20005000  r4 : 4f56f93c
r3 : 20005000  r2 : 4f56f93c     r1 : 4f56f93c  r0 : 00000000
Flags: nzCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

Thanks for your help

Mattis Asp
  • 993
  • 3
  • 14
  • 29
  • the => bdinfo, command told me something about the DRAM bank, starts at 0x10000000 (7 zeros) and ends at 0x4000000. I then used fatload mmc 1:4 0x10005000 hello.bin instead, which then seems to work. I guess I was writing to a out of bound address. go 0x10005000 still does not work. – Mattis Asp Apr 13 '18 at 11:54

3 Answers3

2

Got some help from another friend, I found it very helpful so I will post it:

You can use the Yocto toolchain but you cannot link against the C library (which is done by default) so you have to put some extra options to GCC to let it know that, also, you cannot use the go instruction from U-Boot to jump to an ELF binary that you just loaded in memory, the ELF binary has to be converted to a 'raw' binary (list of ARM instructions in your case) with the tool objdump. An ELF binary it's a specific format that encapsulate your code/your data and some extra information, and the first part of the ELF is the description of the binary, so right now, when you do a go at the first address, you are trying to tell the CPU to execute something which is not an ARM instruction. You basically want to execute what we call the '.text' section of the ELF binary.

Mattis Asp
  • 993
  • 3
  • 14
  • 29
1

Please, find an example at https://www.denx.de/wiki/view/DULG/UBootStandalone#Section_5.12.1.

go does not expect the start of an ELF binary but the address of the entry routine. If you want to access U-Boot routines the binary must have been relocated.

Xypron
  • 2,215
  • 1
  • 12
  • 24
1

I have compiled a simple binary file (hello.bin) and stored it on a memory card.

You have omitted many salient details.
How did you compile this program, e.g. what toolchain, what makefile?
Did you link this program with a library?

The way I understand it the file should be loaded into RAM at the address 0x20005000

How did you get this "understanding"?

Typically the load address of a standalone program depends on a few factors.
First the addresses of available memory (on the target board) has to be considered.
Second, unless the standalone program is relocatable (not likely in your case), then the program must be loaded at its load/starting address as defined when the program was linked.
The load and starting addresses of a program can be obtained from its map file (i.e. the linker output).

When I try to start the binary, the device reports undefined instruction:

That is what happens when the ELF header is "executed".
Since the file clearly contains an ELF header, its filename extension should be .elf rather than .bin.
How did this executable file get the misleading name?

You probably did not build a standalone binary image file.
The examples/standalone/ directory of the U-Boot source code has sample code and a makefile for building standalone binaries, e.g. a hello_world.bin.
Be sure to properly define CONFIG_STANDALONE_LOAD_ADDR for your board!
The default load address is surely to be inappropriate.

the => bdinfo, command told me something about the DRAM bank, starts at 0x10000000 (7 zeros) and ends at 0x4000000.

(First of all, do not put salient information in comments. Add this to your original post by using the edit capability.)
The "information" you provided makes no sense (i.e. the end address is less than the start address). Avoid interpreting the information, and instead simply present (copy'n'paste) the actual output.

I then used fatload mmc 1:4 0x10005000 hello.bin instead, which then seems to work. I guess I was writing to a out of bound address.

The fatload command merely copies the contents of a file into memory. The true success of that copy is confirmed by validating the memory, rather than completion of the command.
Your comment is confusing since you have not mentioned any prior load issues.

go 0x10005000 still does not work.

Trying arbitrary load/start addresses is not an effective debugging technique.
A summation of "seems to work" or "still does not work" is a low-quality description for results.
See How To Ask Questions The Smart Way.

sawdust
  • 16,103
  • 3
  • 40
  • 50
  • I used arm-fslc-linux-gnueabi-gcc to compile it. Actually I wrote ${CC} myapp/helloworld.c -o hello.bin . I would like to print a string in the helloworld to a screen, UART would be fine. The exact address, might not matter, but I expected that I needed to load the binary into memory. I don't have any makefile, and I don't know much about linking. Perhaps you could point me in the right direction? – Mattis Asp Apr 17 '18 at 11:38
  • CC = arm-fslc-linux-gnueabi-gcc -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard --sysroot=/opt/fslc-framebuffer/2.4.2/sysroots/armv7at2hf-neon-fslc-linux-gnueabi – Mattis Asp Apr 17 '18 at 11:39