This is the mail archive of the ecos-discuss@sourceware.org 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: During testing


>>>>> "Augusto" == Augusto Salazar <elpirata2000@yahoo.com> writes:

    Augusto> I found something strange, I was having a problem with
    Augusto> the redboot in my flash, it was only showing me
    Augusto> 0x02000000 as my RAM size, I spend several days compiling
    Augusto> RAM versions of redboot looking for a way to specify the
    Augusto> 64 mb, with no luck.

    Augusto> What I did is to load into flash the redboot and it show
    Augusto> me the 64 mb, I checked back the binaries that I had
    Augusto> tried and this time the show me the 64 mb also.

    Augusto> From this I assume that the RAM version of redboot takes
    Augusto> some configuration from the redboot that is in the flash,
    Augusto> is that correct?? What other configurations does it
    Augusto> take?? For example, boot script?

First, please be careful with your units. mb could mean millibits (not
very useful) or megabits (Mb, commonly used when describing
communication hardware). I suspect you actually meant 64 megabytes or
MB. Mixing up units can cause lots of confusion.

On most platforms the memory size is statically defined in a handful
of files in the appropriate platform HAL package. Find the platform
HAL appropriate for your target hardware and look for an
include/pkgconf directory. This will contain pairs for .ldi and .h
files, one pair for each startup type. If your version of the hardware
has different memory sizes from the standard boards then these files
will need changing. In the .ldi file there will be a MEMORY section
defining the size of each type of memory. In the .h file there will be
definitions for e.g. CYGMEM_REGION_ram_SIZE which will also need
changing, and the same number will be used later on in that file to
specify the heap size. The exact details will depend on the target
hardware.

On some processors additional work may be needed in the startup code.
For example if the processor has an MMU then that will be initialized
during startup, and chances are that only the standard amount of
memory will be mapped into the address space. Again the details will
depend on the target hardware, you will need to carefully read through
the startup code to see what might need changing. This is not
necessarily straightforward as the startup code may be spread over
several different places, e.g. the architectural HAL for the main code
but using processor-specific and board-specific macros from other HAL
packages. Obviously if you make incorrect changes to the startup code
then your board may no longer boot correctly or at all, so do ensure
you have some means of recovery when things go wrong.

Note that typically RedBoot will just use the .ldi and .h settings. It
will not verify that all of the memory really works as expected, i.e.
that the MMU tables etc. are set up correctly.

A small number of targets do support dynamic memory sizing. For
example on a PC target the actual memory size is obtained from the
BIOS. This is accomplished by an optional HAL_MEM_REAL_REGION_TOP
macro. You can search through the install/include subdirectory of a
build tree to see if and how this is defined, but chances are that it
won't be and that instead static memory sizing is used. I am not aware
of any target where a RAM RedBoot would pick up the memory size from
flash configuration data in the way you describe.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts



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


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