Hi, Where is does your stack start? Seems to me that your stack pointer might start at around 0x80010000 and of course it grows down from there. I suspect you're overwriting the stack. Just a thought. Cheers, Lyle > -----Original Message----- > From: linux-mips-bounce@linux-mips.org > [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Jeff Baitis > Sent: Wednesday, May 14, 2003 7:27 PM > To: Pete Popov > Cc: Linux MIPS mailing list > Subject: Re: Power On Self Test and testing memory > > > Hi Pete: > > I forgot that I'm overwriting the RAM-based exception > vectors. Earlier I had disabled interrupts in the CP0 status > register bit 0, but Linux actually needs them enabled... :) > > So, I changed my test to start at base address 0x80001000, > but I still get the same failure at the same RAM location. > > Also important to mention is that my bootloader is executing > from flash ROM, and my initialization is very similar to the > YAMON initialization file that comes with the DbAu1500 eval board. > > Here's what my code is like: > > // in __main > > failures = (int)loader_memcheck((UINT32)0xA0001000, > (UINT32)0xA4000000, 0xAAAAAAAA); failures = > (int)loader_memcheck((UINT32)0xA0001000, (UINT32)0xA4000000, > 0x55555555); failures = > (int)loader_memcheck((UINT32)0x80001000, (UINT32)0x84000000, > 0xAAAAAAAA); // Try to invalidate cache and go again failures > = (int)loader_memcheck((UINT32)0x80001000, > (UINT32)0x84000000, 0xAAAAAAAA); > > .... > > > static unsigned int loader_memcheck( UINT32 base_addr, UINT32 > max_addr, UINT32 test_data) > { > for (i = base_addr; i < max_addr; i=i+4) > { > *((unsigned int *)i) = test_data; > } > > failures = 0; > first_failure = 0xffffffff; > for (i = base_addr; i < max_addr; i=i+4) > { > if (*((unsigned int *)i) != test_data) > { > if ((unsigned int)i < (unsigned int)first_failure) > { > first_failure = i; > } > > ++failures; > } > } > // if failures !=0 print_hex(first_failure) > return failures; > } > > So, after I execute this code, I pull up the EJTAG debugger, > and poke around. > > I notice that even though the C code says that the first > failure is at 0x8000fe50, but when I poke around, I find: > > ... > (gdb) p/x *(0x8000fe04) > $27 = 0xaaaaaaaa > > (gdb) p/x *(0x8000fe08) > $28 = 0x10fe0080 > > (gdb) p/x *(0x8000fe10) > $29 = 0x38000000 > ... > > It seems like I'm having some cache coherency issues, since > the results while executing code are quite differenet. > > Thanks for your help, Pete! > > -Jeff > > On Wed, May 14, 2003 at 03:34:01PM -0700, Pete Popov wrote: > > On Wed, 2003-05-14 at 15:26, Jeff Baitis wrote: > > > Hi all: > > > > > > I implemented memory tests in my bootloader code for the > AU1500. I'm > > > trying to figure out why Linux boots when loaded into > cached KSEG0 > > > (0x 80c0 0000), but my memory test FAILS for this same region. > > > > > > (pretty backwards huh? get linux booting, then write > memory tests!) > > > > > > > > > I start by writing 0x5555 5555 to all of uncached memory, > reading it > > > back, and I write 0xAAAA AAAA to all of uncached memory > and read it > > > back. > > > > > > This works great. > > > > > > Next, I try to write 0x5555 5555 to cached KSEG0 memory, and it > > > fails at addr 0x8000FE50. But Linux boots! > > > > You're not overwriting any of the boot exception vectors, right? > > What's the failure exactly and how does the test work? > > > > Pete > > > > > I'm not issuing SYNC commands when writing to cached > memory; could > > > this be the problem? > > > > > > We've exhaustively verified the memory burst parameters, > etc. They > > > look good. > > > > > > Thank you in advance for your ideas! > > > > > > Regards, > > > Jeff > > > > -- > Jeffrey Baitis - Associate Software Engineer > > Evolution Robotics, Inc. > 130 West Union Street > Pasadena CA 91103 > > tel: 626.535.2776 | fax: 626.535.2777 | baitisj@evolution.com >
