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: ecos redboot compile problem.


It's a good concern, but misplaced in this case for a couple of reasons:

1) In general eCos does not enable MMU-style memory protection.  Having said
that, it is possible/likely that certain regions of non-existent memory may
be flagged as "inaccessible" using whatever hardware is available (the MMU
on the ARMs, the BAT registers on the PowerPC's etc...), but eCos does not
implement general memory protection such as is found in Linux, or
occasionally, Windows.

2) Even if eCos did flag certain regions of memory as "readonly" (which it
would do for the internal SRAM of the OMAP), the only time that those first
two locations of SRAM are written are immediately following a reset --
before any such protections would be enabled (which they are not).

So, in this case, you may rest easily :-)

--wpd


> -----Original Message-----
> From: Beymer, Mike [mailto:Mike dot Beymer at itron dot com] 
> Sent: Friday, April 25, 2003 4:27 PM
> To: Doyle, Patrick
> Cc: eCos Discussion
> Subject: RE: [ECOS] ecos redboot compile problem.
> 
> 
> So I take it ecos isn't invoking memory protection based on this?
>  My thought for a infinite loop was if this code was in 
> protected memory
> when we attempt to access that area with a write it will generate a
> data abort exception and the value would not be changed. When we 
> return from the exception an run again we would again find 
> the same values.
> but I may be just blowing wind.
>  -Mike  
> 
> -----Original Message-----
> From: Doyle, Patrick [mailto:WPD at dtccom dot com]
> Sent: Friday, April 25, 2003 11:45 AM
> To: Beymer, Mike
> Cc: eCos Discussion
> Subject: RE: [ECOS] ecos redboot compile problem.
> 
> 
> > Another point just discovered, 
> >     An arm-elf-objdump -h  of redboot.img reveals .rom_vectors as 
> >                  CONTENTS, ALLOC, LOAD, READONLY, CODE
> >        arm-elf-objdump -h of redboot-SRAM.out show .rom_vectors as
> >                  CONTENTS, ALLOC, LOAD, CODE
> > 
> I don't know why it changed from when I created 
> redboot-SRAM.out to now, but
> it doesn't matter.  The READONLY attribute is just a flag to loader.
> RedBoot, at startup just scribbles to locations in SRAM 
> (which is writable,
> despite what hints might be in some files somewhere on the 
> host computer),
> so why do you think that is putting you in an infinite loop?
> 
> >   if the READONLY means that code is not allowed to be 
> > changed i.e. protected
> >   space. Then trying to rewrite the 0x12345678 and 0x87654321 
> > would fail and 
> >   put me into an infinite loop. How do I get this READONLY 
> > turned off??
> 
> --wpd
> 
> 
> 
> 
> This message was scanned for viruses.
> 
> 
> 

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