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

[Peter Crosthwaite]

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

Regards,
Peter

>