[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-discuss] Weird qemu behaviour with Freescale Coldfire MCF5282
From: |
Alessandro Carminati |
Subject: |
[Qemu-discuss] Weird qemu behaviour with Freescale Coldfire MCF5282 |
Date: |
Wed, 30 Jan 2019 15:26:57 +0000 |
Hello,
I'm trying reverse engineer the firmware, apparently bare metal, of an
industrial controller. The device is based on a Coldfire controller, to be more
precise, the MCF5282. To track its behavior, I want to use Qemu in its M68k
fashion which is supporting already the MCF5206 and the MCF5208. The Coldfire
implementation of Qemu lacks in many places, and it seems targeted to run Linux
after the bootloader has left the hardware in a particular state. To run my
firmware, I had to patch it removing all the hardware initialization, and write
a new Qemu file for the CPU I wanted to target, the MCF5282.
So far, It seems that my code is working, and the CPU is initialized as the
initialization code I have skipped would have done. When I start my emulation,
strangeness begins, and there I ask for your help for understanding what is
going on. When I run
qemu-system-m68k -nographic -cpu m5282 -kernel Firmware.bin.qemuPatched \
-serial telnet:127.0.0.1:4444,server,nowait \
-serial telnet:127.0.0.1:4445,server,nowait \
-serial telnet:127.0.0.1:4446,server,nowait \
-d in_asm -D execution.log
I expected all the instruction of the target CPU to be logged, and that's it is
what's happened, at least until it reaches a branch instruction.
That time forward, no more instructions are logged, though the emulation is
continuing.
I can say that emulation is continuing because if I add to the logged
properties the target machine status, I see that the CPU state is changing
after the that last instruction is logged and the PC is changing also.
The strangeness does not stop here, and if I follow the PC values, I see that
CPU is executing instructions in the firmware address space in an unexpected
way, to make a long story short, it seems it is sampling the real flow without
writing every single step.
Does someone recognize in it the expected behavior?
Also, at least one time, I found a call to a function (jsr) where the flow
logged seems to indicate that function is not executed. It just logs the next
instruction, but looking at the CPU state it's clear that function has been
executed. Is Qemu which is malfunctioning, or it's just me who can not
understand what is going on?
----------------
IN:
0x00004da6: movel %fp@(8),%d6
D0 = 00000064 A0 = 00082748 F0 = 7fff ffffffffffffffff ( nan)
D1 = 00000028 A1 = 00084778 F1 = 7fff ffffffffffffffff ( nan)
D2 = 00000025 A2 = 00000000 F2 = 7fff ffffffffffffffff ( nan)
D3 = 00000000 A3 = 00000000 F3 = 7fff ffffffffffffffff ( nan)
D4 = 00000000 A4 = 00000000 F4 = 7fff ffffffffffffffff ( nan)
D5 = 00000000 A5 = 00000000 F5 = 7fff ffffffffffffffff ( nan)
D6 = 00000000 A6 = 0008fe44 F6 = 7fff ffffffffffffffff ( nan)
D7 = 00000000 A7 = 0008fe34 F7 = 7fff ffffffffffffffff ( nan)
PC = 00004da6 SR = 2004 T:0 I:0 SI --Z--
FPSR = 00000000 ----
FPCR = 0000 X RN
A7(MSP) = 00000000 ->A7(USP) = 0008fe30 A7(ISP) = 00000000
VBR = 0x00000000
SFC = 0 DFC 0
SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000
DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
MMUSR 00000000, fault at 00000000
----------------
IN:
0x00004daa: jsr 0x4ca0
D0 = 00000064 A0 = 00082748 F0 = 7fff ffffffffffffffff ( nan)
D1 = 00000028 A1 = 00084778 F1 = 7fff ffffffffffffffff ( nan)
D2 = 00000025 A2 = 00000000 F2 = 7fff ffffffffffffffff ( nan)
D3 = 00000000 A3 = 00000000 F3 = 7fff ffffffffffffffff ( nan)
D4 = 00000000 A4 = 00000000 F4 = 7fff ffffffffffffffff ( nan)
D5 = 00000000 A5 = 00000000 F5 = 7fff ffffffffffffffff ( nan)
D6 = 00000064 A6 = 0008fe44 F6 = 7fff ffffffffffffffff ( nan)
D7 = 00000000 A7 = 0008fe34 F7 = 7fff ffffffffffffffff ( nan)
PC = 00004daa SR = 2000 T:0 I:0 SI -----
FPSR = 00000000 ----
FPCR = 0000 X RN
A7(MSP) = 00000000 ->A7(USP) = 0008fe30 A7(ISP) = 00000000
VBR = 0x00000000
SFC = 0 DFC 0
SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000
DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
MMUSR 00000000, fault at 00000000
----------------
IN:
0x00004db0: movew %d0,%d7
D0 = 00000002 A0 = 000822c8 F0 = 7fff ffffffffffffffff ( nan)
D1 = 00000020 A1 = 00084778 F1 = 7fff ffffffffffffffff ( nan)
D2 = 0000007f A2 = 00000000 F2 = 7fff ffffffffffffffff ( nan)
D3 = 00000000 A3 = 00000000 F3 = 7fff ffffffffffffffff ( nan)
D4 = 00000000 A4 = 00000000 F4 = 7fff ffffffffffffffff ( nan)
D5 = 00000000 A5 = 00000000 F5 = 7fff ffffffffffffffff ( nan)
D6 = 00000064 A6 = 0008fe44 F6 = 7fff ffffffffffffffff ( nan)
D7 = 00000000 A7 = 0008fe34 F7 = 7fff ffffffffffffffff ( nan)
PC = 00004db0 SR = 2000 T:0 I:0 SI -----
FPSR = 00000000 ----
FPCR = 0000 X RN
A7(MSP) = 00000000 ->A7(USP) = 0008fe30 A7(ISP) = 00000000
VBR = 0x00000000
SFC = 0 DFC 0
SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000
DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
MMUSR 00000000, fault at 00000000
Regards
Alessandro
- [Qemu-discuss] Weird qemu behaviour with Freescale Coldfire MCF5282,
Alessandro Carminati <=