This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MLO start address

Hi all,
I have two questions about making the MLO loader for the Blaze device.
Target: Blaze
Toolchain: mydroid/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3
System: Ubuntu LTS 12 64Bit

My build process is configured like described on omappedia.com:

make ARCH=arm omap44XXsdp_config
make ift 2>&1 |tee ${MYDROID}/logs/x-loader_make.out


1. Address of _start
********************

The start address of the MLO is set by the define TEXT_BASE located in board/omap4430sdp/config.mk to 0x40304350. After 'make ift' is done the address of _start (which seams to be the first code) is set to 0x40304360. Perhaps this is done by alignment issue of the compiler.

> grep _start x-load.map
                0x40304360                _start

The compiler inserts 16 zero bytes before the new address of _start.

> hd x-load.bin -n 32
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  
00000010  12 00 00 ea 14 f0 9f e5  10 f0 9f e5 0c f0 9f e5

Setting TEXT_BASE to 0x40304360 prevents the 'move' of _start.

Why is 0x40304350 used as TEXT_BASE? What are the 16 zero bytes good for?


2. Makefile grep (MLO)
**********************
In one of the following steps in Makefile the address of _start is fetched from System.map which is now 0x40304360. The result is assigned to TEXT_BASE which was set to 0x40304350 before (board/omap4430sdp/config.mk).

Part of Makefile:
x-load.bin.ift: signGP System.map x-load.bin
    TEXT_BASE=`grep -w _start System.map|cut -d ' ' -f1`
    ./signGP x-load.bin $(TEXT_BASE)

The assignment seams not to work (because it is done in a sub shell created by the make process). The signGP is always called with the 'old' value of TEXT_BASE (before grep) 0x40304350, which results in including the 16 leading bytes from question 1 into the MLO file.
> hd MLO -n 32 -s 512
00000200  b4 5f 00 00 50 43 30 40  00 00 00 00 00 00 00 00  
00000210  00 00 00 00 00 00 00 00  12 00 00 ea 14 f0 9f e5

As far as I know the first ARM instruction 0xEA000012 should be located at 0x208 not at 0x218.

Is this correct?

Best regards,
Roman Jordan

  • Hi,

    just for info: I have changed TEXT_BASE to 0x40304360 (board/omap4430sdp/config.mk) and removed the line containing the command grep from toplevel Makefile and it  works. Now the 16 zero bytes between the program header and the first command are gone.

    Best regards,

    Roman Jordan

  • Comment,

    I read chapter 27 in OMAP4460 TRM, across the chapter there are some points that leads to the use of MMC/eMMC booting, starting from ROM code reading SYSBOOT configuration passing the part of how to select used FS and what flags are checked for this. Almost at the end of the chapter in section "27.4.8.3 GP Header" describes the addition of a GP header, this paragraph matches the comments from your first post.

    I downloaded TRM from http://www.ti.com/product/omap4460

  • Hi all,

    so does anybody know why the start address of the MLO is set to 0x40304350 (which leads to moving it to 0x40304360 during build) and why the Makefile contains a grep command line which does nothing.

    Best regards,

    Roman

  • For what I remember of this post the grep command could check for the existence of a file that will indicate when to use one method or another adding the 0x10 bytes to teh address or not.

    I didn't received the email for this post at that time, sorry for the late response.

  • Hi Manuel,

    1. grep

    The result (assingment) of the grep is nerver used. So why it is done in such way?

    I have removed this line in my build environment.

    2. start address

    Using the given start address will result in 0x10 leading bytes. How does the processor handle these bytes? Why this is done?

    I have adjusted the address of the MLO in that case that there are no leading bytes and it runs as expected. So it is easier/ clear to me.

    Currently I have no problems with these modifications.

    Best regards,

    Roman

  • For what I read the use of the grep seems to be used to find if there is present a configuration file that indicates that it is going to be used or not used the 0x10 bytes configuration. That was my point about the grep command, it is it.