Re: [ECOS] Confused with RAM layout, help~

[Yanjun Yang <yangyj at pku dot edu dot cn>]

Thanks for your information.

Because I run RedBoot from RAM, I disabled the initial start up code
from hal_platform_setup.h.  Maybe the older RedBoot's memory map messes
up with the newer one's. However, if I do some remap, will the ROM
monitor get confused?

Here is my _RAM.h and _RAM.ldi, may they still have problems.


#ifndef __ASSEMBLER__
#include <cyg/infra/cyg_type.h>
#include <stddef.h>

#endif
#define CYGMEM_REGION_ram (0xA0000000)
#define CYGMEM_REGION_ram_SIZE (0x4000000)
#define CYGMEM_REGION_ram_ATTR (CYGMEM_REGION_ATTR_R | CYGMEM_REGION_ATTR_W)
#ifndef __ASSEMBLER__
extern char CYG_LABEL_NAME (__heap1) [];
#endif
#define CYGMEM_SECTION_heap1 (CYG_LABEL_NAME (__heap1))
#define CYGMEM_SECTION_heap1_SIZE (0xf00000 - (size_t) CYG_LABEL_NAME (__heap1))
#ifndef __ASSEMBLER__
#endif



#include <cyg/infra/cyg_type.inc>

MEMORY
{
    vrom : ORIGIN = 0x00000000, LENGTH = 0x1000
    ram  : ORIGIN = 0xA0000000, LENGTH = 0x4000000
}

SECTIONS
{
    SECTIONS_BEGIN
    SECTION_fixed_vectors (vrom, 0x20, LMA_EQ_VMA)  // virtual ROM addr, but really in physical ram
    SECTION_rom_vectors (ram, 0xa0020000, LMA_EQ_VMA)
    SECTION_text (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fini (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata1 (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fixup (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_gcc_except_table (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_data (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_bss (ram, ALIGN (0x4), LMA_EQ_VMA)
    CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
//    CYG_LABEL_DEFN(__pci_window) = 0xf00000; . = CYG_LABEL_DEFN(__pci_window) + 0x100000;
    SECTIONS_END
}


On Fri, Dec 17, 2004 at 09:51:38AM +0100, Andrew Lunn wrote:
> On Fri, Dec 17, 2004 at 01:07:44PM +0800, Yanjun Yang wrote:
> 
> > I got an xscale based system from Intel and want to port the most
> > recent RedBoot to support this board. Since Intel provided an early
> > version RedBoot with source I thought the task will be easy. But
> > when the new RedBoot banner came out, it issued a line about RAM as
> > follow:
> > 
> > RAM: 0xa0000000-0xa4000000, [0xa0043d48-0x00eb1000] available
> 
> This 0x00eb1000 probably shows that you have your heap in a funy
> location. Please show us your *_ROM.ldi and *_ROM.h file from the hal
> include/pkgconf directory.
> 
> > The older working version RedBoot just gives:
> > 
> > RAM: 0xa0000000-0xa4000000
> > 
> > There was also other problems, but I think this must be solved first.
> > 
> > The variant I use is PXA2X0, and I heard in this list that ARM
> > always assume RAM is started from 0x00000000, but that's where my
> > FLASH started.
> 
> After boot the flash and RAM are normally remapped so that RAM is at
> 0x0 and the FLASH is somewhere higher. If looks like redboot is
> printing the unmapped addresses. 
>  
> > BTW, I have four E28F128J3A devices to form 64M of 32 bits memory,
> > but only the first two can be recognized when I set
> > CYGNUM_FLASH_BASE as 0x00040000 (any block boundery but the first
> > one), and any access to the FLASH data will cause some memory
> > violation.
> 
> You need to give the address the flash is mapped to, not the physical
> address. I suggest you take a closer look at the start up code for
> your HAL and see where it remaps the various types of memory to. Its
> probaby using the MMU to do this.
> 
>         Andrew
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 

-- 
Yanjun Yang
School of Electronics Engineering and Computer Science
Peking University
Email: yangyj@pku.edu.cn

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