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 snipped-for-privacy@yahoo.com (Dford) Organization:
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?
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 ->
0x00c00000Then ---
#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?
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
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?
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?
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?
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 snipped-for-privacy@yahoo.com (Dford) Organization:
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?
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 ->
0x00c00000Then ---
#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?
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
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?
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?
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?
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?