[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stephen Warren
Subject: Re: [Qemu-devel] [Qemu-arm] [PATCH] bcm2835_property: use cached values when querying framebuffer
Date: Fri, 22 Apr 2016 09:43:23 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 04/22/2016 01:46 AM, Gerd Hoffmann wrote:

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]