[ECOS] ARM ROM regions and interrupt vectors

[ECOS] ARM ROM regions and interrupt vectors

[Patrick Doyle]

I am missing something...

I am confused by the memory layout memory files for the ARM platforms.  Of
the approximately 20 platforms in the HAL directory, only one (iq80310)
places ROM at address 0.  From my undestanding of the ARM architecture, the
processor's reset vector is at address 0.  So, I expected to find all of
them with ROM at address 0.  I understand that some ARM cores have a
coprocessor register which can be used to remap the interrupt vectors.  I
also understand that some ARM cores have MMU's, and can probably remap the
interrupt vectors via the MMU.  But I am confused about how the processor's
listed in the ARM tree come out of reset.

Is it common practice that ARM boards have some sort of boot ROM that is
mapped to address 0 and is not (or can not be) overwritten by RedBoot?  As I
said at the start of this email, I am missing something here.  How does
RedBoot get control of the processor if it vectors to address 0 at reset,
but no RedBoot code exists at address 0?

--wpd


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] ARM ROM regions and interrupt vectors

[Mark Salter]

>>>>> Patrick Doyle writes:

> I am missing something...
> I am confused by the memory layout memory files for the ARM platforms.  Of
> the approximately 20 platforms in the HAL directory, only one (iq80310)
> places ROM at address 0.  From my undestanding of the ARM architecture, the
> processor's reset vector is at address 0.  So, I expected to find all of
> them with ROM at address 0.  I understand that some ARM cores have a
> coprocessor register which can be used to remap the interrupt vectors.  I
> also understand that some ARM cores have MMU's, and can probably remap the
> interrupt vectors via the MMU.  But I am confused about how the processor's
> listed in the ARM tree come out of reset.

> Is it common practice that ARM boards have some sort of boot ROM that is
> mapped to address 0 and is not (or can not be) overwritten by RedBoot?  As I
> said at the start of this email, I am missing something here.  How does
> RedBoot get control of the processor if it vectors to address 0 at reset,
> but no RedBoot code exists at address 0?

I don't know of any boards which don't map ROM at address zero for booting.
Early in the boot process, RedBoot will either use some hw mechanism to
remap the ROM or remap the ROM with the MMU. The code that runs before this
remap occurs must be position independent.

--Mark

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

RE: [ECOS] ARM ROM regions and interrupt vectors

[Patrick Doyle]

> -----Original Message-----
> From: Mark Salter [mailto:msalter@redhat.com]
> Sent: Tuesday, November 19, 2002 7:51 AM
> To: wpd@delcomsys.com
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] ARM ROM regions and interrupt vectors
> 
> 
> >>>>> Patrick Doyle writes:
> > Is it common practice that ARM boards have some sort of boot ROM that is
> > mapped to address 0 and is not (or can not be) overwritten by RedBoot?  As I
> > said at the start of this email, I am missing something here.  How does
> > RedBoot get control of the processor if it vectors to address 0 at reset,
> > but no RedBoot code exists at address 0?
> 
> I don't know of any boards which don't map ROM at address zero for booting.
> Early in the boot process, RedBoot will either use some hw mechanism to
> remap the ROM or remap the ROM with the MMU. The code that runs before this
> remap occurs must be position independent.
> 
> --Mark
Thanks... Now that I know what to look for, I can see how the e7t platform does it.

--wpd


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss