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

[Andrew Baumann]

Hi all,

> From: Peter Crosthwaite [mailto:address@hidden
> Sent: Friday, 22 April 2016 09:18
> 
> On Thu, Apr 21, 2016 at 9:06 AM, Stephen Warren
> <address@hidden> wrote:
> > On 04/21/2016 08:07 AM, Sylvain Garrigues wrote:
> >>
> >> Le 21 avr. 2016 à 15:42, Peter Maydell <address@hidden> a
> >> écrit
> >> :
> >>>
> >>>
> >>> There may be something we can do here to make FreeBSD's life easier,
> >>> but we definitely can't do it on the eve of a release.
> >>
> >>
> >> I didn’t know it was release day, my timing is not perfect then,
> >> sorry about that, I didn’t intend to put stress on you guys today.
> >> Like you mentioned, the Linux boot protocol doesn’t mandate any
> >> loading address, hence the possibility to set it on the command line.
> >> It would benefit not only to FreeBSD (which is strictly Linux boot
> >> ABI compliant BTW - that is how I found the qemu bootloader bug and
> >> fixed it in
> >> b4850e5) but all other OS.
> >> On the real hardware Raspberry Pi, there is the kernel_address
> >> firmware feature which enable to set the kernel load address. Would
> >> be neat to have it *someday* in qemu for any board if it is not too hard to
> implement.
> >
> >
> > It would indeed be nice if qemu for the Pi implemented the exact same
> > bootloader setup as real HW does. That is, loading boot images from
> > the FAT partition on the SD card, parsing config.txt, etc.
> >
> > 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).

You got further on this than I did. I considered a couple of options, of 
varying complexity/compatibility:

 0. The status quo: we support -kernel (for Linux images) and -bios (e.g. 
Windows), but otherwise all the options that can be set in config.txt are 
treated as the defaults. For example, -bios images are always loaded at 0x8000. 
Additionally, framebuffer parameters can be set directly from the command line 
(e.g. Windows wants -global bcm2835-fb.pixo=0).
 1. More pi-specific parameters in the line of the framebuffer parameters 
above, to control things like the image load address, and maybe to enable 
trustzone boot akin to config.txt's kernel-old=1.
 2. Code to parse config.txt and set the parameters above.
 3. Code to emulate the bootloader entirely, pulling config.txt and all the 
relevant boot bits out of an SD image (this is what Peter describes above).
 4. An ARM-based reimplementation of the bootloader, running under emulation.

I discarded even considering option 3 because I assumed you wouldn't want a FAT 
implementation linked into qemu. And I'm not inclined to add ini-parsing code, 
so my gut feeling was to go a little further on option 1 and add parameters to 
the raspi machines (I assume this is possible?) for basic things like the load 
address, and rely on users to translate config.txt settings into command-line 
parameters.

Andrew