Strange memory addresses

I'm writing this is a separate thread to the patches as it's more just
me being confused. Also, I think I sent the patches e-mail off the back
of a reply by mistake, so it's gone under some other thread. Sorry about
that. Shall I resend it?

I've been trying to get linux to turn on the LCD after either it or
windows has suspended. I managed to work out that windows does something
with the SSP. Unfortunately, watching p2v(SSP register x) doesn't help.
Nothing seems to write to that virtual address directly when I use
SETLCD. Instead, I've made the irq/fault handlers report the address
when doing the memory poll and then just added the SSP registers to the
TRACES variables. This, provided the IRQs happen fast enough gives me
the rough area of memory as the code usually sits in small wait loops
just after sending/receiving to/from the port.

The PC is usually around 0x0bb08000 (MVA) when the changes get made.
This is VA 0x01b08000. The LSMOD in haret reports the following at that
address:
1076 fl=00000000 mid=87257108 pid=00000000 gusg=001 pusg=016
base=01AE0000 size=0003d000 hmod=87257108 mod=pxa27x_lcd.dll exe=

Which seemed likely, given it was playing with the LCD. But there isn't
anything mapped at 0x01ae8000 (or at 0x0bae8000 for that matter). The
begginning of the 'dump mmu' looks like this:
virt phys desc flags
00000000 | | UNMAPPED |
02000000 | | Coarse | D=0
02000000 | | UNMAPPED |
02021000 | c38dc000 | Small (4K) | CB AP=0000
...
(and 0x0b is unmapped aswell)

Trying VDUMP 0x01b08000 or 0x0bb08000 in haret gives exceptions as well.

I eventually found the code by having haret report the 10 instructions
either side of the PC, dumping the entirety of RAM and searching for
them. They came up at 0xc3100000 phys which is only mapped here,
according to 'dump mmu':
virt phys desc flags
c3b06000 | c30fe000 | Small (4K) | CB AP=0000
c3b07000 | c30ff000 | Small (4K) | CB AP=0000

c3b08000 | c3100000 | Small (4K) | CB AP=0000
c3b09000 | c3101000 | Small (4K) | CB AP=0000
c3b0a000 | c3102000 | Small (4K) | CB AP=0000
c3b0b000 | c3103000 | Small (4K) | CB AP=0000
c3b0c000 | c3104000 | Small (4K) | CB AP=0000

c3b0d000 | c30d8000 | Small (4K) | CB AP=0000

So how does 0bb0 MVA / 01b0 VA end up as c3b0?

I've now disassembled the code in question, and can trace it using INSN
and INSN2 set to 0x0bb0xxxx. The SSP registers are read/written to by
str/ldr s to 0x00490000, (again, not mapped in the haret mmu dump. It's
not at c249 either). Am I reading something wrong?
The problem is that it also read/writes to 00460000 and 004a0000, which
I think are important and I can't find out what these point to.

Any ideas what's going on here?

Oliver
Received on Thu Apr 17 2008 - 19:54:00 EDT