On Fri, Apr 22, 2016 at 4:44 AM, Andrew Baumann <andrew.baum...@microsoft.com> 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 >> <swar...@wwwdotorg.org> wrote: >> > On 04/21/2016 08:07 AM, Sylvain Garrigues wrote: >> >> >> >> Le 21 avr. 2016 à 15:42, Peter Maydell <peter.mayd...@linaro.org> 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