[ECOS] ARM 920t queries with eCos

[Michael Anburaj]

>"When system is booting MMU is off and bootROM is mapped at address 0.
>Therefore bootMonitor (the boot loader) gets executed. After systems boots,
>MMU is turned on and a remapping happens. During remapping, RAM is mapped 
>to
>address 0 and bootROM maps to somewhere else

Yes.

>(I suppose this should be EBI reason. Actully it is already there, at boot 
>time this is aliased to
>bottom). The address I see in target.ld reflact address after remapping has
>taken place (MMU on)."

Can you explain me, How the RAM gets to 0x0000.0000 during boot time? Is it 
by some Hardware means in the EBI (like in Atmel ARM chips)?

There are several advantages in having RAM mapped to VMA 0x0.
Since you mentioned about the bootMonitor; Each third party boot monitor 
(like Angel) might have its own method of dealing with the HW vectors (0x00 
~ 0x20). It would be very difficult for eCOS or any other generic piece of 
SW for that matter to work with each of these monitors. It might be a bad 
idea to completely eliminate the onboard monitor (but platforms of different 
archs do), so we keep the monitor until Redboot starts up & after which 
complete control over the HW vectors is assumed by redboot by ensuring 100% 
code path within Redboot/eCOS. If we have RAM at 0x0, then Reboot can fix 
all the HW vectors with its own code, there by eliminating the monitor 
completely. The onboard third party monitor gets dummied out at this point 
<after Redboot starts>.

If the RAM is at 0x0 even before Redboot starts, then VMA 0x0000.0000 will 
or can be mapped to physical 0x0 (RAM).

Cheers,
-Mike.

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail


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