Skip to contentSkip to conversation

arm: timer_init() and bss (relocation)

U-Boot Alexander Holler 4 participants 5 messages Jan 22, 2011

lore
Share & tools
lore
#0 lore raw

Hello,

because I still have problems where I think the problem is the relocation, I've had a look at some timer code.

E.g. in arch/arm/cpu/arm926ejs/kirkwood/timer.c on top there is

struct kwtmr_registers *kwtmr_regs = (struct kwtmr_registers *)KW_TIMER_BASE;

which is used in timer_init().

In arch/arm/cpu/armv7/omap-common/timer.c we have

static struct gptimer *timer_base = (struct gptimer *)CONFIG_SYS_TIMERBASE;

which is used in timer_init() too.

(I assume similiar code is used in more files, I've just had a look at those two.)

timer_init() is called in board_init_f() through init_sequence, that means before relocation.

Did I miss something, or I'm right that this is a problem because those two variables are stored in bss but are accessed before relocation?

Regards,

Alexander

#1 lore raw
Quoted 18 lines · Alexander Holler

Hello,

because I still have problems where I think the problem is the relocation, I've had a look at some timer code.

E.g. in arch/arm/cpu/arm926ejs/kirkwood/timer.c ?on top there is

struct kwtmr_registers *kwtmr_regs = (struct kwtmr_registers *)KW_TIMER_BASE;

which is used in timer_init().

In arch/arm/cpu/armv7/omap-common/timer.c we have

static struct gptimer *timer_base = (struct gptimer *)CONFIG_SYS_TIMERBASE;

which is used in timer_init() too.

Quoted 9 lines

(I assume similiar code is used in more files, I've just had a look at those two.)

timer_init() is called in board_init_f() through init_sequence, that means before relocation.

Did I miss something, or I'm right that this is a problem because those two variables are stored in bss but are accessed before relocation?

These are both initialized data so they do not go in bss.

Quoted 8 lines

Regards,

Alexander
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

#2 lore raw

Am 22.01.2011 07:38, schrieb John Rigby:

Quoted 22 lines · Alexander Holler
Quoted 21 lines

Hello,

because I still have problems where I think the problem is the relocation, I've had a look at some timer code.

E.g. in arch/arm/cpu/arm926ejs/kirkwood/timer.c on top there is

struct kwtmr_registers *kwtmr_regs = (struct kwtmr_registers *)KW_TIMER_BASE;

which is used in timer_init().

In arch/arm/cpu/armv7/omap-common/timer.c we have

static struct gptimer *timer_base = (struct gptimer *)CONFIG_SYS_TIMERBASE;

which is used in timer_init() too.

(I assume similiar code is used in more files, I've just had a look at those two.)

Quoted 7 lines
Quoted 6 lines

timer_init() is called in board_init_f() through init_sequence, that means before relocation.

Did I miss something, or I'm right that this is a problem because those two variables are stored in bss but are accessed before relocation?

These are both initialized data so they do not go in bss.

Correct, I should have a look into u-boot.map before writing this mail. Thanks for the pointer.

But this leads me to the question what happens with the stuff in the data section. Seems I should have again a look at the lowlevel stuff to understand that.

Thanks,

Alexander

#3 lore raw

Dear Alexander Holler,

Quoted 29 lines

Am 22.01.2011 07:38, schrieb John Rigby:

Quoted 28 lines · Alexander Holler
Quoted 27 lines

Hello,

because I still have problems where I think the problem is the relocation, I've had a look at some timer code.

E.g. in arch/arm/cpu/arm926ejs/kirkwood/timer.c on top there is

struct kwtmr_registers *kwtmr_regs = (struct kwtmr_registers *)KW_TIMER_BASE;

which is used in timer_init().

In arch/arm/cpu/armv7/omap-common/timer.c we have

static struct gptimer *timer_base = (struct gptimer *)CONFIG_SYS_TIMERBASE;

which is used in timer_init() too.

(I assume similiar code is used in more files, I've just had a look at those two.)

timer_init() is called in board_init_f() through init_sequence, that means before relocation.

Did I miss something, or I'm right that this is a problem because those two variables are stored in bss but are accessed before relocation?

Quoted 8 lines
Quoted 1 line

These are both initialized data so they do not go in bss.

Correct, I should have a look into u-boot.map before writing this mail. Thanks for the pointer.

But this leads me to the question what happens with the stuff in the data section. Seems I should have again a look at the lowlevel stuff to understand that.

Intuitively (without looking at the code) I would think that CONST DATA is ok,
but non const, initialized data cannot work because it is not initialized before relocation...

Best Regards,
Reinhard

#4 lore raw

Le 22/01/2011 08:21, Reinhard Meyer a ?crit :

Quoted 8 lines
Quoted 3 lines

But this leads me to the question what happens with the stuff in the data section. Seems I should have again a look at the lowlevel stuff to understand that.

Intuitively (without looking at the code) I would think that CONST DATA is ok,
but non const, initialized data cannot work because it is not initialized before relocation...

To be precise:

1. const data are readable before and after relocation.

2. non-const initialized data are readable only until relocated, and then writable as well.

3. BSS data cannot and must not be used at all until relocated, and are then zeroed out before board_init_r() starts.

Quoted 2 lines

Best Regards,
Reinhard

Amicalement,

Signature · 1 line
Albert.