• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 450 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

AM3354: LCD support in U-boot

AM3354: Large U-boot image fails to boot

dakata_pz
Prodigy 130 points

Part Number: AM3354

Hi,

I am using AM3354 and the latest SDK Linux v06.01: u-boot-2019.01+gitAUTOINC+029e4c009a-g029e4c009a. I am using a custom board (which is basically a BBB + Resistive touch screen). 

I am able to boot my board, the problem comes when I add u-boot splash screen with the proper size 1024x768 (which matches the resolution of my display).

When I load the header of the image in my u-boot build, resulting u-boot.img is about 4.5MB, and u-boot cannot load and boot the board:
U-Boot SPL 2019.01-gb206ca7-dirty (Feb 03 2020 - 10:43:53 +0200)
Trying to boot from MMC1

As you can see the first stage (MLO) is loading and doing the very basic board init, but cannot load the u-boot.img and finish the board boot up.

When I use smaller image (u-boot.img is about 1.5 MB in size), I am able to fully boot my board:
U-Boot SPL 2019.01-gb206ca7-dirty (Feb 03 2020 - 10:43:53 +0200)
Trying to boot from MMC1


U-Boot 2019.01-gb206ca7-dirty (Feb 03 2020 - 10:43:53 +0200)

CPU  : AM335X-GP rev 2.1
Model: Yordan's debug version
DRAM:  512 MiB
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from FAT... *** Warning - bad CRC, using default environment
                                                                                
<ethaddr> not set. Validating first E-fuse MAC                          
Net:   Could not get PHY for ethernet@4a100000: addr 0                          
eth0: ethernet@4a100000                                                         
Warning: usb_ether MAC addresses don't match:                                   
Address in ROM is          de:ad:be:ef:00:01                                    
Address in environment is  a0:f6:fd:47:b0:f1                                    
, eth1: usb_ether                                                               
Hit any key to stop autoboot:  0                                                
=>

This was working with an older u-boot version: TI Sitara SDK version 06.00.00.00, U-Boot version is 2013.01.01. The latest u-boot is having troubles. Did someone else encounter this problem? Can someone provide any pointers to debug this?

I remember u-boot was doing some code relocation within the RAM allocated for u-boot.img. Could this be part of my problem? If yes, could you provide pointers how to disable this code relocation?

Thanks and regards.

  • 0
    Prodigy 130 points

    Hi,

    I found a previous discussion on u-boot relocating itself into higher DRAM address here:
     

    Is this still the case in u-boot2019.1? Could this be the root cause of my problem (not being able to boot larger u-boot.img)?

    Thanks,
    Yordan

  • 0
    TI__Guru 70662 points

    dakata_pz said:
    I remember u-boot was doing some code relocation within the RAM allocated for u-boot.img. Could this be part of my problem? If yes, could you provide pointers how to disable this code relocation?

    The problem may not be related to relocation or the size of U-Boot, but could also be due to U-Boot silently crashing with your altered configuration because of something else so I think we need to dig a little deeper here first.

    Two ways to find out:

    - Insert an endless while(1){} loop "trap" to the beginning of U-Boot's board_init_f() function, located in common/board_f.c. Then, use JTAG to connect to the device and see if program execution is indeed trapped there as expected and the surrounding code block makes sense, or if it has crashed.

    ...or or this "poor man's method"...

    - Start with your working U-Boot configuration and artificially inflate the size of U-Boot by adding a huge (several MB in size) constant array of data (might need to declare as 'volatile' to prevent optimization) or add a very large number of nop() statements for example to common/board_f.c until the size of your U-Boot image is about 4.5MB. Then run this U-Boot and see if it still behaves as expected. Basically, running a known-good U-Boot, except of bigger size (to test relocation).

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Prodigy 130 points

    Hi Andreas,

    I am currently focused on tuning some kernel functionality. I will take a look at this later and update the thread.
    Marking it resolved for now, but will have to reopen it later, sorry for the inconvenience.

    Best Regards,
    Yordan