Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

  • State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 101 subscribers
  • Views 1213 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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 GP Image Header Size Field Problem

Davi Evangelista
Expert 1090 points

Hello,

I'm working with AM335x and while making some changes in my version of U-Boot I started having serious problems with the MLO boot.

Turns out that I was luck enough to generate a MLO image which had the vary last 8 valid bytes being used to store part of the uart0_pin_mux variable. After the board failed to boot, I used CCS to debug it and I noticed that these last 8 bytes, that in my case store the termination .reg_offset = -1, were always with some sort of garbage. All this could be seen from the Memory Browser window, accessing the address shown in u-boot-spl.map.

I'm explaining all of this because when the code tried to use the termination, there wasn't any -1 to be found and every time the code jumped to _fiq interruption in arch/arm/cpu/armv7/start.S, freezing the boot process.

In the end, turns out that the image I generate and copy to the NAND is generally fine, with the exception of the Size field in its GP Image Header. As described in the Technical Reference Manual, the Size field is used with the Destination field in the ROM code. In my case, for some reason that I don't yet know, the Size field is ALWAYS 8 bytes short. I went back on some stable versions of my own MLO images and this problem is there in every single one of them. The fact that none of those previous images incurs in an illegal memory access is just luck, I think...

The easy solution was to make a program that read the MLO image and adds 8 bytes to the Size field. That did the trick and my board started booting again.

I wonder if this behavior is a bug. My version of U-Boot is somewhat old now: U-Boot-2013.01.01-amsdk-06.00.00. The cross compiler is:

arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.7-2013.03-20130313 - Linaro GCC 2013.03) 4.7.3 20130226 (prerelease)

So maybe this is just happening in my environment, maybe not, so I'm reporting it. Also, if this is indeed a bug, what do I have to change in the Makefile or its scripts to correct this issue in a proper manner?

Another thing, the Technical Reference Manual says that the GP Image Header is in the start of the image, but the MLO has it 512 bytes shifted... Why?

Thanks

DAVI

  • 0
    TI__Guru**** 393215 points

    Hi Davi,

    I'm forwarding this to the SW team.

  • 0
    TI__Genius 10965 points
    Hi Davi,
    Take a look at this thread - > e2e.ti.com/.../207888
    Here you will see those 512 Bytes are actually for the optional CH header.
    What changes did you made to the MLO, can you guide me through your process of modification and build?
    Regards,
    Boyko
  • 0 in reply to Boyko Kazakov
    Expert 1090 points

    I changed nothing regarding the compilation process.

    After make finishes compiling the U-Boot, I run the program in annex to add 8 bytes to the Size field. The only argument required is the path to the MLO image.

    Thank you for the explanation on the optional header!

    DAVI

    MLOImageAdjust.c 
    #include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>

int main(int argc, char *argv[])
{
	FILE *fd;
	u_int32_t size;

	if(2!=argc || access(argv[1], F_OK )) {
		return EXIT_FAILURE;
	}

	fd=fopen(argv[1],"rb+");
	if(NULL==fd) {
		return EXIT_FAILURE;
	}

	fseek(fd,512,SEEK_SET);
	fread(&size,4,1,fd);
	size+=8;
	fseek(fd,512,SEEK_SET);
	fwrite(&size,4,1,fd);

	fclose(fd);

	return EXIT_SUCCESS;
}