|Subject:||Re: [Qemu-devel] [Qemu-arm] [PATCH] bcm2835_property: use cached values when querying framebuffer|
|Date:||Fri, 22 Apr 2016 20:09:48 +0200|
|Le 22 avr. 2016 à 13:44, Andrew Baumann <address@hidden> a écrit :|
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,
|[Prev in Thread]||Current Thread||[Next in Thread]|