[U-Boot-Users] ARM exception vectors -- relocating

[U-Boot-Users] ARM exception vectors -- relocating

[Curt Brune]

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

-- 

========================================================================
 Curt Brune           | Phone   1.650.380.2528 |     Managing Principal
 curt at cucy.com        | WWW       www.cucy.com |           Cucy Systems
========================================================================
             Cucy Systems -- Software. Integration. Training.
========================================================================

[U-Boot-Users] ARM exception vectors -- relocating

[Wolfgang Denk]

In message <20040706102730.B25870@cucy.com> 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
...
> 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.

> 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.

> 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().

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

No.

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

No.

Best regards,

Wolfgang Denk

-- 
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

[U-Boot-Users] ARM exception vectors -- relocating

[Marius Groeger]

On Tue, 6 Jul 2004, Wolfgang Denk wrote:

> In message <20040706102730.B25870@cucy.com> 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
> ...
> > 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

-- 
Marius Groeger <mgroeger@sysgo.com>           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

[U-Boot-Users] ARM exception vectors -- relocating

[Wolfgang Denk]

In message <Pine.LNX.4.56.0407070943450.1753@mag.sysgo.com> you wrote:
> 
> > 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

-- 
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.

[U-Boot-Users] ARM exception vectors -- relocating

[Marius Groeger]

On Wed, 7 Jul 2004, Wolfgang Denk wrote:

> In message <Pine.LNX.4.56.0407070943450.1753@mag.sysgo.com> you wrote:
> >
> > > 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.

> 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

-- 
Marius Groeger <mgroeger@sysgo.com>           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

[U-Boot-Users] ARM exception vectors -- relocating

[Friedrich, Lars]

>> 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.

I think you fail to understand the problem.

IF the flash memory is mapped to an area != 0x0 AND
the SDRAM memory is mapped to 0x0 BUT the _TEXT_BASE does not
start at 0x0, THEN the exception vectors will not work,
as there is no proper handling of this case in the current code.

All other issues you have raised are correct, but fail to recognize
the situation.

Best regards,
Lars Friedrich

-- 

[U-Boot-Users] ARM exception vectors -- relocating

[Marius Groeger]

On Wed, 7 Jul 2004, Friedrich, Lars wrote:

> >> 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.
>
> I think you fail to understand the problem.
>
> IF the flash memory is mapped to an area != 0x0 AND
> the SDRAM memory is mapped to 0x0 BUT the _TEXT_BASE does not
> start at 0x0, THEN the exception vectors will not work,
> as there is no proper handling of this case in the current code.
>
> All other issues you have raised are correct, but fail to recognize
> the situation.

You are right, but I wasn't trying to. :-) I was merely clarifying how
things were done in ARMboot, when things still worked consistently
(granted, for a much smaller set of machines/archs.) In other words,
it is not ARMboot's fault that you're running into problems. I don't
know how U-Boot does it today, and specifically, how your board
configures things.

I agree this is not much help for you and I apologise for the noise.

Regards,
Marius

-- 
Marius Groeger <mgroeger@sysgo.com>           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