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

[Peter Crosthwaite]

On Fri, Apr 22, 2016 at 4:44 AM, Andrew Baumann
<address@hidden> wrote:
> 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.

Setting up U-boot to be #4 could work.

>
> I discarded even considering option 3 because I assumed you wouldn't want a 
> FAT implementation linked into qemu.

rPI is not alone here though. Xilinx Zynq does exactly the same thing
with boot code pulling things out of SD card + FAT so you have at
least two precedents justifying the feature.

Regards,
Peter

> 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