SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

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

15 Mar '12

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

2 1

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

15 Mar '12

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. > * 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.

2 1

[PATCH 0/3] Fix hang in smp_probe on reboot after cpu hotplug
by Igor Mammedov 15 Mar '12

15 Mar '12

- Halt if number of started cpus are more then expected - Allow bios to detect if qemu has cpus status map for acpi hotplug - Take in account hot(un)plugged cpus on reboot Related qemu patches I'll post to qemu-devel Signed-off-by: Igor Mammedov <imammedo(a)redhat.com>

5 26

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

15 Mar '12

On Tue, Mar 13, 2012 at 06:44:19PM +0900, Daniel Castro wrote: > Hello, > > Sorry to bring this again, but I am still struggling with 16 bit disk operation. > > This time I have a simpler question. > > When I do container_of(...) I get pointer to 0xd630. > The address when I created the drive struct is 0x000fd630. > What do I need to do to be able to use the return of container_of in 16bit code? When in "segmented" mode (both 16bit mode and 32bit segmented mode) the processor does not have a uniform view of memory. This is quite complex and painful to work with, so basically no modern systems use it anymore. For compatibility, seabios must still support 16bit mode though. This means that when it is in segmented mode it has a different view of memory than the init code (which runs in regular 32bit flat mode). So, the following code: u8 myglobal VAR16VISIBLE; ... dprintf(1, "myglobal addr = %p\n", &myglobal); Will show two different results - it prints 0xf1234 in 32bit flat mode (it's a variable in the f-segment). In 16bit mode it shows up as 0x1234 - the build arranges for this in order to keep the address within a 16bit range. To access the variable in 16bit mode, one must use GET_GLOBAL(myglobal) - this will arrange for the proper segment accessor (in this case %cs) to be used in conjunction with the variable address (eg, 0x1234) to load the proper value. However, the following code: int *myptr VAR16VISIBLE; ... myptr = malloc_fseg(16); ... dprintf(1, "myptr = %p\n", GET_GLOBAL(myptr)); The dprintf will show 0xf4567 regardless of the mode it is in. That is because the pointer is loaded up at runtime with a 32 bit flat address, and the build has no way of "fixing" that up. To access the content of the pointer, one would use the GET_GLOBALFLAT() macro. To make things slightly more complex, a *drive_g pointer returned from block.c:getDrive() makes the conversion from GLOBALFLAT to GLOBAL (via the GLOBALFLAT2GLOBAL macro. So, if you're working with drive_g pointers, you should just use GET_GLOBAL. This, BTW, is the reason for the "_g" and "_gf" sufixes found in places through the code - they're identifiers for pointers that are global vs globalflat. Also, be aware that *every* pointer access (that isn't pointing to a variable on the stack) must be wrapped in a macro. Failure to do this will result in random data being read. As an example of this, to read the integer pointed to by the global variable "myptr" above, one would need to run GET_GLOBALFLAT(*GET_GLOBAL(myptr)) - one macro to extract the global variable and the other macro to extract the data pointed to by the global variable. So, basically, pointers have to be accessed the correct way in order for the system to work. I know this is complex, but it's just the reality of programming in segmented mode. This complexity has nothing to do with container_of - that macro works the same way regardless of the mode. -Kevin

2 1

Re: [SeaBIOS] [PATCH 0/2] Implement VBE function 15h
by Kevin O'Connor 15 Mar '12

15 Mar '12

On Mon, Mar 12, 2012 at 02:40:14PM +0000, Julian Pidancet wrote: > On Sat, Mar 10, 2012 at 7:01 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote: > > On Wed, Mar 07, 2012 at 02:41:05AM +0000, Julian Pidancet wrote: > >> Implements VBE function 15h defined in the VBE/DDC standard. > >> Contains a preliminary implementation for bochsvga which returns > >> a hardcoded EDID with some generic informations. > >> > >> It seems Xorg refuses to use resolutions higher than 1024x768 if > >> the ROM doesn't return an EDID with timing informations to support > >> it. > >> > >> I think this work can be completed to add support for the Geode vga > >> ROM, as an I2C interface is probably available to extract the EDID > >> from a real monitor. > > > > I'm okay with the change, but I don't think it should be enabled in > > the upcoming SeaBIOS v1.7.0 release. Perhaps add a config setting and > > disable it by default. > > > > Also, the comment on patch 2 seems to indicate it is untested. I > > think it should be tested before committing. > > > > How about including only the first of this 2-patch set. It only adds > the 15h function stub and is a pretty low-risk change. What's the gain to having the stub present? It will always just return an error code, right? -Kevin

2 1

[PATCH 00/19] USB improvements
by Kevin O'Connor 15 Mar '12

15 Mar '12

This series updates the USB code. This is mostly a code reorganization, though there are a couple of bug fixes (mostly for OHCI). -Kevin Kevin O'Connor (19): Batch free USB pipes on OHCI controllers. Batch free USB pipes on UHCI controllers. Batch free USB pipes on EHCI controllers. usb: Centralize pipe free list code. usb: Remove cntl->defaultpipe cache. usb: Obtain free list items in main code. usb: Introduce 'struct usbdevice_s' to describe info for a given device. usb: Push 'struct usbdevice_s' usage through to pipe allocation. usb: Build path via chain of usbdevice_s. usb: Pass usbdevice_s to alloc_async_pipe. usb: Pass 'struct usbdevice_s' into controller alloc_async functions. usb: Pass 'struct usbdevice_s' to controller alloc_intr_pipe functions. usb: Move code around in usb controller code. usb: Generalize controller alloc_async_pipe / alloc_intr_pipe code. usb: Move code around in usb.c. usb: Move EHCI tt_* fields to EHCI controller code. usb: Populate OHCI endpoint descriptor info at pipe allocation. usb: Fix barrier() placement in OHCI interrupt schedule add. usb: Remove QH_MULT_SHIFT flag from qh.info1. src/boot.c | 25 ++-- src/boot.h | 3 +- src/usb-ehci.c | 441 +++++++++++++++++++++++++++----------------------------- src/usb-ehci.h | 8 +- src/usb-hid.c | 28 ++-- src/usb-hid.h | 6 +- src/usb-hub.c | 14 +- src/usb-hub.h | 4 +- src/usb-msc.c | 14 +- src/usb-msc.h | 6 +- src/usb-ohci.c | 323 +++++++++++++++++++++--------------------- src/usb-ohci.h | 8 +- src/usb-uhci.c | 411 +++++++++++++++++++++++++--------------------------- src/usb-uhci.h | 8 +- src/usb.c | 277 +++++++++++++++++------------------ src/usb.h | 48 ++++--- 16 files changed, 797 insertions(+), 827 deletions(-) -- 1.7.6.5

2 21

Re: [SeaBIOS] usb-msc.c: TEST_UNIT_READY needs USB_DIR_OUT?
by Peter Stuge 14 Mar '12

14 Mar '12

Steve Goodrich wrote: > the USB/SD adapter would start enumeration, but would fail out > during TEST_UNIT_READY because the device came back with a STALL > (this via a LeCroy/CACT USB analyzer). I compared the transactions > to those done during USB enumeration/configuration in Linux, and I > noticed that the Direction bit in bmCBWFlags is *cleared* for the > TEST_UNIT_READY command in Linux, but *set* in coreboot. > > In both cases, dCBWDataTransferLength is zero. > > The USB MSC spec that I'm using states: > If [dCBWDataTransferLength] is zero, the device and the host > shall transfer no data between the CBW and the associated CSW, > and the device shall ignore the value of the Direction bit in > bmCBWFlags. > > Obviously, this device is not ignoring the Direction flag. So... > what should it be? I modified Paolo's patch (usb-msc.c, > usb_cmd_data() function) from 27 Feb 2012 to look like this: > cbw.dCBWDataTransferLength = bytes; > if ((cbw.CBWCB[0] == CDB_CMD_WRITE_10) || > (cbw.CBWCB[0] == CDB_CMD_TEST_UNIT_READY)) { > cbw.bmCBWFlags = USB_DIR_OUT; > } else { > cbw.bmCBWFlags = USB_DIR_IN; > } > cbw.bCBWLUN = 0; // XXX It would have helped to see a patch rather than only the new code. > This change allows the device to work, but: > 1. Is this the right way to do this? It's not more right or wrong than the other way around. > 2. Will this break anything else? I'm sure it will break plenty of other non-compliant USB MSC devices which also do not ignore the direction bit and require it to be 1. > 3. Are there other commands that should be set for OUT instead of IN? Hm, commands? Not sure what you mean here. The only other thing you could do is to make the code detect the STALL, clear the stall, and then try with the direction bit inverted. This will work with devices which are not too broken to support clearing the stall. This may be a subset or a superset of those with broken MSC bulk-only implementations. Lots of fun when engineers are too stupid to follow specifications. :( The behavior might actually depend on the SD card rather than the USB-to-SD converter chip. This may or may not be relevant for you to investigate. //Peter

3 2

usb-msc.c: TEST_UNIT_READY needs USB_DIR_OUT?
by Steve Goodrich 14 Mar '12

14 Mar '12

I've been working with coreboot and SeaBIOS lately to try to get a platform working, including having boot capability using an SD-to-USB adapter. I got stuck on this last part: the USB/SD adapter would start enumeration, but would fail out during TEST_UNIT_READY because the device came back with a STALL (this via a LeCroy/CACT USB analyzer). I compared the transactions to those done during USB enumeration/configuration in Linux, and I noticed that the Direction bit in bmCBWFlags is *cleared* for the TEST_UNIT_READY command in Linux, but *set* in coreboot. In both cases, dCBWDataTransferLength is zero. The USB MSC spec that I'm using states: If [dCBWDataTransferLength] is zero, the device and the host shall transfer no data between the CBW and the associated CSW, and the device shall ignore the value of the Direction bit in bmCBWFlags. Obviously, this device is not ignoring the Direction flag. So... what should it be? I modified Paolo's patch (usb-msc.c, usb_cmd_data() function) from 27 Feb 2012 to look like this: cbw.dCBWDataTransferLength = bytes; if ((cbw.CBWCB[0] == CDB_CMD_WRITE_10) || (cbw.CBWCB[0] == CDB_CMD_TEST_UNIT_READY)) { cbw.bmCBWFlags = USB_DIR_OUT; } else { cbw.bmCBWFlags = USB_DIR_IN; } cbw.bCBWLUN = 0; // XXX This change allows the device to work, but: 1. Is this the right way to do this? 2. Will this break anything else? 3. Are there other commands that should be set for OUT instead of IN? Thanks! -- Steve G.

1 0

New packages
by Fred . 13 Mar '12

13 Mar '12

Please upload new packages on: http://code.coreboot.org/p/seabios/downloads/

1 0

16 Segementation help
by Daniel Castro 13 Mar '12

13 Mar '12

Hello, Sorry to bring this again, but I am still struggling with 16 bit disk operation. This time I have a simpler question. When I do container_of(...) I get pointer to 0xd630. The address when I created the drive struct is 0x000fd630. What do I need to do to be able to use the return of container_of in 16bit code? Thanks in advance and sorry for bothering so much. Daniel -- +-=====---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | | | Daniel Castro, | | | | Consultant/Programmer.| | | | U Andes | +-------------------------------------+

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS