This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ARM ROM regions and interrupt vectors


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]