December 2011 - SeaBIOS - mail.coreboot.org

Re: [SeaBIOS] Simple Boot Flag Specification
by Peter Stuge Dec. 10, 2011

Dec. 10, 2011

Fred . wrote: > I am not a programmer. > But I looked at the specification and it looks short and simple, so it > looks like it would be quick and easy for a programmer to implement. What would be the benefit? //Peter

2 1

Add bootsplash.jpg and bootsplash.bmp file in tree
by Fred . Dec. 9, 2011

Dec. 9, 2011

Add a default bootsplash.jpg and bootsplash.bmp file in the source tree.

1 0

Re: [SeaBIOS] Simple Boot Flag Specification
by Peter Stuge Dec. 9, 2011

Dec. 9, 2011

Fred . wrote: > Add support for Simple Boot Flag Specification. > http://www.microsoft.com/whdc/resources/respec/specs/simp_boot.mspx Please send patches. Thanks in advance! //Peter

2 1

Simple Boot Flag Specification
by Fred . Dec. 9, 2011

Dec. 9, 2011

Add support for Simple Boot Flag Specification. http://www.microsoft.com/whdc/resources/respec/specs/simp_boot.mspx

1 0

Request: add support for animated splash screens
by Fred . Dec. 7, 2011

Dec. 7, 2011

In the Windows splash screen the Windows logo is glowing. It would be nice if SeaBIOS supported animated splash screens. This could be done with APNG or MNG. Even GIF, though it has color depth limitations.

1 0

Re: [SeaBIOS] [SeaBIOS PATCH v2] hotplug: Add device per func in ACPI DSDT tables
by Michael S. Tsirkin Dec. 7, 2011

Dec. 7, 2011

On Wed, Sep 21, 2011 at 01:39:22AM -0400, Amos Kong wrote: > ----- Original Message ----- > > On Tue, Sep 20, 2011 at 06:45:57AM -0400, Amos Kong wrote: > > > From 48ea1c9188334b89a60b4f9e853e86fc04fda4a5 Mon Sep 17 00:00:00 > > > 2001 > > > From: Amos Kong <akong(a)redhat.com> > > > Date: Tue, 20 Sep 2011 15:38:43 +0800 > > > Subject: [SeaBIOS PATCH v2] hotplug: Add device per func in ACPI > > > DSDT tables > > > > > > Only func 0 is registered to guest driver (we can > > > only found func 0 in slot->funcs list of driver), > > > the other functions could not be cleaned when > > > hot-removing the whole slot. This patch adds > > > device per function in ACPI DSDT tables. > > > > > > Have tested with linux/winxp/win7, hot-adding/hot-remving, > > > single/multiple function device, they are all fine. > > > --- > > > Changes from v1: > > > - cleanup the macros, bios.bin gets back to 128K > > > - notify only when func0 is added and removed > > > > How about moving code into functions so that it isn't duplicated for > > each PCI device. See the patch below as an example (100% untested). Hmm, I sent patches that did a similar thing but in a slightly more compact way. Message ids: 20110919092932.GB4501(a)redhat.com 20110919093644.GC4501(a)redhat.com 20110919100434.GA6764(a)redhat.com Did they not reach you or something's wrong with them? > > Tested, it works as my original patch-v2. > > > The CPU hotplug stuff works this way, except it run-time generates > > the > > equivalent of "Device(S???)" and "PCNT". (It may make sense to > > run-time generate the PCI hotplug as well - it consumes about 10K of > > space to statically generate the 31 devices.) > > I'm ok with the new version. > > Acked-by: Amos Kong <akong(a)redhat.com> > > > -Kevin > > > > > > diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl > > index 08412e2..31ac5eb 100644 > > --- a/src/acpi-dsdt.dsl > > +++ b/src/acpi-dsdt.dsl > > @@ -128,48 +128,6 @@ DefinitionBlock ( > > PCRM, 32, > > } > > > > -#define hotplug_slot(name, nr) \ > > - Device (S##name) { \ > > - Name (_ADR, nr##0000) \ > > - Method (_EJ0,1) { \ > > - Store(ShiftLeft(1, nr), B0EJ) \ > > - Return (0x0) \ > > - } \ > > - Name (_SUN, name) \ > > - } > > - > > - hotplug_slot(1, 0x0001) > > - hotplug_slot(2, 0x0002) > > - hotplug_slot(3, 0x0003) > > - hotplug_slot(4, 0x0004) > > - hotplug_slot(5, 0x0005) > > - hotplug_slot(6, 0x0006) > > - hotplug_slot(7, 0x0007) > > - hotplug_slot(8, 0x0008) > > - hotplug_slot(9, 0x0009) > > - hotplug_slot(10, 0x000a) > > - hotplug_slot(11, 0x000b) > > - hotplug_slot(12, 0x000c) > > - hotplug_slot(13, 0x000d) > > - hotplug_slot(14, 0x000e) > > - hotplug_slot(15, 0x000f) > > - hotplug_slot(16, 0x0010) > > - hotplug_slot(17, 0x0011) > > - hotplug_slot(18, 0x0012) > > - hotplug_slot(19, 0x0013) > > - hotplug_slot(20, 0x0014) > > - hotplug_slot(21, 0x0015) > > - hotplug_slot(22, 0x0016) > > - hotplug_slot(23, 0x0017) > > - hotplug_slot(24, 0x0018) > > - hotplug_slot(25, 0x0019) > > - hotplug_slot(26, 0x001a) > > - hotplug_slot(27, 0x001b) > > - hotplug_slot(28, 0x001c) > > - hotplug_slot(29, 0x001d) > > - hotplug_slot(30, 0x001e) > > - hotplug_slot(31, 0x001f) > > - > > Name (_CRS, ResourceTemplate () > > { > > WordBusNumber (ResourceProducer, MinFixed, MaxFixed, > > PosDecode, > > @@ -762,6 +720,119 @@ DefinitionBlock ( > > Zero /* reserved */ > > }) > > > > + /* PCI hotplug */ > > + Scope(\_SB.PCI0) { > > + /* Methods called by bulk generated PCI devices below */ > > + Method (PCEJ, 1, NotSerialized) { > > + // _EJ0 method - eject callback > > + Store(ShiftLeft(1, Arg0), B0EJ) > > + Return (0x0) > > + } > > + > > + /* Bulk generated PCI hotplug devices */ > > +#define hotplug_func(nr, fn) \ > > + Device (S##nr##fn) { \ > > + Name (_ADR, 0x##nr##000##fn) \ > > + Method (_EJ0, 1) { Return(PCEJ(0x##nr)) } \ > > + Name (_SUN, 0x##nr) \ > > + } The fundamental question is still why would we have _EJ0 methods in functions >0 when they are not individually hotpluggable. I think only function 0 should have _EJ0. > > + > > +#define hotplug_slot(nr) \ > > + hotplug_func(nr, 0) \ > > + hotplug_func(nr, 1) \ > > + hotplug_func(nr, 2) \ > > + hotplug_func(nr, 3) \ > > + hotplug_func(nr, 4) \ > > + hotplug_func(nr, 5) \ > > + hotplug_func(nr, 6) \ > > + hotplug_func(nr, 7) > > + > > + hotplug_slot(01) > > + hotplug_slot(02) > > + hotplug_slot(03) > > + hotplug_slot(04) > > + hotplug_slot(05) > > + hotplug_slot(06) > > + hotplug_slot(07) > > + hotplug_slot(08) > > + hotplug_slot(09) > > + hotplug_slot(0a) > > + hotplug_slot(0b) > > + hotplug_slot(0c) > > + hotplug_slot(0d) > > + hotplug_slot(0e) > > + hotplug_slot(0f) > > + hotplug_slot(10) > > + hotplug_slot(11) > > + hotplug_slot(12) > > + hotplug_slot(13) > > + hotplug_slot(14) > > + hotplug_slot(15) > > + hotplug_slot(16) > > + hotplug_slot(17) > > + hotplug_slot(18) > > + hotplug_slot(19) > > + hotplug_slot(1a) > > + hotplug_slot(1b) > > + hotplug_slot(1c) > > + hotplug_slot(1d) > > + hotplug_slot(1e) > > + hotplug_slot(1f) > > + > > + /* PCI hotplug notify method */ > > + Method(PCNF, 0) { > > + // Local0 = iterator > > + Store (Zero, Local0) > > + While (LLess(Local0, 31)) { > > + Increment(Local0) > > + If (And(PCIU, ShiftLeft(1, Local0))) { > > + PCNT(Local0, 1) > > + } > > + If (And(PCID, ShiftLeft(1, Local0))) { > > + PCNT(Local0, 3) > > + } > > + } > > + Return(One) > > + } > > + > > +#define hotplug_notify(nr) \ > > + If (LEqual(Arg0, 0x##nr)) {Notify(S##nr##0, Arg1)} > > + > > + Method(PCNT, 2) { > > + hotplug_notify(01) > > + hotplug_notify(02) > > + hotplug_notify(03) > > + hotplug_notify(04) > > + hotplug_notify(05) > > + hotplug_notify(06) > > + hotplug_notify(07) > > + hotplug_notify(08) > > + hotplug_notify(09) > > + hotplug_notify(0a) > > + hotplug_notify(0b) > > + hotplug_notify(0c) > > + hotplug_notify(0d) > > + hotplug_notify(0e) > > + hotplug_notify(0f) > > + hotplug_notify(10) > > + hotplug_notify(11) > > + hotplug_notify(12) > > + hotplug_notify(13) > > + hotplug_notify(14) > > + hotplug_notify(15) > > + hotplug_notify(16) > > + hotplug_notify(17) > > + hotplug_notify(18) > > + hotplug_notify(19) > > + hotplug_notify(1a) > > + hotplug_notify(1b) > > + hotplug_notify(1c) > > + hotplug_notify(1d) > > + hotplug_notify(1e) > > + hotplug_notify(1f) > > + } > > + } > > + > > /* CPU hotplug */ > > Scope(\_SB) { > > /* Objects filled in by run-time generated SSDT */ > > @@ -842,49 +913,9 @@ DefinitionBlock ( > > Return(0x01) > > } > > > > -#define gen_pci_hotplug(nr) \ > > - If (And(\_SB.PCI0.PCIU, ShiftLeft(1, nr))) { \ > > - Notify(\_SB.PCI0.S##nr, 1) \ > > - } \ > > - If (And(\_SB.PCI0.PCID, ShiftLeft(1, nr))) { \ > > - Notify(\_SB.PCI0.S##nr, 3) \ > > - } > > - > > Method(_L01) { > > - gen_pci_hotplug(1) > > - gen_pci_hotplug(2) > > - gen_pci_hotplug(3) > > - gen_pci_hotplug(4) > > - gen_pci_hotplug(5) > > - gen_pci_hotplug(6) > > - gen_pci_hotplug(7) > > - gen_pci_hotplug(8) > > - gen_pci_hotplug(9) > > - gen_pci_hotplug(10) > > - gen_pci_hotplug(11) > > - gen_pci_hotplug(12) > > - gen_pci_hotplug(13) > > - gen_pci_hotplug(14) > > - gen_pci_hotplug(15) > > - gen_pci_hotplug(16) > > - gen_pci_hotplug(17) > > - gen_pci_hotplug(18) > > - gen_pci_hotplug(19) > > - gen_pci_hotplug(20) > > - gen_pci_hotplug(21) > > - gen_pci_hotplug(22) > > - gen_pci_hotplug(23) > > - gen_pci_hotplug(24) > > - gen_pci_hotplug(25) > > - gen_pci_hotplug(26) > > - gen_pci_hotplug(27) > > - gen_pci_hotplug(28) > > - gen_pci_hotplug(29) > > - gen_pci_hotplug(30) > > - gen_pci_hotplug(31) > > - > > - Return (0x01) > > - > > + // PCI hotplug event > > + Return(\_SB.PCI0.PCNF()) > > } > > Method(_L02) { > > // CPU hotplug event > >

3 5

[PATCH 9/9] Removed superfluous irrelevant time
by Fred . Dec. 5, 2011

Dec. 5, 2011

>From c7ff0721ef713a5b43f438c117c7d28bb3e8857e Mon Sep 17 00:00:00 2001 From: anonymous <anonymous(a)VirtualBox.(none)> Date: Mon, 5 Dec 2011 21:52:19 +0100 Subject: [PATCH 9/9] Removed superfluous irrelevant time --- Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index c3ba2f3..6a1422e 100644 --- a/Makefile +++ b/Makefile @@ -5,7 +5,7 @@ # This file may be distributed under the terms of the GNU LGPLv3 license. # Program version -VERSION=pre-1.6.4-$(shell date +"%Y%m%d_%H%M%S")-$(shell hostname) +VERSION=pre-1.6.4-$(shell date +"%Y%m%d")-$(shell hostname) # Output directory OUT=out/ -- 1.7.7.3

1 0

Pause button
by Fred . Dec. 5, 2011

Dec. 5, 2011

Add so you can press the Pause/Break button on the keyboard to pause the bootup so you can read the messages on the screen because it goes so fast. Other BIOS such as AMI and Award can do this.

1 0

[PATCH 2/6] Fixed capitalization
by Fred . Dec. 5, 2011

Dec. 5, 2011

>From 4976cedfde3dd04125a05b4ae9b8eb0944c0985e Mon Sep 17 00:00:00 2001 From: anonymous <anonymous(a)VirtualBox.(none)> Date: Sun, 4 Dec 2011 16:00:54 +0100 Subject: [PATCH 2/6] Fixed capitalization --- TODO | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/TODO b/TODO index 23f26c0..0ac187e 100644 --- a/TODO +++ b/TODO @@ -16,6 +16,6 @@ is unnecessary. Support PCIv3 roms? Add support for PCI "configuration code" extensions? -Possibly add option to eliminate tsc based delays on emulators. +Possibly add option to eliminate TSC-based delays on emulators. Possibly support sending debug information over EHCI debug port. -- 1.7.7.3

1 0

[PATCH 1/6] Improvements without changing content.
by Fred . Dec. 5, 2011

Dec. 5, 2011

>From 679784bb134c4e84531e64de6727b4bc8d0f4d6b Mon Sep 17 00:00:00 2001 From: anonymous <anonymous(a)VirtualBox.(none)> Date: Sun, 4 Dec 2011 15:52:07 +0100 Subject: [PATCH 1/6] Improvements without changing content. --- README | 78 ++++++++++++++++++++++++++++++++-------------------------------- 1 files changed, 39 insertions(+), 39 deletions(-) diff --git a/README b/README index 1f40433..b74681e 100644 --- a/README +++ b/README @@ -1,5 +1,5 @@ -This code implements an X86 legacy bios. It is intended to be -compiled using standard gnu tools (eg, gas and gcc). +This code implements an x86 legacy bios. It is intended to be +compiled using standard GNU tools (eg, gas and gcc). To build, one should be able to run "make" in the main directory. The resulting file "out/bios.bin" contains the processed bios image. @@ -7,27 +7,27 @@ resulting file "out/bios.bin" contains the processed bios image. Testing of images: -To test the bios under bochs, one will need to instruct bochs to use -the new bios image. Use the 'romimage' option - for example: +To test the BIOS under Bochs, one will need to instruct Bochs to use +the new BIOS image. Use the 'romimage' option - for example: bochs -q 'floppya: 1_44=myfdimage.img' 'romimage: file=out/bios.bin' -To test under qemu, one will need to create a directory with all the -bios images and then overwrite the main bios image. For example: +To test under QEMU, one will need to create a directory with all the +BIOS images and then overwrite the main BIOS image. For example: cp /usr/share/qemu/*.bin mybiosdir/ cp out/bios.bin mybiosdir/ -Once this is setup, one can instruct qemu to use the newly created -directory for rom images. For example: +Once this is setup, one can instruct QEMU to use the newly created +directory for ROM images. For example: qemu -L mybiosdir/ -fda myfdimage.img Overview of files: -The src/ directory contains the bios source code. Several of the -files are compiled twice - once for 16bit mode and once for 32bit +The src/ directory contains the BIOS source code. Several of the +files are compiled twice - once for 16-bit mode and once for 32-bit mode. (The build system will remove code that is not needed for a particular mode.) @@ -40,33 +40,33 @@ temporary and final files. Build overview: -The 16bit code is compiled via gcc to assembler (file out/ccode.16.s). +The 16-bit code is compiled via gcc to assembler (file out/ccode.16.s). The gcc "-fwhole-program" and "-ffunction-sections -fdata-sections" options are used to optimize the process so that gcc can efficiently compile and discard unneeded code. (In the code, one can use the macros 'VISIBLE16' and 'VISIBLE32FLAT' to instruct a symbol to be -outputted in 16bit and 32bit mode respectively.) +outputted in 16-bit and 32-bit mode respectively.) This resulting assembler code is pulled into romlayout.S. The gas option ".code16gcc" is used prior to including the gcc generated -assembler - this option enables gcc to generate valid 16 bit code. +assembler - this option enables gcc to generate valid 16-bit code. The post code (post.c) is entered, via the function handle_post(), in -32bit mode. The 16bit post vector (in romlayout.S) transitions the +32-bit mode. The 16bit post vector (in romlayout.S) transitions the cpu into 32 bit mode before calling the post.c code. -In the last step of compilation, the 32 bit code is merged into the 16 +In the last step of compilation, the 32-bit code is merged into the 16 bit code so that one binary file contains both. Currently, both 16bit -and 32bit code will be located in the memory at 0xe0000-0xfffff. +and 32-bit code will be located in the memory at 0xe0000-0xfffff. -GCC 16 bit limitations: +GCC 16-bit limitations: -Although the 16bit code is compiled with gcc, developers need to be +Although the 16-bit code is compiled with gcc, developers need to be aware of the environment. In particular, global variables _must_ be treated specially. -The code has full access to stack variables and general purpose +The code has full access to stack variables and general-purpose registers. The entry code in romlayout.S will push the original registers on the stack before calling the C code and then pop them off (including any required changes) before returning from the interrupt. @@ -79,7 +79,7 @@ normally do in standard C code. However, variables stored outside the stack need to be accessed via the GET_VAR and SET_VAR macros (or one of the helper macros described -below). This is due to the 16bit segment nature of the X86 cpu when +below). This is due to the 16-bit segment nature of the x86 CPU when it is in "real mode". The C entry code will set DS and SS to point to the stack segment. Variables not on the stack need to be accessed via an explicit segment register. Any other access requires altering one @@ -99,23 +99,23 @@ Most BIOS variables are stored in global variables, the "BDA", or macros (GET/SET_GLOBAL, GET/SET_BDA, and GET/SET_EBDA) are available to simplify these accesses. -Global variables defined in the C code can be read in 16bit mode if +Global variables defined in the C code can be read in 16-bit mode if the variable declaration is marked with VAR16, VAR16VISIBLE, VAR16EXPORT, or VAR16FIXED. The GET_GLOBAL macro will then allow read access to the variable. Global variables are stored in the 0xf000 segment, and their values are persistent across soft resets. Because -the f-segment is marked read-only during run-time, the 16bit code is -not permitted to change the value of 16bit variables (use of the -SET_GLOBAL macro from 16bit mode will cause a link error). Code -running in 32bit mode can not access variables with VAR16, but can +the f-segment is marked read-only during run-time, the 16-bit code is +not permitted to change the value of 16-bit variables (use of the +SET_GLOBAL macro from 16-bit mode will cause a link error). Code +running in 32-bit mode can not access variables with VAR16, but can access variables marked with VAR16VISIBLE, VAR16EXPORT, VAR16FIXED, or -with no marking at all. The 32bit code can use the GET/SET_GLOBAL +with no marking at all. The 32-bit code can use the GET/SET_GLOBAL macros, but they are not required. -GCC 16 bit stack limitations: +GCC 16-bit stack limitations: -Another limitation of gcc is its use of 32-bit temporaries. Gcc will +Another limitation of gcc is its use of 32-bit temporaries. GCC will allocate 32-bits of space for every variable - even if that variable is only defined as a 'u8' or 'u16'. If one is not careful, using too much stack space can break old DOS applications. @@ -124,9 +124,9 @@ There does not appear to be explicit documentation on the minimum stack space available for bios calls. However, Freedos has been observed to call into the bios with less than 150 bytes available. -Note that the post code and boot code (irq 18/19) do not have a stack +Note that the post code and boot code (IRQ 18/19) do not have a stack limitation because the entry points for these functions transition the -cpu to 32bit mode and reset the stack to a known state. Only the +cpu to 32-bit mode and reset the stack to a known state. Only the general purpose 16-bit service entry points are affected. There are some ways to reduce stack usage: making sure functions are @@ -136,29 +136,29 @@ helps, inlining of functions can sometimes help, and passing of packed structures can also help. It is also possible to transition to/from an extra stack stored in the EBDA using the stack_hop helper function. -Some useful stats: the overhead for the entry to a bios handler that +Some useful stats: the overhead for the entry to a BIOS handler that takes a 'struct bregs' is 42 bytes of stack space (6 bytes from interrupt insn, 32 bytes to store registers, and 4 bytes for call insn). An entry to an ISR handler without args takes 30 bytes (6 + 20 + 4). -Debugging the bios: +Debugging the BIOS: -The bios will output information messages to a special debug port. -Under qemu, one can view these messages by adding '-chardev +The BIOS will output information messages to a special debug port. +Under QEMU, one can view these messages by adding '-chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios' to the qemu command line. Once this is done, one should see status messages on the console. -The gdb-server mechanism of qemu is also useful. One can use gdb with +The gdb-server mechanism of QEMU is also useful. One can use gdb with qemu to debug system images. To use this, add '-s -S' to the qemu command line. For example: qemu -L mybiosdir/ -fda myfdimage.img -s -S Then, in another session, run gdb with either out/rom16.o (to debug -bios 16bit code) or out/rom32.o (to debug bios 32bit code). For +BIOS 16-bit code) or out/rom32.o (to debug BIOS 32-bit code). For example: gdb out/rom16.o @@ -166,8 +166,8 @@ gdb out/rom16.o Once in gdb, use the command "target remote localhost:1234" to have gdb connect to qemu. See the qemu documentation for more information on using gdb and qemu in this mode. Note that gdb seems to get -breakpoints confused when the cpu is in 16-bit real mode. This makes +breakpoints confused when the CPU is in 16-bit real mode. This makes stepping through the program difficult (though 'step instruction' -still works). Also, one may need to set 16bit break points at both -the cpu address and memory address (eg, break *0x1234 ; break +still works). Also, one may need to set 16-bit break points at both +the CPU address and memory address (eg, break *0x1234 ; break *0xf1234). -- 1.7.7.3

1 0