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