SeaBIOS April 2012

seabios@seabios.org

27 participants
63 discussions

Splash Screen fix (RGB bits per channel)

by Steve Goodrich

I was trying to get a JPG splash screen working and found a problem displaying the image correctly. I'm going to bypass the arguments around including a splash screen inside a product that completes before the monitor can even sync; this is simply about code. Anyway, the code as written was finding the first video mode of the correct width/height and using that. Unfortunately, the mode was a 5-5-5 while the JPG was being decoded as 5-6-5 (bits per RGB channel). The patch below add a check for the proper bits-per-channel value before accepting/using the mode. I'm not a JPG expert, so I don't know if this will work for all situations but I thought I'd submit it for review. -- Steve G. diff --git a/src/bootsplash.c b/src/bootsplash.c index 76b72c1..69ba018 100644 --- a/src/bootsplash.c +++ b/src/bootsplash.c @@ -53,7 +53,8 @@ static int find_videomode(struct vbe_info *vesa_info, struct vbe_mode_info *mode_info , int width, int height, int bpp_req) { - dprintf(3, "Finding vesa mode with dimensions %d/%d\n", width, height); + dprintf(3, "Finding vesa mode with dimensions %d x %d (%d bpp)\n", + width, height, bpp_req); u16 *videomodes = SEGOFF_TO_FLATPTR(vesa_info->video_mode); for (;; videomodes++) { u16 videomode = *videomodes; @@ -84,6 +85,12 @@ find_videomode(struct vbe_info *vesa_info, struct vbe_mode_info *mode_info if (depth != bpp_req) continue; } + // if this is 16 bits per pixel but R:G:B is not 5:6:5 format, continue + if ((depth == 16) && + ((mode_info->red_size != 5) || + (mode_info->green_size != 6) || + (mode_info->blue_size != 5))) + continue; return videomode; } }

9 years, 5 months

Re: [SeaBIOS] Version bump?

by Kevin O'Connor

On Sat, Apr 07, 2012 at 10:09:28PM +0200, Fred . wrote: > http://www.seabios.org/Releases > > Why did the version jump from 0.6.2 to 1.6.3 ? I increased the major number as I felt the project was no longer in a "beta" stage. -Kevin

9 years, 5 months

Re: [SeaBIOS] Version bump?

by Peter Stuge

Fred . wrote: > Why did the version jump from 0.6.2 to 1.6.3 ? Who cares - it's just a number. //Peter

9 years, 5 months

Version bump?

by Fred .

http://www.seabios.org/Releases Why did the version jump from 0.6.2 to 1.6.3 ?

9 years, 5 months

Re: [SeaBIOS] Wrong address returned by container _of macro

by Kevin O'Connor

On Wed, Apr 04, 2012 at 04:04:54PM +0900, Daniel Castro wrote: > Hello All, > > I have a little problem, when I try to get my drive on boot (16bit) I > am getting the wrong address: > > This code: > struct xendrive_s * xendrive = > GLOBALFLAT2GLOBAL(container_of(GET_GLOBAL(op->drive_g), struct > xendrive_s, drive)); op is on the stack, so one must not use GET_GLOBAL on it. Also, drive_g is already a "global", so GLOBALFLAT2GLOBAL must not be called on it. So, this should read: struct xendrive_s * xendrive = container_of(op->drive_g, struct xendrive_s, drive)) If one looks at the other disk drivers, they'll see something similar - for example ahci_cmd_data() has: struct ahci_port_s *port = container_of( op->drive_g, struct ahci_port_s, drive); -Kevin

9 years, 5 months

Re: [SeaBIOS] Wrong address returned by container _of macro

by Daniel Castro

On Wed, Apr 4, 2012 at 4:04 PM, Daniel Castro <evil.dani(a)gmail.com> wrote: > Hello All, > > I have a little problem, when I try to get my drive on boot (16bit) I > am getting the wrong address: > > This code: > struct xendrive_s * xendrive = > GLOBALFLAT2GLOBAL(container_of(GET_GLOBAL(op->drive_g), struct > xendrive_s, drive)); > dprintf(1,"Xendrive at:%p\n",xendrive); > Returns this: > Xendrive at:0xfff10000 > > But it should be this instead: > dprintf(1,"TEST drive 0 %p \n",i,GET_GLOBAL(xendrives[0])); > returns this: > TEST drive 0 0x000fd620 > > This last address is the address returned when done this: > struct xendrive_s *xd = malloc_fseg(sizeof(struct xendrive_s*)); > SET_FLATPTR(xendrives[count_drives],xd); > The xd pointer is later used for: > boot_add_hd(&xd->drive,desc,drives); > > Any tip to solve this will be greatly appreciated. I found a way around it, I create a global array with the drives as I add them to the boot, when the read operation is called, I compare the op->drive address to the ones I have registered, that way I can recover the struct that contains the drive and my custom struct for the drive. > > Thanks you all, > > Daniel > > > > > > -- > +-=====---------------------------+ > | +---------------------------------+ | This space intentionally blank > for notetaking. > | | | Daniel Castro, | > | | | Consultant/Programmer.| > | | | U Andes | > +-------------------------------------+ -- +-=====---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | | | Daniel Castro, | | | | Consultant/Programmer.| | | | U Andes | +-------------------------------------+

9 years, 5 months

[PATCH] Replace level gpe event with edge gpe event for hot-plug handlers

by Igor Mammedov

in current code, pci hot-plug gpe event handler is defined as a level one "_L01" 1. hw adds device, sets GPE.1 bit and sends SCI 2. OSPM gets SCI, reads GPE00.sts and masks GPE.1 bit in GPE00.en 3. OSPM executes _L01 4. hw adds second device and sets GPE.1 bit but SCI is not asserted since GPE00.en masks event 5. OSPM resets GPE.1 bit in GPE00.sts and umasks it in GPE00.en as result event for step 4 is lost because step 5 clears it and OS will not see added second device. ACPI 50 spec: 5.6.4 General-Purpose Event Handling defines GPE event handling as following: 1. Disables the interrupt source (GPEx_BLK EN bit). 2. If an edge event, clears the status bit. 3. Performs one of the following: * Dispatches to an ACPI-aware device driver. * Queues the matching control method for execution. * Manages a wake event using device _PRW objects. 4. If a level event, clears the status bit. 5. Enables the interrupt source. Switching from level to edge event handler reduces chances to hit race window. Same applies to cpu-hotplug, so switch it to edge handler as well. Tested with RHEL6, 3.3.+ kernel, winxp, and w2008r2, and I wasn't able to trigger race after using edge event handler. Signed-off-by: Igor Mammedov <imammedo(a)redhat.com> --- src/acpi-dsdt.dsl | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl index 4e04c48..4bdc268 100644 --- a/src/acpi-dsdt.dsl +++ b/src/acpi-dsdt.dsl @@ -723,11 +723,11 @@ DefinitionBlock ( Method(_L00) { Return(0x01) } - Method(_L01) { + Method(_E01) { // PCI hotplug event Return(\_SB.PCI0.PCNF()) } - Method(_L02) { + Method(_E02) { // CPU hotplug event Return(\_SB.PRSC()) } -- 1.7.7.6

9 years, 5 months

Wrong address returned by container _of macro

by Daniel Castro

Hello All, I have a little problem, when I try to get my drive on boot (16bit) I am getting the wrong address: This code: struct xendrive_s * xendrive = GLOBALFLAT2GLOBAL(container_of(GET_GLOBAL(op->drive_g), struct xendrive_s, drive)); dprintf(1,"Xendrive at:%p\n",xendrive); Returns this: Xendrive at:0xfff10000 But it should be this instead: dprintf(1,"TEST drive 0 %p \n",i,GET_GLOBAL(xendrives[0])); returns this: TEST drive 0 0x000fd620 This last address is the address returned when done this: struct xendrive_s *xd = malloc_fseg(sizeof(struct xendrive_s*)); SET_FLATPTR(xendrives[count_drives],xd); The xd pointer is later used for: boot_add_hd(&xd->drive,desc,drives); Any tip to solve this will be greatly appreciated. Thanks you all, Daniel -- +-=====---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | | | Daniel Castro, | | | | Consultant/Programmer.| | | | U Andes | +-------------------------------------+

9 years, 5 months

Re: [SeaBIOS] [PATCH v2] x86emu: Correctly handle 0x66 prefix for some instructions

by Michael Tokarev

What is the outcome of this patch? I mean, does it actually fix something visible, instead of a potential problem? [] >>> Anyone interested in this ? Is there a maintainer for x86emu ? The >>> MAINTAINERS file in xorg-docs doesn't mention anything about it. >> >> CCed: Adam Jackson >> >> Adam, you seem to be the maintainer of the xorg vesa driver. I think >> this patch is closely related. Would you mind taking a look at it ? I asked another question related to xorg vesa driver, also related to qemu, about it being unable to find available resolutions when run under qemu -- this: http://lists.x.org/archives/xorg-devel/2012-March/030037.html Is this 0x66 issue related to my question somehow? :) Thanks, /mjt

9 years, 5 months

Re: [SeaBIOS] [PATCH v2] x86emu: Correctly handle 0x66 prefix for some instructions

by Julian Pidancet

On Thu, Mar 15, 2012 at 10:45 PM, Julian Pidancet <julian.pidancet(a)gmail.com> wrote: > On Thu, Mar 15, 2012 at 10:39 PM, Julian Pidancet > <julian.pidancet(a)gmail.com> wrote: >> On Fri, Mar 9, 2012 at 2:08 AM, Guillem Jover <guillem(a)hadrons.org> wrote: >>> On Fri, 2012-03-09 at 00:02:55 +0000, Julian Pidancet wrote: >>>> 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> >>> >>> Looks good to me: >>> >>> Reviewed-by: Guillem Jover <guillem(a)hadrons.org> >>> >>> thanks, >>> guillem >> >> Anyone interested in this ? Is there a maintainer for x86emu ? The >> MAINTAINERS file in xorg-docs doesn't mention anything about it. >> > > CCed: Adam Jackson > > Adam, you seem to be the maintainer of the xorg vesa driver. I think > this patch is closely related. Would you mind taking a look at it ? > > Thanks, > Ping ? -- Julian

9 years, 5 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS April 2012