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: Variable RAM Sizing


Thanks, exactly what I was looking for.
Jay

-----Original Message-----
From: Jonathan Larmour [mailto:jifl@eCosCentric.com]
Sent: Tuesday, February 04, 2003 6:15 PM
To: Jay Foster
Cc: 'ecos-discuss@sources.redhat.com'
Subject: Re: [ECOS] Variable RAM Sizing


Jay Foster wrote:
> I have looked in the documentation and searched the source, but have not
> been able to determine how eCos knows how much RAM is actually present.
My
> platform can have different amounts of DRAM installed on it.  My memory
> layout files define the largest DRAM size that will occur.  This provides
> the definitions CYGMEM_REGION_ram_SIZE and CYGMEM_REGION_heap1_SIZE.
> However, they are only correct when the maximum amount of DRAM is
installed.

You should set the ram size in the linker to be the size you want apps to 
successfully link with. Some people might set that to the minimum amount 
of RAM, not the maximum, in order to force a link error if it _may_ not
fit.

> I found the CYGINT_HAL_ARM_MEM_REAL_REGION_TOP CDL definition and used it
to
> map to the function, hal_arm_mem_real_region_top(), located in my platform
> specific code.  This function returns the true top of RAM, based on the
> hal_dram_size variable, which is initialized by my hal_platform_setup.h
> file.

I believe nothing uses hal_dram_size itself. Only the 
HAL_MEM_REAL_REGION_TOP macro.

> Looking at the code, redboot is the only "application" that makes use of
> this.  How does eCos figure out how much RAM is really there, and how big
> the heap really is?  I can find no evidence that it uses the
> CYGMEM_REGION_ram_xxx or CYGMEM_REGION_heap1_xxx definitions either.  Does
> it just use its own memory sizing algorithm and start at the end of the
.bss
> section?

No, more magic is required than just the C preprocessor can deal with. See 
services/memalloc/common/current/src/heapgen.tcl. And in a built tree look 
in services/memalloc/common/current/heaps.cxx and heaps.hxx for the result.

Jifl
-- 
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


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

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