SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

USB OHCI issues when keyboard activity occurs prior to booting from thumbdrive
by Dave Frodin 17 Mar '12

17 Mar '12

All, I'm seeing another USB issue with our platform(s). I've been following the other active USB mail list issue "usb ohci pipe free fix" but don't exactly know where that one started. I'm only guessing that this could be related. The description of my h/w setup is ... - AMD/Persimmon platform (also observed failure on IEI/Kino) - USB thumbdrive with GRUB (menu options for Ubuntu,memtest86,etc) - USB wireless keyboard/mouse (also observed failure with wired USB keyboard) I using the SeaBIOS master source. The failure occurs when the system boots up to the GRUB menu. If I let the menu timeout it will boot the default option which is Ubuntu. If I hit the <Enter> key the system will lock-up with no output on the debug COM port. If at the GRUB menu and I <down arrow> to the memtest86 option, it will sometimes work and sometimes lockup. I then changed the SeaBIOS debug message level to 8. Then at the point where I hit <ENTER> for the default GRUB option. I will see several debug messages indicating traffic related to the USB thumbdrive and then never ending "handle_hwpic1 irq=0" messages. Then as I was browsing through the usb code I noticed that some of the keyboard messages only occur at level 9, so I set the level to 9 and all of my booting failures went away. ?. I tracked the message that was somehow fixing my problem down to the file usb-hid.c, in ftn handle_key() (~line 216). If I change that "dprintf(9,..." to "dprintf(1,...", and change the debug message level down below 9, everything still works. So the delay due to that one debug message fixes some issue related to using a USB keyboard and thumbdrive at the same time. I don't see this issue if I use a SATA drive instead of the USB thumbdrive. Our in-house USB guru (whose not familiar with coreboot) suggests it could be an issue with the OHCI stack. Does anybody have any suggestions on what this could be? Or where I should start looking? thanks in advance, Dave

3 3

Re: [SeaBIOS] [PATCH] memory hotplug
by Igor Mammedov 16 Mar '12

16 Mar '12

On 03/16/2012 03:09 PM, Vasilis Liaskovitis wrote: > Hi, > > On Thu, Mar 15, 2012 at 02:01:38PM +0200, Gleb Natapov wrote: >> Commenting a little bit late, but since you've said that you are working on >> a new version of the patch... better late than never. >> >> On Thu, Aug 11, 2011 at 04:39:38PM +0200, Vasilis Liaskovitis wrote: >>> Hi, >>> >>> I am testing a set of experimental patches for memory-hotplug on x86_64 host / >>> guest combinations. I have implemented this in a similar way to cpu-hotplug. >>> >>> A dynamic SSDT table with all memory devices is created at boot time. This >>> table calls static methods from the DSDT. A byte array indicates which memory >>> device is online or not. This array is kept in sync with a qemu-kvm bitmap array >>> through ioport 0xaf20. Qemu-kvm updates this table on a "mem_set" command and >>> an ACPI event is triggered. >>> >>> Memory devices are 128MB in size (to match /sys/devices/memory/block_size_bytes >>> in x86_64). They are constructed dynamically in src/ssdt-mem.asl , similarly to >>> hotpluggable-CPUs. The _CRS memstart-memend attribute for each memory device is >>> defined accordingly, skipping the hole at 0xe0000000 - 0x100000000. >>> Hotpluggable memory is always located above 4GB. >>> >> What is the reason for this limitation? > > We currently model a PCI hole from below_4g_mem_size to 4GB, see i440fx_init > call in pc_init1. The decision was discussed here: > http://patchwork.ozlabs.org/patch/105892/ > afaict because there was no clear resolution on using a top-of-memory register. > So, hotplugging will start at 4GB + above_4g_mem_size. Unless we can model the > pci hole more accurately hardware-wise. > >> >>> Qemu-kvm sets the upper bound of hotpluggable memory with "maxmem = [totalmemory in >>> MB]" on the command line. Maxmem is an argument for "-m" similar to maxcpus for smp. >>> E.g. "-m 1024,maxmem=2048" on the qemu command line will create memory devices >>> for 2GB of RAM, enabling only 1GB initially. >>> >>> Qemu_monitor triggers a memory hotplug with: >>> (qemu) mem_set [memory range in MBs] online >>> >> As far as I see mem_set does not get memory range as a parameter. The >> parameter is amount of memory to add/remove and memory is added/removed >> to/from the top. >> >> This is not flexible enough. Find grained control for memory slots is >> needed. What about exposing memory slot configuration to command line >> like this: >> >> -memslot mem=size,populated=yes|no >> >> adding one of those for each slot. >> > yes, I agree we need this. > Is the idea to model all physical DIMMs? For initial system RAM does it make > sense to explicitly specify slots at the command line, or infer them? > > I think we can allocate a new qemu ram MemoryRegion for each new hotplugged > slot/DIMM, so there will be a 1-1 mapping between new populated slots and > qemu memory ram regions. Perhaps we want initial memory allocation to also > comply with physical slot/DIMM modeling. Initial (cold) RAM is created as > a single MemoryRegion pc.ram > > Also in kvm we can easily run out of kvm_memory_slots (10 slots per VM and 32 > system-wide I think) > >> mem_set will get slot id to populate/depopulate just like cpu_set gets >> cpu slot number to remove and not just yanks cpus with highest slot id. > > right, but I think for upstream qemu, people would like to eventually use device_add, > instead of a new mem_set command. Pretty much the same way as cpu hotplug? > > For this to happen, memory devices should be modeled in QOM/qdev. Are we planning > on keeping a CPUSocket structures for CPUs? or perhaps modelling a memory controller I'd rather dump CPUSocket structure unless it's really required, it was introduced just for providing hotplug-able icc bus for cpus since hot-plug on sysbus was disabled. > is the right way. What type should the memory controller/devices be a child of? > > I 'll try to resubmit in a few weeks time, though depending on feedack qom/qdev of > memory devices will probably take longer. > > thanks, > > - Vasilis > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- ----- Igor

1 0

Re: [SeaBIOS] [PATCH] memory hotplug
by Gleb Natapov 16 Mar '12

16 Mar '12

Commenting a little bit late, but since you've said that you are working on a new version of the patch... better late than never. On Thu, Aug 11, 2011 at 04:39:38PM +0200, Vasilis Liaskovitis wrote: > Hi, > > I am testing a set of experimental patches for memory-hotplug on x86_64 host / > guest combinations. I have implemented this in a similar way to cpu-hotplug. > > A dynamic SSDT table with all memory devices is created at boot time. This > table calls static methods from the DSDT. A byte array indicates which memory > device is online or not. This array is kept in sync with a qemu-kvm bitmap array > through ioport 0xaf20. Qemu-kvm updates this table on a "mem_set" command and > an ACPI event is triggered. > > Memory devices are 128MB in size (to match /sys/devices/memory/block_size_bytes > in x86_64). They are constructed dynamically in src/ssdt-mem.asl , similarly to > hotpluggable-CPUs. The _CRS memstart-memend attribute for each memory device is > defined accordingly, skipping the hole at 0xe0000000 - 0x100000000. > Hotpluggable memory is always located above 4GB. > What is the reason for this limitation? > Qemu-kvm sets the upper bound of hotpluggable memory with "maxmem = [totalmemory in > MB]" on the command line. Maxmem is an argument for "-m" similar to maxcpus for smp. > E.g. "-m 1024,maxmem=2048" on the qemu command line will create memory devices > for 2GB of RAM, enabling only 1GB initially. > > Qemu_monitor triggers a memory hotplug with: > (qemu) mem_set [memory range in MBs] online > As far as I see mem_set does not get memory range as a parameter. The parameter is amount of memory to add/remove and memory is added/removed to/from the top. This is not flexible enough. Find grained control for memory slots is needed. What about exposing memory slot configuration to command line like this: -memslot mem=size,populated=yes|no adding one of those for each slot. mem_set will get slot id to populate/depopulate just like cpu_set gets cpu slot number to remove and not just yanks cpus with highest slot id. -- Gleb.

2 1

Re: [SeaBIOS] [PATCH 0/2] Implement VBE function 15h
by Gerd Hoffmann 16 Mar '12

16 Mar '12

Hi, > I think a good interface would expose the EDID block directly instead > of a prefered resolution and let Seabios forge the EDID. Qemu is also > the "virtual monitor" after all... > It is easier to have support code which generates the EDID block in > qemu, than having it in SeaBIOS. Indeed, makes sense. cheers, Gerd

1 0

Re: [SeaBIOS] [PATCH 0/2] Implement VBE function 15h
by Gerd Hoffmann 16 Mar '12

16 Mar '12

Hi, >> I was thinking more along the lines of having >> etc/vga-prefered-{xres,yres} fw_cfg files, then generate a EDID block >> with them so xorg can pick them up and use as default resolution? >> > > The problem is that the bochs driver will become qemu specific if we do that. Of course we'll need default backups in case the fw_cfg interface or the config files in fw_cfg space are not present, not only for non-qemu use cases but also old qemu versions. We could also extent the bochs interface for that (which is maybe the better option anyway). cheers, Gerd

2 1

Re: [SeaBIOS] [PATCH 0/2] Implement VBE function 15h
by Gerd Hoffmann 16 Mar '12

16 Mar '12

Hi, > Is it worth trying to support high resolutions in Xorg ? If yes, then > we need to expose a valid EDID block. But what capabilities should the > virtual monitor report ? (I mean max resolution, preferred resolution, > should they be static, provided by configuration options, or > dynamically chosen at run-time). At runtime, read from qemu firmware config interface? cheers, Gerd

3 3

Re: [SeaBIOS] [PATCH 3/3] Take in account hot(un)plugged cpus on reboot
by Gleb Natapov 16 Mar '12

16 Mar '12

On Thu, Mar 15, 2012 at 10:33:01AM -0400, Igor Mammedov wrote: > > > ----- Original Message ----- > > From: "Gleb Natapov" <gleb(a)redhat.com> > > To: "Igor Mammedov" <imammedo(a)redhat.com> > > Cc: "Kevin O'Connor" <kevin(a)koconnor.net>, "jan kiszka" <jan.kiszka(a)siemens.com>, seabios(a)seabios.org > > Sent: Thursday, March 15, 2012 3:13:58 PM > > Subject: Re: [SeaBIOS] [PATCH 3/3] Take in account hot(un)plugged cpus on reboot > > > > On Thu, Mar 15, 2012 at 10:08:17AM -0400, Igor Mammedov wrote: > > > > Good point. You mean we need a list of apic ids of available cpus > > > > right? > > > > Can SeaBIOS build this list by reading apic id in > > > > smp_ap_boot_code? > > > > > > I've looked at how tables are build. It seems that it's not hard > > > and sufficient > > > to build an equivalent temporary byte array of (un)available apic > > > ids that > > > corresponds to 0xaf00 bitmap at boot time, under following > > > restriction: > > > - apic id shall be in range [0..max_cpus) > > Why this restriction? ap bootstrap code can grab array entry with > > atomic > > operation and store its apic id there. > we need to know in advance how large array to allocate. > and if apic id is to serve as index in this array and to correspond to > appropriate bit in 0xaf00 bitmap. > > Why limiting apic id range to [0..max_cpus) is bad thing? > IIRC part of topology information is conveyed through apic ids, so you cannot express some topology with limited apic ranges. That said currently seabios assumes that apic ids are in this range so it would not be a big dial to continue assuming it for now. > > > > > * this will allow to allocate array where apic id will serve > > > as index, > > > thus making it equvivalent to 0xaf00 bitmap. > > > * and easily fill this array in smp_ap_boot_code without > > > inventing > > > and using mutexes/spinlocks in smp_ap_boot_code. > > > > > > > > > This will require cooperation from qemu side. apic id could be > > > checked > > > somewhere in device_add command handler call chain or at cpu object > > > creation > > > time. > > > > > > Jan, > > > What do you think about setting such restriction on apic id of > > > cpus in > > > qemu? > > > > > We do have such restriction currently. A couple of years ago I > > removed > > it from the kernel, but qemu and current bios code still has it. > > > > -- > > Gleb. > > -- Gleb.

2 1

Re: [SeaBIOS] [PATCH v2] x86emu: Correctly handle 0x66 prefix for some instructions
by Peter Stuge 15 Mar '12

15 Mar '12

Julian Pidancet wrote: > Anyone interested in this ? I'm interested for the sake of coreboot at least. //Peter

1 0

Re: [SeaBIOS] 16 Segementation help
by Kevin O'Connor 15 Mar '12

15 Mar '12

On Thu, Mar 15, 2012 at 07:33:10PM +0900, Daniel Castro wrote: > Kevin, I greatly appreciate your help. Sorry to bother you again. > > Could you please check the following sample code, I am sure I am doing > something wrong, but I am on the right path: It would help if you sent actual code samples. The details are important. > I have: > struct xendrive_s * xd = conteiner_of(op->drive_g,...) GET_GLOBAL(op->drive_g) -- as that is a memory access. > struct blk_info * bi = GLOBALFLAT2GLOBAL($(GET_GLOBALFLAT(xd)->info); I don't know what $ does. > To test I do: > dprintf(1,"DEBUG test xendrive %p and an int > %d.\n",GET_GLOBALFLAT(xd),GET_GLOBALFLAT(GET_GLOBALFLAT(bi)->buffer_gref)); Neither "bi" nor "xd" is a non-stack memory access so they shouldn't be wrapped. "bi->buffer_gref" is a memory access. So it should look like dprintf("...", xd, GET_GLOBALFLAT(bi->buffer_gref)). (This is assuming the pointer in buffer_gref was obtained via malloc_fseg.) -Kevin

2 1

Re: [SeaBIOS] [PATCH v2] x86emu: Correctly handle 0x66 prefix for some instructions
by Julian Pidancet 15 Mar '12

15 Mar '12

On Thu, Mar 15, 2012 at 10:39 PM, Julian Pidancet <julian.pidancet(a)gmail.com> wrote: > On Fri, Mar 9, 2012 at 2:08 AM, Guillem Jover <guillem(a)hadrons.org> wrote: >> On Fri, 2012-03-09 at 00:02:55 +0000, Julian Pidancet wrote: >>> Some instructions are not emulated correctly by x86emu when they >>> are prefixed by the 0x66 opcode. >>> I've identified problems in the emulation of these intructions: ret, >>> enter, leave, iret and some forms of call. >>> >>> Most of the time, the problem is that these instructions should push or >>> pop 32-bit values to/from the stack, instead of 16bit, when they are >>> prefixed by the 0x66 special opcode. >>> >>> The SeaBIOS project aims to produce a complete legacy BIOS >>> implementation as well as a VGA option ROM, entirely written in C and >>> using the GCC compiler. >>> >>> In 16bit code produced by the GCC compiler, the 0x66 prefix is used >>> almost everywhere. This patch is necessary to allow the SeaBIOS VGA >>> option ROM to function with Xorg when using the vesa driver. >>> >>> v2: - Decrement BP instead of EBP in accordance with the Intel Manual >>> - Assign EIP instead of IP when poping the return address from the >>> stack in 32-bit operand size mode in ret_far_IMM, ret_far, and iret >>> - When poping EFLAGS from the stack in iret in 32-bit operand size >>> mode, apply some mask to preserve Read-only flags. >>> >>> Signed-off-by: Julian Pidancet <julian.pidancet(a)gmail.com> >> >> Looks good to me: >> >> Reviewed-by: Guillem Jover <guillem(a)hadrons.org> >> >> thanks, >> guillem > > Anyone interested in this ? Is there a maintainer for x86emu ? The > MAINTAINERS file in xorg-docs doesn't mention anything about it. > CCed: Adam Jackson Adam, you seem to be the maintainer of the xorg vesa driver. I think this patch is closely related. Would you mind taking a look at it ? Thanks, -- Julian

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS