Re: [Qemu-arm] [Qemu-devel] [PATCH] bcm2835_property: use cached values when querying framebuffer

[Gerd Hoffmann <kraxel@redhat.com>]

  Hi,

> > Ideally as was mentioned earlier this would be done by simply executing the
> > existing bootloader under emulation, rather than building all that code into
> > qemu. However, in the Pi case, the bootloader runs on the VideoCore (a
> > separate non-ARM CPU), so isn't (and likely won't be since IIUC it isn't
> > fully documented) emulated by qemu. by the time the ARM CPU runs, everything
> > (kernel, DTB/ATAGS, ARM boot stub, ...) is already loaded into RAM, the
> > display is already probed over HDMI and the controller scanning out a dummy
> > image, etc.
> >
> > So I think if that were to be supported, it'd have to be coded into qemu. Is
> > that something that could happen, or would such patches not fit qemu's model
> > well?
> 
> I made half a start on this project but had to shelve it.
> 
> The hard part is the FAT filesystem. The basic approach I started on
> was to link in the relevant bits of the GNU mtools so QEMU can poke
> around in a FAT filesystem hosted on a block device. Then just mount
> the SD card and emulate the boot logic of the VideoCore bootloader.
> This amount of new code should actually be pretty small, as the FS
> driver is handled by mtools and the SDHCI can be shorted by just
> having this alternate bootloader go direct to the block device (fish
> the blockdev out from the SD card).

Alternatively we can just go for a later boot loader stage, i.e. put a
u-boot build for rpi2 to pc-bios/ (we already have one for ppc there)
and run that by default.

Our sdcard emulation seems to have problems though:

   U-Boot 2016.05-rc2 (Apr 22 2016 - 09:11:45 +0200)

   DRAM:  960 MiB
   RPI 2 Model B (0xa21041)
   MMC:   <uboot hangs here>

Recent linux kernels have trouble talking to the mmc too.