SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

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

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

09 Mar '12

1 0

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

08 Mar '12

On Wed, 2012-03-07 at 17:54:57 +0000, Julian Pidancet wrote: > On Wed, Mar 7, 2012 at 1:46 PM, Guillem Jover <guillem(a)hadrons.org> wrote: > > On Mon, 2012-03-05 at 17:49:08 +0000, Julian Pidancet wrote: > >> diff --git a/hw/xfree86/x86emu/ops.c b/hw/xfree86/x86emu/ops.c > >> index 5d3cac1..440b8dc 100644 > >> --- a/hw/xfree86/x86emu/ops.c > >> +++ b/hw/xfree86/x86emu/ops.c > >> @@ -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_EBP -= 4; > >> + push_long(fetch_data_long_abs(M.x86.R_SS, M.x86.R_BP)); > > > > Shouldn't this be: > > > > push_long(fetch_data_long_abs(M.x86.R_SS, M.x86.R_EBP)) > > > > ? > > > > From the Intel® 64 and IA-32 Architectures Software Developer Manuals, > here is the pseudo code associated with the enter instruction: > > [...] > IF (NestingLevel > 1) > THEN FOR i <- 1 to (NestingLevel - 1) > DO > IF 64-Bit Mode (StackSize = 64) > THEN > RBP <- RBP - 8; > Push([RBP]); (* Quadword push *) > ELSE IF OperandSize = 32 > THEN > IF StackSize = 32 > EBP <- EBP - 4; > Push([EBP]); (* Doubleword push *) > ELSE (* StackSize = 16 *) > BP <- BP - 4; > Push([BP]); (* Doubleword push *) > FI; > FI; > ELSE (* OperandSize = 16 *) > IF StackSize = 32 > THEN > EBP <- EBP - 2; > Push([EBP]); (* Word push *) > ELSE (* StackSize = 16 *) > BP <- BP - 2; > Push([BP]); (* Word push *) > FI; > FI; > OD; > FI; > [...] > > I believe the 0x66 prefix only affects OperandSize, not StackSize. Right. What affects the stack size is the B flag on the stack descriptor. > 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. > 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. :) > I will respin a patch shortly. thanks, guillem

2 2

[RFC] [SEABIOS] Take in account hotplugged cpus on reboot
by Igor Mammedov 08 Mar '12

08 Mar '12

Initial count of active cpus is communicated to bios from qemu via CMOS_BIOS_SMP_COUNT io port. However if cpus are hotplugged after boot and then guest is rebooted without taking down qemu then bios might be stuck at smp_probe while (cmos_smp_count + 1 != readl(&CountCPUs)) yield(); where cmos_smp_count + 1 will be less that CountCPUs due to additional hotplugged cpus. One way to fix bug is to take in account hotplugged cpus and count online cpus in cpu status bitmap that qemu provides at 0xaf00 and bios uses for ACPI cpu hotplug in acpi-dsdt.dsl. Alternative ways to fix issue is disscussed on following thread: http://www.seabios.org/pipermail/seabios/2011-August/002147.html without any conclusion Rationale why counting cpus in cpu_sts bitmap at 0xaf00 might be better that updating CMOS_BIOS_SMP_COUNT in qemu. feeble one: we already relying on cpu_sts at 0xaf00 for ACPI cpu hotplug machinery and it seems that there is no standard way to pass this info (so we are now using "board extension"). 2nd: another possible use for cpu_sts bitmap is when cpus are able to be (hot)plugged in nonconsecutive order, MADT + CPON package should be build taking in account info about which cpus are (un)plugged. However there is compatibility question: What to do with qemu versions that doen't have cpu_hotplug? --- src/smp.c | 18 ++++++++++++++++++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/src/smp.c b/src/smp.c index 8c077a1..f24d6fa 100644 --- a/src/smp.c +++ b/src/smp.c @@ -17,6 +17,9 @@ #define APIC_ENABLED 0x0100 +#define ACPI_CPU_STATUS_MAP 0xaf00 +#define ACPI_CPU_STATUS_MAP_SZ 32 + struct { u32 ecx, eax, edx; } smp_mtrr[32] VAR16VISIBLE; u32 smp_mtrr_count VAR16VISIBLE; @@ -115,6 +118,21 @@ smp_probe(void) msleep(10); } else { u8 cmos_smp_count = inb_cmos(CMOS_BIOS_SMP_COUNT); + u8 i = 0, acpi_cpu_online_count = 0; + + /* count plugged in cpus in acpi PRST bitmap */ + while (i < ACPI_CPU_STATUS_MAP_SZ) { + u8 j = 0, status = inb(ACPI_CPU_STATUS_MAP + (i++)); + while (j < 8) + if ((status >> j++) & 1) + ++acpi_cpu_online_count; + } + /* if one or several cpus were hotplugged then on reboot we should + * take them into account and wait for them too*/ + if (cmos_smp_count < --acpi_cpu_online_count) + cmos_smp_count = acpi_cpu_online_count; + + dprintf(1, "acpi_cpu_online_count: %d\n", acpi_cpu_online_count); while (cmos_smp_count + 1 != readl(&CountCPUs)) yield(); } -- 1.7.7.6

1 0

Re: [SeaBIOS] [coreboot] Bug when I compiling coreboot with SeaBIOS
by Kevin O'Connor 08 Mar '12

08 Mar '12

On Wed, Mar 07, 2012 at 10:30:17AM -0800, ron minnich wrote: > The solution in other projects I have worked on is to have an > initialized struct and just copy it at runtime to the right place. > This gets around all the issues with ld (which have been issues in > various ways for 12 years now ... just different ones :) > > How big are the tables? If they're not that big then just copying them > to where they need to be at startup might be the best solution. LD is > going to continue to break, always has and always will. Just a > thought. > > This fails on recent arch and ubuntu. If you can find a way not to use > this kind of LD trick, life will be easier. It's not really a trick - we're just asking LD to put sections at specific addresses - it's real basic stuff. > Of course if this is going to mess up entry points then we're out of luck. It's code entry points as well. I can't think of an easy way to do that as things get real messy when relocating code due to relative offsets in the code. It's doable, but it quickly reaches the complexity of just implementing a poor-man's LD replacement. -Kevin

1 0

Re: [SeaBIOS] [coreboot] Bug when I compiling coreboot with SeaBIOS
by Kevin O'Connor 07 Mar '12

07 Mar '12

On Mon, Mar 05, 2012 at 04:01:45PM -0800, ron minnich wrote: > I'm seeing the ld problem on all my linux systems. What distro do you have? This got fixed in Fedora updates at least. I would normally work around build tool defects (and have done so on many occasions). Unfortunately, this LD one is too severe. The issue is that SeaBIOS needs to have certain tables and code entry points at specific memory locations - this is a requirement for compatibility. The SeaBIOS build generates an LD script to locate the appropriate sections at the correct addresses. Unfortunately, the broken version of LD gets confused with alignment and refuses to place data at the locations they need to be. Not much that can be done - any solution would effectively require not using LD - might as well write our own LD (with the limited requirements of seabios) than try to work around it. -Kevin

2 1

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

07 Mar '12

Hi! On Mon, 2012-03-05 at 17:49:08 +0000, Julian Pidancet wrote: > diff --git a/hw/xfree86/x86emu/ops.c b/hw/xfree86/x86emu/ops.c > index 5d3cac1..440b8dc 100644 > --- a/hw/xfree86/x86emu/ops.c > +++ b/hw/xfree86/x86emu/ops.c > @@ -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_EBP -= 4; > + push_long(fetch_data_long_abs(M.x86.R_SS, M.x86.R_BP)); Shouldn't this be: push_long(fetch_data_long_abs(M.x86.R_SS, M.x86.R_EBP)) ? > + } 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(); > @@ -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_IP = 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_IP = 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_IP = pop_long(); > + M.x86.R_CS = pop_long() & 0xffff; > + M.x86.R_FLG = pop_long(); > + } 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(); > } On these three hunks, when on 32-bit mode shouldn't the registers be M.x86.R_EIP and M.x86.R_EFLG? regards, guillem

2 1

Help using a macro in 16bit code
by Daniel Castro 07 Mar '12

07 Mar '12

Hello All, I am working in the PV-Drivers for xen. I am trying to use a macro that will return a pointer inside a structure defined by a macro, using a macro. For example I create the front ring that will contain the disk read requests with a macro like this: struct blkif_ring * shared = memalign_low(4096,4096); //return 0x000fd630 this above 16bit space SHARED_RING_INIT(shared); So far I have a pointer located at 0x0009a000 Under 32bit the struct is correct and all is working according to plan. But on 16bit operation read on disk I have struct blkfront_info * shared_ring = container_of(op-drive_g.info->shared)); // I get d630 I should get it from the correct segment, but how? RING_GET_REQUEST(shared_ring); //this returns 0xffff and should be something 0xa010 segment SS or something like that My problem is I do not know which macro to use to set the malloc in a place (segment) I can locate later in 16bit code. And since I am using macros when I try to use MAKE_FLATPTR and GET_SEG they make compilation error. Sorry for such silly questions. 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