This is the mail archive of the ecos-bugs@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]

[Bug 1000025] New: RedBoot can't deal with non-contiguous memory


http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000025

           Summary: RedBoot can't deal with non-contiguous memory
           Product: eCos
           Version: CVS
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: normal
         Component: RedBoot
        AssignedTo: gary@mlbassoc.com
        ReportedBy: jifl@ecoscentric.com
         QAContact: ecos-bugs@sources.redhat.com


(I can't find an existing bug for this even though this is a long-standing
issue). RedBoot doesn't support non-contiguous regions of memory. This is found,
for example, on the PC (0x0-0xa000 and then 0x10000 up) or the EB40a (internal
vs. external SRAM). People have had to play MMU tricks to work around this
limitation.

The option CYGSEM_REDBOOT_VALIDATE_USER_RAM_LOADS was essentially a hack to work
around this, but can't report a diagnostic if loading via x/y modem since the
x/ymodem prog on the host will have the terminal.

The solution would ideally allow future fit-in with memory layout scheme... it's
not brill, but probably one of the more future-proof ways would be using a CDL
option which perhaps gives an array initializer of the form {{startAddress1,
endAddress1}, {startAddress2,endAddress2},{NULL,NULL}} that could be used by C.
Then in future, it wouldn't be that difficult for something to go over this and
convert it to whatever MLTv2 really needs as it will be well formed.



------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.


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