AM5728: What was the resolution to the previous poster's issue?

Sean Heffernan1

Part Number: AM5728

We are having similar issues with our custom AM5728-based board.

Previous revisions of our board booted up properly from an SD card, but our latest revision fails to boot. The older revisions used two banks of DDR3 memory while the latest revision only uses one bank; we are not sure if this is what's causing our boot issues.

What was the resolution to this issue?

over 2 years ago

0 Josue Zamitiz-Ayala over 2 years ago

TI__Mastermind 39996 points

Hello Sean,

There was no resolution to that previous thread since the Original Poster (OP) did not respond.
Could you please give us more information about your environment?
Do you have any error boot logs?

What software are you using?

Is the DDR3 memory the exactly the same as on the first revisions?

-Josue

0 Sean Heffernan1 over 2 years ago in reply to Josue Zamitiz-Ayala

Intellectual 290 points

Hello Josue,

In the first revision of our board, we installed two MT41K512M16HA-125:A devices on each DDR bank; these are DDR3L devices, and we are supplying VDDS_DDRx pins with 1.35V.

In the second revision of our board, we are installing two MT41K512M16HA-107:A devices on the DDR1 bank and leaving DDR2 unused. The AM57xx Schematic Checklist says that the unused DDR2_DQSn and DDR2_DQSNn pins should be "pulled to GND or to the appropriate power supply through a 1kΩ resistor"; we are pulling the DQSn pins to GND and the DQSNn pins to VDDS_DDR2 via 8 individual 10kΩ resistors.

The first revision of our board boots up properly from the SD card; the second revision fails to boot, and the only message we get out of our serial debug port (UART3) is shown below:

U-Boot SPL 2017.01-00361-g605ef5e-dirty (May 19 2018 - 14:38:53)

I am only now noticing that we are using a different speed grade of DDR3L on the two boards (I am not the board designer); could this be the cause of our problems?

+1 Josue Zamitiz-Ayala over 2 years ago in reply to Sean Heffernan1

TI__Mastermind 39996 points

Hello Sean,

Yes, this could very well be the reason.

Was the DDR configuration modified for the second revision (different DDR speed)?

The first thing u-boot does is set up the memory.

Please see this thread for more information: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/565727/am5718-ddr-memory-multiple-speed-grades which points out the following app-note https://www.ti.com/lit/an/sprac36e/sprac36e.pdf

-Josue

0 Sean Heffernan1 over 2 years ago in reply to Josue Zamitiz-Ayala

Intellectual 290 points

Josue,

I will check with my colleagues and see if they changed the DDR configuration appropriately when we switched to the newer board revision.

Sean

0 Josue Zamitiz-Ayala over 2 years ago in reply to Sean Heffernan1

TI__Mastermind 39996 points

Sounds good!

0 Sean Heffernan1 over 2 years ago in reply to Josue Zamitiz-Ayala

Intellectual 290 points

Hello Josue,

I confirmed that we never changed our DDR configuration when we redesigned our board. So I used the sprac36e app note and spreadsheet to calculate new configuration register values and gave the data to our software team to compile a new u-boot code.

Unfortunately, it does not look like our new u-boot code has resolved the problem.

I mentioned in a previous post that we are pulling the DQSn pins of the unused DDR2 bank to GND and the DQSNn pins to VDDS_DDR2 via 8 individual 10kΩ resistors. Is this OK, or should all of the pins be pulled to the same rail (either GND or VDDS_DDR2)?

+1 Kevin S over 2 years ago in reply to Sean Heffernan1

TI__Mastermind 43750 points

Hi Sean,

Since you are no longer using the second DDRSS, can you confirm whether you updated the DMM register settings?

Can you confirm that variable emif1_enabled is set to 1 and emif2_enabled is set to 0 after the code linked below executes?

https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/arch/arm/mach-omap2/emif-common.c?h=ti-u-boot-2021.01&id=44a87e3ab85c6d64044f0b5ad677008316baad70#n1451

Sean Heffernan1 said:
I mentioned in a previous post that we are pulling the DQSn pins of the unused DDR2 bank to GND and the DQSNn pins to VDDS_DDR2 via 8 individual 10kΩ resistors. Is this OK, or should all of the pins be pulled to the same rail (either GND or VDDS_DDR2)?

Pulling to opposite rails aligns with section 8.2.2.4.2 of the datasheet:

"When not using all or part of a DDR interface, the proper method of handling the unused pins is to tie off the ddrx_dqsi pins to ground via a 1k-Ω resistor and to tie off the ddrx_dqsni pins to the corresponding vdds_ddrx supply via a 1k-Ω resistor."

Regards,
Kevin

0 Sean Heffernan1 over 2 years ago in reply to Kevin S

Intellectual 290 points

Great news, after updating all of the EMIF and DMM register settings, we are now able to boot up our boards from the MicroSD card.

One follow up question: we are monitoring the serial port during u-boot and notice the following messages at the start of the debug log:

U-Boot SPL 2016.05-00118-gdd926c6000-dirty (Dec 18 2023 - 18:34:54)
DRA752-GP ES2.0
Trying to boot from MMC1
reading args
spl_load_image_fat_os: error reading image args, err - -1
reading u-boot.img
reading u-boot.img
reading u-boot.img
reading u-boot.img

Can you tell us the meaning of the "-dirty" suffix?

+1 Kevin S over 2 years ago in reply to Sean Heffernan1

TI__Mastermind 43750 points

Hi Sean,

Sean Heffernan1 said:
U-Boot SPL 2016.05-00118-gdd926c6000-dirty (Dec 18 2023 - 18:34:54)

Sean Heffernan1 said:
Can you tell us the meaning of the "-dirty" suffix?

I believe that implies there are changes to tracked files in your source repository that have not been committed. See the variable UBOOTRELEASE in the documentation below.

https://docs.u-boot.org/en/latest/develop/version.html

Regards,
Kevin

0 Hanmant Gaikwad over 2 years ago in reply to Kevin S

Prodigy 150 points

Hi Kevin,

I'm getting issue while booting board with New 2021 u-boot source code version.it should have worked for this new 2021 u-boot version(did same configuration related registers for custom board) because as it's working on 2016 u-boot version .

U-Boot SPL 2021.01-00003-g16d964ac27-dirty (Dec 19 2023 - 12:44:06 +0530)
DRA752-GP ES2.0
Trying to boot from MMC1
Loading Environment from FAT... OK

U-Boot 2021.01-00003-g16d964ac27-dirty (Dec 19 2023 - 12:44:06 +0530)

CPU : DRA752-GP ES2.0
Model: TI AM5728 IDK
Board: UNKNOWN(BeagleBoard X15?) REV UNKNOWN
DRAM: 2 GiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from FAT... OK
Net: Could not get PHY for ethernet@48484000: addr 1
eth2: ethernet@48484000
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
Failed to load 'boot.scr'
347 bytes read in 10 ms (33.2 KiB/s)
Loaded env from uEnv.txt
Importing environment from mmc0 ...
Running uenvcmd ...
32657816 bytes read in 1415 ms (22 MiB/s)
5186624 bytes read in 233 ms (21.2 MiB/s)
## Starting application at 0x84100000 ...
prefetch abort
pc : [<00000140>] lr : [<841002f4>]
reloc pc : [<8189d140>] lr : [<0599d2f4>]
sp : 4037fd28 ip : 00000000 fp : 840ffff8
r10: fefe4f10 r9 : fcf42ed0 r8 : 00000002
r7 : 0003c07b r6 : 40300000 r5 : 4037f064 r4 : 00000001
r3 : 00000004 r2 : 00000198 r1 : 80800041 r0 : 00000001
Flags: nzcv IRQs off FIQs off Mode SVC_32 (T)
Code: 0000 0000 0000 0000 (0000) 0000
Resetting CPU ...

resetting ...

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1304710/am5728-am5728-sd-u-boot-issue

0 Josue Zamitiz-Ayala over 2 years ago in reply to Hanmant Gaikwad

TI__Mastermind 39996 points

Hello Hanmant,

The question asked by this thread has been resolved. For this other issue, lets keep it in the other existing thread: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1304710/am5728-am5728-sd-u-boot-issue

Please mark Kevin's last response as "This resolve my issue" in order to close this thread.

Thank you!

-Josue

Processors

Processors forum

AM5728: What was the resolution to the previous poster's issue?