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

[Stephen Warren <swarren@wwwdotorg.org>]

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.