Skip to contentSkip to conversation

ARM exception vectors -- relocating

U-Boot-Users Curt Brune 3 participants 5 messages Jul 6, 2004 – Jul 7, 2004

lore
Share & tools
lore

Curt Brune

author
#0 lore raw

Hello,

I have a question about relocating the exception vectors for the ARM platform. I am working with cpu/arm720t/start.S and want to use interrupts, but I think I see a problem with the code as it stands now. Consider the following scenario:

1. power on, cpu starts executing from address 0x0, which is located in flash.

2. memsetup.S configures 8MB SRAM to begin at address 0x0 and remaps flash to address 0x01000000.

3. back in start.S u-boot is relocated(copied) from flash to TEXT_BASE = 0x007d0000.

Now the exception vectors are sitting in SRAM @ 0x007d0000 and in flash @ 0x0100000 -- if I want to use interrupts, however, the exception vectors need to be in SRAM at address 0x0.

Currently I have added an additional relocation step to start.S that explicitly copies the vectors from flash to 0x0 (in SRAM) if TEXT_BASE is not equal 0x0 (if TEXT_BASE is equal to 0x0 there is no problem).

Question: Is start.S the correct place to put this, perhaps bracketed with "#ifdef CONFIG_USE_IRQ/#endif"? It seems like a global problem that all arm720t boards that use interrupts would have. Or is memsetup.S a better place for this?

Comments?

Cheers,
Curt

Signature · 6 lines
========================================================================
 Curt Brune           | Phone   1.650.380.2528 |     Managing Principal
 curt at cucy.com        | WWW       www.cucy.com |           Cucy Systems
========================================================================
             Cucy Systems -- Software. Integration. Training.
========================================================================
#1 lore raw
Quoted 3 lines · In message <[email protected]> you wrote:

I have a question about relocating the exception vectors for the ARM platform. I am working with cpu/arm720t/start.S and want to use

...

Quoted 3 lines

Now the exception vectors are sitting in SRAM @ 0x007d0000 and in flash @ 0x0100000 -- if I want to use interrupts, however, the exception vectors need to be in SRAM at address 0x0.

This is one of the areas where the old ARMBoot code hits us hard. They never implemented the relocation correctly.

Quoted 3 lines

Currently I have added an additional relocation step to start.S that explicitly copies the vectors from flash to 0x0 (in SRAM) if TEXT_BASE is not equal 0x0 (if TEXT_BASE is equal to 0x0 there is no problem).

Please submit a patch.

Quoted 1 line

Question: Is start.S the correct place to put this, perhaps bracketed

Yes, it is. See function trap_init() [in cpu/*/start.S] as used in PowerPC systems. trap_init() should be called from board_init_r().

Quoted 1 line

with "#ifdef CONFIG_USE_IRQ/#endif"? It seems like a global problem

No.

Quoted 2 lines

that all arm720t boards that use interrupts would have. Or is memsetup.S a better place for this?

No.

Best regards,

Wolfgang Denk

Signature · 3 lines
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Brain fried - Core dumped
#2 lore raw
Quoted 11 lines · Wolfgang Denk
Quoted 3 lines · In message <[email protected]> you wrote:

I have a question about relocating the exception vectors for the ARM platform. I am working with cpu/arm720t/start.S and want to use

...

Quoted 3 lines

Now the exception vectors are sitting in SRAM @ 0x007d0000 and in flash @ 0x0100000 -- if I want to use interrupts, however, the exception vectors need to be in SRAM at address 0x0.

This is one of the areas where the old ARMBoot code hits us hard. They never implemented the relocation correctly.

Interrupts worked fine in ARMboot. Maybe you broke CONFIG_USE_IRQ when you ripped the code.

Regards,
Marius

Signature · 4 lines
Marius Groeger <[email protected]>           Project Manager
SYSGO AG                      Embedded and Real-Time Software
Voice: +49 6136 9948 0                  FAX: +49 6136 9948 10
www.sysgo.com | www.elinos.com | www.osek.de | www.imerva.com
#3 lore raw
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 3 lines

This is one of the areas where the old ARMBoot code hits us hard. They never implemented the relocation correctly.

Interrupts worked fine in ARMboot. Maybe you broke CONFIG_USE_IRQ when you ripped the code.

Maybe, but I don't think so. At least I see no code in ARMBoot to relocate the exception vectors.

Do you still have access to an ARMBoot based system using interrupts? Do interrupts continue to work when you are running from RAM and erase the flash?

Best regards,

Wolfgang Denk

Signature · 3 lines
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Of course there's no reason for it, it's just our policy.
#4 lore raw
Quoted 10 lines · Wolfgang Denk
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 3 lines

This is one of the areas where the old ARMBoot code hits us hard. They never implemented the relocation correctly.

Interrupts worked fine in ARMboot. Maybe you broke CONFIG_USE_IRQ when you ripped the code.

Maybe, but I don't think so. At least I see no code in ARMBoot to relocate the exception vectors.

Because they can't be. The vectors always sit at address 0000'0000, and thus in the flash. You can only change that by turning on the MMU. So the relocated entry points are loaded to the pc via ldr, the only exception being the RESET vector, obviosly. In other words, interrupts in ARMboot can only be used _after_ relocation.

Quoted 2 lines

Do interrupts continue to work when you are running from RAM and erase the flash?

For the reasons given above, this cannot work if the flash to be programmed sits at 0000'0000.

Regards,
Marius

Signature · 4 lines
Marius Groeger <[email protected]>           Project Manager
SYSGO AG                      Embedded and Real-Time Software
Voice: +49 6136 9948 0                  FAX: +49 6136 9948 10
www.sysgo.com | www.elinos.com | www.osek.de | www.imerva.com