code, which performs DRAM test in romStart() routine in bootInit.c - VxWorks

This is a discussion on code, which performs DRAM test in romStart() routine in bootInit.c - VxWorks ; Hi, Does anyone have and willing to share/post code, which performs DRAM test in romStart() routine in bootInit.c (at vxworks boot) ? See background info listed below ... Al ****************************************** Newsgroups: comp.os.vxworks Subject: Re: POST / RAM Test Date: 11 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: code, which performs DRAM test in romStart() routine in bootInit.c

  1. code, which performs DRAM test in romStart() routine in bootInit.c

    Hi,

    Does anyone have and willing to share/post code,
    which performs DRAM test in romStart() routine in bootInit.c (at
    vxworks boot) ?

    See background info listed below ...

    Al
    ******************************************
    Newsgroups: comp.os.vxworks
    Subject: Re: POST / RAM Test
    Date: 11 Dec 2001 01:15:17 -0800
    From: vincent_hue@yahoo.com (Vincent)
    Organization: http://groups.google.com/

    Davis,

    Find some information below.

    Vincent

    davis_spam@yahoo.com (Dford) wrote in message
    > 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?


    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.

    > Thanks in advance for any help,
    >
    > Dford



  2. Re: code, which performs DRAM test in romStart() routine in bootInit.c

    Please have a look at http://www.netrino.com/Articles/MemoryTesting/

    You may find interesting information.

    Patrick

    al wrote:
    > Hi,
    >
    > Does anyone have and willing to share/post code,
    > which performs DRAM test in romStart() routine in bootInit.c (at
    > vxworks boot) ?
    >
    > See background info listed below ...
    >
    > Al
    > ******************************************
    > Newsgroups: comp.os.vxworks
    > Subject: Re: POST / RAM Test
    > Date: 11 Dec 2001 01:15:17 -0800
    > From: vincent_hue@yahoo.com (Vincent)
    > Organization: http://groups.google.com/
    >
    > Davis,
    >
    > Find some information below.
    >
    > Vincent
    >
    > davis_spam@yahoo.com (Dford) wrote in message
    >
    >>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?

    >
    >
    > 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.
    >
    >
    >>Thanks in advance for any help,
    >>
    >>Dford

    >
    >


+ Reply to Thread