SeaBIOS March 2012

seabios@seabios.org

31 participants
85 discussions

Re: [SeaBIOS] [Qemu-devel] Regression: more 0.12 regression (SeaBIOS related?)
by Kevin O'Connor 12 Mar '12

12 Mar '12

On Tue, Mar 06, 2012 at 09:00:55AM -0800, Alain Ribière wrote: > Hello, > > I'm reacting a bit later but I have a trouble with an old DOS OS from Digital Research called Concurrent DOS. > It worked fine till Qemu v0.11.1. > I tried it with a lot of versions from 0.12.0 to 1.0.1 and it boot correctly. But after a key pressed, I can't use the keyboard any more. The system is not freezed (there is a clock in the bottom side of the screen which is running) but I can't use the keyboard any more. > It worked also with 0.12.0-rc1 and the PC-BIOS. It seems that with Seabios it doesn't work any more but PC-BIOS is no longer supported by QEMU (from v0.12.0). > > Do you know what can I do ? You can help debug the issue so it can be fixed in SeaBIOS. Start with producing a log from SeaBIOS by adding (on a recent qemu) the following to the command-line: -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios Also, if there is an image available for download, other developers can take a look at it as well. -Kevin

5 11

Re: [SeaBIOS] [coreboot] Linux-ready Firmware Kit
by Gleb Natapov 11 Mar '12

11 Mar '12

On Sun, Mar 11, 2012 at 04:28:38PM +0100, Fred . wrote: > Linux-ready Firmware Development Kit r3 segfaults under QEMU 0.14.1 > (Ubuntu 11.10 Oneiric) during the SUN duplicate test at 30% with the > message: > Segmentation fault (core dumped) plugins//acpicompile.exe 2>. > What about more recent qemu? 1.0? > On Tue, Mar 6, 2012 at 4:04 AM, Peter Stuge <peter(a)stuge.se> wrote: > > Fred . wrote: > >> Intel provides a Linux-ready Firmware Kit > > > > This is well-known in the community since many years. > > > > If you want to contribute then please *USE* the software and either > > just report results, or even better send fixes for any problems which > > are found. > > > > As you know, you can do limited testing completely using software. > > > > > > //Peter > > > > _______________________________________________ > > SeaBIOS mailing list > > SeaBIOS(a)seabios.org > > http://www.seabios.org/mailman/listinfo/seabios > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > http://www.seabios.org/mailman/listinfo/seabios -- Gleb.

1 0

Re: [SeaBIOS] [coreboot] Linux-ready Firmware Kit
by Peter Stuge 11 Mar '12

11 Mar '12

Fred . wrote: > Intel provides a Linux-ready Firmware Kit This is well-known in the community since many years. If you want to contribute then please *USE* the software and either just report results, or even better send fixes for any problems which are found. As you know, you can do limited testing completely using software. //Peter

2 1

Lots of USB work going on
by Fred . 11 Mar '12

11 Mar '12

Lately, there been lots of USB work being done with a patch set of 19 patches. Which gets me wondering about thoughts, plans, and status on xHCI (eXtensible Host Controller Interface) in regards to SeaBIOS. So whats up? http://www.intel.com/technology/usb/download/xHCI_Specification_for_USB.pdf

1 0

SeaBIOS v1.6.3.2 release
by Kevin O'Connor 11 Mar '12

11 Mar '12

A new stable release of SeaBIOS (version 1.6.3.2) has been tagged. This release has some minor bug fixes, mostly build related. The release is available via git: git clone git://git.seabios.org/seabios -b 1.6.3-stable -Kevin Kevin O'Connor (6): Add PYTHON definition to Makefile. Permit .rodata.__PRETTY_FUNCTION__. sections in roms. BCVs should inherrit the legacy harddrive priority. Fix missing NULL pointer checks causing boot failure on 1meg machines. Use "#!/bin/sh" instead of ":" in tools/gen-offsets.sh. Update version to 1.6.3.2 Makefile | 9 +++++---- src/boot.c | 2 +- src/pmm.c | 3 ++- tools/gen-offsets.sh | 2 +- tools/layoutrom.py | 12 ++++++++---- 5 files changed, 17 insertions(+), 11 deletions(-)

1 0

[PATCH 0/3] Redesign of pciinit.c
by Alexey Korolev 10 Mar '12

10 Mar '12

Hi, This patch series redesigns the existing pciinit.c code and introduces linked list operations. Changes are more about structures definitions rather than functionality. There are no more arrays of bases and counts in new implementation. The new implementation is based on dynamic allocation of pci_region_entry structures. Each pci_region_entry structure could be a PCI bar or a downstream PCI region (bridge). Each entry has a set of attributes: type (IO, MEM, PREFMEM), is64bit, size, base address, PCI device owner, and a pointer to the pci_bus it belongs to. Also this series introduces list head operations which could be quite handy not only for pciinit.c code but for post memory manager and thread operations. The patch series includes 3 patches. 1. Introduce List operations 2. Redesign of pciinit.c code to make use of pci_region_entry structure. 3. Make use of list operations in pmm.c and stack.c src/pci.h | 6 -- src/pciinit.c | 266 ++++++++++++++++++++++++++------------------------------- src/pmm.c | 29 ++----- src/stacks.c | 8 +-- src/util.h | 32 +++++++ 5 files changed, 163 insertions(+), 178 deletions(-)

2 4

Re: [SeaBIOS] usb ohci pipe free fix
by Kevin O'Connor 10 Mar '12

10 Mar '12

On Sun, Mar 04, 2012 at 12:44:01AM +0100, Nils wrote: > Op woensdag 22-02-2012 om 20:48 uur [tijdzone -0500], schreef Kevin > O'Connor: > > That's odd. It looks like the controller was running for 236ms and > > then freezes. The only thing I can think of to track this down is to > > sprinkle dprintf() statements through the code until we find what > > caused the controller to stop. > The controller freezes after the the lines 487 + 488 in usb-ohci.c: > > > for (i=startpos; i<ARRAY_SIZE(hcca->int_table); i+=ms) > > hcca->int_table[i] = (u32)ed; > > If i comment them out the controller doesn't freeze anymore and the > timeout disappears. > Do you have a another suggestion or patch i could test? I don't see anything wrong with the above code. (The barrier() should be moved, but I don't see that causing the problems you're seeing.) Getting more info may help. Something like the below. Another thing you could try is forcing the "if (frameexp == 0)" branch (by, for example, changing it to "if (1 || frameexp == 0)". -Kevin --- a/src/usb-ohci.c +++ b/src/usb-ohci.c @@ -482,18 +496,22 @@ ohci_alloc_intr_pipe(struct usb_pipe *dummy, int frameexp) } // Add to interrupt schedule. - barrier(); struct ohci_hcca *hcca = (void*)cntl->regs->hcca; if (frameexp == 0) { // Add to existing interrupt entry. struct ohci_ed *intr_ed = (void*)hcca->int_table[0]; ed->hwNextED = intr_ed->hwNextED; + barrier(); intr_ed->hwNextED = (u32)ed; } else { int startpos = 1<<(frameexp-1); ed->hwNextED = hcca->int_table[startpos]; - for (i=startpos; i<ARRAY_SIZE(hcca->int_table); i+=ms) + dprintf(1, "update h=%p s=%d ms=%d ed=%p\n", hcca, startpos, ms, ed); + barrier(); + for (i=startpos; i<ARRAY_SIZE(hcca->int_table); i+=ms) { + dprintf(1, "u i=%d o=%x n=%p\n", i, hcca->int_table[i], ed); hcca->int_table[i] = (u32)ed; + } } return &pipe->pipe;

4 15

Re: [SeaBIOS] [Qemu-devel] XP install cores with SCSI LSI 53C895A disks
by Gerhard Wiesinger 09 Mar '12

09 Mar '12

On Thu, 8 Mar 2012, Gerd Hoffmann wrote: > On 03/07/12 20:58, Gerhard Wiesinger wrote: >> On Wed, 7 Mar 2012, Brian Jackson wrote: >>> I think most people trying to use qemu for anything useful have given >>> up on if=scsi. Some distros even disable support because they don't >>> want to QA it. That should be a decent sign that you may want to avoid >>> it. >> >> OK, but SAS (Serial attached SCSI) is technology in the area of storage >> interface technology where all big storage vendors see future (e.g. they >> give up: FC and SATA drives, SATA drives are replaced by MDL SATA drives >> (SATA 7200RPM drives with SAS interface)). > > The problem isn't scsi. The problem is the lsi adapter. Problem #1 is > the hardware design which makes it hard to emulate it correctly and #2 > that you need a non-redistributable rom file to boot from it. Advantages of LSI 53C895A over others: 1.) OS support is great, even for legacy systems: DOS, Win 3.1, Win95, NT 4, W2K, XP, Vista, Win7, Linux, etc. I don't know any adapter with such wide range of OS support. Also tested up to 2TB of LUNs. 2.) OS support out of the box without additional drivers for a lot of newer OSes 3.) Migration from VMWare SCSI is easy 4.) Works well here for about 1 year for legacy VMs for DOS and NT 4 5.) BIOS geometry translation is correct, also according to partition table (doesn't work correctly on MEGASAS, INT13 geometry interrupts are not correct, already reported to Hannes) 7.) LSI SCSI DMA technology is fast. I'm getting /dev/null performance over 500MB/s ..., optimized for parallel IOPS, etc. 8.) Faster ROM init than MEGASAS Disadvantages: 1.) ROM non distributable 2.) non complete implementation 3.) 2TB limit 4.) Slower ROM INIT than without any Option ROM Megasas also needs a ROM rom to boot from it. Not to forget iSCSI which is also current/future SCSI technology ... Even if it is hard but I think the goal of qemu should be to implement all supported hardware pieces as good as possible (e.g. LSI 53C895A). I know it is not an easy task (see my thread about rtl8139) but I think together we can manage it. Are there any LSI 53C895A known bugs or incomplete implementation issues which are known? Any hints on the core dump? >> Therefore I don't understand why distros are giving up SAS which is also >> SCSI (of course old legacy SCSI is understandable). > > Nobody gives up on scsi. See virtio-scsi merged recently. There also > is megasas aiming for merge (which shares the boot issue with lsi though). Disadvantage of virtio-scsi is that drivers are needed. Is INT13h supported for legacy OS and to boot? Future? But as far as I saw implemented in seabios, right? What BIOS translation is used? Buslogic? LSI logic? Partition guessing? BTW: I've found out how LSI logic BIOS geometry translation works with (guessing) and without existing partition table. That might be an option for Seabios to implement. @Kevin: What do you think? Ciao, Gerhard -- http://www.wiesinger.com/

4 3

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

09 Mar '12

On Thu, 2012-03-08 at 22:57:30 +0000, Julian Pidancet wrote: > On Wed, Mar 7, 2012 at 7:04 PM, Guillem Jover <guillem(a)hadrons.org> wrote: > > On Wed, 2012-03-07 at 17:54:57 +0000, Julian Pidancet wrote: > > > So according to the manual, it should be BP, not EBP. > > > > The register being decreased should match the one being used to address > > the stack, and the one to use depends on the descriptor as per above. > > There is no "descriptor" in real mode. Default stack size is always 16-bit. Certainly! And sorry, somehow missed the fact this is exclusively real-mode being emulated. > Also, I think the right thing to do is to decrement BP instead of EBP > when SYSMODE_PREFIX_DATA is set: > > M.x86.R_BP -= 4; > push_long(fetch_data_long_abs(M.x86.R_SS, M.x86.R_BP)); > > instead of: > > M.x86.R_EBP -= 4; > push_long(fetch_data_long_abs(M.x86.R_SS, M.x86.R_BP)); > > ...to remain exactly consistent with the manual. Indeed. > > > In any case, It won't be a problem, because the 16 high bits of EBP > > > will most likely be zero in real-mode code. > > > > Well, not if the the code is using some 32-bit instructions. :) > They are not "32-bit instructions". The processor is still functioning > in real-mode, therefore, addressing still follows the rules of > real-mode addressing, as mentioned in Volume 1:Basic Architecture : > 3.3.5 32-Bit and 16-Bit Address and Operand Sizes Regardless of the mode, if the instructions are being modified by the prefixes to use 32-bit operands or addresses, they are in my book 32-bit instructions. In any case what I meant was that ebp can have any value because the register can be assigned directly, for example, and wrap-around might vary depending on what part of it it's being operated on. thanks, guillem

1 0

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

09 Mar '12

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> --- hw/xfree86/x86emu/ops.c | 194 ++++++++++++++++++++++++++++++++++------------ 1 files changed, 143 insertions(+), 51 deletions(-) diff --git a/hw/xfree86/x86emu/ops.c b/hw/xfree86/x86emu/ops.c index 5d3cac1..c5d5139 100644 --- a/hw/xfree86/x86emu/ops.c +++ b/hw/xfree86/x86emu/ops.c @@ -8487,7 +8487,11 @@ static void x86emuOp_ret_near_IMM(u8 X86EMU_UNUSED(op1)) DECODE_PRINTF2("%x\n", imm); RETURN_TRACE("RET",M.x86.saved_cs,M.x86.saved_ip); TRACE_AND_STEP(); - M.x86.R_IP = pop_word(); + if (M.x86.mode & SYSMODE_PREFIX_DATA) { + M.x86.R_EIP = pop_long(); + } else { + M.x86.R_IP = pop_word(); + } M.x86.R_SP += imm; DECODE_CLEAR_SEGOVR(); END_OF_INSTR(); @@ -8503,7 +8507,11 @@ static void x86emuOp_ret_near(u8 X86EMU_UNUSED(op1)) DECODE_PRINTF("RET\n"); RETURN_TRACE("RET",M.x86.saved_cs,M.x86.saved_ip); TRACE_AND_STEP(); - M.x86.R_IP = pop_word(); + if (M.x86.mode & SYSMODE_PREFIX_DATA) { + M.x86.R_EIP = pop_long(); + } else { + M.x86.R_IP = pop_word(); + } DECODE_CLEAR_SEGOVR(); END_OF_INSTR(); } @@ -8787,11 +8795,16 @@ static void x86emuOp_enter(u8 X86EMU_UNUSED(op1)) frame_pointer = M.x86.R_SP; if (nesting > 0) { for (i = 1; i < nesting; i++) { - M.x86.R_BP -= 2; - push_word(fetch_data_word_abs(M.x86.R_SS, M.x86.R_BP)); + if (M.x86.mode & SYSMODE_PREFIX_DATA) { + M.x86.R_BP -= 4; + push_long(fetch_data_long_abs(M.x86.R_SS, M.x86.R_BP)); + } else { + M.x86.R_BP -= 2; + push_word(fetch_data_word_abs(M.x86.R_SS, M.x86.R_BP)); } - push_word(frame_pointer); } + push_word(frame_pointer); + } M.x86.R_BP = frame_pointer; M.x86.R_SP = (u16)(M.x86.R_SP - local); DECODE_CLEAR_SEGOVR(); @@ -8808,7 +8821,11 @@ static void x86emuOp_leave(u8 X86EMU_UNUSED(op1)) DECODE_PRINTF("LEAVE\n"); TRACE_AND_STEP(); M.x86.R_SP = M.x86.R_BP; - M.x86.R_BP = pop_word(); + if (M.x86.mode & SYSMODE_PREFIX_DATA) { + M.x86.R_EBP = pop_long(); + } else { + M.x86.R_BP = pop_word(); + } DECODE_CLEAR_SEGOVR(); END_OF_INSTR(); } @@ -8827,8 +8844,13 @@ static void x86emuOp_ret_far_IMM(u8 X86EMU_UNUSED(op1)) DECODE_PRINTF2("%x\n", imm); RETURN_TRACE("RETF",M.x86.saved_cs,M.x86.saved_ip); TRACE_AND_STEP(); - M.x86.R_IP = pop_word(); - M.x86.R_CS = pop_word(); + if (M.x86.mode & SYSMODE_PREFIX_DATA) { + M.x86.R_EIP = pop_long(); + M.x86.R_CS = pop_long() & 0xffff; + } else { + M.x86.R_IP = pop_word(); + M.x86.R_CS = pop_word(); + } M.x86.R_SP += imm; DECODE_CLEAR_SEGOVR(); END_OF_INSTR(); @@ -8844,8 +8866,13 @@ static void x86emuOp_ret_far(u8 X86EMU_UNUSED(op1)) DECODE_PRINTF("RETF\n"); RETURN_TRACE("RETF",M.x86.saved_cs,M.x86.saved_ip); TRACE_AND_STEP(); - M.x86.R_IP = pop_word(); - M.x86.R_CS = pop_word(); + if (M.x86.mode & SYSMODE_PREFIX_DATA) { + M.x86.R_EIP = pop_long(); + M.x86.R_CS = pop_long() & 0xffff; + } else { + M.x86.R_IP = pop_word(); + M.x86.R_CS = pop_word(); + } DECODE_CLEAR_SEGOVR(); END_OF_INSTR(); } @@ -8939,9 +8966,15 @@ static void x86emuOp_iret(u8 X86EMU_UNUSED(op1)) TRACE_AND_STEP(); - M.x86.R_IP = pop_word(); - M.x86.R_CS = pop_word(); - M.x86.R_FLG = pop_word(); + if (M.x86.mode & SYSMODE_PREFIX_DATA) { + M.x86.R_EIP = pop_long(); + M.x86.R_CS = pop_long() & 0xffff; + M.x86.R_EFLG = (pop_long() & 0x257FD5) | (M.x86.R_EFLG & 0x1A0000); + } else { + M.x86.R_IP = pop_word(); + M.x86.R_CS = pop_word(); + M.x86.R_FLG = pop_word(); + } DECODE_CLEAR_SEGOVR(); END_OF_INSTR(); } @@ -11168,19 +11201,36 @@ static void x86emuOp_opcFF_word_RM(u8 X86EMU_UNUSED(op1)) } break; case 2: /* call word ptr ... */ - destval = fetch_data_word(destoffset); - TRACE_AND_STEP(); - push_word(M.x86.R_IP); - M.x86.R_IP = destval; + if (M.x86.mode & SYSMODE_PREFIX_DATA) { + destval = fetch_data_long(destoffset); + TRACE_AND_STEP(); + push_long(M.x86.R_EIP); + M.x86.R_EIP = destval; + } else { + destval = fetch_data_word(destoffset); + TRACE_AND_STEP(); + push_word(M.x86.R_IP); + M.x86.R_IP = destval; + } break; case 3: /* call far ptr ... */ - destval = fetch_data_word(destoffset); - destval2 = fetch_data_word(destoffset + 2); - TRACE_AND_STEP(); - push_word(M.x86.R_CS); - M.x86.R_CS = destval2; - push_word(M.x86.R_IP); - M.x86.R_IP = destval; + if (M.x86.mode & SYSMODE_PREFIX_DATA) { + destval = fetch_data_long(destoffset); + destval2 = fetch_data_word(destoffset + 4); + TRACE_AND_STEP(); + push_long(M.x86.R_CS); + M.x86.R_CS = destval2; + push_long(M.x86.R_EIP); + M.x86.R_EIP = destval; + } else { + destval = fetch_data_word(destoffset); + destval2 = fetch_data_word(destoffset + 2); + TRACE_AND_STEP(); + push_word(M.x86.R_CS); + M.x86.R_CS = destval2; + push_word(M.x86.R_IP); + M.x86.R_IP = destval; + } break; case 4: /* jmp word ptr ... */ destval = fetch_data_word(destoffset); @@ -11250,19 +11300,36 @@ static void x86emuOp_opcFF_word_RM(u8 X86EMU_UNUSED(op1)) } break; case 2: /* call word ptr ... */ - destval = fetch_data_word(destoffset); - TRACE_AND_STEP(); - push_word(M.x86.R_IP); - M.x86.R_IP = destval; + if (M.x86.mode & SYSMODE_PREFIX_DATA) { + destval = fetch_data_long(destoffset); + TRACE_AND_STEP(); + push_long(M.x86.R_EIP); + M.x86.R_EIP = destval; + } else { + destval = fetch_data_word(destoffset); + TRACE_AND_STEP(); + push_word(M.x86.R_IP); + M.x86.R_IP = destval; + } break; case 3: /* call far ptr ... */ - destval = fetch_data_word(destoffset); - destval2 = fetch_data_word(destoffset + 2); - TRACE_AND_STEP(); - push_word(M.x86.R_CS); - M.x86.R_CS = destval2; - push_word(M.x86.R_IP); - M.x86.R_IP = destval; + if (M.x86.mode & SYSMODE_PREFIX_DATA) { + destval = fetch_data_long(destoffset); + destval2 = fetch_data_word(destoffset + 4); + TRACE_AND_STEP(); + push_long(M.x86.R_CS); + M.x86.R_CS = destval2; + push_long(M.x86.R_EIP); + M.x86.R_EIP = destval; + } else { + destval = fetch_data_word(destoffset); + destval2 = fetch_data_word(destoffset + 2); + TRACE_AND_STEP(); + push_word(M.x86.R_CS); + M.x86.R_CS = destval2; + push_word(M.x86.R_IP); + M.x86.R_IP = destval; + } break; case 4: /* jmp word ptr ... */ destval = fetch_data_word(destoffset); @@ -11332,19 +11399,36 @@ static void x86emuOp_opcFF_word_RM(u8 X86EMU_UNUSED(op1)) } break; case 2: /* call word ptr ... */ - destval = fetch_data_word(destoffset); - TRACE_AND_STEP(); - push_word(M.x86.R_IP); - M.x86.R_IP = destval; + if (M.x86.mode & SYSMODE_PREFIX_DATA) { + destval = fetch_data_long(destoffset); + TRACE_AND_STEP(); + push_long(M.x86.R_EIP); + M.x86.R_EIP = destval; + } else { + destval = fetch_data_word(destoffset); + TRACE_AND_STEP(); + push_word(M.x86.R_IP); + M.x86.R_IP = destval; + } break; case 3: /* call far ptr ... */ - destval = fetch_data_word(destoffset); - destval2 = fetch_data_word(destoffset + 2); - TRACE_AND_STEP(); - push_word(M.x86.R_CS); - M.x86.R_CS = destval2; - push_word(M.x86.R_IP); - M.x86.R_IP = destval; + if (M.x86.mode & SYSMODE_PREFIX_DATA) { + destval = fetch_data_long(destoffset); + destval2 = fetch_data_word(destoffset + 4); + TRACE_AND_STEP(); + push_long(M.x86.R_CS); + M.x86.R_CS = destval2; + push_long(M.x86.R_EIP); + M.x86.R_EIP = destval; + } else { + destval = fetch_data_word(destoffset); + destval2 = fetch_data_word(destoffset + 2); + TRACE_AND_STEP(); + push_word(M.x86.R_CS); + M.x86.R_CS = destval2; + push_word(M.x86.R_IP); + M.x86.R_IP = destval; + } break; case 4: /* jmp word ptr ... */ destval = fetch_data_word(destoffset); @@ -11412,11 +11496,19 @@ static void x86emuOp_opcFF_word_RM(u8 X86EMU_UNUSED(op1)) } break; case 2: /* call word ptr ... */ - destreg = DECODE_RM_WORD_REGISTER(rl); - DECODE_PRINTF("\n"); - TRACE_AND_STEP(); - push_word(M.x86.R_IP); - M.x86.R_IP = *destreg; + if (M.x86.mode & SYSMODE_PREFIX_DATA) { + destreg = DECODE_RM_LONG_REGISTER(rl); + DECODE_PRINTF("\n"); + TRACE_AND_STEP(); + push_long(M.x86.R_EIP); + M.x86.R_EIP = *destreg; + } else { + destreg = DECODE_RM_WORD_REGISTER(rl); + DECODE_PRINTF("\n"); + TRACE_AND_STEP(); + push_word(M.x86.R_IP); + M.x86.R_IP = *destreg; + } break; case 3: /* jmp far ptr ... */ DECODE_PRINTF("OPERATION UNDEFINED 0XFF \n"); -- Julian Pidancet

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS March 2012