66AK2H06: Build u-boot to use on-chip memory (OCM) instead of DDR

Lance Jump

Part Number: 66AK2H06

How can I build u-boot to run from on-chip memory instead of DDR? Below is the motivation

We have production boards based on Keystone 2. (These boards do not have an emulator connection.) Sometimes we get a board where booting fails when the SPL tries to transfer control to u-boot in DDR (determined based on messages). We would like to use u-boot to examine registers and such t help in debug, but it won't run because DDR is broken.

Thanks,

Lance

over 7 years ago

0 Yordan Kovachev over 7 years ago

TI__Guru**** 161600 points

Hi Lance,

The spl (MLO) runs from the on-chip memory. U-boot is loaded in DDR & executes from there. I'll have a look at this, but in my experience you shouldn't be able to execute u-boot from internal memory.

Best Regards,
Yordan

0 Lance Jump over 7 years ago in reply to Yordan Kovachev

Expert 1280 points

Yordan,

Thanks for the quick response. I appreciate you looking into this.

I do not need much capability from u-boot for this and I certainly don't plan to boot anything using it. But the ability to examine/modify registers/memory may prove valuable in diagnosing the problem.

Thanks,
Lance

0 Yordan Kovachev over 7 years ago in reply to Lance Jump

TI__Guru**** 161600 points

Hi Lance,

I think I have another option for you, if you're running linux on your board.
You can use u-boot falcon mode, this skips the u-boot part and loads the kernel directly, so your boot sequence will be:
ROM Code -> BMC-> MLO -> Kernel, instead of ROM Code -> BMC-> MLO -> U-boot -> Kernel

Check these links for info how to build & use u-boot in falcon mode:
e2e.ti.com/.../1999092
e2e.ti.com/.../1893477
www.denx.de/.../2013-ELCE-U-Boot-Falcon-Boot.pdf

Best Regards,
Yordan

0 Yordan Kovachev over 7 years ago in reply to Yordan Kovachev

TI__Guru**** 161600 points

Sorry disregard the above. If you need u-boot only for debugging this won't work for you.
I'll see for other solution.

Best Regards,
Yordan

0 Rex Chang over 7 years ago in reply to Yordan Kovachev

TI__Guru 50170 points

HI, Lance,

The u-boot is running off on-chip memory in MSMC @ 0x0c00 0000. DDR3 is initialized and configured by u-boot, so u-boot can't run from DDR3 before it is configured. You didn't say what SDK was used. The starting address has been moved between MCSDK and ProcSDK from 0x0c001000 to 0x0c00 0000.

I am not sure how you can debug this because the console is also initialized in u-boot. If it fails at when SPL jumps to u-boot, then the print won't work either.

Rex

0 Lance Jump over 7 years ago in reply to Rex Chang

Expert 1280 points

Rex,

I am using MCSDK. I believe that the u-boot-spl, also initializes the console because I get messages from it, the last of which is that it is clearing DDR. I am guessing that, not long after, the SPL jumps to the full u-boot in (broken) DDR and it all falls apart.

I was hoping that I could either build the full u-boot to use OCM instead of DDR, or add some interactive routines (e.g. register/memory access) into u-boot-spl. A less attractive alternative would be to add debug code to SPL in an edit/make/load process -- tedious, but better than nothing, especially since a UART boot takes less than a minute.

None of this would be normal, permanent code since it is only needed to test the occasional bad board. With everything in BGA packages and routing on inner layers with buried vias, it is very difficult to probe anything. But there may be some clues in the DDR controller registers to help narrow our search.

I am having trouble finding where the destination address for u-boot in DDR is defined or where the final transition from SPL to full u-boot is performed, although I have only looked at it for a couple of hours. Any clues would be useful. Also, I will be offended if you think this whole plan is a bad idea.

Thanks,

Lance

0 Lance Jump over 7 years ago in reply to Lance Jump

Expert 1280 points

Rex: Oops... I meant to say "I will NOT be offended..." Kind of changes the meaning.

0 Rex Chang over 7 years ago in reply to Lance Jump

TI__Guru 50170 points

Hi, Lance,

Don't worry. I knew it was a typo.

KS2 uses 2 stage booting. The bootloader first loads a tiny piece of code, spl, to MSMC to start, then spl loads uboot still to MSMC to run. So, u-boot, not just SPL, is on MSMC. Not until u-boot initializes the DDR3, then it relocates itself to DDR3. You can refer to doc/README.arm-relocation for more details, or take a look at the board_init_f() in arch/arm/lib/board.c in u-boot source code.

I thought you were on ProcSDK, Just curious your configuration. Do you mind sharing or correct my entries?

MCSDK version: 3.1.4.7

BootMode: ARM SPI

DDR3A: (Vendor) 2GB 1600 MT/s

sysclk for ARM

and for DDR3A:

0 Lance Jump over 7 years ago in reply to Rex Chang

Expert 1280 points

Rex,

Ah, now I understand your earlier comments. No wonder I couldn't find the transition to DDR -- I was looking in SPL when it is u-boot-full that actually sets that up. I should have already known that because we normally bring boards using UART boot of u-boot, which does not use the spl.

So, really debugging code should be put in u-boot full before it transitions to DDR.

We are using MCSDK 3.01.01.04. Below are the initial power on messages:

DRAM: 2 GiB CPU rev: 1
U-Boot SPL 2013.01-dirty (Oct 31 2015 - 06:50:55)
spi_setup_slave bus=0 cs=0 regs=21000400 frq=30000000
SF: Detected N25Q512A with page size 64 KiB, total 64 MiB

U-Boot 2013.01-dirty (Oct 31 2015 - 06:50:55)

I2C: ready
Cannot read DIMM params
Detected SO-DIMM []

Reseting entire DDR3 memory to 0 ...
DRAM: 2 GiB
NAND: 256 MiB
spi_setup_slave bus=0 cs=0 regs=21000400 frq=30000000
SF: Detected N25Q512A with page size 64 KiB, total 64 MiB
Net: K2HK_EMAC0, K2HK_EMAC1
Hit any key to stop autoboot: 0

Processors

Processors forum

66AK2H06: Build u-boot to use on-chip memory (OCM) instead of DDR