66AK2G12: u-boot relocation issue, hangs at "Relocating to"

Graziano Rufolo

Part Number: 66AK2G12

Hi,

I have developed a custom board with 66AK2G12 and now I am working to port the u-boot from evaluation board (k2g-ice and k2g-evm) to custom board. I am using SDK 06_01_00_08 Linux RT.

I have executed the necessary modification in order to start-up the first stages of u-boot(my board does not have the EEPROM for board recognizing as evaluation ones) and I have executed the proper modification to EMIF and PHY registers in board/<vendor>/<board>/ddr3_k2g.c to init DDR.

In fact get_ram_size() after ddr_init() recognizes the effective DDR size and I have enabled the power on self test for memory in order to stress the DDR and I did not found any problem at that moment.

But the process stuck when u-boot relocates to DDR. Below the console message on Uart with DEBUG enabled:

initcall: 0c05d6d5


U-Boot 2019.01-svn8 (Mar 19 2021 - 17:47:44 +0100)

initcall: 0c010299
U-Boot code: 0C000000 -> 0C091BA0  BSS: -> 0C0C138C
initcall: 0c0019e5
CPU: 66AK2Gx-100 SR1.0
initcall: 0c002c45
Selecting config 'keystone-k2g-hpc'initcall: 0c0106d5
Model: Texas Instruments K2G SoC - Hitachi Propulsion Controller (HPC) board
initcall: 0c010391
DRAM:  initcall: 0c0028f5
Avvio u-boot entro 1 secondi
initcall: 0c062e39
initcall: 0c010375
initcall: 0c010475
Monitor len: 000C138C
Ram size: 10000000
Ram top: 90000000
initcall: 0c010129
initcall: 0c010159
TLB table from 8fff0000 to 8fff4000
initcall: 0c0103d7
initcall: 0c0103db
initcall: 0c010251
Reserving 772k for U-Boot at: 8ff2e000
initcall: 0c01022d
Reserving 33024k for malloc() at: 8deee000
initcall: 0c01033d
Reserving 80 Bytes for Board Info at: 8deedfb0
initcall: 0c0103df
initcall: 0c010205
Reserving 224 Bytes for Global Data at: 8deeded0
initcall: 0c0101b5
Reserving 14656 Bytes for FDT at: 8deea590
initcall: 0c0103e3
initcall: 0c0103e7
initcall: 0c0103f7
initcall: 0c0104d1
initcall: 0c01013d
initcall: 0c010401

RAM Configuration:
Bank #0: 80000000 256 MiB

DRAM:  256 MiB
initcall: 0c0101a1
New Stack Pointer is: 8deea570
initcall: 0c010311
initcall: 0c0103eb
initcall: 0c0103ef
initcall: 0c0102b9
Relocation Offset is: 83f2e000
Relocating to 8ff2e000, new gd at 8deeded0, sp at 8deea570

Which could be the reason of that behaviour? Could it depend again from DDR configuration or something simpler as UART console properties? Consider that CONFIG_SYS_TEXT_BASE is set 0x0C000000 in /config/<board>_defconfig and when I try to modify it, u-boot does not start.

I hope you have any suggestion to solve the problem.

Regards

Graziano

over 5 years ago

0 Hong Guan64 over 5 years ago

TI__Guru* 79080 points

Hi Graziano,
I'm attaching u-boot log captured on AM335x EVM (1GB DDR) for your reference as currently I don't have access to K2G EVM,
1. DDR size is "dynamically" determined via calling get_ram_size() as listed below:
where dram_init() in "/arch/arm/mach-omap2/am33xx/board.c", and get_ram_size() in "/common/memsize.c"

/*
 * Check memory range for valid RAM. A simple memory test determines
 * the actually available RAM size between addresses `base' and
 * `base + maxsize'.
 */
long get_ram_size(long *base, long maxsize){}

int dram_init(void)
{
#ifndef CONFIG_SKIP_LOWLEVEL_INIT
	sdram_init();
#endif

	/* dram_init must store complete ramsize in gd->ram_size */
	gd->ram_size = get_ram_size(
			(void *)CONFIG_SYS_SDRAM_BASE,
			CONFIG_MAX_RAM_BANK_SIZE);
	return 0;
}

where for AM335x EVM (1GB DDR)
- /include/configs/ti_am335x_common.h
#define CONFIG_MAX_RAM_BANK_SIZE (1024 << 20) /* 1GB */
- /include/configs/ti_armv7_common.h
#define CONFIG_SYS_SDRAM_BASE 0x80000000

=> DDR:80000000-bfffffff

2. u-boot is relocated as shown below (details in the attached log file) after DDR size detection.

...
DRAM:  1 GiB
initcall: 8080ef45
New Stack Pointer is: bdf388b0
initcall: 8080eef3
initcall: 8080f0bd
initcall: 8080f195
initcall: 8080f199
initcall: 8080f065
Relocation Offset is: 3f767000
Relocating to bff67000, new gd at bdf46eb8, sp at bdf388b0
initcall: bff762e9
initcall: bff762ed
initcall: 8080f45d (relocated to bff7645d)
initcall: 8080f429 (relocated to bff76429)
...

Best,

-Hong

0 Hong Guan64 over 5 years ago in reply to Hong Guan64

TI__Guru* 79080 points

Att

Fullscreen am3_6.3_u-boot_relocation.txt Download

<debug_uart>
Passed early_system_init()
 
Passed board_early_init_f()

Passed sdram_init()

U-Boot SPL 2019.01-g175b3522cc-dirty (Feb 10 2021 - 21:07:41 -0600)
Trying to boot from MMC1
clock is disabled (0Hz)
selecting mode MMC legacy (freq : 0 MHz)
clock is enabled (400000Hz)
selecting mode MMC legacy (freq : 25 MHz)
sd card: widths [4, 1, ] modes [MMC legacy, SD High Speed (50MHz), ]
host: widths [4, 1, ] modes [MMC legacy, MMC High Speed (26MHz), SD High Speed (50MHz), MMC High Speed (52MHz), ]
trying mode SD High Speed (50MHz) width 4 (at 50 MHz)
selecting mode SD High Speed (50MHz) (freq : 50 MHz)
clock is enabled (50000000Hz)
initcall: 8080eeb1
initcall: 80845a39
initcall: 8081437f
initcall: 8080eea9
initcall: 8080f14d
initcall: 8080eec9
initcall: 8080f19d
initcall: 8080eecd
initcall: 8080f181
initcall: 8080f159
>>>> initf_dm: 825:
 Class    index  Probed  Driver                Name
-----------------------------------------------------------
 root        0  [ + ]   root_driver           root_driver
 rsa_mod_ex  0  [   ]   mod_exp_sw            `-- mod_exp_sw
initcall: 808020a9
initcall: 808472f5
initcall: 80831029
initcall: 8080f131
initcall: 80829bd5
initcall: 80846481


U-Boot 2019.01-g175b3522cc-dirty (Feb 10 2021 - 21:07:41 -0600)

initcall: 8080f041
U-Boot code: 80800000 -> 8086C2A4  BSS: -> 80888C68
initcall: 80801fd1
CPU  : AM335X-GP rev 2.1
initcall: 8080f4dd
Model: TI AM335x EVM
initcall: 8080f1a5
initcall: 8080eef3
initcall: 8080f121
DRAM:  initcall: 80802061
initcall: 8080eef3
initcall: 8080eef3
initcall: 8080eef3
initcall: 8080f251
Monitor len: 00088C68
Ram size: 40000000
Ram top: C0000000
initcall: 8080eed1
initcall: 8080eefd
TLB table from bfff0000 to bfff4000
initcall: 8080f185
initcall: 8080f189
initcall: 8080eff9
Reserving 547k for U-Boot at: bff67000
initcall: 8080efd1
Reserving 32896k for malloc() at: bdf47000
initcall: 8080f0e9
Reserving 104 Bytes for Board Info at: bdf46f98
initcall: 8080eee5
initcall: 8080efa9
Reserving 224 Bytes for Global Data at: bdf46eb8
initcall: 8080ef59
Reserving 58848 Bytes for FDT at: bdf388d8
initcall: 8080f18d
initcall: 8080f191
initcall: 8080f1a1
initcall: 8080f2ad
initcall: 80802077
initcall: 8080f1b5

RAM Configuration:
Bank #0: 80000000 1 GiB
Bank #1: 0 0 Bytes
Bank #2: 0 0 Bytes
Bank #3: 0 0 Bytes

DRAM:  1 GiB
initcall: 8080ef45
New Stack Pointer is: bdf388b0
initcall: 8080eef3
initcall: 8080f0bd
initcall: 8080f195
initcall: 8080f199
initcall: 8080f065
Relocation Offset is: 3f767000
Relocating to bff67000, new gd at bdf46eb8, sp at bdf388b0
initcall: bff762e9
initcall: bff762ed
initcall: 8080f45d (relocated to bff7645d)
initcall: 8080f429 (relocated to bff76429)
initcall: 8080f4a5 (relocated to bff764a5)
initcall: 8080f3f9 (relocated to bff763f9)
Pre-reloc malloc() used 0x1ac bytes (0 KB)
initcall: 8080eead (relocated to bff75ead)
initcall: 8080f3eb (relocated to bff763eb)
initcall: 8080f4a9 (relocated to bff764a9)
initcall: 8080f4a1 (relocated to bff764a1)
initcall: 8080f469 (relocated to bff76469)
>>>> initr_dm: 302:
 Class    index  Probed  Driver                Name
-----------------------------------------------------------
 root        0  [ + ]   root_driver           root_driver
 rsa_mod_ex  0  [   ]   mod_exp_sw            |-- mod_exp_sw
 simple_bus  0  [   ]   generic_simple_bus    `-- ocp
 simple_bus  1  [   ]   generic_simple_bus        |-- l4_wkup@44c00000
 simple_bus  2  [   ]   generic_simple_bus        |   |-- prcm@200000
 simple_bus  3  [   ]   generic_simple_bus        |   `-- scm@210000
 simple_bus  4  [   ]   generic_simple_bus        |       `-- scm_conf@0
 gpio        0  [   ]   gpio_omap                 |-- gpio@44e07000
 gpio        1  [   ]   gpio_omap                 |-- gpio@4804c000
 gpio        2  [   ]   gpio_omap                 |-- gpio@481ac000
 gpio        3  [   ]   gpio_omap                 |-- gpio@481ae000
 serial      0  [   ]   omap_serial               |-- serial@44e09000
 serial      1  [   ]   omap_serial               |-- serial@48022000
 i2c         0  [   ]   i2c_omap                  |-- i2c@44e0b000
 i2c         1  [   ]   i2c_omap                  |-- i2c@4802a000
 mmc         0  [   ]   omap_hsmmc                |-- mmc@48060000
 blk         0  [   ]   mmc_blk                   |   `-- mmc@48060000.blk
 timer       0  [   ]   omap_timer                |-- timer@48040000
 timer       1  [   ]   omap_timer                |-- timer@48042000
 timer       2  [   ]   omap_timer                |-- timer@48044000
 timer       3  [   ]   omap_timer                |-- timer@48046000
 timer       4  [   ]   omap_timer                |-- timer@48048000
 timer       5  [   ]   omap_timer                |-- timer@4804a000
 misc        0  [   ]   ti-musb-wrapper           |-- usb@47400000
 usb         0  [   ]   ti-musb-peripheral        |   |-- usb@47401000
 usb         0  [   ]   ti-musb-host              |   `-- usb@47401800
 eth         0  [   ]   eth_cpsw                  `-- ethernet@4a100000
initcall: 8080056d (relocated to bff6756d)
initcall: 8083c6e1 (relocated to bffa36e1)
initcall: 80816b51 (relocated to bff7db51)
initcall: 8080f3e1 (relocated to bff763e1)
initcall: 8080f3cd (relocated to bff763cd)
Now running in RAM - U-Boot at: bff67000
initcall: 8080eef3 (relocated to bff75ef3)
initcall: 8080eef3 (relocated to bff75ef3)
initcall: 8080eef3 (relocated to bff75ef3)
initcall: 8080f4ad (relocated to bff764ad)
initcall: 8080eef3 (relocated to bff75ef3)
initcall: 8080f3a9 (relocated to bff763a9)
NAND:  256 MiB
initcall: 8080f391 (relocated to bff76391)
MMC:   gpio_request_tail: Node 'mmc@48060000', property 'wp-gpios', failed to request GPIO index 0: -2
OMAP SD/MMC: 0
initcall: 8080f349 (relocated to bff76349)
Loading Environment from FAT... MMC: no card present
mmc_init: -123, time 2
initcall: 8080eef3 (relocated to bff75ef3)
initcall: 8080f4b3 (relocated to bff764b3)
initcall: 8080eef3 (relocated to bff75ef3)
initcall: 80816b65 (relocated to bff7db65)
initcall: 8080f33f (relocated to bff7633f)
initcall: 808137e9 (relocated to bff7a7e9)
initcall: 8080208f (relocated to bff6908f)
initcall: 8080eef3 (relocated to bff75ef3)
initcall: 80801b7d (relocated to bff68b7d)
initcall: 8080f335 (relocated to bff76335)
initcall: 8080f31d (relocated to bff7631d)
initcall: 80800721 (relocated to bff67721)
<ethaddr> not set. Validating first E-fuse MAC
initcall: 8080eef3 (relocated to bff75ef3)
initcall: 8080f309 (relocated to bff76309)
Net:   gpio_get_list_count: Node 'ethernet@4a100000', property 'mode-gpios', GPIO count failed: -2
eth0: ethernet@4a100000
Warning: usb_ether MAC addresses don't match:
Address in ROM is          de:ad:be:ef:00:01
Address in environment is  d0:ff:50:56:e6:b3
, eth1: usb_ether
initcall: 8080f301 (relocated to bff76301)
Hit any key to stop autoboot:  2  0 
=> bdinfo
arch_number = 0x00000e05
boot_params = 0x80000100
DRAM bank   = 0x00000000
-> start    = 0x80000000
-> size     = 0x40000000
baudrate    = 115200 bps
TLB addr    = 0xbfff0000
relocaddr   = 0xbff67000
reloc off   = 0x3f767000
irq_sp      = 0xbdf388c0
sp start    = 0xbdf388b0
Early malloc usage: 1ac / 1000
fdt_blob    = 0xbdf388d8
=>

aching u-boot log captured on AM335x EVM (1GB DDR) for your reference.

0 Graziano Rufolo over 5 years ago

Intellectual 445 points

Hi,

I used your u-boot log to compare it with my board.

I noted that my u-boot flow executes setup_reloc funtion (in common/board_f.c) where these debugs are printed (Relocation Offset is: 83f2f000
Relocating to 8ff2f000, new gd at 8deeeed0, sp at 8deeb570) and then no more output are visible. Instead of your log, my u-boot flow does not pass in /common/board_r.c function. In order to understand where the stuck occurs, I put a debug print just before hang() inboard_f.c and in each function after board_f.c (for example jump_to_copy) and also in the first function in /common/board_r.c but nothing is displayed on console.

Reading deeply in code I understand that board level initialization (init_sequence_f and init_sequence_r) is executed in /arc/arm/lib/crt0.S. The relocation should happen between init_sequence_f (where my u-boot stucks after executing setup_reloc) and init_sequence_r. Since no other debug message is shown in board_f.c and board_r.c I suppose that something goes wrong in crt0.S when the flow try to relocate. Below I report the explanation written in crt0.s. Maybe my u-boot hangs between step 4a to 5.

_main execution sequence is:
 *
 * 1. Set up initial environment for calling board_init_f().
 *    This environment only provides a stack and a place to store
 *    the GD ('global data') structure, both located in some readily
 *    available RAM (SRAM, locked cache...). In this context, VARIABLE
 *    global data, initialized or not (BSS), are UNAVAILABLE; only
 *    CONSTANT initialized data are available. GD should be zeroed
 *    before board_init_f() is called.
 *
 * 2. Call board_init_f(). This function prepares the hardware for
 *    execution from system RAM (DRAM, DDR...) As system RAM may not
 *    be available yet, , board_init_f() must use the current GD to
 *    store any data which must be passed on to later stages. These
 *    data include the relocation destination, the future stack, and
 *    the future GD location.
 *
 * 3. Set up intermediate environment where the stack and GD are the
 *    ones allocated by board_init_f() in system RAM, but BSS and
 *    initialized non-const data are still not available.
 *
 * 4a.For U-Boot proper (not SPL), call relocate_code(). This function
 *    relocates U-Boot from its current location into the relocation
 *    destination computed by board_init_f().
 *
 * 4b.For SPL, board_init_f() just returns (to crt0). There is no
 *    code relocation in SPL.
 *
 * 5. Set up final environment for calling board_init_r(). This
 *    environment has BSS (initialized to 0), initialized non-const
 *    data (initialized to their intended value), and stack in system
 *    RAM (for SPL moving the stack and GD into RAM is optional - see
 *    CONFIG_SPL_STACK_R). GD has retained values set by board_init_f().
 *
 * 6. For U-Boot proper (not SPL), some CPUs have some work left to do
 *    at this point regarding memory, so call c_runtime_cpu_setup.
 *
 * 7. Branch to board_init_r().

Unfortunately I am not an assembler expert but I try to undestand what the code do exactly and if it is possible to debug it.

Moreover I have compiled u-boot without debug option. Below the result:

U-Boot 2019.01-svn8 (Mar 21 2021 - 11:13:43 +0100)

CPU: 66AK2Gx-100 SR1.0
Model: Texas Instruments K2G SoC - Hitachi Propulsion Controller (HPC) board
Avvio u-boot entro 1 secondi

Clear entire DDR3 memory to enable ECC
256 MiB
MMC:
Loading Environment from FAT... In:    serial@02530c00
Out:   serial@02530c00
Err:   serial@02530c00
Net:   Could not get PHY for ethernet-mdio: addr 0
undefined instruction
pc : [<a0402ac8>]          lr : [<8ff812f3>]
reloc pc : [<1c4a1ac8>]    lr : [<0c0202f3>]
sp : 8df1d4f0  ip : 00000000     fp : 0c000020
r10: 00000017  r9 : 8df20ec8     r8 : 00000000
r7 : 8df21380  r6 : 00000000     r5 : 04200f00  r4 : 8df21cc0
r3 : a0402ac4  r2 : 0000000a     r1 : 00000000  r0 : 00000000
Flags: nzcv  IRQs off  FIQs off  Mode SVC_32
Code: 6e2ef3ae 3df91fad 7f819e53 ddd3e3df (ff323eff)
Resetting CPU ...

resetting ...

The message "undefined instruction" could be referred to Program Counter; its address is strange, not similar to stack pointer and link register that instead assume address similar to address region after relocation (my DDR memory size is 256 MB, starting at 80000000 with size 10000000, ram top 90000000) but my supposition could be wrong.

Basing on my explanation above, I hope you have any suggestion in order to understand the problem.

Wainting for a feedback.

Regards

Graziano

0 Graziano Rufolo over 5 years ago in reply to Graziano Rufolo

Intellectual 445 points

Hi again,

while waiting your feedback I did a comparison with k2g_evm/k2g_ice u-boot source files with my modified source files used to do the porting of u-boot from my board.

One of the differences is in /board/<vendor>/<myboard>/mux-k2g.h where, at the first step, I defined the all the SoC pad configuration obtained from pinmux tool.

Successively I noted the I defined only the necessary peripherals (usb, qspi, ddr memory) in /arch/arm/dts/keystone-k2g-<myboard>.dts just for enabling usb boot and qspi boot as defined in my project requirement.

Therefore I mapped in mux-k2g.h only the pads related to peripherals defined in keystone-k2g-<myboard>.dts.

That modification allows to resolve the hang and I am able to access in u-boot console.

At the moment I consider the issue resolved. I hope that no other problem arise. In any case it could be interesting understang precisely how these modifications affect u-boot start-up flow. If you have any idea, don't hesitate to share with me.

Next step I have to test QSPI boot (already enabled in evm boards) and load the linux operating system. For other issues not related to this one, I will open new threads.

Regards

Graziano

Processors

Processors forum

66AK2G12: u-boot relocation issue, hangs at "Relocating to"