AM5748: U-boot: Hangs on custom eeprom code in do_board_detect()

Hi Jonathan,

I want to make sure that you have tried the suggestions in this thread and if that has gotten you further.

https://e2e.ti.com/support/processors/f/791/t/798346

Let me know and we can work it out, please consider adding more details to provide what you have tried.

Regards

Karthik

Thanks for the response.  The link you posted is for Linux and not U-boot.  Is it possible to get early console output from u-boot?  

Hi Jonathan,

Could you please post the traces that you are getting at SPL/U-boot and where you are facing the crash?
That will help us analyze the situation better. Are you getting any traces on SPL already?

Which SDK version are you using?

- Keerthy

Hi Keerthy,

I am basing my changes off the processor-sdk-u-boot-2019.01 branch.  Trying to add support for our upcoming AM57x SOM.  

I've been able to verify the boot process gets all the way through the SPL and things stop working after the SPL jumps to the u-boot.img.  

I've also been able to narrow the crash down to the new eeprom code I added, for some reason the i2c calls seem to lead to the crash.  If I return from my get config function before any i2c operations, u-boot launches.  But as soon as I try to talk to the i2c the board crashes.  I am continuing to dig into why this is.  Though being able to print something to the console would speed the process up.

Hung

U-Boot SPL 2019.01-00910-g41b1fcad17a3-dirty (Jun 09 2020 - 16:46:23 -0400)
DRA752-GP ES2.0
no pinctrl state for default mode
** Unable to read file dra7-ipu1-fw.xem4 **
Firmware loading failed
Trying to boot from MMC1
no pinctrl state for default mode
spl: mmc boot mode: fs
Loading Environment from FAT... *** Warning - bad CRC, using default environment

Loading Environment from MMC... *** Warning - bad CRC, using default environment

Jumping to U-Boot
loaded - jumping to U-Boot...

Output when it works (Commented out i2c reads)

U-Boot SPL 2019.01-00910-g41b1fcad17a3-dirty (Jun 09 2020 - 16:46:23 -0400)
DRA752-GP ES2.0
no pinctrl state for default mode
** Unable to read file dra7-ipu1-fw.xem4 **
Firmware loading failed
Trying to boot from MMC1
no pinctrl state for default mode
spl: mmc boot mode: fs
Loading Environment from FAT... *** Warning - bad CRC, using default environment

Loading Environment from MMC... *** Warning - bad CRC, using default environment

Jumping to U-Boot
loaded - jumping to U-Boot...

U-Boot 2019.01-00904-g939f7056ab18-dirty (Jun 22 2020 - 10:17:54 -0400)

CPU  : DRA752-GP ES2.0
Model: TI AM5748 IDK
Board: MitySOM-57x Dev Kit
DRAM:  2 GiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from FAT... *** Warning - bad CRC, using default environment

Loading Environment from MMC... *** Warning - bad CRC, using default environment

Info - Didn't find block
Warning: fastboot.board_rev: unknown board revision
i2c_write: error waiting for data ACK (status=0x116)
cdce9xx_reg_write: failed for addr:5, ret:-121
Net:   Could not get PHY for ethernet@48484000: addr 0

Warning: ethernet@48484000 using MAC address from ROM
eth0: ethernet@48484000
Hit any key to stop autoboot:  0

Hi Jonathan,

Can you share the point where you are introducing your code. I doubt if we can
get prints very early without having to reshuffle some console related fundamental
u-boot code. Do you have any hardware debugger JTAG or Lauterbach?

- Keerthy

I am trying to access the EEPROM from the do_board_detect function. After some investigation yesterday, it seems that this function may be executed from SRAM and before the i2c init function is called.  However, the TI EEPROM reading normally happens in this function so I'm not sure why my code is tripping up.  If I am running from SRAM at this point then it's possible I've blown the stack but that's a guess.

I don't have a debugger with me but I could have one shipped to me. Do you have a link to what connector is needed for the debugger and recommended debugger.  I'm used to the AM335x so usually use a spectrum digital debugger but we likely have some others.

Hi Jonathan,

Need a quick confirmation on the exact board being used. I assume it is am5748-idk and not a custom am5748 based board.
Am i right?

If it is possible can you share the code that you are adding as a patch here? I will try reproduce the failure myself and
debug at my end as well.

Regards,
Keerthy

Hi Keerthy,  Sorry I thought I had mentioned the board.  My bad.  I am using the BB X15 board since it most closely matched the ram configuration we are using on our custom board.

The code is a mess of debug statements right now but I'll try to push it to github to share.