AM4372: RAM not correctly detected

Hi,

Apologies for the delayed response, we're trying to make sure you get an expert who can best address this question.

Thanks,

Max

Hi Alberto,

Do we know if there’s EEPORM on your board.

In order to facilitate supporting multiple boards, SDK bootloader (SPL) reads board_id programmed in EEPROM, and then setups board configuration (PMIC, D-PLL, DDR, pinmux…) based on the board ID detected, where board_id and specific board configuration are in board.h/board.c under <board/ti/am437x/> for AM437x.

You may want to take a look at this e2e thread on how to skip board ID detection for user board either w/o EEPORM or blank EEPROM:

https://e2e.ti.com/support/processors/f/791/p/934968/3454481#3454481

Also enabling UART print in early SPL approves very useful when working on board bring-up:

https://e2e.ti.com/support/processors/f/791/p/929728/3441869#3441869 

Best,

-Hong

Hi Hong,
Thank you very much for your answer,
We have EEPROM and we did enable the UART print. Our problem is refered to the print UART thai it shows:
<debug_uart> spl_early_init
board_early_init_f
sdram_init
sdram_init begin
sdram_init end
get_ram_size
ram size: 4
The problem is that RAM is not correctly detected.
Compared to EVM we obtain in print UART:
<debug_uart> spl_early_init
do_board_detect
board_early_init_f
sdram_init
get_ram_size
ram size: 2147483648
In the original question I formulated I uploaded our schematic electrical design and settings for RAM; can you please give me your opinion about it and our problem?
Thank you very much in advance, Best regrads!

Hi Hong,

As you can see in Alberto's post, we do use UART debugging already. The problem is that get_ram_size returns "4" and not the correct value.

In sdram_init we call:

config_ddr(400, &ioregs_ddr3, NULL, NULL,
				   &ddr3_smaway_emif_regs_400Mhz, 0);

const struct ctrl_ioregs ioregs_ddr3 = {
	.cm0ioctl = DDR3_ADDRCTRL_IOCTRL_VALUE,
	.cm1ioctl = DDR3_ADDRCTRL_WD0_IOCTRL_VALUE,
	.cm2ioctl = DDR3_ADDRCTRL_WD1_IOCTRL_VALUE,
	.dt0ioctl = DDR3_DATA0_IOCTRL_VALUE,
	.dt1ioctl = DDR3_DATA0_IOCTRL_VALUE,
	.dt2ioctrl = DDR3_DATA0_IOCTRL_VALUE,
	.dt3ioctrl = DDR3_DATA0_IOCTRL_VALUE,
	.emif_sdram_config_ext = 0x0002C163,
};

static const struct emif_regs ddr3_smaway_emif_regs_400Mhz = {
	.sdram_config = 0x61A05332,
	.sdram_config2 = 0x00000000,
	.ref_ctrl = 0x00000c30,
	.sdram_tim1 = 0xEAAAE51B,
	.sdram_tim2 = 0x266B7FDA,
	.sdram_tim3 = 0x5F7F867F,
	.read_idle_ctrl = 0x00050000,
	.zq_config = 0x50077D33,
	.temp_alert_config = 0x00000000,
	.emif_ddr_phy_ctlr_1 = 0x00048009,
	.emif_ddr_ext_phy_ctrl_1 = 0x00040100,
	.emif_ddr_ext_phy_ctrl_2 = 0x00000000,
	.emif_ddr_ext_phy_ctrl_3 = 0x00000000,
	.emif_ddr_ext_phy_ctrl_4 = 0x00000000,
	.emif_ddr_ext_phy_ctrl_5 = 0x00000000,
	.emif_rd_wr_lvl_rmp_win = 0x00000000,
	.emif_rd_wr_lvl_rmp_ctl = 0x00000000,
	.emif_rd_wr_lvl_ctl = 0x00000000,
	.emif_rd_wr_exec_thresh = 0x00000405,
	.emif_prio_class_serv_map = 0x00000000,
	.emif_connect_id_serv_1_map = 0x00000000,
	.emif_connect_id_serv_2_map = 0x00000000,
	.emif_cos_config = 0x00ffffff};

Do you have any idea what we could have done wrong, also based on the EMIF Excel which Alberto has attached in his initial post?

Regards
Peter

Hi Hong,
Thank you very much for your answer,
We have EEPROM and we did enable the UART print. Our problem is refered to the print UART thai it shows:
<debug_uart> spl_early_init
board_early_init_f
sdram_init
sdram_init begin
sdram_init end
get_ram_size
ram size: 4
The problem is that RAM is not correctly detected.
Compared to EVM we obtain in print UART:
<debug_uart> spl_early_init
do_board_detect
board_early_init_f
sdram_init
get_ram_size
ram size: 2147483648
In the original question I formulated I uploaded our schematic electrical design and settings for RAM; can you please give me your opinion about it and our problem?
Thank you very much in advance, Best regrads!

Hi Hong,

As you can see in Alberto's post, we do use UART debugging already. The problem is that get_ram_size returns "4" and not the correct value.

In sdram_init we call:

Do you have any idea what we could have done wrong, also based on the EMIF Excel which Alberto has attached in his initial post?

Regards

Hi Peter,

After enabling board id detection from reading EEPROM, have we checked all board id dependent HW configurations (PMIC, DPLL, DDR) are setup correctly?

For AM437x, in board.c (board/ti/am437x/) file

- PMIC, and DPLL configuration in scale_vcore()

- DDR configuration in sdram_init()

In-correct configuration in any of above (PMIC, DPLL, DDR, Pinmux) may potentially leads un-expected behavior, or board boot "fail".

albgarc2014 said:

The problem is that get_ram_size returns "4" and not the correct value

Most likely this points to in-correct DDR configuration. Do we have JTAG on board? It is worth to trace code boot flow with JTAG to see

- all HW configuration (PMIC, DPLL, DDR) are all setup and called correctly

- DDR memory can be accessed successfully after sdram_init() call 

Best,

-Hong

Hi Hong,

For sure there is something wrong in our DDR parameters but we have tried several combinations which seemed logical to us with no improvement. This is why we have opened the ticket hoping that, based on the data provided, you can give us a hint where we may have made a mistake.

Regards

Peter

Hi Peter,

For debugging board bring-up issue, JTAG would be useful to navigate through code flow.

Specifically have we verified (via JTAG or early printf's)

-all HW configuration (PMIC, DPLL, DDR) are setup and called as expected on your board?

Best,

-Hong

Effectively we were lucky to notice that BBB has a very similar memory module so we copied that configuration... However the important thing is that it is working now.

Peter/Alberto,

Thanks for the update, and very good news to have on-board DDR working.

Best,

-Hong

I am afraid I have to re-open this case. It is true that it was looking quite well with the BBB setup but we got a lot of kernel relocation errors on a Linux level. So we want back to our original Excel sheet and started from scratch.

The output of the DDR script looks quite promising,RAM size is being calculated correctly and debug does not show any crashes during the SPL phase. However, for some reason u-boot does not come up.

One interesting thing is that we had the same problem with the BBB settings as well until we set a (wrong) #define EMIF1_BASE 0x4c00000f.The trick does not work for the real configuration though.

From your experience, do you have any idea where to look into or is there a document describing the major steps in the spl to uboot process? To be honest, our expertise ends with the hardware design and begins with the dts/mux configuration. We have never has similar issues before but we are under extreme pressure to get this working so and hint or shortcut is extremely welcome.


BBB memory MT41K256M16HA-125E.zip

Actual memory MT41K256M16TW-107.zip

Regards
Peter

We are with RAM problems yet

Hi Peter,

Peter Hoyer said:

The output of the DDR script looks quite promising,RAM size is being calculated correctly and debug does not show any crashes during the SPL phase. However, for some reason u-boot does not come up.

Do we have any logs?

Peter Hoyer said:

From your experience, do you have any idea where to look into or is there a document describing the major steps in the spl to uboot process?

In addition to regular serial log, many U-Boot modules (source files) already contain various forms of debug() print statements which can be activated on a per-module basis by adding a #define DEBUG to the top of the source file.

Another option is to use JTAG debugger to trace/narrow down the issue, especially useful for initial board bring-up. For u-boot symbol relocation when debugging u-boot, see note here

e2e.ti.com/.../3433571

We'll review the attached files for DDR configuration, and get back if any issues are identified.

Best,

-Hong

Hong Guan64 said:

Do we have any logs?

<debug_uart> spl_early_init
board_early_init_f
Timed out in wait_for_event: status=0000
Check if pads/pull-ups of bus are properly configured
sdram_init
get_ram_size
ram size: 536870912

U-Boot SPL 2019.01-gc7c7f6afb4-dirty (Sep 09 2020 - 20:26:11 +0200)
Trying to boot from MMC1
SPL: Please implement spl_start_uboot() for your board
SPL: Direct Linux boot not active!

We did actually do the JTAG of the SPL process and it looked fine. No crash. This is why I have asked if you have any outline of the SPL boot process to have a look "hat is missing.

Hong Guan64 said:

We'll review the attached files for DDR configuration, and get back if any issues are identified.

Thank you!!!

Hi Peter,

Peter Hoyer said:

This is why I have asked if you have any outline of the SPL boot process to have a look "hat is missing.

I’m attaching my note describing SPL boot flow till u-boot.

Hopefully it will facilitate SPL debugging via either enabling debug() prints or using JTAG debugger, which is very useful for board bring-up.

Best,

-Hong

spl_boot_flow.docx

Peter, i looked briefly at your logs, and i don't see anything that stand out.  The last picture in spl_boot_flow.docx shows what looks like good data at the beginning of the DDR.  Is there code at 0x80800300?  That is where the first branch jumps to.  When you get to that point, can you successfully read/write the DDR in a memory window?

Regards,

James

Sorry Peter, i thought the .docx file was from you, not Hong.  Let me make some different suggestions:

-after a u-boot failure, open up a memory window in CCS in the DDR memory space.  Can you successfully peek/poke values in the DDR?  If not, what is the behavior.  Can you run the DSS script at this point?

-check proper voltages on VDCDC3 and VREF

Regards,

James

Hi James and Hong,

First of all thank you very much indeed for your support.

I have gone through the entire process and SPL does actually run until the very end. Without excetions or anything strange I am getting up to jump_to_image_no_args:

I suppose after that he is jumping into main u-boot:

There is no output on the console and I suppose I am unable to load symbols beause I do not know the offset. Is there any other way to get the offset than "bdinfo" and then "relocaddr"?

To answer your questions: I am able to run the ddr script at any time with no surprising output. VDCDC3 is 1.35V and VREF is 0.68V, both as expected.

Regards
Peter

Hi Peter,

Can you take a look at this e2e thread on how to debug u-boot

e2e.ti.com/.../3433571

where I created a note on how to get u-boot symbol relocation offset

e2e.ti.com/.../u_2D00_boot_5F00_JTAG_5F00_debug.pdf

Best,

-Hong

Hi Hong,

I do not get there. Once SPL has finished, execution remains here forever:

Regards
Peter

Peter,

I'm attaching a note showing the last few steps when SPL loading u-boot into DDR @0x80800000.

would you try it out to see if you can do the same?

Best,

-Hongspl_load_u-boot.docx

Hi Hong,

Yes, this works for me (in a sense that I can do the same).

Regards

Peter

Any further ideas?

Hi Peter,

I’m attaching a note summarizing u-boot boot flow.

Hope it would help u-boot debug by tracing code via JTAG, or adding serial dump via regular printf() or debug() by adding “#define DEBUG”.

Best,

-Hong

u-boot_boot_flow.docx

Hi Hong,

The document which you have attached describes the regular u-boot flow and how to get the relocation offset once you have the u-boot console. This would be useful if I would reach that console which is exactly the problem which we are facing.

Given that you told me to set a breakpoint at relocate_code. I replied that the problem is that after relocation it enters regular u-boot but it gets into a loop before reaching the breakpoint.

Then we have had a look at the last steps of SPL and I confirmed you that our board behaves as expected.

So what do you suggest now?
What may cause this problem?
Do you see any potential problems in the EMIF configuration altough the DDR test tool replied it is fine?
As, when using the BBB RAM settings I had exactly the same problem unless I set EMIF1_BASE to an incorrect value which then made me however reach the u-boot prompt, what may this tell us about the problem?

Regards
Peter

Hi Peter,

In last post, I uploaded my note "u-boot_boot_flow.docx" which lists u-boot boot flow summary, and how to enable debug() in board_init_f(), and board_init_r().

Additional option is to add “#define DEBUG” at the top of “/lib/initcall.c” to enable full “initcall xxxxxxxx” debug dump in u-boot log.
The extended log would dump u-boot boot progress, and potentially indicate where u-boot booting fails:

Note that:
1. initcall_run_list() (/lib/initcall.c) is called by boot_init_f() (/common/board_f.c),
which executes a sequence of initialization functions defined in init_sequence_f[] = {…};
2. Similarly initcall_run_list() is also called in boot_init_r() (/common/board_r.c),
which runs a sequence of initialization functions defined in init_sequence_r[] = {…};

Best,
-Hong