Re: [SeaBIOS] Chromebook doesn't boot BSD
On Mon, 15 Feb 2016 12:27:09 -0500 Kevin O'Connor wrote: > On Mon, Feb 15, 2016 at 05:16:06PM +0100, Ronny Schneider wrote: > > > Am 15.02.2016 um 15:40 schrieb edward wandasiewicz <0.w3...@gmail.com>: > > > On Sun, Feb 14, 2016 at 11:02 PM, Kevin O'Connor > > > wrote: > > >> - it looks more like the various BSD kernels don't like the USB > > >> controller and/or USB drive on your machine. Have you tried > > >> using a different type of USB drive for the install media? It's > > >> also possible there's something in the ACPI tables that coreboot > > >> provides that is confusing the BSDs. > > > > I tried several usb-sticks and sd-cards. Every time the same result: > > it doesn’t work. If i boot NetBSD without ACPI-support the screen > > turns black and stays this way until the machine is shut down. > > > > >> Your logs seem to indicate you also have an eMMC and an SD card. > > >> Have you tried placing the install media on an SD card instead of > > >> USB? > > > > That’s right. The main storage device of this Chromebook is an > > eMMC. Booting from SD card is working if it is a linux. BSD won’t > > start from. The same results as using an usb stick. > > > > >> Another thing you could do is launch the install media with the > > >> same verson of SeaBIOS on QEMU emulating an XHCI drive and SD > > >> drive - just to see if it's possible to reproduce outside of your > > >> particular machine. See below. > > > > Using QEMU it is working flawlessly, wether the SeaBIOS version is > > 1.8, 1.9 or 1.9.1 (which i compiled myself). So it really seems to > > be a problem with the BSDs. > > So, if both XHCI and SD work on QEMU, then I don't have much of a > guess as to what the underlying problem is. It's odd that two > independent hardware systems (xhci and sd) would both experience the > same failure to find the root drive. > > As a long shot, you could compile seabios without CONFIG_SDCARD and > then deploy it on your chromebook - just to see if booting from usb > then works. Similarly, you could try without CONFIG_USB_XHCI to see > if sd somehow then works. I don't have much hope either would help > though. > > The other option would be to follow up with the various BSD developers > to see if you can extract more debug information to narrow down the > cause of the failure. > > -Kevin I opened a bug at the DragonFlyBSD list for bugs and will see if someone can help with this problem: https://bugs.dragonflybsd.org/issues/2890 Maybe i have to get in touch with the other BSD-devs. Thank you all so far! :-) Best greetings, -- Ronny Schneider ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v3 3/3] fw/pci: Allocate IGD stolen memory
On Mon, Feb 15, 2016 at 02:50:41PM -0500, Kevin O'Connor wrote: > On Mon, Feb 15, 2016 at 09:29:26PM +0200, Michael S. Tsirkin wrote: > > I can build a generic interface to pass addresses > > allocated by bios back to QEMU. It looks like this would > > be useful for other purposes as well. Interested? > > If this is undertaken, I suggest extending fw_cfg to support "writable > files" instead of introducing a whole new interface. > > -Kevin Exactly, this is what I had in mind. -- MST ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v3 3/3] fw/pci: Allocate IGD stolen memory
On Mon, 15 Feb 2016 21:29:26 +0200 "Michael S. Tsirkin" wrote: > On Mon, Feb 15, 2016 at 12:20:23PM -0700, Alex Williamson wrote: > > On Mon, 15 Feb 2016 10:54:51 +0100 > > Igor Mammedov wrote: > > > > > On Sat, 13 Feb 2016 18:03:31 -0700 > > > Alex Williamson wrote: > > > > > > > On Sat, 13 Feb 2016 19:20:32 -0500 > > > > "Kevin O'Connor" wrote: > > > > > > > > > On Sat, Feb 13, 2016 at 01:57:09PM -0700, Alex Williamson wrote: > > > > > > On Sat, 13 Feb 2016 15:05:09 -0500 > > > > > > "Kevin O'Connor" wrote: > > > > > > > On Sat, Feb 13, 2016 at 11:51:51AM -0700, Alex Williamson wrote: > > > > > > > > > > > > > > > On Sat, 13 Feb 2016 13:18:39 -0500 > > > > > > > > "Kevin O'Connor" wrote: > > > > > > > > > On Sat, Feb 13, 2016 at 08:12:09AM -0700, Alex Williamson > > > > > > > > > wrote: > > > > > > > > > > On Fri, 12 Feb 2016 21:49:04 -0500 > > > > > > > > > > "Kevin O'Connor" wrote: > > > > > > > > > > > On Fri, Feb 12, 2016 at 05:23:18PM -0700, Alex Williamson > > > > > > > > > > > wrote: > > > > > > > > > > > > Intel IGD makes use of memory allocated and marked > > > > > > > > > > > > reserved by the > > > > > > > > > > > > BIOS as a stolen memory range. For the most part, > > > > > > > > > > > > guest drivers don't > > > > > > > > > > > > make use of this, but our achilles heel is the vBIOS. > > > > > > > > > > > > The vBIOS > > > > > > > > > > > > programs the device to use the host stolen memory range > > > > > > > > > > > > and it's used > > > > > > > > > > > > in the pre-boot environment. Generally the guest won't > > > > > > > > > > > > have access to > > > > > > > > > > > > the host stolen memory area, so these accesses either > > > > > > > > > > > > land in VM > > > > > > > > > > > > memory or unassigned space and generate IOMMU faults. > > > > > > > > > > > > By allocating > > > > > > > > > > > > this range in SeaBIOS and programming it into the > > > > > > > > > > > > device, QEMU (via > > > > > > > > > > > > vfio) can make sure this guest allocated stolen memory > > > > > > > > > > > > range is used > > > > > > > > > > > > instead. > > > > > > > > > > > > > > > > > > > > > > What does "vBIOS" mean in this context? Is it the video > > > > > > > > > > > device option > > > > > > > > > > > rom or something else? > > > > > > > > > > > > > > > > > > > > vBIOS = video BIOS, you're correct, it's just the video > > > > > > > > > > device option > > > > > > > > > > ROM. > > > > > > > > > > > > > > > > > > Is the problem from when the host runs the video option rom, > > > > > > > > > or is the > > > > > > > > > problem from the guest (via SeaBIOS) running the video option > > > > > > > > > rom? If > > > > > > > > > the guest is running the option rom, is it the first time the > > > > > > > > > option > > > > > > > > > rom has been run for the machine (ie, was the option rom not > > > > > > > > > executed > > > > > > > > > on the host when the host machine first booted)? > > > > > > > > > > > > > > > > > > FWIW, many of the chromebooks use coreboot with Intel > > > > > > > > > graphics and a > > > > > > > > > number of users have installed SeaBIOS (running natively) on > > > > > > > > > their > > > > > > > > > machines. Running the intel video option rom more than once > > > > > > > > > has been > > > > > > > > > known to cause issues. > > > > > > > > > > > > > > > > The issue is in the VM and it occurs every time the option ROM > > > > > > > > is > > > > > > > > executed. Standard VGA text mode displays fine (ex. SeaBIOS > > > > > > > > version > > > > > > > > string and boot menu), but any sort of extended graphics mode > > > > > > > > (ex. live > > > > > > > > CD boot menu) tries to make use of the host memory area which > > > > > > > > corresponds to the stolen memory area of the physical device. > > > > > > > > We're > > > > > > > > not really sure how the ROM execution arrives at these > > > > > > > > addresses (not > > > > > > > > from the device according to access traces), but we can see > > > > > > > > when the > > > > > > > > ROM is writing these addresses to the device and modify they > > > > > > > > addresses > > > > > > > > to point at a VM memory range which we've allocated. That's > > > > > > > > what this > > > > > > > > code attempts to do, allocate a buffer and tell QEMU about it > > > > > > > > via the > > > > > > > > BDSM (Base Data of Stolen Memory) register. > > > > > > > > > > > > > > Forgive me if I'm not fully understanding this. If I read what > > > > > > > you're > > > > > > > saying then the sequence is something like: > > > > > > > > > > > > > > 1 - the host system bios (or vgabios) programs the GTT/stolen > > > > > > > memory > > > > > > > base register at host system bootup time and reserves it in > > > > > > > the > > > > > > > host e820 map. > > > > > > > > > > > > > >
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v3 3/3] fw/pci: Allocate IGD stolen memory
On Mon, Feb 15, 2016 at 09:29:26PM +0200, Michael S. Tsirkin wrote: > I can build a generic interface to pass addresses > allocated by bios back to QEMU. It looks like this would > be useful for other purposes as well. Interested? If this is undertaken, I suggest extending fw_cfg to support "writable files" instead of introducing a whole new interface. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v3 3/3] fw/pci: Allocate IGD stolen memory
On Mon, Feb 15, 2016 at 12:20:23PM -0700, Alex Williamson wrote: > On Mon, 15 Feb 2016 10:54:51 +0100 > Igor Mammedov wrote: > > > On Sat, 13 Feb 2016 18:03:31 -0700 > > Alex Williamson wrote: > > > > > On Sat, 13 Feb 2016 19:20:32 -0500 > > > "Kevin O'Connor" wrote: > > > > > > > On Sat, Feb 13, 2016 at 01:57:09PM -0700, Alex Williamson wrote: > > > > > On Sat, 13 Feb 2016 15:05:09 -0500 > > > > > "Kevin O'Connor" wrote: > > > > > > On Sat, Feb 13, 2016 at 11:51:51AM -0700, Alex Williamson wrote: > > > > > > > > > > > > > On Sat, 13 Feb 2016 13:18:39 -0500 > > > > > > > "Kevin O'Connor" wrote: > > > > > > > > On Sat, Feb 13, 2016 at 08:12:09AM -0700, Alex Williamson > > > > > > > > wrote: > > > > > > > > > On Fri, 12 Feb 2016 21:49:04 -0500 > > > > > > > > > "Kevin O'Connor" wrote: > > > > > > > > > > On Fri, Feb 12, 2016 at 05:23:18PM -0700, Alex Williamson > > > > > > > > > > wrote: > > > > > > > > > > > Intel IGD makes use of memory allocated and marked > > > > > > > > > > > reserved by the > > > > > > > > > > > BIOS as a stolen memory range. For the most part, guest > > > > > > > > > > > drivers don't > > > > > > > > > > > make use of this, but our achilles heel is the vBIOS. > > > > > > > > > > > The vBIOS > > > > > > > > > > > programs the device to use the host stolen memory range > > > > > > > > > > > and it's used > > > > > > > > > > > in the pre-boot environment. Generally the guest won't > > > > > > > > > > > have access to > > > > > > > > > > > the host stolen memory area, so these accesses either > > > > > > > > > > > land in VM > > > > > > > > > > > memory or unassigned space and generate IOMMU faults. By > > > > > > > > > > > allocating > > > > > > > > > > > this range in SeaBIOS and programming it into the device, > > > > > > > > > > > QEMU (via > > > > > > > > > > > vfio) can make sure this guest allocated stolen memory > > > > > > > > > > > range is used > > > > > > > > > > > instead. > > > > > > > > > > > > > > > > > > > > What does "vBIOS" mean in this context? Is it the video > > > > > > > > > > device option > > > > > > > > > > rom or something else? > > > > > > > > > > > > > > > > > > vBIOS = video BIOS, you're correct, it's just the video > > > > > > > > > device option > > > > > > > > > ROM. > > > > > > > > > > > > > > > > Is the problem from when the host runs the video option rom, or > > > > > > > > is the > > > > > > > > problem from the guest (via SeaBIOS) running the video option > > > > > > > > rom? If > > > > > > > > the guest is running the option rom, is it the first time the > > > > > > > > option > > > > > > > > rom has been run for the machine (ie, was the option rom not > > > > > > > > executed > > > > > > > > on the host when the host machine first booted)? > > > > > > > > > > > > > > > > FWIW, many of the chromebooks use coreboot with Intel graphics > > > > > > > > and a > > > > > > > > number of users have installed SeaBIOS (running natively) on > > > > > > > > their > > > > > > > > machines. Running the intel video option rom more than once > > > > > > > > has been > > > > > > > > known to cause issues. > > > > > > > > > > > > > > The issue is in the VM and it occurs every time the option ROM is > > > > > > > executed. Standard VGA text mode displays fine (ex. SeaBIOS > > > > > > > version > > > > > > > string and boot menu), but any sort of extended graphics mode > > > > > > > (ex. live > > > > > > > CD boot menu) tries to make use of the host memory area which > > > > > > > corresponds to the stolen memory area of the physical device. > > > > > > > We're > > > > > > > not really sure how the ROM execution arrives at these addresses > > > > > > > (not > > > > > > > from the device according to access traces), but we can see when > > > > > > > the > > > > > > > ROM is writing these addresses to the device and modify they > > > > > > > addresses > > > > > > > to point at a VM memory range which we've allocated. That's what > > > > > > > this > > > > > > > code attempts to do, allocate a buffer and tell QEMU about it via > > > > > > > the > > > > > > > BDSM (Base Data of Stolen Memory) register. > > > > > > > > > > > > Forgive me if I'm not fully understanding this. If I read what > > > > > > you're > > > > > > saying then the sequence is something like: > > > > > > > > > > > > 1 - the host system bios (or vgabios) programs the GTT/stolen memory > > > > > > base register at host system bootup time and reserves it in the > > > > > > host e820 map. > > > > > > > > > > > > 2 - upon running qemu, the guest reruns the vga bios option rom > > > > > > which > > > > > > seems to work (ie, text mode works) > > > > > > > > > > > > 3 - in the guest, upon running a bootloader that uses graphics mode, > > > > > > the bootloader calls the vgabios to switch to graphics mode, and > > > > > > the vgabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v3 3/3] fw/pci: Allocate IGD stolen memory
On Mon, 15 Feb 2016 10:54:51 +0100 Igor Mammedov wrote: > On Sat, 13 Feb 2016 18:03:31 -0700 > Alex Williamson wrote: > > > On Sat, 13 Feb 2016 19:20:32 -0500 > > "Kevin O'Connor" wrote: > > > > > On Sat, Feb 13, 2016 at 01:57:09PM -0700, Alex Williamson wrote: > > > > On Sat, 13 Feb 2016 15:05:09 -0500 > > > > "Kevin O'Connor" wrote: > > > > > On Sat, Feb 13, 2016 at 11:51:51AM -0700, Alex Williamson wrote: > > > > > > On Sat, 13 Feb 2016 13:18:39 -0500 > > > > > > "Kevin O'Connor" wrote: > > > > > > > On Sat, Feb 13, 2016 at 08:12:09AM -0700, Alex Williamson wrote: > > > > > > > > > > > > > > > On Fri, 12 Feb 2016 21:49:04 -0500 > > > > > > > > "Kevin O'Connor" wrote: > > > > > > > > > On Fri, Feb 12, 2016 at 05:23:18PM -0700, Alex Williamson > > > > > > > > > wrote: > > > > > > > > > > Intel IGD makes use of memory allocated and marked reserved > > > > > > > > > > by the > > > > > > > > > > BIOS as a stolen memory range. For the most part, guest > > > > > > > > > > drivers don't > > > > > > > > > > make use of this, but our achilles heel is the vBIOS. The > > > > > > > > > > vBIOS > > > > > > > > > > programs the device to use the host stolen memory range and > > > > > > > > > > it's used > > > > > > > > > > in the pre-boot environment. Generally the guest won't > > > > > > > > > > have access to > > > > > > > > > > the host stolen memory area, so these accesses either land > > > > > > > > > > in VM > > > > > > > > > > memory or unassigned space and generate IOMMU faults. By > > > > > > > > > > allocating > > > > > > > > > > this range in SeaBIOS and programming it into the device, > > > > > > > > > > QEMU (via > > > > > > > > > > vfio) can make sure this guest allocated stolen memory > > > > > > > > > > range is used > > > > > > > > > > instead. > > > > > > > > > > > > > > > > > > What does "vBIOS" mean in this context? Is it the video > > > > > > > > > device option > > > > > > > > > rom or something else? > > > > > > > > > > > > > > > > vBIOS = video BIOS, you're correct, it's just the video device > > > > > > > > option > > > > > > > > ROM. > > > > > > > > > > > > > > Is the problem from when the host runs the video option rom, or > > > > > > > is the > > > > > > > problem from the guest (via SeaBIOS) running the video option > > > > > > > rom? If > > > > > > > the guest is running the option rom, is it the first time the > > > > > > > option > > > > > > > rom has been run for the machine (ie, was the option rom not > > > > > > > executed > > > > > > > on the host when the host machine first booted)? > > > > > > > > > > > > > > FWIW, many of the chromebooks use coreboot with Intel graphics > > > > > > > and a > > > > > > > number of users have installed SeaBIOS (running natively) on their > > > > > > > machines. Running the intel video option rom more than once has > > > > > > > been > > > > > > > known to cause issues. > > > > > > > > > > > > The issue is in the VM and it occurs every time the option ROM is > > > > > > executed. Standard VGA text mode displays fine (ex. SeaBIOS version > > > > > > string and boot menu), but any sort of extended graphics mode (ex. > > > > > > live > > > > > > CD boot menu) tries to make use of the host memory area which > > > > > > corresponds to the stolen memory area of the physical device. We're > > > > > > not really sure how the ROM execution arrives at these addresses > > > > > > (not > > > > > > from the device according to access traces), but we can see when the > > > > > > ROM is writing these addresses to the device and modify they > > > > > > addresses > > > > > > to point at a VM memory range which we've allocated. That's what > > > > > > this > > > > > > code attempts to do, allocate a buffer and tell QEMU about it via > > > > > > the > > > > > > BDSM (Base Data of Stolen Memory) register. > > > > > > > > > > Forgive me if I'm not fully understanding this. If I read what you're > > > > > saying then the sequence is something like: > > > > > > > > > > 1 - the host system bios (or vgabios) programs the GTT/stolen memory > > > > > base register at host system bootup time and reserves it in the > > > > > host e820 map. > > > > > > > > > > 2 - upon running qemu, the guest reruns the vga bios option rom which > > > > > seems to work (ie, text mode works) > > > > > > > > > > 3 - in the guest, upon running a bootloader that uses graphics mode, > > > > > the bootloader calls the vgabios to switch to graphics mode, and > > > > > the vgabios sends commands to the graphics hardware that somehow > > > > > reference the host stolen memory > > > > > > > > What exactly happens here isn't clear to me, but this is a plausible > > > > explanation. What we see in tracing access to the hardware is that a > > > > bunch of addresses are written to the device that fall within the host > > > >
Re: [SeaBIOS] [RFC PATCH v3 3/3] fw/pci: Allocate IGD stolen memory
On Mon, 15 Feb 2016 11:31:41 +0100 Gerd Hoffmann wrote: > Hi, > > > The issue is in the VM and it occurs every time the option ROM is > > executed. Standard VGA text mode displays fine (ex. SeaBIOS version > > string and boot menu), but any sort of extended graphics mode (ex. live > > CD boot menu) tries to make use of the host memory area which > > corresponds to the stolen memory area of the physical device. > > I'm wondering whenever we can just use seavgabios (and support standard > vga modes only). The reason we need the vBIOS is to turn on the LCD panel, which in turn has this dependency on the stolen memory area. I'd be pretty surprised if a generic VGA BIOS affected the panel in any way. Maybe seavgabios could be used for desktop IGD assignment, though I don't really know how to detect an attached panel. Thanks, Alex ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Chromebook doesn't boot BSD
On Mon, Feb 15, 2016 at 05:16:06PM +0100, Ronny Schneider wrote: > > Am 15.02.2016 um 15:40 schrieb edward wandasiewicz <0.w3...@gmail.com>: > > On Sun, Feb 14, 2016 at 11:02 PM, Kevin O'Connor wrote: > >> - it looks more like the various BSD kernels don't like the USB > >> controller and/or USB drive on your machine. Have you tried > >> using a different type of USB drive for the install media? It's > >> also possible there's something in the ACPI tables that coreboot > >> provides that is confusing the BSDs. > > I tried several usb-sticks and sd-cards. Every time the same result: > it doesn’t work. If i boot NetBSD without ACPI-support the screen > turns black and stays this way until the machine is shut down. > > >> Your logs seem to indicate you also have an eMMC and an SD card. > >> Have you tried placing the install media on an SD card instead of > >> USB? > > That’s right. The main storage device of this Chromebook is an > eMMC. Booting from SD card is working if it is a linux. BSD won’t > start from. The same results as using an usb stick. > > >> Another thing you could do is launch the install media with the > >> same verson of SeaBIOS on QEMU emulating an XHCI drive and SD > >> drive - just to see if it's possible to reproduce outside of your > >> particular machine. See below. > > Using QEMU it is working flawlessly, wether the SeaBIOS version is > 1.8, 1.9 or 1.9.1 (which i compiled myself). So it really seems to > be a problem with the BSDs. So, if both XHCI and SD work on QEMU, then I don't have much of a guess as to what the underlying problem is. It's odd that two independent hardware systems (xhci and sd) would both experience the same failure to find the root drive. As a long shot, you could compile seabios without CONFIG_SDCARD and then deploy it on your chromebook - just to see if booting from usb then works. Similarly, you could try without CONFIG_USB_XHCI to see if sd somehow then works. I don't have much hope either would help though. The other option would be to follow up with the various BSD developers to see if you can extract more debug information to narrow down the cause of the failure. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Chromebook doesn't boot BSD
> Am 15.02.2016 um 15:40 schrieb edward wandasiewicz <0.w3...@gmail.com>: > > On Sun, Feb 14, 2016 at 11:02 PM, Kevin O'Connor wrote: >> On Sun, Feb 14, 2016 at 08:30:47PM +0100, Ronny Schneider wrote: Am 14.02.2016 um 19:29 schrieb Kevin O'Connor : On Sun, Feb 14, 2016 at 06:04:16PM +0100, Ronny Schneider wrote: > Hello there, > > i have a Toshiba Chromebook 2 (CB30-B-104) with a flashed on SeaBIOS by > the script from John Lewis: > https://johnlewis.ie/custom-chromebook-firmware/rom-download/ > > Linux is running very well but i want to see OpenBSD 5.8 on this laptop. > But it’s not working, neither do FreeBSD 10.2, NetBSD 7.0 or DragonFly > 4.2. The boot stops at the point where the kernel wants to mount the > root-filesystem. I even copied an installed OpenBSD-System from an > usb-stick onto the emmc-flash of the chromebook but it’s not working. > > I googled arround and found out the problem is not unknown among the > Chromebook Pixel. So i thought i could help a little by providing my > cbmem-bootlog for my machine: http://pastebin.com/asLqar5q > If i can do more to see OpenBSD booting on this laptop, please let me > know :-) When you say "it's not working" - what happens - does the machine hang or does it attempt to reboot? If it hangs, are you sure the machine is really stuck instead of just the display not working? >>> >>> The Display is working all the time. Using NetBSD, it also applies the >>> native resolution of the panel. >>> If it hangs, can you provide all the information on the screen prior to the hang. >>> >>> I used the amd64 install-images on an 64GB USB3-Stick for the following >>> pictures. If you want me to copy the installer-images onto the mmc of the >>> chromebook, tell me please. >>> >>> With FreeBSD 11 it freezes. The machine hangs at the moment the kernel >>> tries to mount the root-filesystem and does not respond to any keypress >>> anymore. I have to shutdown the chromebook by keep pressing on the >>> powerbutton for a few seconds. >>> Image: http://bilderhochladen.org/i/SFrHFStWws/ >>> >>> With OpenBSD 5.8 it „stalls“. The Cursor is blinking but nothing more >>> happens. Although the chromebook shuts down when the powerbutton is pressed. >>> Image: http://bilderhochladen.org/i/4jFRYDYO11/ >>> >>> With NetBSD 7.0 it „stalls“ too. The Cursor is not blinking but i can enter >>> a „root device“. If nothing is entered it gives me the choice of either >>> „ddb“, „halt“ or „reboot“. „Halt" and „Reboot" are working properly, the >>> machine shuts down or reboots correctly. >>> Image 1: http://bilderhochladen.org/i/zgq1usG2Ri/ >>> Image 2: http://bilderhochladen.org/i/EqVSDbn25x/ >>> >>> With Dragonfly 4.2 the kernel stops at the moment it tries to mount the >>> root-filesystem and asks me to enter the device. The machine has to be shut >>> down via holding the powerbutton for a few seconds. >>> Image 1: http://bilderhochladen.org/i/TRIdjee9VP/ >>> Image 2: http://bilderhochladen.org/i/khPrwt4P0C/ >>> >> >> So if I understand correctly, you are attempting to launch BSD install >> media from a USB drive, and the installer fails to start? >> >> This doesn't look like a typical SeaBIOS issue > > Try OpenBSD snapshots. > > You're findings on the Toshiba Chromebook 2 may vary from what I found > with the Chromebook Pixel 2015. > > bsd.rd - you cant directly boot a bsd.rd kernel as it doesn't load > inteldrm. VGA only, but there's no VGA 800x600 resolution for SeaBIOS > to use, hence no dmesg output. It does boot, but you don't see the > screen changes. > > bsd - snapshots only - will load inteldrm > > bsd 5.8 - will not load inteldrm > > It will load the kernel (bsd snapsots) but won't display any dmesg > output, until the kernel finds inteldrm, then it will output dmesg and > hey presto, we've booted up. > > If you want to update OpenBSD bsd, I use arch Linux and boot bsd.rd > through qemu. > > This patch > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/drm/i915/i915_drv.c?sortby=date > > Revision 1.95 fixes this issue, hence snapshots only. > > This only refers to the Chromebook Pixel 2015 only. > > If we run > > $ vbeinfo > > in grub2, we only get one resolution available, of 1280 x 850 x 16. No > 800 x 600, so no dmesg output till inteldrm hits. > > Coolstar organisation on Google+ (search coreboot Google+) has found a > patch for Coreboot to fix this resolution problem at boot,. > > I used > > http://goo.gl/9sgchs > > from https://wiki.archlinux.org/index.php/Chrome_OS_devices > > to repartition the SSD on the Pixel 2015, install Arch, Grub2 & > OpenBSD keeping ChromeOS too for updates to Coreboot & SeaBIOS. > > You can install OpenBSD to the SSD and write the MBR (no Grub > installed) and it will boot up via Ctrl-L keeping ChromeOS via Ctrl-D. > But you need another OS to boot bsd.rd via qemu to upd
Re: [SeaBIOS] Chromebook doesn't boot BSD
On Sun, Feb 14, 2016 at 11:02 PM, Kevin O'Connor wrote: > On Sun, Feb 14, 2016 at 08:30:47PM +0100, Ronny Schneider wrote: >> > Am 14.02.2016 um 19:29 schrieb Kevin O'Connor : >> > On Sun, Feb 14, 2016 at 06:04:16PM +0100, Ronny Schneider wrote: >> >> Hello there, >> >> >> >> i have a Toshiba Chromebook 2 (CB30-B-104) with a flashed on SeaBIOS by >> >> the script from John Lewis: >> >> https://johnlewis.ie/custom-chromebook-firmware/rom-download/ >> >> >> >> Linux is running very well but i want to see OpenBSD 5.8 on this laptop. >> >> But it’s not working, neither do FreeBSD 10.2, NetBSD 7.0 or DragonFly >> >> 4.2. The boot stops at the point where the kernel wants to mount the >> >> root-filesystem. I even copied an installed OpenBSD-System from an >> >> usb-stick onto the emmc-flash of the chromebook but it’s not working. >> >> >> >> I googled arround and found out the problem is not unknown among the >> >> Chromebook Pixel. So i thought i could help a little by providing my >> >> cbmem-bootlog for my machine: http://pastebin.com/asLqar5q >> >> If i can do more to see OpenBSD booting on this laptop, please let me >> >> know :-) >> > >> > When you say "it's not working" - what happens - does the machine hang or >> > does it attempt to reboot? >> > If it hangs, are you sure the machine is really stuck instead of just the >> > display not working? >> >> The Display is working all the time. Using NetBSD, it also applies the >> native resolution of the panel. >> >> > If it hangs, can you provide all the information on the screen prior to >> > the hang. >> >> I used the amd64 install-images on an 64GB USB3-Stick for the following >> pictures. If you want me to copy the installer-images onto the mmc of the >> chromebook, tell me please. >> >> With FreeBSD 11 it freezes. The machine hangs at the moment the kernel tries >> to mount the root-filesystem and does not respond to any keypress anymore. I >> have to shutdown the chromebook by keep pressing on the powerbutton for a >> few seconds. >> Image: http://bilderhochladen.org/i/SFrHFStWws/ >> >> With OpenBSD 5.8 it „stalls“. The Cursor is blinking but nothing more >> happens. Although the chromebook shuts down when the powerbutton is pressed. >> Image: http://bilderhochladen.org/i/4jFRYDYO11/ >> >> With NetBSD 7.0 it „stalls“ too. The Cursor is not blinking but i can enter >> a „root device“. If nothing is entered it gives me the choice of either >> „ddb“, „halt“ or „reboot“. „Halt" and „Reboot" are working properly, the >> machine shuts down or reboots correctly. >> Image 1: http://bilderhochladen.org/i/zgq1usG2Ri/ >> Image 2: http://bilderhochladen.org/i/EqVSDbn25x/ >> >> With Dragonfly 4.2 the kernel stops at the moment it tries to mount the >> root-filesystem and asks me to enter the device. The machine has to be shut >> down via holding the powerbutton for a few seconds. >> Image 1: http://bilderhochladen.org/i/TRIdjee9VP/ >> Image 2: http://bilderhochladen.org/i/khPrwt4P0C/ >> > > So if I understand correctly, you are attempting to launch BSD install > media from a USB drive, and the installer fails to start? > > This doesn't look like a typical SeaBIOS issue Try OpenBSD snapshots. You're findings on the Toshiba Chromebook 2 may vary from what I found with the Chromebook Pixel 2015. bsd.rd - you cant directly boot a bsd.rd kernel as it doesn't load inteldrm. VGA only, but there's no VGA 800x600 resolution for SeaBIOS to use, hence no dmesg output. It does boot, but you don't see the screen changes. bsd - snapshots only - will load inteldrm bsd 5.8 - will not load inteldrm It will load the kernel (bsd snapsots) but won't display any dmesg output, until the kernel finds inteldrm, then it will output dmesg and hey presto, we've booted up. If you want to update OpenBSD bsd, I use arch Linux and boot bsd.rd through qemu. This patch http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/drm/i915/i915_drv.c?sortby=date Revision 1.95 fixes this issue, hence snapshots only. This only refers to the Chromebook Pixel 2015 only. If we run $ vbeinfo in grub2, we only get one resolution available, of 1280 x 850 x 16. No 800 x 600, so no dmesg output till inteldrm hits. Coolstar organisation on Google+ (search coreboot Google+) has found a patch for Coreboot to fix this resolution problem at boot,. I used http://goo.gl/9sgchs from https://wiki.archlinux.org/index.php/Chrome_OS_devices to repartition the SSD on the Pixel 2015, install Arch, Grub2 & OpenBSD keeping ChromeOS too for updates to Coreboot & SeaBIOS. You can install OpenBSD to the SSD and write the MBR (no Grub installed) and it will boot up via Ctrl-L keeping ChromeOS via Ctrl-D. But you need another OS to boot bsd.rd via qemu to update files from snapshots/amd64 to upgrade OpenBSD going forward. Haven't tried the other BSD's. Edward. >- it looks more like > the various BSD kernels don't like the USB controller and/or USB drive > on your machine. Have you tried
Re: [SeaBIOS] ipxe/seabios: segment register initialization
On Mon, Feb 15, 2016 at 08:43:18AM +0200, Michael S. Tsirkin wrote: > On Mon, Feb 15, 2016 at 01:07:09AM +, Michael Brown wrote: > > On 14/02/16 19:52, Michael S. Tsirkin wrote: > > >On Sun, Feb 14, 2016 at 05:36:38PM +, Michael Brown wrote: > > >>On 14/02/16 15:53, Michael S. Tsirkin wrote: > > >>>do you think %DS should be zeroed when NBP is called then? > > >> > > >>Not according to the PXE spec. > > >> > > >>As far as I can tell, the initial value of %ds is undefined for both a PXE > > >>NBP and a BIOS boot sector. > > > > > >Thanks, > > > > Out of interest: did this question arise as a purely academic curiosity, or > > is there some product in existence which creates a boot sector that relies > > on %ds==0? > > > > Michael > > FWIW QEMU has a unit test with a boot sector that relies on %ds=0: > https://git.kernel.org/cgit/virt/kvm/mst/qemu.git/tree/tests/bios-tables-test.c?h=pci > (search for boot_sector in this file). > > It's a test, not a product though, and would be easy to change not to > rely on this. FYI, I agree with Michael Brown - I know of no spec requiring %ds (nor most of the other cpu registers) to be initialized when invoking the boot sector. SeaBIOS does currently zero most registers, but this was done for general "data cleanliness" reasons. I would recommend that bootloaders not rely on any particular initial cpu state. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [RFC PATCH v3 3/3] fw/pci: Allocate IGD stolen memory
On Sat, Feb 13, 2016 at 06:03:31PM -0700, Alex Williamson wrote: > On Sat, 13 Feb 2016 19:20:32 -0500 > "Kevin O'Connor" wrote: > > This confuses me - why didn't the host system BIOS turn on the LCD > > panel during host bootup? > > It turns off when we reset the device between VM instances or between > VM boots. IGD supports Function Level Reset (FLR). > > > >Another desktop IvyBridge system > > > doesn't really care about the vBIOS so long as we don't ask it to > > > output anything before the guest native drivers are loaded. If we > > > could, I think we'd just enable vBIOS for laptop panel support, but > > > that's really not an option, it's going to run as a boot option ROM as > > > well, so we need to fix the issues that it generates there. > > > > From my experience with coreboot, running the vga option rom multiple > > times during a given boot is very fragile. (By multiple times, I mean > > either the host running it and then a guest, or running it multiple > > times from multiple guests.) YMMV. > > We do this regularly for graphics assignment, Nvidia, AMD, and now > Intel. It generally works ok. Perhaps you've seen issues with the > option ROM being run multiple times without resetting the device. I > could certainly believe that. Interesting. Using the FLR could be useful on some coreboot systems where users want to run the option rom twice. Thanks. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] AHCI: Set transfer mode according to the capabilities of connected drive
Hi Kevin. We had some issues with some connected AHCI devices in SeaBIOS. We have connected some CF-Cards by using a simple SATA<->IDE bridge to the mainboard and in some cases, the drive (which is the CF-card) was not recognized correctly. After some deeper analysis we found that SeaBIOS does not set up the transfer rate which is used to communicate to the drive. The supported transfer rate can be found in the data structure which is delivered by IDENTIFY_DEVICE command. So in our error cases the default transfer rate was too high and therefore data error has occurred. I have attached a patch which will deal with this case on AHCI controllers. Maybe you can push this patch to mainline or at least have a look at it. Up to now I have verified the function of this patch with the latest master branch of SeaBIOS and a Broadwell-DE CPU. I have used PIO4, default PIO, Multiword-DMA2 and several Ultra-DMA CF-cards to ensure that all three paths work properly. BTW: I am not that familiar with code style in SeaBIOS. If I made some formal mistakes, feel free to correct them. Thank you in advance Werner ahci_transfermode.diff Description: ahci_transfermode.diff ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [RFC PATCH v3 3/3] fw/pci: Allocate IGD stolen memory
Hi, > The issue is in the VM and it occurs every time the option ROM is > executed. Standard VGA text mode displays fine (ex. SeaBIOS version > string and boot menu), but any sort of extended graphics mode (ex. live > CD boot menu) tries to make use of the host memory area which > corresponds to the stolen memory area of the physical device. I'm wondering whenever we can just use seavgabios (and support standard vga modes only). cheers, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v3 3/3] fw/pci: Allocate IGD stolen memory
On Sat, 13 Feb 2016 18:03:31 -0700 Alex Williamson wrote: > On Sat, 13 Feb 2016 19:20:32 -0500 > "Kevin O'Connor" wrote: > > > On Sat, Feb 13, 2016 at 01:57:09PM -0700, Alex Williamson wrote: > > > On Sat, 13 Feb 2016 15:05:09 -0500 > > > "Kevin O'Connor" wrote: > > > > On Sat, Feb 13, 2016 at 11:51:51AM -0700, Alex Williamson wrote: > > > > > On Sat, 13 Feb 2016 13:18:39 -0500 > > > > > "Kevin O'Connor" wrote: > > > > > > On Sat, Feb 13, 2016 at 08:12:09AM -0700, Alex Williamson wrote: > > > > > > > > > > > > > On Fri, 12 Feb 2016 21:49:04 -0500 > > > > > > > "Kevin O'Connor" wrote: > > > > > > > > On Fri, Feb 12, 2016 at 05:23:18PM -0700, Alex Williamson > > > > > > > > wrote: > > > > > > > > > Intel IGD makes use of memory allocated and marked reserved > > > > > > > > > by the > > > > > > > > > BIOS as a stolen memory range. For the most part, guest > > > > > > > > > drivers don't > > > > > > > > > make use of this, but our achilles heel is the vBIOS. The > > > > > > > > > vBIOS > > > > > > > > > programs the device to use the host stolen memory range and > > > > > > > > > it's used > > > > > > > > > in the pre-boot environment. Generally the guest won't have > > > > > > > > > access to > > > > > > > > > the host stolen memory area, so these accesses either land in > > > > > > > > > VM > > > > > > > > > memory or unassigned space and generate IOMMU faults. By > > > > > > > > > allocating > > > > > > > > > this range in SeaBIOS and programming it into the device, > > > > > > > > > QEMU (via > > > > > > > > > vfio) can make sure this guest allocated stolen memory range > > > > > > > > > is used > > > > > > > > > instead. > > > > > > > > > > > > > > > > What does "vBIOS" mean in this context? Is it the video device > > > > > > > > option > > > > > > > > rom or something else? > > > > > > > > > > > > > > vBIOS = video BIOS, you're correct, it's just the video device > > > > > > > option > > > > > > > ROM. > > > > > > > > > > > > Is the problem from when the host runs the video option rom, or is > > > > > > the > > > > > > problem from the guest (via SeaBIOS) running the video option rom? > > > > > > If > > > > > > the guest is running the option rom, is it the first time the option > > > > > > rom has been run for the machine (ie, was the option rom not > > > > > > executed > > > > > > on the host when the host machine first booted)? > > > > > > > > > > > > FWIW, many of the chromebooks use coreboot with Intel graphics and a > > > > > > number of users have installed SeaBIOS (running natively) on their > > > > > > machines. Running the intel video option rom more than once has > > > > > > been > > > > > > known to cause issues. > > > > > > > > > > The issue is in the VM and it occurs every time the option ROM is > > > > > executed. Standard VGA text mode displays fine (ex. SeaBIOS version > > > > > string and boot menu), but any sort of extended graphics mode (ex. > > > > > live > > > > > CD boot menu) tries to make use of the host memory area which > > > > > corresponds to the stolen memory area of the physical device. We're > > > > > not really sure how the ROM execution arrives at these addresses (not > > > > > from the device according to access traces), but we can see when the > > > > > ROM is writing these addresses to the device and modify they addresses > > > > > to point at a VM memory range which we've allocated. That's what this > > > > > code attempts to do, allocate a buffer and tell QEMU about it via the > > > > > BDSM (Base Data of Stolen Memory) register. > > > > > > > > Forgive me if I'm not fully understanding this. If I read what you're > > > > saying then the sequence is something like: > > > > > > > > 1 - the host system bios (or vgabios) programs the GTT/stolen memory > > > > base register at host system bootup time and reserves it in the > > > > host e820 map. > > > > > > > > 2 - upon running qemu, the guest reruns the vga bios option rom which > > > > seems to work (ie, text mode works) > > > > > > > > 3 - in the guest, upon running a bootloader that uses graphics mode, > > > > the bootloader calls the vgabios to switch to graphics mode, and > > > > the vgabios sends commands to the graphics hardware that somehow > > > > reference the host stolen memory > > > > > > What exactly happens here isn't clear to me, but this is a plausible > > > explanation. What we see in tracing access to the hardware is that a > > > bunch of addresses are written to the device that fall within the host > > > e820 reserved area and then the device starts generating IOMMU faults > > > trying to access those addresses. > > > > > > > 4 - your patch causes QEMU to catch these commands with references to > > > > the host stolen memory and replace them with references to the > > > > guest stolen memory (which seabios creates) > > > > > > > > Am I un
Re: [SeaBIOS] [SEABIOS] Plans for either 1.9.1 or 1.10.0?
Hi, > 1.9-stable created now, with the patch above cherry-picked. 1.9.1 tagged & tarball uploaded now. cheers, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
