Difference between revisions of "QemuMachineDevelopment"
m |
VeroniqueL (Talk | contribs) m |
||
| (12 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | == | + | == Introduction == |
| − | + | The aim of this project is to provide a fully functional and user-friendly way for developers and people interested in the Armadeus Project to test software as if it were running on a real board. | |
| − | + | ||
| − | The aim of this project is to provide a fully functional and user-friendly way for developers and people interested in the Armadeus Project to test software | + | |
In a far-off time, the aim is to provide a small framework to build dynamic software tests and run them automatically (after a static analysis of code for instance in order to build a fully featured report). | In a far-off time, the aim is to provide a small framework to build dynamic software tests and run them automatically (after a static analysis of code for instance in order to build a fully featured report). | ||
| + | |||
| + | '''See FireBoard project in the [[Contest | Contest 2008]] page.''' | ||
== Armadeus boards devices == | == Armadeus boards devices == | ||
| Line 45: | Line 45: | ||
|} | |} | ||
| − | |||
| − | |||
| − | + | == Qemu mechanisms : Qemu separated in three parts == | |
| − | + | ||
| − | + | Qemu is a wide software in which it could be difficult to land up. So a little explanation have to be done. | |
| − | + | ||
| + | === The code translation and the emulation system core === | ||
| + | |||
| + | Qemu integrates a dynamic code translation "machine" which translates target instructions in host ones on the fly. They all are already implemented in Qemu, so we have not them to remake. But this part of code is heavy compact and need knowledge in both host and target instructions set in order to understand it. | ||
| + | |||
| + | All the code of the TCG (Tiny Code Generator) is placed in the tcg directory of the source tree and contains implementations independently of targets. | ||
| − | + | The entry point of Qemu is placed in the vl.c file. After reading it, you could see that the major part of Qemu is contained in it. Every function you should need to talk with the emulated environment is defined there. Consequently, the first point of our work is to understand the behavior of Qemu through these lines. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | === The Target specific code === | |
| − | + | It's not already clear to me where are placed the Qemu target specific code. So, at this time, it looks like there is mainly situated in the target-X directory (X have to be replaced by the target name, like "arm"). | |
| − | + | ||
| − | + | ||
| − | + | === The hardware emulation layer === | |
| − | + | Despite of the hardware emulation layer is implemented both in the common emulation system and in an independent directory (named "hw"). It interacts with the emulation core through Qemu common functions each time. (see vl.c file) | |
| − | + | ||
| − | + | ||
==Links== | ==Links== | ||
Latest revision as of 16:23, 1 September 2009
Contents
Introduction
The aim of this project is to provide a fully functional and user-friendly way for developers and people interested in the Armadeus Project to test software as if it were running on a real board.
In a far-off time, the aim is to provide a small framework to build dynamic software tests and run them automatically (after a static analysis of code for instance in order to build a fully featured report).
See FireBoard project in the Contest 2008 page.
Armadeus boards devices
| Device | Implemented ? |
|---|---|
| Network interface | not implemented |
| SD/MMC card reader | not implemented |
| GPIO | not implemented |
| Led's | not implemented |
| CAN bus | not implemented |
| I2C bus | not implemented |
| ADC/DAC | not implemented |
| SPI | not implemented |
| SSI | not implemented |
| UART | not implemented |
| USB (slave/host) | not implemented |
| LCD | not implemented |
| FPGA | not implemented |
| SRAM | not implemented |
| CSI | not implemented |
| Touchscreen | not implemented |
Qemu mechanisms : Qemu separated in three parts
Qemu is a wide software in which it could be difficult to land up. So a little explanation have to be done.
The code translation and the emulation system core
Qemu integrates a dynamic code translation "machine" which translates target instructions in host ones on the fly. They all are already implemented in Qemu, so we have not them to remake. But this part of code is heavy compact and need knowledge in both host and target instructions set in order to understand it.
All the code of the TCG (Tiny Code Generator) is placed in the tcg directory of the source tree and contains implementations independently of targets.
The entry point of Qemu is placed in the vl.c file. After reading it, you could see that the major part of Qemu is contained in it. Every function you should need to talk with the emulated environment is defined there. Consequently, the first point of our work is to understand the behavior of Qemu through these lines.
The Target specific code
It's not already clear to me where are placed the Qemu target specific code. So, at this time, it looks like there is mainly situated in the target-X directory (X have to be replaced by the target name, like "arm").
The hardware emulation layer
Despite of the hardware emulation layer is implemented both in the common emulation system and in an independent directory (named "hw"). It interacts with the emulation core through Qemu common functions each time. (see vl.c file)
