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

[Stephen Warren]

On 04/22/2016 01:46 AM, Gerd Hoffmann wrote:
>    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.

The disadvantage here is that people might expect all their options in 
config.txt (e.g. kernel command-line, load address, DTB overlays, GPU 
RAM size, etc.) to be honored on any Pi platform. If we jump straight 
into U-Boot, they won't be, at least not in the typical Pi way.

> 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>

This particular issue is because the bcm2835 timer isn't emulated, and 
the U-Boot MMC driver call udelay or similar, which is implemented by 
waiting for that timer to tick. There's a patch in Andrew's github tree 
that implements the timer, and with that U-Boot at least gets to its 
shell prompt, or did the last time I tested it.