SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

[ANNOUNCE] SeaBIOS 1.10.0
by Kevin O'Connor 26 Oct '16

26 Oct '16

The 1.10.0 version of SeaBIOS has now been released. For more information on the release, please see: http://seabios.org/Releases New in this release: * Initial support for Trusted Platform Module (TPM) version 2.0 * Several USB XHCI timing fixes on real hardware * Support for "LSI MPT Fusion" scsi controllers on QEMU * Support for virtio devices mapped above 4GB * Several bug fixes and code cleanups For information on obtaining SeaBIOS, please see: http://seabios.org/Download ===== git shortlog -n rel-1.9.0..rel-1.10.0 ===== Kevin O'Connor (124): usb: Allow configuration of sigatt time (in etc/usb-time-sigatt) xhci: Check for device disconnects during USB2 reset polling sdcard: Only enable error_irq_enable for bits defined in SDHCI v1 spec sdcard: fix typo causing 32bit write to 16bit block_size field sdcard: Enable extra debugging on sdcard_waitw() timeout acpi_extract: Move main code to new function main() acpi_extract: Make the generated .hex files more human readable acpi_extract: Don't generate unused (and empty) q35-acpi-dsdt.hex file acpi: Don't build SSDT files on every build; store them in git acpi: Remove build check for iasl tpm: Move standard definitions from tcgbios.h to new file std/tcg.h util.h: Minor - HaveRunPost is in misc.c not resume.c tpm: Add "static" declaration to functions not used outside tcgbios.c tpm: Move code around in tcgbios.c tpm: Move error recovery from tpm_extend_acpi_log() to only caller tpm: Open code tpm_ipl() into callers tpm: Change tpm_add_measurement() to tpm_add_action() tpm: Move tpm_add_bootdevice() into callers tpm: Move tpm_start_option_rom_scan() and tpm_calling_int19h() into callers tpm: pcpes->event is a variable length array tpm: Don't pass entry_count around in parameters to/from tpm_extend_acpi_log() tpm: There is no need to pass pcrindex to hash_log_extend_event() tpm: Perform hashing separately from logging tpm: There is no need to pass event_length to hash/extend functions tpm: Avoid scatter-gather copying in build_and_send_cmd() tpm: Don't implement scatter-gather in transmit() tpm: Merge tpm_log_event() and tpm_extend_acpi_log() tpm: Merge tpm_log_extend_event() and tpm_extend(); extend before logging xhci: Wait for port enable even for USB3 devices xhci: Improve port status change debugging xhci: Disable slot on failed set_address command nmi: Don't try to switch onto extra stack in NMI handler scsi: Do not call printf() from scsi_is_ready() block: Report drive->sectors using "%u" instead of "%d" tpm: Add banner separating the TCG bios interface code from TCG menu code tpm: Avoid macro expansion of tpm request / response structs tpm: Simplify hardware probe and detection checks tpm: Add wrapper function tpmhw_set_timeouts() tpm: Move TPM hardware functions from tcgbios.c to hw/tpm_drivers.c tpm: Rework TPM interface shutdown support tpm: Simplify tcpa probe tpm: Introduce tpm_get_capability() helper function tpm: Eliminate response buffer parameter from build_and_send_cmd() tpm: Don't return a status from external bios measurement functions tpm: No need to check the return status of measurements tpm: Don't call tpm_set_failure() from tpm_log_extend_event() tpm: Don't use 16bit BIOS return codes in build_and_send_cmd() tpm: Don't use 16bit BIOS return codes in tpm_log_event() tpm: Don't use 16bit BIOS return codes in tpmhw_* functions tpm: Don't use 16bit BIOS return codes in TPM menu functions usb: Remove usbdev->slotid field coreboot: Check for unaligned cbfs header resume: Make KVM soft reboot loop detection more flexible post: Always set HaveRunPost prior to setting any other global variable kbd: Don't treat scancode and asciicode as separate values kbd: Refactor capslock and numlock handling ehci: Only delay UHCI/OHCI port scan until after EHCI setup completes usb: Eliminate USB controller setup thread pci: Add helper functions for internal driver BAR handling ahci: Convert to new PCI BAR helper functions ata: Convert to new PCI BAR helper functions esp-scsi: Convert to new PCI BAR helper functions lsi-scsi: Convert to new PCI BAR helper functions megasas: Convert to new PCI BAR helper functions pvscsi: Convert to new PCI BAR helper functions sdcard: Convert to new PCI BAR helper functions ehci: Convert to new PCI BAR helper functions ohci: Convert to new PCI BAR helper functions uhci: Convert to new PCI BAR helper functions xhci: Convert to new PCI BAR helper functions virtio: Convert to new PCI BAR helper functions pci: Consistently set pci->have_drivers for devices with internal drivers pci: Implement '%pP' printf handler for 'struct pci_device' pointers pci: Move code in pci.c that is specific to pciinit.c to pciinit.c pci: Split low-level pci code from higher-level 'struct pci_device' code scsi: Always use MAXDESCSIZE when building drive description block: Move drive setup to new function block_setup() tpm: Unify tpm_fill_hash()/tpm_log_extend_event() and use in BIOS interface docs: Note release date of 1.9.1 build: fix .text section address alignment tpm: Write logs in TPM 2 format mpt-scsi: Declare 'int i' outside of for loop for older compilers block: Move send_disk_op() from block.c to disk.c disk: Avoid stack_hop() path if already on the extra stack optionroms: Drop support for CONFIG_OPTIONROMS_DEPLOYED shadow: Batch PCI config writes virtio: Use threads when scanning for virtio devices scsi: Launch a thread when scanning for drives in the scsi drivers docs: Note release date of 1.9.2 usb-xhci: Remove unused const variables tcgbios: Remove unused const variable vgabios: Remove special case of dh==0xff in handle_1013() vgabios: Don't check for special case of page==0xff on external calls vgabios: Simplify set_cursor_pos() docs: Note release date of 1.9.3 vgabios: Simplify scroll logic blockcmd: CMD_SCSI op is only used in 32bit mode swcursor: Move swcursor code from vgafb.c to new file swcursor.c swcursor: Concentrate swcursor logic in swcursor.c vgafb: Move header definitions from vgabios.h to new file vgafb.h vgainit: Move video param setup to stdvga_build_video_param() vgautil: Add new header file with misc function and variable definitions vgautil: Move generic definitions from stdvga.h to vgautil.h vgautil: Move definitions from cbvga.h and clext.h to vgautil.h version: Update header files now that version.c is not auto generated checkstack: Handle conditional checks at start of functions tpm: Append to TPM2 log the hashes used for PCR extension ps2: Remove stale check for timeout warning on reset pic: The default hardware interrupt handlers should not take a parameter kbd: Implement 101-key keyboard keycode mapping kbd: Implement extended keycode mappings for keypad-enter and keypad-/ kbd: Suppress keys without mappings kbd: Merge bda->kbd_flag0 and bda->kbd_flag1 kbd: Extract out shift flag setting into new function kbd: Move checking for special keys in __process_keys() into switch kbd: Ignore fake shift keys usb-hid: Generate Ctrl+Break and Alt+SysReq keys kbd: Generate interrupt events for SysReq, PrtScr, and Break post: Map int 0x05 to entry point kbd: Move extended and release events out of special key detection switch build: Be sure to also include out/*.d in Makefile smp: consolidate CPU APIC ID detection and accounting build: Add -fno-pie to the gcc flags when available docs: Note v1.10.0 release Stefan Berger (34): tpm: Temporarily deactivate the TPM in case of failure tpm: Refactor function building TPM commands tpm: Refactor the parameters being passed to tpm_extend_acpi_log tpm: Refactor hash_log_event BIOS interface function tpm: Refactor hash_log_extend_event tpm: fix compiler warning with older gcc versions tpm: Drop code using the TPM for sha1 tpm: Set timeouts and durations to microsecond values tpm: Cache all log related pointers in tpm_state tpm: Refactor pass_through_to_tpm tpm: Rename remaining interrupt functions tpm: Remove check for working TPM from TPM interrupt handler tpm: Check length parameter of the array tpm: Add a menu for TPM configuration tpm: Copy digest into HashLogExentEvent response tpm: Move assert_physical_presence and dependencies tpm: Add support for harware physical presence tpm: Rework the assertion of physical presence tpm: Remove usage of PP_CMD_ENABLE from all but one place tpm: Do not set TPM in failure mode if menu command fails tpm: Extend TPM TIS with TPM 2 support. tpm: Factor out tpm_extend tpm: Prepare code for TPM 2 functions tpm: Implement tpm20_startup and tpm20_s3_resume tpm: Implement tpm20_set_timeouts tpm: Implement tpm20_prepboot tpm: Implement tpm20_extend tpm: Implement tpm20_menu tpm: Implement TPM 2's tpm_set_failure part tpm: Filter TPM commands in passthrough API tpm: Retrieve the PCR Bank configuration tpm: Restructure tpm20_extend to use buffer and take hash as parameter tpm: Refactor tpml_digest_values_sha1 structure tpm: Extend tpm20_extend to support extending to multiple PCR banks Gerd Hoffmann (4): ahci: set transfer mode according to the capabilities of connected drive virtio: uninline _vp_{read,write} virtio: pci cfg access virtio: fix virtio-pci Igor Mammedov (3): paravirt: disable legacy bios tables in case of more than 255 CPUs add helpers to read etc/boot-cpus at resume time support booting with more than 255 CPUs Dana Rubin (2): pvscsi: Fix incorrect arguments order in call to memalign_low pvscsi: Use high memory for rings Marcel Apfelbaum (2): fw/pci: do not automatically allocate IO region for PCIe bridges fw/pci: add Q35 S3 support Alex Williamson (1): fw/pci: Add support for mapping Intel IGD via QEMU Cao jin (1): Fix comment typo Cole Robinson (1): biostables: Support SMBIOS 2.6+ UUID format Don Slutz (1): Support for booting from LSI Logic LSI53C1030, SAS1068, SAS1068e Haozhong Zhang (1): fw/msr_feature_control: add support to set MSR_IA32_FEATURE_CONTROL Matt DeVillier (1): sdcard: skip detection of PCI sdhci controllers if etc/sdcard used Paolo Bonzini (1): smp: restore MSRs on S3 resume Piotr Król (1): docs: fix various typos and inconsistency Roger Pau Monne (1): build: fix typo in buildversion.py Zheng Bao (1): splash: Skip the RGB555 mode

1 0

Build failure with GCC 6 from Debian Sid/unstable
by Paul Menzel 25 Oct '16

25 Oct '16

Dear SeaBIOS folks, just a note, that due to a regression in GCC 6 in Debian Sid/unstable [1] the latest master branch [2] does not build. ``` $ make Build Kconfig config file Compile checking out/src/misc.o Compile checking out/src/stacks.o src/stacks.c: Assembler messages: src/stacks.c:567: Error: found '(', expected: ')' src/stacks.c:567: Error: junk `(%ebp))' after expression src/stacks.c:568: Warning: indirect call without `*' Makefile:133: die Regel für Ziel „out/src/stacks.o“ scheiterte make: *** [out/src/stacks.o] Fehler 1 ``` It builds fine with gcc-4.9 and gcc-5. ``` $ make CC=gcc-4.9 -j $ make CC=gcc-5 -j ``` There is gcc-6 6.2.0-9 out already [3], but it’s not available over the mirrors yet. Thanks, Paul [1] http://metadata.ftp-master.debian.org/changelogs/main/g/gcc-6/gcc-6_6.2.0-7… gcc (Debian 6.2.0-7) 6.2.0 20161018 [2] commit 00b0402 (docs: fix various typos and inconsistency) [3] http://metadata.ftp-master.debian.org/changelogs/main/g/gcc-6/gcc-6_6.2.0-9…

4 11

[PATCH] build: Be sure to also include out/*.d in Makefile
by Kevin O'Connor 25 Oct '16

25 Oct '16

Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 41bfcf4..1916ecf 100644 --- a/Makefile +++ b/Makefile @@ -281,4 +281,4 @@ clean: distclean: clean $(Q)rm -f .config .config.old --include $(patsubst %,$(OUT)%/*.d,$(DIRS)) +-include $(OUT)*.d $(patsubst %,$(OUT)%/*.d,$(DIRS)) -- 2.5.5

1 1

[PATCH v5 0/4] support booting more than 255 CPUs with QEMU
by Igor Mammedov 25 Oct '16

25 Oct '16

Changelog since: v4: * (Kevin) drop [PATCH v4 3/5] error out if present cpus count changed during SMP bringup and resolve conflicts caused by this in followup patches v3: * don't move CPU counting around, leave it as is and consolidate apic_id accounting only * add and use qemu_*_present_cpus_count() helpers to init/get boot cpus count at boot time and only qemu_get_present_cpus_count() at resume time * fix S3 wakeup stuck in resume vector * If cpu were hotplugged during smp_scan, report it to user instead of silently hanging if it came online while smp_scan() waits for APs v2: * rebase on top of current master /smp_scan() changes/ v1: * s/count_cpu/apic_id_init/ * merge handle_x2apic() into apic_id_init() RFC: * move out max-cpus check out of mptable_setup() * factor out CPU counting/apic ID detection in separate function * return back accidentially deleted debug message with APIC ID * drop unused code in smp_setup() According to SDM, if CPUs have APIC ID more than 254 firmware should pass control to OS in x2APIC mode. This series adds x2APIC bootstrap initialization. QEMU side of x2APIC support: "[PATCH v3 00/13] pc: q35: x2APIC support in kvm_apic mode" https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg02865.html Note: S3 wakeup works as expected if linux guest is running with IRQ remapping enabled. However it seems that kernel is buggy with IRQ remapping disabled as kernel disables CPUs with APIC ID > 254 and on resume from S3 hangs somewere after getting control from Seabios. Cc: rkrcmar(a)redhat.com Cc: mst(a)redhat.com Cc: jan.kiszka(a)web.de Cc: kraxel(a)redhat.com Cc: pbonzini(a)redhat.com Cc: lersek(a)redhat.com Cc: kraxel(a)redhat.com Igor Mammedov (3): paravirt: disable legacy bios tables in case of more than 255 CPUs add helpers to read etc/boot-cpus at resume time support booting with more than 255 CPUs Kevin O'Connor (1): smp: consolidate CPU APIC ID detection and accounting src/fw/paravirt.h | 3 +++ src/x86.h | 1 + src/fw/paravirt.c | 44 ++++++++++++++++++++++++++++++++++++++++++-- src/fw/smp.c | 52 +++++++++++++++++++++++++++++++++++++--------------- 4 files changed, 83 insertions(+), 17 deletions(-) -- 2.7.4

2 7

Re: [SeaBIOS] [PATCH] vgabios: Reorder video modes to work around a Windows bug
by Kevin O'Connor 20 Oct '16

20 Oct '16

On Wed, Oct 19, 2016 at 11:32:41AM +0200, Ladi Prosek wrote: > On Wed, Oct 19, 2016 at 10:06 AM, Ladi Prosek <lprosek(a)redhat.com> wrote: > > On Wed, Oct 19, 2016 at 1:29 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote: > >> On Mon, Oct 17, 2016 at 05:53:04PM +0200, Ladi Prosek wrote: > >>> Windows Server 2016 and Windows 10 RS1 come with a bug in its blue screen > >>> of death rendering logic which prevents it from generating crash dumps. > >>> > >>> The bug does not manifest if Windows sees a suitable 32 bpp video mode > >>> before a suitable 24 bpp video mode in the list of modes returned from > >>> vgabios. This commit moves all 32 bpp modes to the front of the list to > >>> make sure that this is always the case. > >>> > >>> Signed-off-by: Ladi Prosek <lprosek(a)redhat.com> > >>> --- > >>> vgasrc/bochsvga.c | 39 ++++++++++++++++++++------------------- > >>> 1 file changed, 20 insertions(+), 19 deletions(-) > >>> > >>> diff --git a/vgasrc/bochsvga.c b/vgasrc/bochsvga.c > >>> index ec5d101..c5d1511 100644 > >>> --- a/vgasrc/bochsvga.c > >>> +++ b/vgasrc/bochsvga.c > >>> @@ -28,6 +28,25 @@ static struct bochsvga_mode > >>> u16 mode; > >>> struct vgamode_s info; > >>> } bochsvga_modes[] VAR16 = { > >>> + /* 32 bpp BOCHS modes */ > >>> + { 0x140, { MM_DIRECT, 320, 200, 32, 8, 16, SEG_GRAPH } }, > >>> + { 0x141, { MM_DIRECT, 640, 400, 32, 8, 16, SEG_GRAPH } }, > >>> + { 0x142, { MM_DIRECT, 640, 480, 32, 8, 16, SEG_GRAPH } }, > >>> + { 0x143, { MM_DIRECT, 800, 600, 32, 8, 16, SEG_GRAPH } }, > >>> + { 0x144, { MM_DIRECT, 1024, 768, 32, 8, 16, SEG_GRAPH } }, > >>> + { 0x145, { MM_DIRECT, 1280, 1024, 32, 8, 16, SEG_GRAPH } }, > >>> + { 0x147, { MM_DIRECT, 1600, 1200, 32, 8, 16, SEG_GRAPH } }, > >>> + { 0x14c, { MM_DIRECT, 1152, 864, 32, 8, 16, SEG_GRAPH } }, > >>> + { 0x177, { MM_DIRECT, 1280, 768, 32, 8, 16, SEG_GRAPH } }, > >>> + { 0x17a, { MM_DIRECT, 1280, 800, 32, 8, 16, SEG_GRAPH } }, > >>> + { 0x17d, { MM_DIRECT, 1280, 960, 32, 8, 16, SEG_GRAPH } }, > >>> + { 0x180, { MM_DIRECT, 1440, 900, 32, 8, 16, SEG_GRAPH } }, > >>> + { 0x183, { MM_DIRECT, 1400, 1050, 32, 8, 16, SEG_GRAPH } }, > >>> + { 0x186, { MM_DIRECT, 1680, 1050, 32, 8, 16, SEG_GRAPH } }, > >>> + { 0x189, { MM_DIRECT, 1920, 1200, 32, 8, 16, SEG_GRAPH } }, > >>> + { 0x18c, { MM_DIRECT, 2560, 1600, 32, 8, 16, SEG_GRAPH } }, > >>> + { 0x18f, { MM_DIRECT, 1280, 720, 32, 8, 16, SEG_GRAPH } }, > >>> + { 0x192, { MM_DIRECT, 1920, 1080, 32, 8, 16, SEG_GRAPH } }, > >>> /* standard modes */ > >>> { 0x100, { MM_PACKED, 640, 400, 8, 8, 16, SEG_GRAPH } }, > >>> { 0x101, { MM_PACKED, 640, 480, 8, 8, 16, SEG_GRAPH } }, > >>> @@ -56,50 +75,32 @@ static struct bochsvga_mode > >>> { 0x11D, { MM_DIRECT, 1600, 1200, 15, 8, 16, SEG_GRAPH } }, > >>> { 0x11E, { MM_DIRECT, 1600, 1200, 16, 8, 16, SEG_GRAPH } }, > >>> { 0x11F, { MM_DIRECT, 1600, 1200, 24, 8, 16, SEG_GRAPH } }, > >>> - /* BOCHS modes */ > >>> - { 0x140, { MM_DIRECT, 320, 200, 32, 8, 16, SEG_GRAPH } }, > >>> - { 0x141, { MM_DIRECT, 640, 400, 32, 8, 16, SEG_GRAPH } }, > >>> - { 0x142, { MM_DIRECT, 640, 480, 32, 8, 16, SEG_GRAPH } }, > >>> - { 0x143, { MM_DIRECT, 800, 600, 32, 8, 16, SEG_GRAPH } }, > >>> - { 0x144, { MM_DIRECT, 1024, 768, 32, 8, 16, SEG_GRAPH } }, > >>> - { 0x145, { MM_DIRECT, 1280, 1024, 32, 8, 16, SEG_GRAPH } }, > >>> + /* 8, 15, 16, and 24 bpp BOCHS modes */ > >>> { 0x146, { MM_PACKED, 320, 200, 8, 8, 16, SEG_GRAPH } }, > >>> - { 0x147, { MM_DIRECT, 1600, 1200, 32, 8, 16, SEG_GRAPH } }, > >> > >> Thanks. Instead of moving all of the 32bit modes to the top of the > >> list, can the 32bit modes be kept next to the other modes with the > >> same resolution, just above the 24bpp mode? > > > > Yes, that would work too. As long as 32 bpp come before 24 bpp for the > > same resolution, it will be fine. > > > >> Also, all of the mode numbers above 0x11b are arbitrary, so it would > >> be preferable to renumber the mode numbers as lines are moved. > > > > Will do. > > > >> We were about to make a SeaBIOS release - does this need to go into > >> that release? > > > > It would be highly desired as the problematic Windows builds have > > already RTM'ed. > > > > I'll send a v2 with the changes as suggested above. > > Actually, I spoke too soon. The problematic 24 bpp mode that Windows > picks right now is 118 and that's within the standard range so I can't > move 144 above it and renumber. What would be considered safer, > keeping the same mode numbers or partially renumbering to keep them > monotonically increasing except for the standard range? I wouldn't renumber anything at 0x11B or below - those are defined in the vbe3 spec. Ordering and the numbering of all the other modes can be changed. Despite the comment in the source, modes 0x11C-0x11F do not appear to be standard modes. Thinking on this further, there's a good chance other systems (in addition to Windows) choose the first valid mode found. So, reordering the 32bit modes above the 24bit modes could cause changes in other systems as well. So, I think it may be too risky to push this into the pending SeaBIOS release. -Kevin

3 2

Re: [SeaBIOS] [PATCH] vgabios: Reorder video modes to work around a Windows bug
by Laszlo Ersek 20 Oct '16

20 Oct '16

On 10/19/16 15:16, Ladi Prosek wrote: > On Wed, Oct 19, 2016 at 2:23 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote: >> On Wed, Oct 19, 2016 at 11:32:41AM +0200, Ladi Prosek wrote: >>> On Wed, Oct 19, 2016 at 10:06 AM, Ladi Prosek <lprosek(a)redhat.com> wrote: >>>> On Wed, Oct 19, 2016 at 1:29 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote: >>>>> On Mon, Oct 17, 2016 at 05:53:04PM +0200, Ladi Prosek wrote: >>>>>> Windows Server 2016 and Windows 10 RS1 come with a bug in its blue screen >>>>>> of death rendering logic which prevents it from generating crash dumps. >>>>>> >>>>>> The bug does not manifest if Windows sees a suitable 32 bpp video mode >>>>>> before a suitable 24 bpp video mode in the list of modes returned from >>>>>> vgabios. This commit moves all 32 bpp modes to the front of the list to >>>>>> make sure that this is always the case. >>>>>> >>>>>> Signed-off-by: Ladi Prosek <lprosek(a)redhat.com> >>>>>> --- >>>>>> vgasrc/bochsvga.c | 39 ++++++++++++++++++++------------------- >>>>>> 1 file changed, 20 insertions(+), 19 deletions(-) >>>>>> >>>>>> diff --git a/vgasrc/bochsvga.c b/vgasrc/bochsvga.c >>>>>> index ec5d101..c5d1511 100644 >>>>>> --- a/vgasrc/bochsvga.c >>>>>> +++ b/vgasrc/bochsvga.c >>>>>> @@ -28,6 +28,25 @@ static struct bochsvga_mode >>>>>> u16 mode; >>>>>> struct vgamode_s info; >>>>>> } bochsvga_modes[] VAR16 = { >>>>>> + /* 32 bpp BOCHS modes */ >>>>>> + { 0x140, { MM_DIRECT, 320, 200, 32, 8, 16, SEG_GRAPH } }, >>>>>> + { 0x141, { MM_DIRECT, 640, 400, 32, 8, 16, SEG_GRAPH } }, >>>>>> + { 0x142, { MM_DIRECT, 640, 480, 32, 8, 16, SEG_GRAPH } }, >>>>>> + { 0x143, { MM_DIRECT, 800, 600, 32, 8, 16, SEG_GRAPH } }, >>>>>> + { 0x144, { MM_DIRECT, 1024, 768, 32, 8, 16, SEG_GRAPH } }, >>>>>> + { 0x145, { MM_DIRECT, 1280, 1024, 32, 8, 16, SEG_GRAPH } }, >>>>>> + { 0x147, { MM_DIRECT, 1600, 1200, 32, 8, 16, SEG_GRAPH } }, >>>>>> + { 0x14c, { MM_DIRECT, 1152, 864, 32, 8, 16, SEG_GRAPH } }, >>>>>> + { 0x177, { MM_DIRECT, 1280, 768, 32, 8, 16, SEG_GRAPH } }, >>>>>> + { 0x17a, { MM_DIRECT, 1280, 800, 32, 8, 16, SEG_GRAPH } }, >>>>>> + { 0x17d, { MM_DIRECT, 1280, 960, 32, 8, 16, SEG_GRAPH } }, >>>>>> + { 0x180, { MM_DIRECT, 1440, 900, 32, 8, 16, SEG_GRAPH } }, >>>>>> + { 0x183, { MM_DIRECT, 1400, 1050, 32, 8, 16, SEG_GRAPH } }, >>>>>> + { 0x186, { MM_DIRECT, 1680, 1050, 32, 8, 16, SEG_GRAPH } }, >>>>>> + { 0x189, { MM_DIRECT, 1920, 1200, 32, 8, 16, SEG_GRAPH } }, >>>>>> + { 0x18c, { MM_DIRECT, 2560, 1600, 32, 8, 16, SEG_GRAPH } }, >>>>>> + { 0x18f, { MM_DIRECT, 1280, 720, 32, 8, 16, SEG_GRAPH } }, >>>>>> + { 0x192, { MM_DIRECT, 1920, 1080, 32, 8, 16, SEG_GRAPH } }, >>>>>> /* standard modes */ >>>>>> { 0x100, { MM_PACKED, 640, 400, 8, 8, 16, SEG_GRAPH } }, >>>>>> { 0x101, { MM_PACKED, 640, 480, 8, 8, 16, SEG_GRAPH } }, >>>>>> @@ -56,50 +75,32 @@ static struct bochsvga_mode >>>>>> { 0x11D, { MM_DIRECT, 1600, 1200, 15, 8, 16, SEG_GRAPH } }, >>>>>> { 0x11E, { MM_DIRECT, 1600, 1200, 16, 8, 16, SEG_GRAPH } }, >>>>>> { 0x11F, { MM_DIRECT, 1600, 1200, 24, 8, 16, SEG_GRAPH } }, >>>>>> - /* BOCHS modes */ >>>>>> - { 0x140, { MM_DIRECT, 320, 200, 32, 8, 16, SEG_GRAPH } }, >>>>>> - { 0x141, { MM_DIRECT, 640, 400, 32, 8, 16, SEG_GRAPH } }, >>>>>> - { 0x142, { MM_DIRECT, 640, 480, 32, 8, 16, SEG_GRAPH } }, >>>>>> - { 0x143, { MM_DIRECT, 800, 600, 32, 8, 16, SEG_GRAPH } }, >>>>>> - { 0x144, { MM_DIRECT, 1024, 768, 32, 8, 16, SEG_GRAPH } }, >>>>>> - { 0x145, { MM_DIRECT, 1280, 1024, 32, 8, 16, SEG_GRAPH } }, >>>>>> + /* 8, 15, 16, and 24 bpp BOCHS modes */ >>>>>> { 0x146, { MM_PACKED, 320, 200, 8, 8, 16, SEG_GRAPH } }, >>>>>> - { 0x147, { MM_DIRECT, 1600, 1200, 32, 8, 16, SEG_GRAPH } }, >>>>> >>>>> Thanks. Instead of moving all of the 32bit modes to the top of the >>>>> list, can the 32bit modes be kept next to the other modes with the >>>>> same resolution, just above the 24bpp mode? >>>> >>>> Yes, that would work too. As long as 32 bpp come before 24 bpp for the >>>> same resolution, it will be fine. >>>> >>>>> Also, all of the mode numbers above 0x11b are arbitrary, so it would >>>>> be preferable to renumber the mode numbers as lines are moved. >>>> >>>> Will do. >>>> >>>>> We were about to make a SeaBIOS release - does this need to go into >>>>> that release? >>>> >>>> It would be highly desired as the problematic Windows builds have >>>> already RTM'ed. >>>> >>>> I'll send a v2 with the changes as suggested above. >>> >>> Actually, I spoke too soon. The problematic 24 bpp mode that Windows >>> picks right now is 118 and that's within the standard range so I can't >>> move 144 above it and renumber. What would be considered safer, >>> keeping the same mode numbers or partially renumbering to keep them >>> monotonically increasing except for the standard range? >> >> I wouldn't renumber anything at 0x11B or below - those are defined in >> the vbe3 spec. Ordering and the numbering of all the other modes can >> be changed. Despite the comment in the source, modes 0x11C-0x11F do >> not appear to be standard modes. > > Got it. My point is that given how the standard modes are fixed, it's > not possible to renumber so all modes are in an increasing order. So I > wonder if renumbering is worth it at all. In fact, the issue would be > solved just by changing the order of the two 1024x768 modes mentioned > above: 118 and 144. > >> Thinking on this further, there's a good chance other systems (in >> addition to Windows) choose the first valid mode found. So, >> reordering the 32bit modes above the 24bit modes could cause changes >> in other systems as well. So, I think it may be too risky to push >> this into the pending SeaBIOS release. > > Understood. Would be ok to get it into the next release (assuming this > is how it gets some test exposure - apologies for not being familiar > with the SeaBIOS release process) or would you be opposed to the > change at all? > > Another hypothetical alternative would be to try to find an API > invocation pattern reasonably unique to Windows that would trigger the > new behavior, to minimize the risk. How about a new CONFIG_xxx knob? Thanks Laszlo

2 2

Re: [SeaBIOS] [PATCH] vgabios: Reorder video modes to work around a Windows bug
by Kevin O'Connor 19 Oct '16

19 Oct '16

On Wed, Oct 19, 2016 at 03:16:48PM +0200, Ladi Prosek wrote: > On Wed, Oct 19, 2016 at 2:23 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote: > > On Wed, Oct 19, 2016 at 11:32:41AM +0200, Ladi Prosek wrote: > >> Actually, I spoke too soon. The problematic 24 bpp mode that Windows > >> picks right now is 118 and that's within the standard range so I can't > >> move 144 above it and renumber. What would be considered safer, > >> keeping the same mode numbers or partially renumbering to keep them > >> monotonically increasing except for the standard range? > > > > I wouldn't renumber anything at 0x11B or below - those are defined in > > the vbe3 spec. Ordering and the numbering of all the other modes can > > be changed. Despite the comment in the source, modes 0x11C-0x11F do > > not appear to be standard modes. > > Got it. My point is that given how the standard modes are fixed, it's > not possible to renumber so all modes are in an increasing order. So I > wonder if renumbering is worth it at all. In fact, the issue would be > solved just by changing the order of the two 1024x768 modes mentioned > above: 118 and 144. I'm not sure what the best approach is. If it's really just that one mode, perhaps moving it above 118 and adding a comment is the best approach. If you're moving whole blocks around, I'd renumber. > > Thinking on this further, there's a good chance other systems (in > > addition to Windows) choose the first valid mode found. So, > > reordering the 32bit modes above the 24bit modes could cause changes > > in other systems as well. So, I think it may be too risky to push > > this into the pending SeaBIOS release. > > Understood. Would be ok to get it into the next release (assuming this > is how it gets some test exposure - apologies for not being familiar > with the SeaBIOS release process) or would you be opposed to the > change at all? I'm not opposed to the change - just wary of pushing it out into a release in under a week. > Another hypothetical alternative would be to try to find an API > invocation pattern reasonably unique to Windows that would trigger the > new behavior, to minimize the risk. That sounds complex. -Kevin

1 0

[PATCH] docs: fix various typos and inconsistency
by Piotr Król 19 Oct '16

19 Oct '16

Signed-off-by: Piotr Król <piotr.krol(a)3mdeb.com> --- docs/Debugging.md | 4 ++-- docs/Execution_and_code_flow.md | 10 +++++----- docs/Runtime_config.md | 2 +- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/Debugging.md b/docs/Debugging.md index 7ab5d02d8cad..13cee4dce592 100644 --- a/docs/Debugging.md +++ b/docs/Debugging.md @@ -60,7 +60,7 @@ mkfifo qemudebugpipe qemu -chardev pipe,path=qemudebugpipe,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios ... ``` -and then in another session: +And then in another session: `/path/to/seabios/scripts/readserial.py -nf qemudebugpipe` @@ -77,7 +77,7 @@ Debugging with gdb on QEMU ========================== One can use gdb with QEMU to debug system images. To do this, add '-s --S' to the qemu command line. For example: +-S' to the QEMU command line. For example: `qemu -bios out/bios.bin -fda myfdimage.img -s -S` diff --git a/docs/Execution_and_code_flow.md b/docs/Execution_and_code_flow.md index a54776eef140..4a7ba8d9e4ad 100644 --- a/docs/Execution_and_code_flow.md +++ b/docs/Execution_and_code_flow.md @@ -30,7 +30,7 @@ called in 32bit mode. This then calls post.c:handle_post(). On CSM, the build arranges for romlayout.S:entry_csm() to be called (in 16bit mode). This then calls csm.c:handle_csm() in 32bit mode. Unlike on the emulators and coreboot, the SeaBIOS CSM POST phase is -orchastrated with UEFI and there are several calls back and forth +orchestrated with UEFI and there are several calls back and forth between SeaBIOS and UEFI via handle_csm() throughout the POST process. @@ -58,7 +58,7 @@ transition to 32bit mode and call boot.c:handle_19() or boot.c:handle_18(). The boot phase is technically also part of the "runtime" phase of -SeaBIOS. It is typically invoked immiediately after the POST phase, +SeaBIOS. It is typically invoked immediately after the POST phase, but it can also be invoked by an operating system or be invoked multiple times in an attempt to find a valid boot media. Although the boot phase C code runs in 32bit mode it does not have write access to @@ -120,7 +120,7 @@ atomic memory accesses and complex locking is not required. The goal of these threads is to reduce overall boot time by parallelizing hardware delays. (For example, by allowing the wait for -an ATA harddrive to spinup and respond to commands to occur in +an ATA hard drive to spin-up and respond to commands to occur in parallel with the wait for a PS/2 keyboard to respond to a setup command.) These hardware setup threads are only available during the "setup" sub-phase of the [POST phase](#POST_phase). @@ -144,7 +144,7 @@ interrupts disabled. The first reason is that external software may override the default SeaBIOS handlers that are called on a hardware interrupt event. Indeed, it is common for DOS based applications to do this. These legacy third party interrupt handlers may have -undocumented expections (such as stack location and stack size) and +undocumented expectations (such as stack location and stack size) and may attempt to call back into the various SeaBIOS software services. Greater compatibility and more reproducible results can be achieved by only permitting hardware interrupts at specific points (via yield() @@ -171,7 +171,7 @@ memory"](Memory Model). It ensures SeaBIOS uses a minimal amount of a callers stack (typically no more than 16 bytes) for these legacy calls. (More recently defined BIOS interfaces such as those that support 16bit protected and 32bit protected mode calls standardize a -minimum stack size with adequete space, and SeaBIOS generally will not +minimum stack size with adequate space, and SeaBIOS generally will not use its extra stack in these cases.) The code to implement this stack "hopping" is in romlayout.S and in diff --git a/docs/Runtime_config.md b/docs/Runtime_config.md index 517129621e15..a2617481a6be 100644 --- a/docs/Runtime_config.md +++ b/docs/Runtime_config.md @@ -157,7 +157,7 @@ into bootorder. For example, the file: /pci@i0cf8/*@f/drive@1/disk@0 ``` -will instruct SeaBIOS to attempt to boot from the given USB drive +Will instruct SeaBIOS to attempt to boot from the given USB drive first and then attempt the given ATA harddrive second. SeaBIOS also supports a special "HALT" directive. If a line that -- 2.9.3

2 4

Re: [SeaBIOS] [PATCH] vgabios: Reorder video modes to work around a Windows bug
by Ladi Prosek 19 Oct '16

19 Oct '16

On Wed, Oct 19, 2016 at 10:06 AM, Ladi Prosek <lprosek(a)redhat.com> wrote: > On Wed, Oct 19, 2016 at 1:29 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote: >> On Mon, Oct 17, 2016 at 05:53:04PM +0200, Ladi Prosek wrote: >>> Windows Server 2016 and Windows 10 RS1 come with a bug in its blue screen >>> of death rendering logic which prevents it from generating crash dumps. >>> >>> The bug does not manifest if Windows sees a suitable 32 bpp video mode >>> before a suitable 24 bpp video mode in the list of modes returned from >>> vgabios. This commit moves all 32 bpp modes to the front of the list to >>> make sure that this is always the case. >>> >>> Signed-off-by: Ladi Prosek <lprosek(a)redhat.com> >>> --- >>> vgasrc/bochsvga.c | 39 ++++++++++++++++++++------------------- >>> 1 file changed, 20 insertions(+), 19 deletions(-) >>> >>> diff --git a/vgasrc/bochsvga.c b/vgasrc/bochsvga.c >>> index ec5d101..c5d1511 100644 >>> --- a/vgasrc/bochsvga.c >>> +++ b/vgasrc/bochsvga.c >>> @@ -28,6 +28,25 @@ static struct bochsvga_mode >>> u16 mode; >>> struct vgamode_s info; >>> } bochsvga_modes[] VAR16 = { >>> + /* 32 bpp BOCHS modes */ >>> + { 0x140, { MM_DIRECT, 320, 200, 32, 8, 16, SEG_GRAPH } }, >>> + { 0x141, { MM_DIRECT, 640, 400, 32, 8, 16, SEG_GRAPH } }, >>> + { 0x142, { MM_DIRECT, 640, 480, 32, 8, 16, SEG_GRAPH } }, >>> + { 0x143, { MM_DIRECT, 800, 600, 32, 8, 16, SEG_GRAPH } }, >>> + { 0x144, { MM_DIRECT, 1024, 768, 32, 8, 16, SEG_GRAPH } }, >>> + { 0x145, { MM_DIRECT, 1280, 1024, 32, 8, 16, SEG_GRAPH } }, >>> + { 0x147, { MM_DIRECT, 1600, 1200, 32, 8, 16, SEG_GRAPH } }, >>> + { 0x14c, { MM_DIRECT, 1152, 864, 32, 8, 16, SEG_GRAPH } }, >>> + { 0x177, { MM_DIRECT, 1280, 768, 32, 8, 16, SEG_GRAPH } }, >>> + { 0x17a, { MM_DIRECT, 1280, 800, 32, 8, 16, SEG_GRAPH } }, >>> + { 0x17d, { MM_DIRECT, 1280, 960, 32, 8, 16, SEG_GRAPH } }, >>> + { 0x180, { MM_DIRECT, 1440, 900, 32, 8, 16, SEG_GRAPH } }, >>> + { 0x183, { MM_DIRECT, 1400, 1050, 32, 8, 16, SEG_GRAPH } }, >>> + { 0x186, { MM_DIRECT, 1680, 1050, 32, 8, 16, SEG_GRAPH } }, >>> + { 0x189, { MM_DIRECT, 1920, 1200, 32, 8, 16, SEG_GRAPH } }, >>> + { 0x18c, { MM_DIRECT, 2560, 1600, 32, 8, 16, SEG_GRAPH } }, >>> + { 0x18f, { MM_DIRECT, 1280, 720, 32, 8, 16, SEG_GRAPH } }, >>> + { 0x192, { MM_DIRECT, 1920, 1080, 32, 8, 16, SEG_GRAPH } }, >>> /* standard modes */ >>> { 0x100, { MM_PACKED, 640, 400, 8, 8, 16, SEG_GRAPH } }, >>> { 0x101, { MM_PACKED, 640, 480, 8, 8, 16, SEG_GRAPH } }, >>> @@ -56,50 +75,32 @@ static struct bochsvga_mode >>> { 0x11D, { MM_DIRECT, 1600, 1200, 15, 8, 16, SEG_GRAPH } }, >>> { 0x11E, { MM_DIRECT, 1600, 1200, 16, 8, 16, SEG_GRAPH } }, >>> { 0x11F, { MM_DIRECT, 1600, 1200, 24, 8, 16, SEG_GRAPH } }, >>> - /* BOCHS modes */ >>> - { 0x140, { MM_DIRECT, 320, 200, 32, 8, 16, SEG_GRAPH } }, >>> - { 0x141, { MM_DIRECT, 640, 400, 32, 8, 16, SEG_GRAPH } }, >>> - { 0x142, { MM_DIRECT, 640, 480, 32, 8, 16, SEG_GRAPH } }, >>> - { 0x143, { MM_DIRECT, 800, 600, 32, 8, 16, SEG_GRAPH } }, >>> - { 0x144, { MM_DIRECT, 1024, 768, 32, 8, 16, SEG_GRAPH } }, >>> - { 0x145, { MM_DIRECT, 1280, 1024, 32, 8, 16, SEG_GRAPH } }, >>> + /* 8, 15, 16, and 24 bpp BOCHS modes */ >>> { 0x146, { MM_PACKED, 320, 200, 8, 8, 16, SEG_GRAPH } }, >>> - { 0x147, { MM_DIRECT, 1600, 1200, 32, 8, 16, SEG_GRAPH } }, >> >> Thanks. Instead of moving all of the 32bit modes to the top of the >> list, can the 32bit modes be kept next to the other modes with the >> same resolution, just above the 24bpp mode? > > Yes, that would work too. As long as 32 bpp come before 24 bpp for the > same resolution, it will be fine. > >> Also, all of the mode numbers above 0x11b are arbitrary, so it would >> be preferable to renumber the mode numbers as lines are moved. > > Will do. > >> We were about to make a SeaBIOS release - does this need to go into >> that release? > > It would be highly desired as the problematic Windows builds have > already RTM'ed. > > I'll send a v2 with the changes as suggested above. Actually, I spoke too soon. The problematic 24 bpp mode that Windows picks right now is 118 and that's within the standard range so I can't move 144 above it and renumber. What would be considered safer, keeping the same mode numbers or partially renumbering to keep them monotonically increasing except for the standard range? > Thanks! > Ladi

1 0

[PATCH] vgabios: Reorder video modes to work around a Windows bug
by Ladi Prosek 19 Oct '16

19 Oct '16

Windows Server 2016 and Windows 10 RS1 come with a bug in its blue screen of death rendering logic which prevents it from generating crash dumps. The bug does not manifest if Windows sees a suitable 32 bpp video mode before a suitable 24 bpp video mode in the list of modes returned from vgabios. This commit moves all 32 bpp modes to the front of the list to make sure that this is always the case. Signed-off-by: Ladi Prosek <lprosek(a)redhat.com> --- vgasrc/bochsvga.c | 39 ++++++++++++++++++++------------------- 1 file changed, 20 insertions(+), 19 deletions(-) diff --git a/vgasrc/bochsvga.c b/vgasrc/bochsvga.c index ec5d101..c5d1511 100644 --- a/vgasrc/bochsvga.c +++ b/vgasrc/bochsvga.c @@ -28,6 +28,25 @@ static struct bochsvga_mode u16 mode; struct vgamode_s info; } bochsvga_modes[] VAR16 = { + /* 32 bpp BOCHS modes */ + { 0x140, { MM_DIRECT, 320, 200, 32, 8, 16, SEG_GRAPH } }, + { 0x141, { MM_DIRECT, 640, 400, 32, 8, 16, SEG_GRAPH } }, + { 0x142, { MM_DIRECT, 640, 480, 32, 8, 16, SEG_GRAPH } }, + { 0x143, { MM_DIRECT, 800, 600, 32, 8, 16, SEG_GRAPH } }, + { 0x144, { MM_DIRECT, 1024, 768, 32, 8, 16, SEG_GRAPH } }, + { 0x145, { MM_DIRECT, 1280, 1024, 32, 8, 16, SEG_GRAPH } }, + { 0x147, { MM_DIRECT, 1600, 1200, 32, 8, 16, SEG_GRAPH } }, + { 0x14c, { MM_DIRECT, 1152, 864, 32, 8, 16, SEG_GRAPH } }, + { 0x177, { MM_DIRECT, 1280, 768, 32, 8, 16, SEG_GRAPH } }, + { 0x17a, { MM_DIRECT, 1280, 800, 32, 8, 16, SEG_GRAPH } }, + { 0x17d, { MM_DIRECT, 1280, 960, 32, 8, 16, SEG_GRAPH } }, + { 0x180, { MM_DIRECT, 1440, 900, 32, 8, 16, SEG_GRAPH } }, + { 0x183, { MM_DIRECT, 1400, 1050, 32, 8, 16, SEG_GRAPH } }, + { 0x186, { MM_DIRECT, 1680, 1050, 32, 8, 16, SEG_GRAPH } }, + { 0x189, { MM_DIRECT, 1920, 1200, 32, 8, 16, SEG_GRAPH } }, + { 0x18c, { MM_DIRECT, 2560, 1600, 32, 8, 16, SEG_GRAPH } }, + { 0x18f, { MM_DIRECT, 1280, 720, 32, 8, 16, SEG_GRAPH } }, + { 0x192, { MM_DIRECT, 1920, 1080, 32, 8, 16, SEG_GRAPH } }, /* standard modes */ { 0x100, { MM_PACKED, 640, 400, 8, 8, 16, SEG_GRAPH } }, { 0x101, { MM_PACKED, 640, 480, 8, 8, 16, SEG_GRAPH } }, @@ -56,50 +75,32 @@ static struct bochsvga_mode { 0x11D, { MM_DIRECT, 1600, 1200, 15, 8, 16, SEG_GRAPH } }, { 0x11E, { MM_DIRECT, 1600, 1200, 16, 8, 16, SEG_GRAPH } }, { 0x11F, { MM_DIRECT, 1600, 1200, 24, 8, 16, SEG_GRAPH } }, - /* BOCHS modes */ - { 0x140, { MM_DIRECT, 320, 200, 32, 8, 16, SEG_GRAPH } }, - { 0x141, { MM_DIRECT, 640, 400, 32, 8, 16, SEG_GRAPH } }, - { 0x142, { MM_DIRECT, 640, 480, 32, 8, 16, SEG_GRAPH } }, - { 0x143, { MM_DIRECT, 800, 600, 32, 8, 16, SEG_GRAPH } }, - { 0x144, { MM_DIRECT, 1024, 768, 32, 8, 16, SEG_GRAPH } }, - { 0x145, { MM_DIRECT, 1280, 1024, 32, 8, 16, SEG_GRAPH } }, + /* 8, 15, 16, and 24 bpp BOCHS modes */ { 0x146, { MM_PACKED, 320, 200, 8, 8, 16, SEG_GRAPH } }, - { 0x147, { MM_DIRECT, 1600, 1200, 32, 8, 16, SEG_GRAPH } }, { 0x148, { MM_PACKED, 1152, 864, 8, 8, 16, SEG_GRAPH } }, { 0x149, { MM_DIRECT, 1152, 864, 15, 8, 16, SEG_GRAPH } }, { 0x14a, { MM_DIRECT, 1152, 864, 16, 8, 16, SEG_GRAPH } }, { 0x14b, { MM_DIRECT, 1152, 864, 24, 8, 16, SEG_GRAPH } }, - { 0x14c, { MM_DIRECT, 1152, 864, 32, 8, 16, SEG_GRAPH } }, { 0x175, { MM_DIRECT, 1280, 768, 16, 8, 16, SEG_GRAPH } }, { 0x176, { MM_DIRECT, 1280, 768, 24, 8, 16, SEG_GRAPH } }, - { 0x177, { MM_DIRECT, 1280, 768, 32, 8, 16, SEG_GRAPH } }, { 0x178, { MM_DIRECT, 1280, 800, 16, 8, 16, SEG_GRAPH } }, { 0x179, { MM_DIRECT, 1280, 800, 24, 8, 16, SEG_GRAPH } }, - { 0x17a, { MM_DIRECT, 1280, 800, 32, 8, 16, SEG_GRAPH } }, { 0x17b, { MM_DIRECT, 1280, 960, 16, 8, 16, SEG_GRAPH } }, { 0x17c, { MM_DIRECT, 1280, 960, 24, 8, 16, SEG_GRAPH } }, - { 0x17d, { MM_DIRECT, 1280, 960, 32, 8, 16, SEG_GRAPH } }, { 0x17e, { MM_DIRECT, 1440, 900, 16, 8, 16, SEG_GRAPH } }, { 0x17f, { MM_DIRECT, 1440, 900, 24, 8, 16, SEG_GRAPH } }, - { 0x180, { MM_DIRECT, 1440, 900, 32, 8, 16, SEG_GRAPH } }, { 0x181, { MM_DIRECT, 1400, 1050, 16, 8, 16, SEG_GRAPH } }, { 0x182, { MM_DIRECT, 1400, 1050, 24, 8, 16, SEG_GRAPH } }, - { 0x183, { MM_DIRECT, 1400, 1050, 32, 8, 16, SEG_GRAPH } }, { 0x184, { MM_DIRECT, 1680, 1050, 16, 8, 16, SEG_GRAPH } }, { 0x185, { MM_DIRECT, 1680, 1050, 24, 8, 16, SEG_GRAPH } }, - { 0x186, { MM_DIRECT, 1680, 1050, 32, 8, 16, SEG_GRAPH } }, { 0x187, { MM_DIRECT, 1920, 1200, 16, 8, 16, SEG_GRAPH } }, { 0x188, { MM_DIRECT, 1920, 1200, 24, 8, 16, SEG_GRAPH } }, - { 0x189, { MM_DIRECT, 1920, 1200, 32, 8, 16, SEG_GRAPH } }, { 0x18a, { MM_DIRECT, 2560, 1600, 16, 8, 16, SEG_GRAPH } }, { 0x18b, { MM_DIRECT, 2560, 1600, 24, 8, 16, SEG_GRAPH } }, - { 0x18c, { MM_DIRECT, 2560, 1600, 32, 8, 16, SEG_GRAPH } }, { 0x18d, { MM_DIRECT, 1280, 720, 16, 8, 16, SEG_GRAPH } }, { 0x18e, { MM_DIRECT, 1280, 720, 24, 8, 16, SEG_GRAPH } }, - { 0x18f, { MM_DIRECT, 1280, 720, 32, 8, 16, SEG_GRAPH } }, { 0x190, { MM_DIRECT, 1920, 1080, 16, 8, 16, SEG_GRAPH } }, { 0x191, { MM_DIRECT, 1920, 1080, 24, 8, 16, SEG_GRAPH } }, - { 0x192, { MM_DIRECT, 1920, 1080, 32, 8, 16, SEG_GRAPH } }, }; static int dispi_found VAR16 = 0; -- 2.5.5

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS