Determined physical RAM map:
memory: 00800000 @ 40250000 (usable)
memory: 00040000 @ 9fc00000 (ROM data)
Wasting 8407552 bytes for tracking 262736 unused pages
These are kernel messages, so you are getting into the kernel, but this
looks odd to me. The MIPS processor needs memory mapped in the first
512 MiB to execute. This first 512 MiB will be mapped as cached memory
at virtual address 0x80000000 (known as kseg0) and as uncached memory at
virtual address 0x0a0000000 (known as kseg1). Perhaps you system is like
mine, where I have memory above 512 MiB aliased into the first 512 MiB
of physical space.
The second odd thing is the ROM data physical address. This is a good virtual
address but as a physical address it is not accessible by the MIPS processor
without mapping to with a TLB entry.
Are these supposed to be physical addresses? Maybe that's where I'm going
wrong. I only know the virtual addresses from some experimentation, but I've
got no idea how to find out the physical addresses.
The system won't accept the kernel unless its virtual load address is
0x40020000. If I use the 'sm' (show memory) command in the boot loader it
tells me there is 16MB of RAM starting at 0x20000000 and 8MB starting at
0x21000000, so but if memory is supposed to start at 0x0 then those don't look
like physical addresses either.
TLB refill exception PC = 40024094 address = 7FFFF000
This is not too surprising since the kernel is executing at an address
must have a TLB entry to be accessible.
From my other experiments here, 0x40024094 is fine, the problem is that the
kernel is trying to access the unmapped address at 0x7FFFF000 and I'm not sure
why. It looks like an unusual address - is it trying to trigger an exception
to test whether some exception handler has been installed correctly?
My guess, and since I don't have a lot of information this is a pretty
wild guess, is that you are actually running your kernel at 0x40020000,
and that the reason you can do this is that the bootloader has left the
TLBs in such a state that the first few pages are mapped. Then, when it
leaves the mapped area, it dies with the TLB refill exception.
Another possibility is that you actually start off at reasonable 0x8xxxxxxx
address, but then use a pointer that takes you off to 0x40024094.
I'm pretty sure execution starts at 0x40020000. With some testing code I have
successfully written at 0x40040000 so it looks like that's where the boot
loader has mapped a fair chunk of memory. 0x40024094 shouldn't be a problem,
but 0x7FFFF000 probably would be.
One suggestion is to look at the code at 0x40024094 to see what it's doing.
Then, use a JTAG debugger or add printk() statements to see exactly what's
happening.
I think that's probably the best bet. Unfortunately figuring out where that
address ends up in the C source is a little tricky for me, and I'm still a bit
slow at reading MIPS assembly!
Thanks for your helpful reply.
Cheers,
Adam.
