SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

Re: [SeaBIOS] vgabios testing
by Kevin O'Connor 04 Mar '12

04 Mar '12

On Sun, Mar 04, 2012 at 08:08:12PM +0000, Julian Pidancet wrote: > On Sun, Mar 4, 2012 at 7:54 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote: > > > > The only thing I can think of would be to post-process the assembler > > and replace "retl" instructions with "retw $2" instructions. I'm not > > sure if it would work and it would be real ugly. > > > > As I mentionned, ret is not the only instruction causing problems. > I've identified issues with leave, enter, iret, and even some forms of > the call instruction, and the list is probaly not complete yet. So it > could be even more complicated that we think. Okay. > It looks like x86emu was never tested with gcc produced code before. > And it looks like handling of the 0x66 instruction prefix has been > neglected in a lot of different places in the code. The coreboot project has an improved x86emu - it may have many of these issues fixed. -Kevin

1 0

Re: [SeaBIOS] vgabios testing
by Kevin O'Connor 04 Mar '12

04 Mar '12

On Sun, Mar 04, 2012 at 07:26:58PM +0000, Julian Pidancet wrote: > On Sun, Mar 4, 2012 at 7:04 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote: > > So, I guess the question is, how important is support for > > current/legacy x86emu versions? > > I've tried to replace .code16gcc with .code16 in src/code16gcc.s to > see if gcc would be able to generate code which doesn't use 32bit > version of the call/ret instructions. The result was quite > disappointing, it generates functions like this: That definitely wont work. Gcc assumes the return address is 32bits - it will be totally confused if it's not. (Function parameters passed on the stack wont be in the right spot.) Likely other things will break as well. > I am going to propose a patch to xorg-devel in the next few days, but > in the meantime, it would be nice to find a solution in SeaBIOS so the > code can work with older versions of Xorg. The only thing I can think of would be to post-process the assembler and replace "retl" instructions with "retw $2" instructions. I'm not sure if it would work and it would be real ugly. -Kevin

2 1

Re: [SeaBIOS] USB boot failes
by Kevin O'Connor 04 Mar '12

04 Mar '12

On Sun, Mar 04, 2012 at 03:48:17PM +0100, Christian Gmeiner wrote: > As my last mail is still waiting for approval, I will resend it. > > Hi all, > > I am trying to boot Linux via Grub > from an USB stick. I have tried the USB stick on my devel i5 machine > and it worked. > > Log can be found here: http://nopaste.info/2b119334eb.html I don't see anything that looks obviously wrong from your log. A more detailed description of what's failing may help. Also, you could try copying the image to a machine and run it under qemu (both as an ATA image and as a USB ehci image). Testing under qemu will verify that it's not a logic error. -Kevin

1 0

Re: [SeaBIOS] How to Debug read operation on hda
by Kevin O'Connor 04 Mar '12

04 Mar '12

On Wed, Feb 29, 2012 at 11:22:34AM +0900, Daniel Castro wrote: > Greeting, > > As part of the xen code for PV-Drivers in Seabios I am trying to boot > from a PV drive. The two ends are connected, and it should be working, > but when I try to boot from the harddrive it fails. > Inside the code I treat the cdrom as a drive, except I register it in > seabios with the cdrom function, but also it fails to boot from cdrom > with Error 003. > This could mean that maybe I am adding the drives incorrectly, or that > my read/write opertaion is wrong. > > Since the operation runs in 16bit how can I debug it to see what is being done? I usually debug by adding dprintf statements. When that's too painful, I connect gdb to qemu and set break points - the steps for using gdb are in the README file. I don't know if there is a similar way to connect gdb to a xen session. -Kevin

1 0

USB boot failes
by Christian Gmeiner 04 Mar '12

04 Mar '12

As my last mail is still waiting for approval, I will resend it. Hi all, I am trying to boot Linux via Grub from an USB stick. I have tried the USB stick on my devel i5 machine and it worked. Log can be found here: http://nopaste.info/2b119334eb.html thanks -- Christian Gmeiner, MSc

1 0

Linux-ready Firmware Kit
by Fred . 03 Mar '12

03 Mar '12

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

1 0

invalid handle_legacy_disk
by Christian Gmeiner 02 Mar '12

02 Mar '12

What is the cause of this error message? I am tying to boot via CFC. finalize PMM malloc finalize Add to e820 map: 0009fc00 00000400 2 Add to e820 map: 0f7c0000 00010000 1 Returned 65536 bytes of ZoneHigh e820 map has 5 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 000000000f7d0000 = 1 RAM 4: 000000000f7d0000 - 000000000f7e0000 = 2 RESERVED Jump to int19 enter handle_19: NULL Booting from Hard Disk... Booting from 0000:7c00 ata_reset drive=0x0000db10 ata_reset exit status=50 enter handle_12: a=00000000 b=0010a480 c=00000000 d=00000000 ds=0000 es=0000 ss=0000 si=001069f0 di=000168c0 bp=00001ff0 sp=00001ff4 cs=0000 ip=8a9b f=0246 invalid handle_legacy_disk:846: a=00000201 b=00000000 c=00000001 d=00000081 ds=0000 es=6800 ss=0000 si=00070003 di=0f750201 bp=00001ff0 sp=00001ff4 cs=0000 ip=8994 f=0246 invalid handle_legacy_disk:846: a=00000000 b=00000001 c=00000001 d=00000081 ds=0000 es=6800 ss=0000 si=00070003 di=0f750201 bp=00001ff0 sp=00001ff4 cs=0000 ip=899c f=0246 invalid handle_legacy_disk:846: a=00000201 b=00000000 c=00000001 d=00000081 ds=0000 es=6800 ss=0000 si=00070002 di=0f750201 bp=00001ff0 sp=00001ff4 cs=0000 ip=8994 f=0246 invalid handle_legacy_disk:846: a=00000000 b=00000001 c=00000001 d=00000081 ds=0000 es=6800 ss=0000 si=00070002 di=0f750201 bp=00001ff0 sp=00001ff4 cs=0000 ip=899c f=0246 invalid handle_legacy_disk:846: a=00000201 b=00000000 c=00000001 d=00000081 ds=0000 es=6800 ss=0000 si=00070001 di=0f750201 bp=00001ff0 sp=00001ff4 cs=0000 ip=8994 f=0246 invalid handle_legacy_disk:846: a=00000000 b=00000001 c=00000001 d=00000081 ds=0000 es=6800 ss=0000 si=00070001 di=0f750201 bp=00001ff0 sp=00001ff4 cs=0000 ip=899c f=0246 invalid handle_legacy_disk:846: a=00000000 b=00000081 c=0000000d d=00000000 ds=0000 es=0000 ss=0000 si=0007fe10 di=0f7506c4 bp=00001ff0 sp=00001ff4 cs=0000 ip=8a6f f=0246 invalid handle_legacy_disk:846: a=00001500 b=00000081 c=0000000d d=00000000 ds=0000 es=0000 ss=0000 si=0007fe10 di=0f7506c4 bp=00001ff0 sp=00001ff4 cs=0000 ip=8a74 f=0247 unimplemented handle_1aXX:493: a=00005650 b=00000000 c=00000000 d=0f611eae ds=0000 es=0000 ss=0000 si=0f7a9070 di=0f6134d8 bp=00001ff0 sp=00001ff2 cs=0000 ip=8f1e f=0246 invalid handle_legacy_disk:846: a=00000201 b=00000000 c=00000001 d=00000081 ds=0000 es=6800 ss=0000 si=00070003 di=0f750201 bp=00001ff0 sp=00001ff4 cs=0000 ip=8994 f=0246 invalid handle_legacy_disk:846: a=00000000 b=00000001 c=00000001 d=00000081 ds=0000 es=6800 ss=0000 si=00070003 di=0f750201 bp=00001ff0 sp=00001ff4 cs=0000 ip=899c f=0246 invalid handle_legacy_disk:846: a=00000201 b=00000000 c=00000001 d=00000081 ds=0000 es=6800 ss=0000 si=00070002 di=0f750201 bp=00001ff0 sp=00001ff4 cs=0000 ip=8994 f=0246 invalid handle_legacy_disk:846: a=00000000 b=00000001 c=00000001 d=00000081 ds=0000 es=6800 ss=0000 si=00070002 di=0f750201 bp=00001ff0 sp=00001ff4 cs=0000 ip=899c f=0246 invalid handle_legacy_disk:846: a=00000201 b=00000000 c=00000001 d=00000081 ds=0000 es=6800 ss=0000 si=00070001 di=0f750201 bp=00001ff0 sp=00001ff4 cs=0000 ip=8994 f=0246 invalid handle_legacy_disk:846: a=00000000 b=00000001 c=00000001 d=00000081 ds=0000 es=6800 ss=0000 si=00070001 di=0f750201 bp=00001ff0 sp=00001ff4 cs=0000 ip=899c f=0246 invalid handle_legacy_disk:846: a=00000000 b=00000081 c=0000000d d=00000000 ds=0000 es=0000 ss=0000 si=0007fe10 di=0f7506c4 bp=00001ff0 sp=00001ff4 cs=0000 ip=8a6f f=0246 invalid handle_legacy_disk:846: a=00001500 b=00000081 c=0000000d d=00000000 ds=0000 es=0000 ss=0000 si=0007fe10 di=0f7506c4 bp=00001ff0 sp=00001ff4 cs=0000 ip=8a74 f=0247 -- Christian Gmeiner, MSc

1 0

First access to the block drive
by Daniel Castro 01 Mar '12

01 Mar '12

Hello all, The xen pv drivers are almost done. When I start the booting process from hda seabios tries to read lba at 0 (sector 0) buffer (buf_fl) to 7c00 count 0 operation 0 (read) command 1 (unlisted) I do not understand count 0 and command 1. Should it be count 1, for the first sector on the drive and a command such as listed in drive.h? Is this normal? Am I missing something? Thanks, Daniel -- +-=====---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | | | Daniel Castro, | | | | Consultant/Programmer.| | | | U Andes | +-------------------------------------+

1 0

[PATCH RFC] seabios: add OSHP method stub
by Michael S. Tsirkin 29 Feb '12

29 Feb '12

To allow guests to load the native SHPC driver for a bridge, we must declare an OSHP method for the appropriate device which lets the OS take control of the SHPC. As we don't access SHPC at the moment, we don't need to do anything - just report success. Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> --- diff --git a/src/ssdt-pcihp.dsl b/src/ssdt-pcihp.dsl index 442e7a8..3f50169 100644 --- a/src/ssdt-pcihp.dsl +++ b/src/ssdt-pcihp.dsl @@ -24,6 +24,7 @@ DefinitionBlock ("ssdt-pcihp.aml", "SSDT", 0x01, "BXPC", "BXSSDTPCIHP", 0x1) ACPI_EXTRACT_METHOD_STRING aml_ej0_name \ Method (_EJ0, 1) { Return(PCEJ(0x##slot)) } \ Name (_SUN, 0x##slot) \ + Method (OSHP, 1) { Return(0x0) } \ } hotplug_slot(03)

4 9

1.6.3 stable backports
by Ian Campbell 29 Feb '12

29 Feb '12

Hi, I'm not sure what the correct procedure is for requesting these so I hope it is ok to post here. Xen is currently using the 1.6.3-stable branch of SeaBIOS, our users have requested a backport of two commits (related to building on NetBSD IIRC): 97f1ffcfac4ca382b5008a7aabfc2c300131f978 Add PYTHON definition to Makefile. 805ede2bd35243a4298bc64bd81be6db7cf57f58 Permit .rodata.__PRETTY_FUNCTION__. sections in roms. Would it be possible to backport those two? I actually already backported these to our own 1.6.3-stable-xen branch but belatedly thought I should inquire about the possibility of an upstream backport -- it would be much preferable to keep the divergence between 1.6.3-stable and -xen to a minimum. If you are happy to backport then you could (if you wanted) pull directly from the Xen branch: The following changes since commit 80d11e8577bf03e98f2eb1b0cb3a281ab2879c9e: Update version to 1.6.3.1 (2011-11-24 12:02:03 -0500) are available in the git repository at: git://xenbits.xen.org/seabios.git 1.6.3-stable-xen Kevin O'Connor (2): Add PYTHON definition to Makefile. Permit .rodata.__PRETTY_FUNCTION__. sections in roms. Makefile | 7 ++++--- tools/layoutrom.py | 12 ++++++++---- 2 files changed, 12 insertions(+), 7 deletions(-) Cheers, Ian.

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS