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

[Alessandro Carminati]

From: Thomas Huth <address@hidden>
Sent: 30 January 2019 17:10
To: Alessandro Carminati; address@hidden
Subject: Re: [Qemu-discuss] Weird qemu behaviour with Freescale Coldfire MCF5282

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





Hello,
Thank you for your explanation. It helps me a lot in comprehending how Qemu 
works, and also understand some of the behavior I see in the logs.
Using GDB was my first choice, I tried this way before the log. It is supposed 
to be interactive, therefore more comfortable than  reading a giga log. But 
when I tried it, on the m68k architecture, I couldn't make it work. To say it 
better, I was able to set breakpoints and start the execution, but the single 
step didn't work in my case. In the past, I used Qemu-GDB solution with ARM 
architecture with no problem, so I assumed I just stepped into m68k  
implementation problem and switched on the backup solution. Is there anything 
else I should know on the  "target remote" GDB "s" and "si" commands to work on 
the m68k implementation? When I issue the command, the GDB interface reports no 
error, but the target CPU state does not change.
Regards
Alessandro