Date: Sat, 1 Apr 2017 22:30:43 +0000 From: Marcin Cieslak <saper@saper.info> To: freebsd-xen@freebsd.org Subject: Re: UEFI trouble with OVMF under Xen - nothing boots - SOLVED Message-ID: <alpine.BSF.2.20.1704012227150.1243@z.fncre.vasb> In-Reply-To: <alpine.BSF.2.20.1704011547270.1243@z.fncre.vasb> References: <alpine.BSF.2.20.1704011454040.1243@z.fncre.vasb> <alpine.BSF.2.20.1704011547270.1243@z.fncre.vasb>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 1 Apr 2017, Marcin Cieslak wrote: > On Sat, 1 Apr 2017, Marcin Cieslak wrote: > > > This is a follow up to the UEFI Windows boot problems > > reported after 4.7 got imported: > > > > https://lists.freebsd.org/pipermail/freebsd-xen/2016-June/002745.html > > > > I am using FreeBSD 12.0-CURRENT #6 r314708: Mon Mar 6 13:09:31 UTC 2017 root@o.saper.info:/usr/obj/usr/src/sys/GENERIC amd64 as dom0 > > > > In the 4.5 times I could install and boot Windows 2016 Technical Preview 5 without > > major problems. In fact, I started using this as my default Windows > > environment - it was working very well and very fast. > So, for the archives: I have compiled the newest OVMF git master in the DEBUG mode and found out that under normal qemu both I/O debug port 0x402 logging or serial port logging (depending how OVMF got compiled) do work. I have never been getting debug output from the OVMF started by Xen. What I didn't know is that firmware images are compiled into the hvmloader so that just replacing the ovmf.bin DOES NOT work. I must have had a 32-bit ovmf.bin on the filesystem when I was compiling xen-tools; after replacing it with a 64-bit version and rebuilding xen-tools things started to work. Sorry for noise! Marcin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1704012227150.1243>