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

[Peter Crosthwaite]

On Fri, Apr 22, 2016 at 12:46 AM, Gerd Hoffmann <address@hidden> 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.
>

Rather than a later boot stage, could we set this up to be identical
in functionality to the early boot stage? This enables baremetal devs
who want to debug from the real bootrom handoff (handoff from
VideoCore).

Doing it over FAT+bootloader code does however have the advantage of
not having to go through emulated SD card and TCG.

Regards,
Peter

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