U-Boot relocate_code problem

Davi Evangelista

Hello!

I'm using an old version of U-Boot (U-Boot-2013.01.01-amsdk-06.00.00) with an AM332 processor. Also, my board boots from a NAND device.

To reduce the boot time in our board, I'm trying to skip the relocation U-Boot does once it starts running from DRAM.

The reason is: U-Boot takes 86 ms to relocate itself. As the whole U-Boot takes 921 ms to start the Kernel (I'm not counting the SPL load time), the relocation represents 9.3% of the time...

As U-Boot is already running in the RAM I thought this relocation is not necessary in my board, but removing it seems to bring a lot of issues...

The document README.arm-relocation says that one can skip this relocation if the CONFIG_SYS_TEXT_BASE is the relocation address calculated in board_init_f (not with this works, though). After I compiled U-Boot with this change, the relocation did skip, but I incur in a data abort interruption. I'm pasting the console output below:

U-Boot SPL 2013.01.01 (Mar 19 2015 - 16:00:23)

U-Boot 2013.01.01 (Mar 19 2015 - 16:00:23)

DRAM: 64 MiB
NAND: nand: error: Unable to find NAND settings in GPMC Configuration - quitting
4194303 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using UCC3's environment

data abort

MAYBE you should read doc/README.arm-unaligned-accesses

pc : [<83f98fc8>] lr : [<83f7a6ac>]
sp : 83e6de98 ip : 00000000 fp : 83e6df2c
r10: 00000000 r9 : 83fa93e4 r8 : 83e6df60
r7 : 83f72f38 r6 : 83fad440 r5 : 83e6e000 r4 : 7c08d0c8
r3 : 00000000 r2 : 7c08d0c8 r1 : 00000000 r0 : 07de0f38
Flags: nzCv IRQs off FIQs on Mode SVC_32
Resetting CPU ...

resetting ...

And these messages repeats in a loop. I looked up the file README.arm-unaligned-accesses and with objdump I found that memset is causing the problem:

80128fbc: ea000001 b 80128fc8 <memset+0x38>

This instruction is also inside memset function... Maybe the root problem is the fact the NAND chip is not being recognized anymore, but I'm still debugging the whole thing.

Anyway, as my board boots perfectly fine if I keep CONFIG_SYS_TEXT_BASE intact, could anyone share some thoughts on what I need to do in order to successfully skip the relocation in arch/arm/cpu/armv7/start.S?

Thanks

DAVI

over 9 years ago

0 Biser Gatchev-XID over 9 years ago

TI__Guru**** 393215 points

Hi Davi,

I will forward this to the SW team.

0 Yordan Kovachev over 9 years ago in reply to Biser Gatchev-XID

TI__Guru**** 161600 points

Hi Davi,

I apologize for the delayed response.

All sources I've found during my research point that changing CONFIG_SYS_TEXT_BASE=<relocation address> is the proper way to skip u-boot code relocation.

I tried changing the CONFIG_SYS_TEXT_BASE to be equal to relocation address, on both BeagleBone Black & AM335x Starter Kit (both platforms run SDK8.0, which uses u-boot 2014.07-00107-gd28f2b9-dirty). As a result I get the following logs:

STARTER KIT:

U-Boot 2014.07-00107-gd28f2b9-dirty (Mar 23 2015 - 14:09:45)

##### SYS_TEXT_BASE is 0x8F741000#####U-Boot code: 8F741000 -> 8F7A467C BSS: -> 8FFEFFE0
I2C:   ready
DRAM: Monitor len: 008AEFE0
Ram size: 10000000
Ram top: 90000000
TLB table from 8fff0000 to 8fff4000
Reserving 8891k for U-Boot at: 8f741000
Reserving 16512k for malloc() at: 8e721000
Reserving 80 Bytes for Board Info at: 8e720fb0
Reserving 184 Bytes for Global Data at: 8e720ef8

RAM Configuration:
Bank #0: 80000000 256 MiB

DRAM: 256 MiB
New Stack Pointer is: 8e720ed0
Relocation Offset is: 00000000
Relocating to 8f741000, new gd at 8e720ef8, sp at 8e720ed0
Now running in RAM - U-Boot at: 8f741000

BeagleBone Black:

U-Boot 2014.07-00107-gd28f2b9-dirty (Mar 23 2015 - 14:05:06)

##### SYS_TEXT_BASE is 0x9F741000#####U-Boot code: 9F741000 -> 9F7A467C BSS: -> 9FFEFFE0
I2C:   ready
DRAM: Monitor len: 008AEFE0
Ram size: 20000000
Ram top: A0000000
TLB table from 9fff0000 to 9fff4000
Reserving 8891k for U-Boot at: 9f741000
Reserving 16512k for malloc() at: 9e721000
Reserving 80 Bytes for Board Info at: 9e720fb0
Reserving 184 Bytes for Global Data at: 9e720ef8

RAM Configuration:
Bank #0: 80000000 512 MiB

DRAM: 512 MiB
New Stack Pointer is: 9e720ed0
Relocation Offset is: 00000000
Relocating to 9f741000, new gd at 9e720ef8, sp at 9e720ed0
Now running in RAM - U-Boot at: 9f741000

My boards do not experience any errors due to changing the CONFIG_SYS_TEXT_BASE address, & u-boot is loaded normally. Therefore I think your error is not related to skipping u-boot relocation, but more likely as you stated some other (nand related) configurations.

Best Regards,
Yordan

0 Davi Evangelista over 9 years ago in reply to Yordan Kovachev

Expert 1090 points

Hello Yordan,

After your reply, I looked up the differences between my version of U-Boot and the one you used regarding the early init of U-Boot. I noticed the initialization process changed quite a lot, even the ld script u-boot.lds mapped the sectors of u-boot.img differently.

I started suspecting my problems were due to some error related to the image sectors since after I skipped the relocation, problems started happening. After I merged the new assembly code into my version, keeping the relocation code intact (the newer didn't work, I had to update the sector names it uses...), I successfully skipped the relocation as intended.

As my code now is something between the two versions (SDK 6 and 8), more like a Frankenstein of sorts, my solution may be restrict to my environment and board, but anyhow I wanted to let you know that I was able to solve the issue.

Thanks for sharing that it did work in the latest version. Right now, it's impossible for us to fully update our U-Boot, but small changes we can handle.

Regards,

DAVI

0 Yordan Kovachev over 9 years ago in reply to Davi Evangelista

TI__Guru**** 161600 points

Hi Davi,

Glad to hear you have success with solving your problem.

Also many thanks for sharing the information. This will be useful to other community members with similar problems.

Best Regards,
Yordan

Processors

Processors forum

U-Boot relocate_code problem