I have a custom platform based on Intel PXA255 Xscale processor which
is normally shipped with 64Mb of SDRAM. All of the .BIB files are set
up to reflect this and the platform is stable using this 64Mb setup.

The platform can be expanded with a further 64Mb of SDRAM. Although
this is physically contiguous with the standard fit memory, it is
necessary that the WinCE image can work on both the 64Mb device, or
the 128Mb device.

I am trying to implement the OEMGetExtensionDRAM() to inform the
kernel of the existence of the (tested as working) extra 64Mb, if it
is present.

The kernel hangs very quickly with the following output:

Loaded symbols for 'E:\WINCE420\PUBLIC\TESTV5\RELDIR\CT4000_ARMV4IDEBUG\NK.EXE'
0 PID:0 TID:0 Booting Windows CE version 4.20 for (ARM)
0 PID:0 TID:0 &pTOC = 8010a6ac, pTOC = 80be901c, pTOC->ulRamFree
= 80d75000, MemForPT = 00000000
0 PID:0 TID:0
Old or invalid version stamp in kernel structures - starting clean!
0 PID:0 TID:0 Configuring: Primary pages: 12095, Secondary
pages: 16380, Filesystem pages = 14237
0 PID:0 TID:0
Booting kernel with clean memory configuration:
0 PID:0 TID:0 Memory Sections:
0 PID:0 TID:0 [0] : start: 80d76000, extension: 00003000,
length: 02f3f000
0 PID:0 TID:0 [1] : start: 84000000, extension: 00004000,
length: 03ffc000
0 PID:0 TID:0 Sp=ffffc7cc
2 PID:0 TID:0 Windows CE KernelInit

This looks to me to be fairly promising, as the two correct memory
sections are reported, but the kernel has hung in function
InitMemoryPool() when it is processing the new memory section. It
would appear that a DataAbort exception is being generated.

My implementation of OEMGetExtensionDRAM is:

BOOL OEMGetExtensionDRAM(LPDWORD lpMemStart, LPDWORD lpMemLen)
{
volatile MEMC_STRUCT *v_pMEMC
= (volatile MEMC_STRUCT *)MEMC_BASE_U_VIRTUAL;
BOOL retVal = FALSE;

/* The kernel POST detects whether there is 64Mb or 128Mb. If the
* extra 64Mb (128Mb fit) is found it enables this bank in the
* memory controller. We peek at the memory configuration register
* to see if this is enabled.
*/
if( ( v_pMEMC->mdcnfg & MDCNFG_DE1 ) != 0 )
{
*lpMemStart = EXP_SDRAM_BASE_C_VIRTUAL;
*lpMemLen = (64L*1024L*1024L);
retVal = TRUE;
}
return retVal;
}

I have made sure that the OEMAddressTable contains an entry for the
expansion RAM:

OEMAddressTable

;========================================================================
; Virtual(cached) Phys Addr Size (in MB)
dcd SDRAM_BASE_C_VIRTUAL, SDRAM_BASE_PHYSICAL, 64
; 8000 0000 A000 0000
dcd EXP_SDRAM_BASE_C_VIRTUAL, EXP_SDRAM_BASE_PHYSICAL, 64
; 8400 0000 A400 0000
.
.
.
dcd 0x00000000, 0x00000000, 0
; End of Table (MB MUST BE ZERO!)

Any help would be greatly appreciated.
Regards,
Andrew.

Re: Xscale PXA255 CE.NET 4.2: Getting OEMGetExtensionDRAM to work ? by K

K
Fri Jul 30 13:47:46 CDT 2004

I may gess
1) is EXP_SDRAM_BASE_C_VIRTUAL overlapped with oether entry in
OEMAddressTable (maybe other peripheral, flash etc)
2) is the SDRAM register (mdcnfg and other relative register) setting
properly
you may write a piece of memory sizing code (Write something and read it
back) in eboot or OAL (OEMInit or OEMGetExtensionDRAM) to make sure all of
the SDRAM can be accessed properly.
"AMScholan" <ams@plextek.co.uk>
???????:e4a0dafc.0407280755.57b5e12e@posting.google.com...
> I have a custom platform based on Intel PXA255 Xscale processor which
> is normally shipped with 64Mb of SDRAM. All of the .BIB files are set
> up to reflect this and the platform is stable using this 64Mb setup.
>
> The platform can be expanded with a further 64Mb of SDRAM. Although
> this is physically contiguous with the standard fit memory, it is
> necessary that the WinCE image can work on both the 64Mb device, or
> the 128Mb device.
>
> I am trying to implement the OEMGetExtensionDRAM() to inform the
> kernel of the existence of the (tested as working) extra 64Mb, if it
> is present.
>
> The kernel hangs very quickly with the following output:
>
> Loaded symbols for
'E:\WINCE420\PUBLIC\TESTV5\RELDIR\CT4000_ARMV4IDEBUG\NK.EXE'
> 0 PID:0 TID:0 Booting Windows CE version 4.20 for (ARM)
> 0 PID:0 TID:0 &pTOC = 8010a6ac, pTOC = 80be901c, pTOC->ulRamFree
> = 80d75000, MemForPT = 00000000
> 0 PID:0 TID:0
> Old or invalid version stamp in kernel structures - starting clean!
> 0 PID:0 TID:0 Configuring: Primary pages: 12095, Secondary
> pages: 16380, Filesystem pages = 14237
> 0 PID:0 TID:0
> Booting kernel with clean memory configuration:
> 0 PID:0 TID:0 Memory Sections:
> 0 PID:0 TID:0 [0] : start: 80d76000, extension: 00003000,
> length: 02f3f000
> 0 PID:0 TID:0 [1] : start: 84000000, extension: 00004000,
> length: 03ffc000
> 0 PID:0 TID:0 Sp=ffffc7cc
> 2 PID:0 TID:0 Windows CE KernelInit
>
> This looks to me to be fairly promising, as the two correct memory
> sections are reported, but the kernel has hung in function
> InitMemoryPool() when it is processing the new memory section. It
> would appear that a DataAbort exception is being generated.
>
> My implementation of OEMGetExtensionDRAM is:
>
> BOOL OEMGetExtensionDRAM(LPDWORD lpMemStart, LPDWORD lpMemLen)
> {
> volatile MEMC_STRUCT *v_pMEMC
> = (volatile MEMC_STRUCT *)MEMC_BASE_U_VIRTUAL;
> BOOL retVal = FALSE;
>
> /* The kernel POST detects whether there is 64Mb or 128Mb. If the
> * extra 64Mb (128Mb fit) is found it enables this bank in the
> * memory controller. We peek at the memory configuration register
> * to see if this is enabled.
> */
> if( ( v_pMEMC->mdcnfg & MDCNFG_DE1 ) != 0 )
> {
> *lpMemStart = EXP_SDRAM_BASE_C_VIRTUAL;
> *lpMemLen = (64L*1024L*1024L);
> retVal = TRUE;
> }
> return retVal;
> }
>
> I have made sure that the OEMAddressTable contains an entry for the
> expansion RAM:
>
> OEMAddressTable
>
> ;========================================================================
> ; Virtual(cached) Phys Addr Size (in MB)
> dcd SDRAM_BASE_C_VIRTUAL, SDRAM_BASE_PHYSICAL, 64
> ; 8000 0000 A000 0000
> dcd EXP_SDRAM_BASE_C_VIRTUAL, EXP_SDRAM_BASE_PHYSICAL, 64
> ; 8400 0000 A400 0000
> .
> .
> .
> dcd 0x00000000, 0x00000000, 0
> ; End of Table (MB MUST BE ZERO!)
>
> Any help would be greatly appreciated.
> Regards,
> Andrew.