On 2019-01-30 17:59, Alessandro Carminati wrote:
> From: Thomas Huth
[...]
> 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
>
On Wed, 30 Jan 2019 at 16:11, Thomas Huth wrote:
> 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 n
From: Thomas Huth
Sent: 30 January 2019 17:10
To: Alessandro Carminati; qemu-discuss@nongnu.org
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
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
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 MCF52
Hi,
I'm proud to announce the release (well, the release happen a month ago) 2.0 of
QtEmu
With QtEmu 2.0 I made a complete rewrite from scrath of QtEmu with Qt 5 support.
The highlight of the release:
- Support of GNU/Linux, FreeBSD and Windows.
- Support of QEMU 2.x and 3.x
- Rewritten in Qt5
