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

[Sylvain Garrigues]

Le 22 avr. 2016 à 13:44, Andrew Baumann  a écrit :
> 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.


Having the ARM bootloader (called armstub in raspberry pi developers words), 
the config.txt file, and the « kernel » (whatever it is, ELF or raw binary) on 
a FAT portion of an SD card is convenient for real hardware: on a lambda user 
perspective, you just use your lambda computer to burn an image on a SD card 
(one you don’t use anymore with your camera), then insert it in your shiny new 
raspberry pi hardware.

QEMU in my opinion does not target the regular lambda user, and I wouldn’t go 
as far as mimicking the FAT / SD emulation boot process: my personal use case 
for qemu as a developer is « kernel » development / debugging and my workflow 
sums up to a simple loop: 

# vi some_kernel_source_code.c && make && qemu -kernel the_new_kernel_image
Do that 100 times a day.

Having to place my kernel in a FAT partition of a mounted disk image in my host 
OS would just complexity my process. I don’t expect my emulator to be 100% 
similar to the real hardware (it will never in the case of the Raspberry Pi, as 
long as the GPU firmware source code is closed). I just want to use my emulator 
to get things done fast (on my host computer rather than real hardware) and I 
want to emulate CPU and code (interrupts, etc) as closely as possible, without 
too much effort.

Having said that, I would give the qemu user who wants raspberry pi emulation 
these two functionalities that the raspberry pi firmware provides:
1/ ability to use a custom bootloader before launching the kernel: option 
armstub=somebootloader.bin in config.txt (be it u-boot or a custom stub which 
leaves HYP mode)
2/ ability to load your « kernel » at a specific address: option kernel_address 
in config.txt

So future -kernel-address and -bootloader qemu command line parameters (either 
specific to Raspberry pi or global) is my dream. That way I can play fast with 
whatever bootloader I want, play with HYP mode, and I can use whatever loading 
address I want. 

By the way, for the Raspberry Pi, the address is 0x8000 compared to the default 
0x1 for Arm in qemu, and being able to set it would enable to boot (without 
patching QEMU’s code) NetBSD images (compiled to work at 0x8000) and FreeBSD 
kernel without u-boot (requires the loading address to be a multiple of 2MB). 
Seems to me like basic functionality. I heard your argument Peter mentioning 
the linux boot protocol doesn’t mandate a loading address, and I find it is for 
this specific reason that which should let the user choose it. I also heard the 
« use an ELF » argument but some non-Linux kernels have by default a virtual 
(and not physical) address in their header, so doesn’t work straight out of the 
box.

Just my 2 cents :-) I however want to thank you all for the quality of the ARM 
emulation and more specifically the Raspberry Pi one, it opens many 
possibilities and is charm to work with.

Have a very good week-end all,
Sylvain.

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
 wrote:
> Hi all,
>
>> From: Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com]
>> Sent: Friday, 22 April 2016 09:18
>>
>> On Thu, Apr 21, 2016 at 9:06 AM, Stephen Warren
>>  wrote:
>> > On 04/21/2016 08:07 AM, Sylvain Garrigues wrote:
>> >>
>> >> Le 21 avr. 2016 à 15:42, Peter Maydell  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

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

[Peter Crosthwaite]

On Fri, Apr 22, 2016 at 12:46 AM, Gerd Hoffmann  wrote:
>   Hi,
>
>> > 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).
>
> 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.
>

Rather than a later boot stage, could we set this up to be identical
in functionality to the early boot stage? This enables baremetal devs
who want to debug from the real bootrom handoff (handoff from
VideoCore).

Doing it over FAT+bootloader code does however have the advantage of
not having to go through emulated SD card and TCG.

Regards,
Peter

> 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:   
>
> Recent linux kernels have trouble talking to the mmc too.

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

[Stephen Warren]

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

   Hi,


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


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:   


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.

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

[Andrew Baumann]

> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Friday, 22 April 2016 09:46
>
> 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.
> 
> 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:   
> 
> Recent linux kernels have trouble talking to the mmc too.

I know :( I haven't looked at the more recent kernels, but it could be the same 
issue I spent a while debugging fruitlessly on raspi1 -- it looked like Linux 
was issuing a large MMC read for N blocks, but only programming the DMA 
controller for fewer (

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

[Andrew Baumann]

Hi all,

> From: Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com]
> Sent: Friday, 22 April 2016 09:18
> 
> On Thu, Apr 21, 2016 at 9:06 AM, Stephen Warren
>  wrote:
> > On 04/21/2016 08:07 AM, Sylvain Garrigues wrote:
> >>
> >> Le 21 avr. 2016 à 15:42, Peter Maydell  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

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

[Gerd Hoffmann]

  Hi,

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

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.

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:   

Recent linux kernels have trouble talking to the mmc too.

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

[Peter Crosthwaite]

On Thu, Apr 21, 2016 at 9:06 AM, Stephen Warren  wrote:
> On 04/21/2016 08:07 AM, Sylvain Garrigues wrote:
>>
>> Le 21 avr. 2016 à 15:42, Peter Maydell  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

>

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

[Stephen Warren]

On 04/21/2016 08:07 AM, Sylvain Garrigues wrote:

Le 21 avr. 2016 à 15:42, Peter Maydell  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?