From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Edwards To: Bart Veer Cc: james_ch1@sina.com, ecos-discuss@sources.redhat.com Subject: Re: [ECOS] ecos start in ram Date: Fri, 16 Feb 2001 07:48:00 -0000 Message-id: <20010216095229.A880@visi.com> References: <000801c097b2$ac8760a0$c408aa0a@inc.inventec> <200102161432.f1GEWNJ04541@sheesh.cambridge.redhat.com> X-SW-Source: 2001-02/msg00285.html On Fri, Feb 16, 2001 at 02:32:23PM +0000, Bart Veer wrote: > > James> now I am porting eCos to my test board (based > James> ARM7TDMI), the ROM address is 0x0 and the RAM address is > James> 0xc000000, but in ecos the RAM address is 0x0, so how to > James> config memory layout to run Redboot and eCos? I also think > James> the vectors.S file should be changed, will you tell any? For a while I ran eCos with ROM at 0x0. It's a pain. You'll have to modify vectors.S to move the "fixed vectors" stuff somewhere else (the vsr_table is the part that seemed to matter). Then you'll have to modify the routines that write to the vsr_table -- last time I looked, some of them assumed it was at a particular hard-wired address. You'll also have to set up your ROM so that the interrupt vectors (except for reset) point to code that does indirect jumps via a jump table in RAM. NB: This table is different than the vsr_table in the fixed vectors sections. Then you need to modify the startup code in vectors.S so that it fills in this table instead of of locations at 0x00-0x20. The really painful part is that you have modified "architecture" HAL files that aren't part of your platform HAL. Updating to newer versions of eCos requires re-doing the same changes again to the architecture HAL files. > IIRC on some ARM processors you normally need RAM at location > 0x0, because that is where interrupt vectors etc. are held. You > also need ROM at location 0x0 because bootstraps happen from > that address. In the absence of an MMU, the normal way to > resolve this is to have a memory remap facility: on power up > there is ROM at location 0x0, so bootstrap can proceed; early > on during the bootstrap, the remap switch is toggled and the > memory map changes; the ROM moves somewhere else in memory, and > there is now RAM at location 0x0 so that the interrupt vectors > etc. can be updated. Re-mapping is _far_ easier than what I previously described. You can still run with your code in ROM if you want to, but it's easier debugging if code is in RAM. > So for a typical eCos application, the RAM might be at > 0xC0000000 immediately after power-up but it will be remapped > to 0x0 early on. Hence the eCos memory map will have RAM at > 0x0. > > The exact details are of course hardware-specific, and will > have to be addressed by your platform port. If you don't have a way to remap memory, make the hardware guys add a way. It only takes a few gates and a flip-flop. They've probably got more than enough extra capacity in that PLD. -- Grant Edwards grante@visi.com