Same u-boot for SOM w/ DDR3L and LPDDR4

[jbtalley]

I have 2 boards that share the same PCB.  The only difference is that one board is populated w/ DDR3L memory, and the other is populated w/ LPDDR4 memory.  Both have 4G.

The DDR3L is based on the imx8mmddr3lval machine and it boots/runs as expected.

The LPDDR4 board is based on the imx8mmevk machine and it boots/runs as expected.  

When I try to use a combined image, such that there is a single imx-boot/uboot bootloader, only the DDR4 machine will serial boot.  I've modified the power_init_board function to set the pmic properly based on the memory type (there's a gpio that indicates memory type).

I've updated the ddr_init call to init the correct dram type.  

I've updated the Makefile to include both the lpddr4_timing.c as well as the ddr3l_timing.c file.

DDR4 boot sequence works fine as shown below.

U-Boot SPL 2020.04-imx_v2020.04_5.4.24_2.1.0+gc260666f69 (Feb 23 2024 - 19:00:54 +0000)
DDR 4 Power init
Checking RAM type...
DDR4 detected
DDRINFO: start DRAM init
DDRINFO: DRAM rate 3000MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
DDR init done
Normal Boot...
Tryuing boot: cTrying to boot from USB SDP
SDP: initialize...
SDP: handle requests...
Downloading file of size 1034864 to 0x40400000... done

DDR3 boot sequence, attemps, then resets.

U-Boot SPL 2020.04-imx_v2020.04_5.4.24_2.1.0+gc260666f69 (Feb 23 2024 - 19:00:54 +0000)
DDR 3 Power init
Checking RAM type...
DDR3 detected
DDRINFO: start DRAM init
DDRINFO: DRAM rate 1600MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
DDR init done
Normal Boot...
Tryuing boot: cTrying to boot from USB SDP
"Synchronous Abort" handler, esr 0x96000000
elr: 00000000007e5c4c lr : 00000000007e5ba4
x 0: 00000a01221b3fdc x 1: 0000000042200010
x 2: 00000a00dffb2fed x 3: 00000000007f80c0
x 4: 00000000009105a0 x 5: 0000000000000002
x 6: 0000000000000001 x 7: 0000000000000003
x 8: 0000000000000000 x 9: 0000000000000002
x10: 000000000a200023 x11: 0000000000000002
x12: 0000000000000002 x13: 0000000000000018
x14: 000000000090e558 x15: 0000000000013da4
x16: 00000000007ea5e8 x17: 0000000000000005
x18: 000000000091de80 x19: 0000000000000ff0
x20: 0000000042200ff0 x21: 0000000000000310
x22: 0000000000000300 x23: 0000000000001000
x24: 00000000007f0fbb x25: 00000000deadbeef
x26: 0000000000000005 x27: 0000000000000000
x28: 0000000000000000 x29: 000000000091dca0

Code: cb130000 b2400002 8b000280 f9000682 (f9400402)
Resetting CPU ...

I'm getting out of my comfort zone, but from ./u-boot-imx-2020.04/imx8mm_evk_defconfig/spl/u-boot-spl.map,  00000000007e5c4c maps to 

.text.alloc_simple
0x00000000007e5cb4 0x58 common/built-in.o
.text.malloc_simple
0x00000000007e5d0c 0x8 common/built-in.o
0x00000000007e5d0c malloc_simple

I think I read that esr is pointing to a memory address -- of which 0x96000000 is out of bounds.  I don't know where this value comes from.

I know I _could_ use 2 different bootloaders but that introduces some downstream logistical issues that I'd like to avoid.  

I've attacked this 2 ways - starting w/ the imx8mmevk and trying to port in DDR3L functionality, and the inverse of starting w/ DDR3L and porting in LPDDR4.  In both instances, I can only get the starting board type to work.  Is there some other memory init function I'm missing?  I can't seem to find where the SDP: initialize... is coming from.

If it matters, I'm using a mod'd version of Dunfell - using u-boot-imx 2020.04 and imx-boot 1.0/bl31 binary.

Thanks for making it this far.

[pengyong_zhang]

Hi, @jbtalley 

Got it, Thanks!

B,R

[pengyong_zhang]

Hi, @jbtalley 

Glad to listen you are made it. Could you share the patch for me, And How do you set the GPIO to indicate the DDR type?

B.R

[jbtalley]

Sorry for the misleading GPIO comment.  I bribed our EE to solder up a couple of unused GPIOs to indicate DDR3 vs DDR4. 

I wish I was good enough to detect the memory type without the help of the other GPIOs.  

I'm cleaning up the patches - I'll share once they are tidy.

[pengyong_zhang]

Hi, @jbtalley 

Yes, you are right, Different DDR type use different ddr firmware, You can found it in the imx_makimage file. When you compile the flash.bin file, the imx_mkimage will choose the DDR firmware generate the u-boot-spl-ddr.bin file.

B.R

[jbtalley]

I've managed to tweak the soc.mak and helper.c to deal w/ the extra DDR firmware files.  DDR4 (the original) trains properly, but DDR3 training is failing.  That's different at least - before it would continually reset. 

I need to find a way to verify that the ddr firmware is packaged like i think it is. 

I updated soc.mak to fully pad the DDR4 firmware, and then append the DDR3 firmware to the image.

u-boot-spl-ddr.bin: u-boot-spl.bin $(lpddr4_imem_1d) $(lpddr4_dmem_1d) $(lpddr4_imem_2d) $(lpddr4_dmem_2d) ddr3_imem_1d.bin ddr3_dmem_1d.bin

@objcopy -I binary -O binary --pad-to 0x8000 --gap-fill=0x0 $(lpddr4_imem_1d) lpddr4_pmu_train_1d_imem_pad.bin

@objcopy -I binary -O binary --pad-to 0x1000 --gap-fill=0x0 $(lpddr4_dmem_1d) lpddr4_pmu_train_1d_dmem_pad.bin

@objcopy -I binary -O binary --pad-to 0x8000 --gap-fill=0x0 $(lpddr4_imem_2d) lpddr4_pmu_train_2d_imem_pad.bin

@objcopy -I binary -O binary --pad-to 0x1000 --gap-fill=0x0 $(lpddr4_dmem_2d) lpddr4_pmu_train_2d_dmem_pad.bin

@cat lpddr4_pmu_train_1d_imem_pad.bin lpddr4_pmu_train_1d_dmem_pad.bin > lpddr4_pmu_train_1d_fw.bin

@cat lpddr4_pmu_train_2d_imem_pad.bin lpddr4_pmu_train_2d_dmem_pad.bin > lpddr4_pmu_train_2d_fw.bin

@objcopy -I binary -O binary --pad-to 0x8000 --gap-fill=0x0 ddr3_imem_1d.bin ddr3_imem_1d.bin_pad.bin

@cat ddr3_imem_1d.bin_pad.bin ddr3_dmem_1d.bin > ddr3_pmu_train_fw.bin

@dd if=u-boot-spl.bin of=u-boot-spl-pad.bin bs=4 conv=sync

@cat u-boot-spl-pad.bin lpddr4_pmu_train_1d_fw.bin lpddr4_pmu_train_2d_fw.bin ddr3_imem_1d.bin_pad.bin > u-boot-spl-ddr.bin

@rm -f u-boot-spl-pad.bin lpddr4_pmu_train_1d_fw.bin lpddr4_pmu_train_2d_fw.bin lpddr4_pmu_train_1d_imem_pad.bin lpddr4_pmu_train_1d_dmem_pad.bin lpddr4_pmu_train_2d_imem_pad.bin

U-Boot SPL 2020.04-imx_v2020.04_5.4.24_2.1.0+gdd1fe13d92 (Mar 05 2024 - 16:02:12 +0000)
DDR3 detected
DDRINFO: start DRAM init
DDRINFO: DRAM rate 1600MTS
**** uboot end=7fa890 imem_start=80c890 dmem_start=814890 fw_offset=12000
[PMU Major message = 0x00000008]
PMU String index = 0x00c60000

[PMU Major message = 0x00000008]
PMU String index = 0x04020000

[PMU Major message = 0x000000ff]
Training FAILED

I feel like I'm making progress - this DDR training is a very new black box to me so its slow going.

[jbtalley · Accepted solution]

Score!  

Updating helper.c as well as soc.mak and using the correct padded binary above, I am able to successfully boot the 2 different SOMs w/ the same imx-boot binary.  

Thanks for following along and asking questions.  

To recap for anyone else that comes across this particular problem, the solution was to update soc.mak to fully pad all the DDR firmwares, append the padded firmware to the  u-boot-spl-ddr.bin intermediate file, and update helper.c to deal w/ the memory offsets IMEM_LEN, DMEM_LEN and fw_offset.  

[pengyong_zhang]

Hi, @jbtalley 

When you boot the board, The chip can't judgment what DDR is connected. So you should tell the chip the type of DDR..

B.R

[pengyong_zhang]

Hi, @jbtalley 

You can not use one same image support both two different DDR type, One image match one DDR type.

B.R

[jbtalley]

I'm ok with that answer, but I'm curious as to why. Is this due to logic in the ROM when loading the DDR firmware files? Yocto build process? Both?

[jbtalley]

https://community.nxp.com/t5/i-MX-Processors/i-MX8MM-DDR-firmware-padding/m-p/1036638/highlight/true

It seems there was some success using lpddr and ddr4 in the same image.  IDK if ddr4/lpddr4 is significantly different, but the imx-boot scripts to seem to use different ddr_firmware based on the lpddr and ddr4 EVKs.

I'm need to investigate how/if the ddr_firmware files are used before I can truly accept this as not possible.

[jbtalley]

I'm using Yocto to build.  So bitbake imx-boot.  I assume the problem lies somewhere in how the ddr firmware files are included.  I've tried just adding the ddr3 and ddr4 firmware files to imx-boot but that obviously didn't do any good.  

Do you have a suggestion of something to dig into?  

[pengyong_zhang]

Hi, @jbtalley 

How do you make the flash.bin file when you try use a combined image to boot two different DDR type?

B.R