Re: [Qemu-discuss] Weird qemu behaviour with Freescale Coldfire MCF5282

[Thomas Huth]

On 2019-01-30 16:26, Alessandro Carminati wrote:
> 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?

Sure. It's as simple as this: QEMU is a just-in-time emulator, that
means that the all new code that is seen by the m68k CPU is translated
to host CPU machine code. For code blocks that have already been
translated, the target m68k code is not considered again. So if your
code branches to a part that has already been executed once, you won't
see it again in the output of "-d in_asm".
If you need single-stepping, I recommend to attach a remote GDB instead.

 HTH,
  Thomas