All of our coldfire Boot monitors use the internal SRAM for stack.
5206e, 5272, 5282, 5270, 5234, 5213, 52234

I see no problem putting the stack in SRAM to do the DRAM test.

If this is a first time bring up test, make sure you test the DRAM 
in 8 bit, 16bit and 32 bit writes.

Getting the SDRAM byte steering logic wrong is the most common 
error we see in getting coldfire hardware running.

If the byte steering logic is wrong you won't see it doing 32 bit writes.
You must try 8 and 16 bit writes.

Paul

Hello,

Anybody (on any RTOS) on ColdFire M5271 tried to initialize 52Kb SRAM &
allocate C-stack there to test (using C-code) DRAM at the boot time ?

See relevant info I found so far (but there the guy considers
allocating stack on DRAM and jumping over it during DRAM test - anybody
tried that ?)

Newsgroups: comp.os.vxworks
Subject: POST / RAM Test
Date: 6 Dec 2001 10:20:35 -0800
From: davis_spam@yahoo.com (Dford)
Organization: http://groups.google.com/
Message-ID: <aa73b3d8.0112061020.680766eb@posting.google.com>

Hi,

I'm trying to write a simple DRAM Pattern Test.  I'm using PowerPC
8240 (603E core), Mousse Vooha board.  64MB DRAM.

LOCAL_MEM_LOCAL_ADRS 0x0
LOCAL_MEM_SIZE       0x04000000
USER_RESREVED_MEM    0x0

I am working with a normal compressed bootrom (bootrom.bin) My
questions are as follows:

I need to run the RAM test before the bootrom copies itself into RAM,
obviously.  I am not a strong PowerPC Assembly programmer, so I'm
trying to cheat by doing it in C.  My entry point for the RAM test is
the romStart() routine in bootInit.c.  After romInit.s masks
interrups, sets stack pointer to STACK_ADRS, and readies DRAM, it
jumps to romStart().  In romStart, before the code copies ROM to RAM,
I begin a RAM Pattern test.

Correct me if I am wrong on these points:

At this point the system is still executing instructions out of ROM.
Am I correct in assuming the data section is also in ROM at this
point?

>From: vincent_hue@yahoo.com (Vincent)
>Yes, it should be executing from ROM.
>For my BSP (mv5100), there is no use of the data section up to that point.
>According to romStart.c, only ROM_RESIDENT images need to worry
>about the data section. Both ROM_COPY and ROM_COMPRESS only 'read'
>the data section (could then be in ROM).


I have not compiled the ROM_RESIDENT bootrom (well, I tried
but it was too large to fit in EEPROM).  As I understand it, the
ROM_RESIDENT bootrom only copies the data section to RAM (and .bss
exists in RAM as well), and leaves the .text section in ROM.  My entry
point is before I do the copy from ROM to RAM, so I am assuming the
.data section also exists in ROM at this point.  The stack however,
must exist in RAM somewhere.  I am somewhat confused where it exists
from the code / headers, though.

I see the following defined in configAll.h:

#if ((CPU_FAMILY == MIPS) || (CPU_FAMILY == PPC)
#define STACK_RESIDENT RAM_DST_ADRS

- -- following the chain of events: RAM_DST_ADRS -> RAM_HIGH_ADRS ->
0x00c00000

Then ---

#if (_STACK_DIR == _STACK_GROWS_DOWN)
    **SNIPPED STUFF ABOUT ROM_RESIDENT**
#define STACK_ADRS _romInit

- -- _romInit -> is at 0x10100 for RAM, so bootrom copies to
RAM_HIGH_ADRS, but when the system cold boots out of ROM, it must
execute _romInit from EEPROM which is in the 0xff000100 (cold entry) =
ROM_TEXT_ADRS

#else /* STACK GROWS UP */
#define STACK_ADRS (_romInit-STACK_SAVE)

- -- where STACK_SAVE corresponds to 64 bytes, so this is, I am
assuming
the size of my STACK.  Therefore, I need to avoid the addresses from
0x00c00000 to 0x00c10000 if stack grows down, and 0x00bf0000 to
0x00c00000 if stack grows up.

So, where is _STACK_DIR defined?

>vxArch.h
>For PPC, it definitively grows down.


Also, could someone clear up the following defines:

ROM_LOW_ADRS  = 00010000 # RAM text/data address for VxWorks
ROM_HIGH_ADRS = 00c00000 # RAM text/data address for bootrom

>That would be RAM_LOW and RAM_HIGH. gee, you're confused.
>Look at the romStart.c file, it gives information about these addreses.


I see from the reference manual on bootInit that RAM_LOW_ADRS is where
exc vectors, bp anchor, exc msg, and bootline are stored, and
RAM_HIGH_ADRS is where (romInit + ROM_COPY_SIZE) or binArrayStart is
stored.  So, I understand the system works in the following manner:

_romInit executes direct assembly code, sets STACK_ADRS to
RAM_HIGH_ADRS, inits processor, sets up DRAM, etc., jumps to C routine
romStart.  When do exc msg, bootline, etc. get setup?

>These are 'locations', there is no need to 'setup' a location.
>Exceptions vector are set in excInit() (see reference manual),
>No bootline is involved in 'ROM' image.


This seems to
happen in the romStart routine, but my pattern test runs as the first
piece of code in romStart (before ANY copy happens from ROM to RAM),
and when I hit address 0x4400, the system halts.  This address is
defined below in configAll.h:

#if (CPU_FAMILY == PPC)
#define RESREVED 0x4400  /* avoid zeroing out EXC_MSG */

This I can see if I warm reboot, and dump memory --> my pattern is
written into RAM up to the address 0x4400 at which point it continues
as all 0's.  I'd like to be able to just jump over this section of RAM
with my test, but I am unsure how large the reserved area is defined
as.  Actually, it would be ok, to jump over the entire exc msg, exc
vectors, bp anchor, and bootline, if I could determine how large this
section is.  This would just be RAM_LOW_ADRS plus some offset.  Can
someone tell me how/where it defines how large this section is?

>Please look at the bootClear() routine in romStart.c It clears the RAM
>starting a x4400 = SYS_MEM_BOTTOM = RESERVED.
>You should not write your pattern below RESERVED. It is defined as :
>"Area at the bottom of memory to not clear".
>I guess you're writting '0xXX' to memory and then bootClear() write 0x00,
>which explain the memory dump.
>Now, why your test fail is a different issue. Not enough information
>is provided. Are you sure you don't clear the stack ? (or your data) ?


Finally, I would like to be able to flush / invalidate the dcache
during the pattern fill / verify tests.  I tried issuing the system
calls cacheFlush() / cacheInvalidate() from the romStart() routine,
but the linker complains:

ldppc -X -N -Map mousse.map -e _romInit -Ttext 00010000  \
    -o bootrom romInit.o bootInit.o version.o  \
    D:\tornado\target/lib/libPPC603gnutms.a
D:\tornado\target/lib/libPPC603gnuospfv2.a
D:\tornado\target/lib/libPPC603gnuenvo
y.a D:\tornado\target/lib/libPPC603gnuzlib.a
D:\tornado\target/lib/libPPC603gnutms.a
D:\tornado\target/lib/libdiag.a D:\torna
do\target/lib/libtest.a D:\tornado\target/lib/libsal.a
D:\tornado\target/lib/libbcm.a D:\tornado\target/lib/libsoc.a D:\torna
do\target/lib/libsal.a D:\tornado\target/lib/libPPC603gnuvx.a
bootrom.Z.o
D:\tornado\target/lib/libPPC603gnuvx.a(workQLib.o): In function
`workQPanic':
workQLib.o(.text+0x316): undefined reference to `sysExcMsg'
workQLib.o(.text+0x31e): undefined reference to `sysExcMsg'
workQLib.o(.text+0x32a): undefined reference to `sysExcMsg'
workQLib.o(.text+0x346): undefined reference to `sysExcMsg'
workQLib.o(.text+0x34e): undefined reference to `sysExcMsg'
D:\tornado\target/lib/libPPC603gnuvx.a(workQLib.o)(.text+0x35a): more
undefined references to `sysExcMsg' follow
make: *** [bootrom] Error 0x1

Is it possible to somehow resolve this, or is it necessary to write a
funciton in PPC assembly to invalidate / flush the cache?


>sysExc is defined in sysLib.c
>As you may see, the sysLib.o file is not part of the linked files.
>Your code in ROM cannot call BSP function, or VxWorks fuction that
>are linked to BSP code.

I understand I need a stack for C.  I stated
above that I would need to jump over it.  However, I am unclear which
way it grows.  I believe it grows down in PowerPC, but if anyone else
knows, please issue a response.  Also, it seems necessary for me to
jump over the reserved area for exc msg, etc.  I'd like to know how
large this is defined as (where?).  I also understand where sysExcMsg
is defined.  sysLib.c is compiled in the bootrom Makefile, and also
linked.  Why then, can I not issue a call to it in romStart?  I'm
guessing it is because it is in the compressed region of code, that
gets uncompressed to RAM.  Can someone confirm this, and if so, is
there a workaround?

tried to initialize 52Kb SRAM & allocate C-stack there to test (using
C-code) DRAM at the boot time ?

See relevant info I found so far (but there the guy considers
allocating stack on DRAM and jumping over it during DRAM test - anybody
tried that ?)

Newsgroups: comp.os.vxworks
Subject: POST / RAM Test
Date: 6 Dec 2001 10:20:35 -0800
From: davis_spam@yahoo.com (Dford)
Organization: http://groups.google.com/
Message-ID: <aa73b3d8.0112061020.680766eb@posting.google.com>

Hi,

I'm trying to write a simple DRAM Pattern Test.  I'm using PowerPC
8240 (603E core), Mousse Vooha board.  64MB DRAM.

LOCAL_MEM_LOCAL_ADRS 0x0
LOCAL_MEM_SIZE       0x04000000
USER_RESREVED_MEM    0x0

I am working with a normal compressed bootrom (bootrom.bin) My
questions are as follows:

I need to run the RAM test before the bootrom copies itself into RAM,
obviously.  I am not a strong PowerPC Assembly programmer, so I'm
trying to cheat by doing it in C.  My entry point for the RAM test is
the romStart() routine in bootInit.c.  After romInit.s masks
interrups, sets stack pointer to STACK_ADRS, and readies DRAM, it
jumps to romStart().  In romStart, before the code copies ROM to RAM,
I begin a RAM Pattern test.

Correct me if I am wrong on these points:

At this point the system is still executing instructions out of ROM.
Am I correct in assuming the data section is also in ROM at this
point?

>From: vincent_hue@yahoo.com (Vincent)
>Yes, it should be executing from ROM.
>For my BSP (mv5100), there is no use of the data section up to that point.
>According to romStart.c, only ROM_RESIDENT images need to worry
>about the data section. Both ROM_COPY and ROM_COMPRESS only 'read'
>the data section (could then be in ROM).


I have not compiled the ROM_RESIDENT bootrom (well, I tried
but it was too large to fit in EEPROM).  As I understand it, the
ROM_RESIDENT bootrom only copies the data section to RAM (and .bss
exists in RAM as well), and leaves the .text section in ROM.  My entry
point is before I do the copy from ROM to RAM, so I am assuming the
.data section also exists in ROM at this point.  The stack however,
must exist in RAM somewhere.  I am somewhat confused where it exists
from the code / headers, though.

I see the following defined in configAll.h:

#if ((CPU_FAMILY == MIPS) || (CPU_FAMILY == PPC)
#define STACK_RESIDENT RAM_DST_ADRS

- -- following the chain of events: RAM_DST_ADRS -> RAM_HIGH_ADRS ->
0x00c00000

Then ---

#if (_STACK_DIR == _STACK_GROWS_DOWN)
    **SNIPPED STUFF ABOUT ROM_RESIDENT**
#define STACK_ADRS _romInit

- -- _romInit -> is at 0x10100 for RAM, so bootrom copies to
RAM_HIGH_ADRS, but when the system cold boots out of ROM, it must
execute _romInit from EEPROM which is in the 0xff000100 (cold entry) =
ROM_TEXT_ADRS

#else /* STACK GROWS UP */
#define STACK_ADRS (_romInit-STACK_SAVE)

- -- where STACK_SAVE corresponds to 64 bytes, so this is, I am
assuming
the size of my STACK.  Therefore, I need to avoid the addresses from
0x00c00000 to 0x00c10000 if stack grows down, and 0x00bf0000 to
0x00c00000 if stack grows up.

So, where is _STACK_DIR defined?

>vxArch.h
>For PPC, it definitively grows down.


Also, could someone clear up the following defines:

ROM_LOW_ADRS  = 00010000 # RAM text/data address for VxWorks
ROM_HIGH_ADRS = 00c00000 # RAM text/data address for bootrom

>That would be RAM_LOW and RAM_HIGH. gee, you're confused.
>Look at the romStart.c file, it gives information about these addreses.


I see from the reference manual on bootInit that RAM_LOW_ADRS is where
exc vectors, bp anchor, exc msg, and bootline are stored, and
RAM_HIGH_ADRS is where (romInit + ROM_COPY_SIZE) or binArrayStart is
stored.  So, I understand the system works in the following manner:

_romInit executes direct assembly code, sets STACK_ADRS to
RAM_HIGH_ADRS, inits processor, sets up DRAM, etc., jumps to C routine
romStart.  When do exc msg, bootline, etc. get setup?

>These are 'locations', there is no need to 'setup' a location.
>Exceptions vector are set in excInit() (see reference manual),
>No bootline is involved in 'ROM' image.


This seems to
happen in the romStart routine, but my pattern test runs as the first
piece of code in romStart (before ANY copy happens from ROM to RAM),
and when I hit address 0x4400, the system halts.  This address is
defined below in configAll.h:

#if (CPU_FAMILY == PPC)
#define RESREVED 0x4400  /* avoid zeroing out EXC_MSG */

This I can see if I warm reboot, and dump memory --> my pattern is
written into RAM up to the address 0x4400 at which point it continues
as all 0's.  I'd like to be able to just jump over this section of RAM
with my test, but I am unsure how large the reserved area is defined
as.  Actually, it would be ok, to jump over the entire exc msg, exc
vectors, bp anchor, and bootline, if I could determine how large this
section is.  This would just be RAM_LOW_ADRS plus some offset.  Can
someone tell me how/where it defines how large this section is?

>Please look at the bootClear() routine in romStart.c It clears the RAM
>starting a x4400 = SYS_MEM_BOTTOM = RESERVED.
>You should not write your pattern below RESERVED. It is defined as :
>"Area at the bottom of memory to not clear".
>I guess you're writting '0xXX' to memory and then bootClear() write 0x00,
>which explain the memory dump.
>Now, why your test fail is a different issue. Not enough information
>is provided. Are you sure you don't clear the stack ? (or your data) ?


Finally, I would like to be able to flush / invalidate the dcache
during the pattern fill / verify tests.  I tried issuing the system
calls cacheFlush() / cacheInvalidate() from the romStart() routine,
but the linker complains:

ldppc -X -N -Map mousse.map -e _romInit -Ttext 00010000  \
    -o bootrom romInit.o bootInit.o version.o  \
    D:\tornado\target/lib/libPPC603gnutms.a
D:\tornado\target/lib/libPPC603gnuospfv2.a
D:\tornado\target/lib/libPPC603gnuenvo
y.a D:\tornado\target/lib/libPPC603gnuzlib.a
D:\tornado\target/lib/libPPC603gnutms.a
D:\tornado\target/lib/libdiag.a D:\torna
do\target/lib/libtest.a D:\tornado\target/lib/libsal.a
D:\tornado\target/lib/libbcm.a D:\tornado\target/lib/libsoc.a D:\torna
do\target/lib/libsal.a D:\tornado\target/lib/libPPC603gnuvx.a
bootrom.Z.o
D:\tornado\target/lib/libPPC603gnuvx.a(workQLib.o): In function
`workQPanic':
workQLib.o(.text+0x316): undefined reference to `sysExcMsg'
workQLib.o(.text+0x31e): undefined reference to `sysExcMsg'
workQLib.o(.text+0x32a): undefined reference to `sysExcMsg'
workQLib.o(.text+0x346): undefined reference to `sysExcMsg'
workQLib.o(.text+0x34e): undefined reference to `sysExcMsg'
D:\tornado\target/lib/libPPC603gnuvx.a(workQLib.o)(.text+0x35a): more
undefined references to `sysExcMsg' follow
make: *** [bootrom] Error 0x1

Is it possible to somehow resolve this, or is it necessary to write a
funciton in PPC assembly to invalidate / flush the cache?


>sysExc is defined in sysLib.c
>As you may see, the sysLib.o file is not part of the linked files.
>Your code in ROM cannot call BSP function, or VxWorks fuction that
>are linked to BSP code.

I understand I need a stack for C.  I stated
above that I would need to jump over it.  However, I am unclear which
way it grows.  I believe it grows down in PowerPC, but if anyone else
knows, please issue a response.  Also, it seems necessary for me to
jump over the reserved area for exc msg, etc.  I'd like to know how
large this is defined as (where?).  I also understand where sysExcMsg
is defined.  sysLib.c is compiled in the bootrom Makefile, and also
linked.  Why then, can I not issue a call to it in romStart?  I'm
guessing it is because it is in the compressed region of code, that
gets uncompressed to RAM.  Can someone confirm this, and if so, is
there a workaround?