[SeaBIOS] Linux-ready Firmware Kit
# yum install pmtools # acpidump > acpi.dump # acpixtract -l acpi.dump # dmidecode Intel provides a Linux-ready Firmware Kit, available on a LiveCD (79 MB) ( http://linuxfirmwarekit.org/download/firmwarekit-r3.iso ). You only have to launch it, wait 1 or 2 minutes, and there is a summary of the results based on different topics (memory handling, PCI resources, HPET, ACPI tables, and more). The results is a number of "Fail", "Warn" and "Pass" flags. This Linux-ready Firmware Kit seems to not be developed anymore, but I guess it can give us a idea of the quality of the BIOS. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] vgabios testing
On 03/02/12 09:09, Gerd Hoffmann wrote: > Hi, > > Did some more testing of the vgabios today, two issues popped up: > > (1) screen isn't cleared in some cases. Visible with grub1 in text > mode. When it displays the menu a few stray chars are visible. > Even more obvious it becomes when hitting 'c' then to get a > prompt, then alot of the menu is still visible. > > (2) The Xorg Server has trouble, the VESA driver doesn't work. > > There are also some good news: linux kernel with vesafb active works > fine, likewise winxp guests. Hi Gerd. I took a look at the issue with Xorg. According to my diagnostic, x86emu (the real-mode emulator that the X server uses) seems to have problems emulating mov instructions that uses segment selectors other than DS and SS. In lots of places in the vga bios code, we use instructions like mov %cs:(%eax), %ebp to access global variables (mostly when we use the GET_GLOBAL macro). We also might have a problem we use the SET_FARVAR macro because it uses ES. This issue with segment selector seems to be confirmed by some comments I found in x86emu's code while doing my research: http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/x86emu/decode.c The comment describing the decode_rm00_address function (line 838) seems to imply that only DS or SS can be used. Kevin, would you see a problem modifying the READx_SEG macros in src/farptr.h to only dereference memory using the DS selector, in the vgabios case ? For example: #define READ8_SEG(prefix, SEG, value, var) \ __asm__(prefix "push %%ds\n"\ "movw %%" #SEG " , %%ax\n" \ "movw %%ax, %%ds\n" \ "movb %1, %b0\n" \ "pop %%ds" : "=Qi"(value)\ : "m"(var), "m"(__segment_ ## SEG)) instead of: #define READ8_SEG(prefix, SEG, value, var) \ __asm__(prefix "movb %%" #SEG ":%1, %b0" : "=Qi"(value) \ -- Julian ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] vgabios testing
On 03/04/12 00:21, Julian Pidancet wrote:
> On 03/02/12 09:09, Gerd Hoffmann wrote:
>> Hi,
>>
>> Did some more testing of the vgabios today, two issues popped up:
>>
>> (1) screen isn't cleared in some cases. Visible with grub1 in text
>> mode. When it displays the menu a few stray chars are visible.
>> Even more obvious it becomes when hitting 'c' then to get a
>> prompt, then alot of the menu is still visible.
>>
>> (2) The Xorg Server has trouble, the VESA driver doesn't work.
>>
>> There are also some good news: linux kernel with vesafb active works
>> fine, likewise winxp guests.
>
> Hi Gerd.
>
> I took a look at the issue with Xorg. According to my diagnostic, x86emu
> (the real-mode emulator that the X server uses) seems to have problems
> emulating mov instructions that uses segment selectors other than DS and SS.
>
> In lots of places in the vga bios code, we use instructions like
> mov %cs:(%eax), %ebp to access global variables (mostly when we
> use the GET_GLOBAL macro). We also might have a problem we use the
> SET_FARVAR macro because it uses ES.
>
> This issue with segment selector seems to be confirmed by some comments
> I found in x86emu's code while doing my research:
> http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/x86emu/decode.c
> The comment describing the decode_rm00_address function (line 838) seems
> to imply that only DS or SS can be used.
>
> Kevin, would you see a problem modifying the READx_SEG macros in
> src/farptr.h to only dereference memory using the DS selector, in the
> vgabios case ?
>
> For example:
>
> #define READ8_SEG(prefix, SEG, value, var) \
> __asm__(prefix "push %%ds\n"\
>"movw %%" #SEG " , %%ax\n" \
>"movw %%ax, %%ds\n" \
>"movb %1, %b0\n" \
>"pop %%ds" : "=Qi"(value)\
> : "m"(var), "m"(__segment_ ## SEG))
>
> instead of:
>
> #define READ8_SEG(prefix, SEG, value, var) \
> __asm__(prefix "movb %%" #SEG ":%1, %b0" : "=Qi"(value) \
>
>
Hi again,
I've done further debugging, and you can ignore all of the crap above.
x86emu badly handles the retl instruction and only pops a 16bit wide
value from the stack, whereas the corresponding calll pushes a 32bit
return address. leavel suffers from the same problem.
I've applied the following patch to x86emu and it seems to work better:
diff --git a/hw/xfree86/x86emu/ops.c b/hw/xfree86/x86emu/ops.c
index 5d3cac1..dd15387 100644
--- a/hw/xfree86/x86emu/ops.c
+++ b/hw/xfree86/x86emu/ops.c
@@ -8503,7 +8503,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();
}
@@ -8807,8 +8811,13 @@ static void x86emuOp_leave(u8 X86EMU_UNUSED(op1))
START_OF_INSTR();
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_ESP = M.x86.R_EBP;
+ M.x86.R_EBP = pop_long();
+} else {
+ M.x86.R_SP = M.x86.R_BP;
+ M.x86.R_BP = pop_word();
+}
DECODE_CLEAR_SEGOVR();
END_OF_INSTR();
}
I am now wondering why Xorg calls VBE function 4f01 on the ROM so many
times. It might be another bug.
Also, in my test environment, Xorg still reports a bad checksum.
--
Julian
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] usb ohci pipe free fix
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; iint_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; iint_table); i+=ms)
+dprintf(1, "update h=%p s=%d ms=%d ed=%p\n", hcca, startpos, ms, ed);
+barrier();
+for (i=startpos; iint_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;
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
