I'm not sure I understand how this would work. Switching my board into RAM boot mode means that it maps internal RAM (0x20000000) to 0x00000000. On reset it always start execution from 0x0 but will in this case find nothing there to execute. On the other hand if booting in the boards normal mode (USER mode with flash mapped to 0x0) it will boot fine but when your app wants to change the vector at 0x18 it, as you pointed out, fail to do so. Jumping into high address mapping (by that I understand that when an exception/interrupt occurs all the instructions in the vector at 0x0 jump to another vector in RAM) is what I want to do but still haven't quite worked out where to do - presumably by changing the vector setup of Redboot.
m@ -----Original Message----- From: Andrew Lunn [mailto:[EMAIL PROTECTED] Sent: 16 August 2005 16:21 To: Matt Sartori Cc: eCos Disuss Subject: Re: [ECOS] interrupt/virtual vectors confusion > >You probably need to change this so that it runs in user flash boot > >mode. If you don't have RAM at 0x0 there is no way to change the > >vectors. I expect if you run the eCos tests which test interrupts they > >will fail. > > > > And booting in RAM mode Redboot would still work because the first thing > it does is copy itself into RAM? My current Redboot setup is running in > ROM mode (CYG_HAL_STARTUP == ROM). Presumably that would need changing > to ROMRAM then? It should still be able to run in ROM. It just need to take care when the ROM is remapped out from 0x0 that it is already running from the mapping at the higher address space. You will find the existing ARM platforms do this. What is actually quite common is that the reset vector jumps straight into the high address mapping. Andrew -------------------------------------------------------------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender or postmaster ([EMAIL PROTECTED]) and delete the material from any computer. Although we routinely screen for viruses, addressees should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments. Our Company's email policy is to permit incidental personal use. If this email is of a personal nature, it must not be relied upon as expressing the views or opinions of the company. Visit out website at www.hanoverdisplays.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
