here's question.
any of you guys know about purpose of 0x89f80000~0x89f80040?
purpose of 0x89f80000~0x89f80040
My understanding is that the current SVN toolchain binutils uses the Sony patch.
psp-objdump -d disasembles 0x89f80000~0x89f80040 as
lwl is a standard Mips instruction for unaligned loads, used in conjunction with lwr.
gcc generates bitrev for some of the builtin intrinsics (such as __builtin_ctz), and also implements __builtin_allegrex_bitrev(). You can easily test whether it does the right thing.
psp-objdump -d disasembles 0x89f80000~0x89f80040 as
Code: Select all
0: 89f80000 lwl t8,0(t7)
4: 89f80040 lwl t8,64(t7)gcc generates bitrev for some of the builtin intrinsics (such as __builtin_ctz), and also implements __builtin_allegrex_bitrev(). You can easily test whether it does the right thing.
Did you find anything of interest in that address range?
This is in the nromal user main ram which is 24 megs between 0x88800000 - 0x89FFFFFF so I guess it could be just about anything...
It's the user main ram, but from the cache kernel memory segment. The same physicaly memory is mapped at more than one address, and these 24 megs are mapped at the following addresses, so that might xplain why you didn't recognize the address as user main ram:
0x08800000 - 0x09FFFFFF - user segment, cached
0x48800000 - 0x49FFFFFF - user segment, uncached
0x88800000 - 0x89FFFFFF - kernel segment, cached (accessible only in kernel mode)
0xA8800000 - 0xA9FFFFFF - kernel segment, uncached (accessible only in kernel mode)
The following is a result of a memory scan I made in kernel mode. My scan consisted in attempting to read all the memory in 1 Mb chunks (except around the scratchpad where I went to 1 Kb chunks), and check if I was getting an exception or not:
This is in the nromal user main ram which is 24 megs between 0x88800000 - 0x89FFFFFF so I guess it could be just about anything...
It's the user main ram, but from the cache kernel memory segment. The same physicaly memory is mapped at more than one address, and these 24 megs are mapped at the following addresses, so that might xplain why you didn't recognize the address as user main ram:
0x08800000 - 0x09FFFFFF - user segment, cached
0x48800000 - 0x49FFFFFF - user segment, uncached
0x88800000 - 0x89FFFFFF - kernel segment, cached (accessible only in kernel mode)
0xA8800000 - 0xA9FFFFFF - kernel segment, uncached (accessible only in kernel mode)
The following is a result of a memory scan I made in kernel mode. My scan consisted in attempting to read all the memory in 1 Mb chunks (except around the scratchpad where I went to 1 Kb chunks), and check if I was getting an exception or not:
Code: Select all
0x0000000 - 0x3FFFFFFF: KUSEG0 (cached)
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
BAD 0x00000000 - 0x0000FFFF 64.00 Kb N/A
OK 0x00010000 - 0x00013FFF 16.00 Kb Scratchpad
BAD 0x00014000 - 0x03FFFFFF 63.92 Mb N/A
OK 0x04000000 - 0x047FFFFF 8.00 Mb VRAM + ???
BAD 0x04800000 - 0x087FFFFF 64.00 Mb N/A
OK 0x08800000 - 0x09FFFFFF 24.00 Mb User memory
BAD 0x0A000000 - 0x1DFFFFFF 320.00 Mb N/A
OK 0x1E000000 - 0x1EFFFFFF 16.00 Mb ???
BAD 0x1F000000 - 0x3FFFFFFF 528.00 Mb N/A
0x4000000 - 0x7FFFFFFF: KUSEG1 (non-cached)
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
BAD 0x40000000 - 0x4000FFFF 64.00 Kb N/A
OK 0x40010000 - 0x40013FFF 16.00 Kb Scratchpad
BAD 0x40014000 - 0x43FFFFFF 63.92 Mb N/A
OK 0x44000000 - 0x447FFFFF 8.00 Mb VRAM + ???
BAD 0x44800000 - 0x487FFFFF 64.00 Mb N/A
OK 0x48800000 - 0x49FFFFFF 24.00 Mb User memory
BAD 0x4A000000 - 0x5DFFFFFF 320.00 Mb N/A
OK 0x5E000000 - 0x5EFFFFFF 16.00 Mb ???
BAD 0x5F000000 - 0x7FFFFFFF 528.00 Mb N/A
0x8000000 - 0x9FFFFFFF: KSEG0 (cached)
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
BAD 0x80000000 - 0x8000FFFF 64.00 Kb N/A
OK 0x80010000 - 0x80013FFF 16.00 Kb Scratchpad
BAD 0x80014000 - 0x83FFFFFF 63.92 Mb N/A
OK 0x84000000 - 0x847FFFFF 8.00 Mb VRAM
BAD 0x84800000 - 0x87FFFFFF 56.00 Mb N/A
OK 0x88000000 - 0x883FFFFF 4.00 Mb Kernel memory
BAD 0x88400000 - 0x887FFFFF 4.00 Mb N/A
OK 0x88800000 - 0x89FFFFFF 24.00 Mb User memory
BAD 0x8A000000 - 0c9BFFFFFF 288.00 Mb N/A
OK 0x9C000000 - 0x9C6FFFFF 7.00 Mb ???
BAD 0x9C700000 - 0x9C7FFFFF 1.00 Mb N/A
OK 0x9C800000 - 0x9CAFFFFF 3.00 Mb ???
BAD 0x9CB00000 - 0x9CFFFFFF 5.00 Mb N/A
OK 0x9D000000 - 0x9D4FFFFF 5.00 Mb ???
BAD 0x9D500000 - 0x9D5FFFFF 1.00 Mb N/A
OK 0x9D600000 - 0x9D7FFFFF 2.00 Mb ???
BAD 0x9D800000 - 0x9DDFFFFF 6.00 Mb N/A
OK 0x9DE00000 - 0x9FFFFFFF 34.00 Mb ???
0xA000000 - 0xBFFFFFFF: KSEG1 (non-cached)
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
BAD 0xA0000000 - 0xA3FFFFFF 64.00 Mb N/A
OK 0xA4000000 - 0xA47FFFFF 8.00 Mb VRAM
BAD 0xA4800000 - 0xA7FFFFFF 56.00 Mb N/A
OK 0xA8000000 - 0xA83FFFFF 4.00 Mb Kernel memory
BAD 0xA8400000 - 0xA87FFFFF 4.00 Mb N/A
OK 0xA8800000 - 0xA9FFFFFF 24.00 Mb User memory
BAD 0xAA000000 - 0xBBFFFFFF 288.00 Mb N/A
OK 0xBC000000 - 0xBC6FFFFF 7.00 Mb ???
BAD 0xBC700000 - 0xBC8FFFFF 1.00 Mb N/A (the BC8 range should be readable...?)
OK 0xBC900000 - 0xBCAFFFFF 3.00 Mb ???
BAD 0xBCB00000 - 0xBCFFFFFF 5.00 Mb N/A (the BCC range should be readable...?)
OK 0xBD000000 - 0xBD4FFFFF 5.00 Mb ???
BAD 0xBD500000 - 0xBD5FFFFF 1.00 Mb N/A (the BD5 range should be readable...?)
OK 0xBD600000 - 0xBD7FFFFF 2.00 Mb ??? (slow to read)
BAD 0xBD800000 - 0xBDDFFFFF 6.00 Mb N/A (the BD8, BDC and BDF ranges should be readable...?)
OK 0xBDE00000 - 0xBFFFFFFF 34.00 Mb ???
0xC000000 - 0xDFFFFFFF: KSSEG (cached)
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
BAD 0xC000000 - 0xDFFFFFFF 512.00 Mb N/A
0xE000000 - 0xFFFFFFFF: KSSEG (cached)
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
BAD 0xE000000 - 0xFFFFFFFF 512.00 Mb N/A
The 1st 2MB is the VRAM, and then there are 3 aliases of the VRAM memory with different rearrangements of the address lines. Look at this thread.korskarn wrote:Code: Select all
OK 0x04000000 - 0x047FFFFF 8.00 Mb VRAM + ???