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

[Sylvain Garrigues]

Le 22 avr. 2016 à 13:44, Andrew Baumann <address@hidden> 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 0x10000 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.