AM335x U-boot doesn't start

The software team have been notified. They will respond here.

As far as I understand, Board ID check happens in the function

am33xx_spl_board_init();

This function is called within board.c

But before this call, there is a call to the following function (arch/arm/cpu/armv7/omap-common/boot-common.c):

************************************

preloader_console_init();

из файла common/spl/spl.c:

void preloader_console_init(void)

{

    gd->bd = &bdata;

    gd->baudrate = CONFIG_BAUDRATE;

    serial_init();      /* serial communications setup */

    gd->have_console = 1;

    puts("\nU-Boot SPL " PLAIN_VERSION " (" U_BOOT_DATE " - " \

            U_BOOT_TIME ")\n");

#ifdef CONFIG_SPL_DISPLAY_PRINT

    spl_display_print();

#endif

}

******************************************

from here I see, that am33xx_spl_board_init() is called after preloader functio, which prints @U-Boot SPL " PLAIN_VERSION " (" U_BOOT_DATE " - "  U_BOOT_TIME ")\n")  to console.

But we do not see this string in the console window. Is it possible that something else cause malfunction?

Best regards,

Ilya

u-boot-spl.bin is loaded into internal RAM, it has nothing to do with DDR timings. We can not get to the stage where u-boot set all DDR and other parameters for the system.
So that's why I ask - is there anything else besides EEPROM ID check that can prevent boot for SPL?
And as there is slightly another layout for the files - what are the files where EEPROM check is performed and board parameters should be hard-coded?

BR,
Ilya

Those changes were done for SDK7.0. Could you please confirm that the changes are valid for current SDK release?

Comparing code I see that the main differences are in function read_eeprom(), so other than that are there any other places in the code where we should hardcode board data?

BR,

Ilya

We got SPL and u-boot from SDK 7.0 working, thanks to proposed hard-coded parameters for the function read_eeprom().

But for the latest SDK we still unable to get SPL and u-boot working.

From what II see, the code base has changed rather significantly and now EEPROM-related code contained in many other files, for example in <u-boot>/arch/arm/cpu/armv7/omap-common/boot-common.c

Or here :  <u-boot>/board/ti/common/board-detect.c

If we just try  to hardcode result of read_eeprom(), it doesn't help.

As far as I understand the issue, SPL/u-boot do not work due to wrong EEPROM handling at boot time. Since at the customer board EEPROM is empty at first start-up, we have to hard-code data for the boot.
The question is how to do it correctly in the latest SDK?