Re: [Qemu-devel] Beaglebone Black emulation

[Peter Maydell]

On 3 May 2015 at 12:17, manish tiwari <address@hidden> wrote:
> I want to learn and contribute to qemu.
> In that process I am trying to emulate Beaglebone Black SoC.
> I am taking the reference of kzm SoC but I need to know what are the
> bare minimal devices need to be emulated for Beaglebone Black ?
>
> As I understand these are the following devices needs to be emulated
> 1. CPU model (Cortex-A8)
> 2.  RAM
> 3. UART
>
> What other least number of devices needs to be emulated to for this
> machine model to work well ?

The best bet here would be to take the emulation of the
beagleboard and its omap3 SoC which you can find in this
git tree:
https://git.linaro.org/?p=qemu/qemu-linaro.git
[look at the 'rebasing' branch]
and get it cleaned up and updated to current upstream
practice. This is not a trivial job (my estimate was that
it would be a couple of months work to get the complete
set sorted out and upstreamed, which is why I've never
got round to it), but it can be usefully split up into
a set of tasks with useful intermediate steps (like
"something with a minimal device or two").

The initial steps here would be:
1) rebase the patchset on to qemu master and fix up
  the breakage due to API changes in qemu
[this will be moderately painful if you haven't been
following the API changes as they happened; if you're
interested in taking on the omap3 patches then I can
do this step for you because it will be a lot faster...]
2) add support for direct boot of a guest kernel via
  "-kernel" (currently only "boot via an SD card image"
  is supported, which is awkward because the u-boot
  image insists on checking every device on the board
  and won't boot if any are missing)
3) build a cut-down minimally configured kernel that
  only needs the smallest possible set of devices
  [in particular, no SPI, I2C, MMC or graphics]
4) reorder the patchstack so that it starts with
  those relating to the required minimal device set
  and the SoC model and the board model, and the
  complicated ones to do with I2C etc are afterwards;
  check the kernel boots on this initial set
5) update the patches to correspond to current QEMU
  practice for QOM device modelling (the code in that
  tree is somewhat old and does many things in out
  of date ways)
6) submit the minimal-device patches and get them
  through code review and into QEMU
7) then start trying to clean up the remaining
  patches one device at a time

You'll need (or will learn :-)) familiarity with
handling stacks of patches in git, rebasing them,
reordering them, splitting them, and so on.

-- PMM