|
|
Acorn Arcade forums: Programming: Can someone look at this ARM code for me?
| |
Can someone look at this ARM code for me? |
| |
Stoppers (15:04 21/7/2010)
Phlamethrower (15:48 21/7/2010)
Stoppers (17:19 21/7/2010)
Stoppers (07:48 22/7/2010)
Phlamethrower (09:03 22/7/2010)
Stoppers (16:17 2/9/2010)
|
| |
|
Simon Willcocks |
Message #114857, posted by Stoppers at 15:04, 21/7/2010 |
Member
Posts: 302
|
Here's some code (from the RO4.02 ROMs) running through my emulator. The lines with lots of hex are the register contents, followed by the flag states and the processor mode. It starts off in 26-bit SVC mode (03) and changes back to 32-bit (13); the registers r13 and r14 are loaded from the 32-bit banked registers on the mode change.
Can someone please reassure me that it is behaving properly, so I can start looking elsewhere for my problem?
00000000 00000000 00000070 0100f700 03800000 00000000 10020011 600000c3 00000000 1004120c 00063000 00000000 03200000 03800000 6c0117f7 00014478 nZCv 03
I 00014478 e10f0000 mrs r0, cpsr (nZCv)
600000c3 00000000 00000070 0100f700 03800000 00000000 10020011 600000c3 00000000 1004120c 00063000 00000000 03200000 03800000 6c0117f7 0001447c nZCv 03
I 0001447c e3c0101f bic r1, r0, #31 ; =0x1f (nZCv)
600000c3 600000c0 00000070 0100f700 03800000 00000000 10020011 600000c3 00000000 1004120c 00063000 00000000 03200000 03800000 6c0117f7 00014480 nZCv 03
I 00014480 e3811013 orr r1, r1, #19 ; =0x13 (nZCv)
600000c3 600000d3 00000070 0100f700 03800000 00000000 10020011 600000c3 00000000 1004120c 00063000 00000000 03200000 03800000 6c0117f7 00014484 nZCv 03
I 00014484 e129f001 msr cpsr_cf, r1 (nZCv)
600000c3 600000d3 00000070 0100f700 03800000 00000000 10020011 600000c3 00000000 1004120c 00063000 00000000 03200000 0001191c 00200000 00014488 nZCv 13 |
| |
 [ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #114858, posted by Phlamethrower at 15:48, 21/7/2010, in reply to message #114857 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
the registers r13 and r14 are loaded from the 32-bit banked registers on the mode change. Well, that's where your problem is  Each 26bit processor mode should share the same register file as its 32bit equivalent (AFAIK - I'd have to check the ARM ARM to be 100% sure)
I believe the only register that changes between 26bit and 32bit modes is R15, where in 26bit modes it's essentially a virtual register that's combination of the PC & PSR. I.e. whenever R15 gets written your emulator needs to strip out the PSR bits and write them to the PSR, so that the PC only receives the address bits. And for reads it needs to merge them back together. But I suspect you already do this
[Edited by Phlamethrower at 16:49, 21/7/2010] |
| |
[ Log in to reply ] |
| |
|
Simon Willcocks |
Message #114859, posted by Stoppers at 17:19, 21/7/2010, in reply to message #114858 |
Member
Posts: 302
|
Ah, thanks; the code did look a little strange, that makes a lot more sense.
Now, where did I put that drawing board?
I'm just starting to emulate a whole computer (RPC, of course), and not just a couple of modes in the processor. A couple of days ago my RPC died and I thought I'd try using some of the ROLF technology to get RO4 running. (In the mean time, I fixed the RPC by re-seating some of the memory chips.)
[Edited by Stoppers at 18:30, 21/7/2010] |
| |
[ Log in to reply ] |
| |
|
Simon Willcocks |
Message #114860, posted by Stoppers at 07:48, 22/7/2010, in reply to message #114859 |
Member
Posts: 302
|
Well, now it's trying to write to 0x00000269, while that address is in the ROM. 
I'm not going to have a chance to work on it again for quite a while, but if anyone's interested, its uploaded into the rolf svn (look for emulate_rpc.c). |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #114862, posted by Phlamethrower at 09:03, 22/7/2010, in reply to message #114860 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Well, now it's trying to write to 0x00000269, while that address is in the ROM. There's some funky stuff the OS does during startup to get the hardware working. E.g. I remember seeing some code that writes (or reads?) a dummy IOMD register to get it out of 'ROM mode'. I'm also sure there's meant to be some write-only device that overlaps the ROM in the memory map (unless I'm thinking of the Arc?), so it's possible that writing to 0x269 is a perfectly valid thing to do during startup. There's also code that intentionally triggers a data abort to find out what abort mode is in use (base restored or base updated) - although I'm not sure whether that check is made before or after the MMU gets enabled (if it's done before the MMU, it obviously must be done while the ROM is at 0x00000000 otherwise there'd be no processor vectors to jump to)
I'd suggest either looking over the 3.x kernel sources in the ROOL source tree or looking at/using RPCEmu. Or if you want the fun of working it out for yourself, try adding some logging code to both ROLF and RPCEmu and see what each does for the first N instructions up until the crash. |
| |
[ Log in to reply ] |
| |
|
Simon Willcocks |
Message #115221, posted by Stoppers at 16:17, 2/9/2010, in reply to message #114862 |
Member
Posts: 302
|
There's some funky stuff the OS does during startup to get the hardware working....
I'd suggest either looking over the 3.x kernel sources in the ROOL source tree or looking at/using RPCEmu. Or if you want the fun of working it out for yourself, try adding some logging code to both ROLF and RPCEmu and see what each does for the first N instructions up until the crash. I'm back!
As you suggested, I've been looking at the RPCEmu source for indications of how the hardware works (as well as the RPC TRM, various datasheets, etc.). I even tried integrating the cmos.c code into the emulator, with some success.
I've decided, though, to try identifying routines in the OS by purpose (e.g. "read configuration data" instead of all the i2c bit twiddling) and "patching" the emulated code to call native code routines to perform the necessary functions. The aim is to avoid emulating any specific hardware external to the processor and see just how many (or few) routines are needed to do that. The downside is that, initially, the emulator won't work with anything other than RO4.02 ROM images (although modifying it to work with others should just be a matter of finding the addresses of the appropriate routines).
I've noticed a couple of strange encodings for instructions in the ROM, can anyone tell me if I've missed something in the ARM ARM?
These two instructions are encoded with the (non-existant) op1 as r15 instead of the usual r0. They don't have the S bit set, so as far as I can see they're not the "P" version of the instructions. Any ideas (or is this another thing I can safely ignore)?
03829b20 e3af1e27 mov r1, #624 ; =0x270
03829b84 23af2e27 movcs r2, #624 ; =0x270 |
| |
[ Log in to reply ] |
| |
|
Acorn Arcade forums: Programming: Can someone look at this ARM code for me? | |
|
