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

[Peter Maydell]

On 21 April 2016 at 14:15, Sylvain Garrigues
<address@hidden> wrote:
> Le 21 avr. 2016 à 14:54, Peter Maydell <address@hidden> a écrit :
>> On 21 April 2016 at 13:50, Sylvain Garrigues
>> <address@hidden> wrote:
>>> BTW, would be great to be able to set the load addr on the command
>>> line, wouldn’t it?
>>
>> The booting protocol does not mandate any particular address
>> that the kernel has to be loaded at:
>> https://www.kernel.org/doc/Documentation/arm/Booting
>
> I didn’t know qemu would blindly follow and stick to Linux rules,
> but I understand. I use qemu for baremetal and *BSD emulation, I wish
> it would be easier to change the loading address (and not stick with
> Linux rules like so many people again) :-)

-kernel for a non-ELF file is specifically "boot a Linux kernel according
to the Linux kernel booting protocol". Your other options for booting
are (1) provide -kernel with an ELF file, which we will load at whatever
start address the ELF header specifies, or (2) on boards which have a
flash device, use -bios or -pflash options to specify a flash image to
go in that flash device (I don't think raspi2 has this yet though).
For bare metal testing either of those last two seem like a better
approach; you should also be able to wrap the FreeBSD kernel in an
ELF file to get it to work like that (you'll need to handle SMP
secondary boot yourself though; or just stick a relocation shim
on the front of the FreeBSD kernel).

The reason I'm a bit reluctant to add extra bells and whistles to
the builtin bootloader is that it can quickly get out of hand:
should we support all of Linux, FreeBSD, NetBSD, OpenBSD, Windows,
etc etc etc? At some point the right answer becomes "run the real
guest bootloader like u-boot from flash and let that start the
kernel".

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.

>> If the FreeBSD kernel can't handle being loaded wherever
>> we put it, that sounds like a FreeBSD bug to me…
>
> I would not say it is a bug, but an explicit assumption. Indeed, the
> kernel expects it is loaded on a 2 MB page boundary.
> I’m no expert, but I believe it was made so that we could remove the
> need for setting the physical address in the building process. The
> virtual to physical offset is computed more simply with that assumption.

> With the patch you committed for me earlier today (b4850e5), the patch
> we are talking about in this email (which is not a feature but a bug
> fix in my opinion)

FWIW, I agree this is a bug fix; it's just that we're hours away from
tagging the final RC for this release cycle, so the bar for "is this
bug important enough to put in now?" is quite high...

thanks
-- PMM