From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60026) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atVnJ-0001Rd-7b for qemu-devel@nongnu.org; Fri, 22 Apr 2016 03:46:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1atVnI-0003Xb-6d for qemu-devel@nongnu.org; Fri, 22 Apr 2016 03:46:29 -0400 Message-ID: <1461311177.28204.67.camel@redhat.com> From: Gerd Hoffmann Date: Fri, 22 Apr 2016 09:46:17 +0200 In-Reply-To: References: <1461235306-3393-1-git-send-email-sylvain@sylvaingarrigues.com> <5718FA7F.5030903@wwwdotorg.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Subject: Re: [Qemu-devel] [Qemu-arm] [PATCH] bcm2835_property: use cached values when querying framebuffer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Stephen Warren , Peter Maydell , Markus Armbruster , Andrew Baumann , QEMU Developers , qemu-arm , Sylvain Garrigues , Paolo Bonzini 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, every= thing > > (kernel, DTB/ATAGS, ARM boot stub, ...) is already loaded into RAM, the > > display is already probed over HDMI and the controller scanning out a d= ummy > > image, etc. > > > > So I think if that were to be supported, it'd have to be coded into qem= u. Is > > that something that could happen, or would such patches not fit qemu's = model > > well? >=20 > I made half a start on this project but had to shelve it. >=20 > 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.