SeaBIOS April 2015

seabios@seabios.org

19 participants
42 discussions

Re: [SeaBIOS] [HELP] The program cause screen mess

by Kevin O'Connor

On Sat, Apr 18, 2015 at 10:12:04AM +0800, eJim Lee wrote: > Hi all, > I have had two trouble. > There is a program named wbc and run it on WinXP that was on qemu+kvm+qxl+spice. > https://drive.google.com/file/d/0BwZHW2TTkEdRNm1rVUZwakxrQTQ/view?usp=shari… Do you still have trouble when not using qxl/spice? I tested your program using regular "-vga std" and I don't see any corruption. -Kevin

5 years, 3 months

[HELP] The program cause screen mess

by eJim Lee

Hi all, I have had two trouble. There is a program named wbc and run it on WinXP that was on qemu+kvm+qxl+spice. https://drive.google.com/file/d/0BwZHW2TTkEdRNm1rVUZwakxrQTQ/view?usp=shari… ###################################################### The first trouble: The program cause screen mess, looked like: https://drive.google.com/file/d/0BwZHW2TTkEdRajE5cUsyLWY0dU0/view?usp=shari… I have debugged vgabios and found gfx_write_char have never arrived. But looked nice after I commented this: ------------------------------------------------------------------------------------------- // Write a character to the screen. void vgafb_write_char(struct cursorpos cp, struct carattr ca) { struct vgamode_s *vmode_g = get_current_mode(); if (!vmode_g) return; vgafb_set_swcursor(0); if (GET_GLOBAL(vmode_g->memmodel) != MM_TEXT) { //gfx_write_char(vmode_g, cp, ca); return; } void *dest_far = text_address(cp); if (ca.use_attr) { u16 dummy = (ca.attr << 8) | ca.car; SET_FARVAR(GET_GLOBAL(vmode_g->sstart), *(u16*)dest_far, dummy); } else { SET_FARVAR(GET_GLOBAL(vmode_g->sstart), *(u8*)dest_far, ca.car); } } ------------------------------------------------------------------------------------------- looked like: https://drive.google.com/file/d/0BwZHW2TTkEdRMDhiNUY2emJFQm8/view?usp=shari… The following commit also effect screen: f864b6023ed7b5d6fe8355e7ef2c6f78cd23ecad vgabios: Rewrite vgafb.c graphics operations to set of 4 standard operators. And before patched it, looked like: https://drive.google.com/file/d/0BwZHW2TTkEdRQXZnWFBLaklwZTQ/view?usp=shari… ###################################################### The Second trouble: Screen mess after I move mouse whenever I changed or commented anything, looked like: https://drive.google.com/file/d/0BwZHW2TTkEdRc3BCdXFZa013UEU/view?usp=shari… ###################################################### In fact, I have tried more: On XP ---------------------------------- spice qxl ERROR gtk qxl ERROR spice cirrus ERROR spice VGA ERROR ---------------------------------- On spice: ---------------------------------- xp qxl ERROR win7 qxl ERROR dos qxl NICE * xp cirrus ERROR xp VGA ERROR ---------------------------------- *: work perfectly. On XP: ------------------------------------------------------------ lgpl_vgabios qxl ERROR lgpl_vgabios cirrus ERROR seavgabios qxl ERROR seavgabios cirrus ERROR vmware_vgabios vmware_vga WORKED * ------------------------------------------------------------ *: vmware_vgabios is from vmware workstation. That worked but only support bpp 4 on desktop. ###################################################### I also tried LGPL VGABios and looked like before patch that commit. I have found the program didn't use vgabios api, but vgabios effect the screen. ###################################################### This is my qemu command: qemu-system-x86_64 \ -machine pc-i440fx-2.1,accel=kvm,usb=off \ -m 1024 \ -realtime mlock=off \ -smp 1,sockets=1,cores=1,threads=1 \ -no-user-config \ -nodefaults \ -rtc base=localtime \ -no-shutdown \ -global PIIX4_PM.disable_s3=1 \ -global PIIX4_PM.disable_s4=0 \ -boot strict=on \ -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ -drive file=/root/ram/xp.append,if=none,id=drive-ide0-0-0,format=qcow2,cache=writeback,discard=unmap \ -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=2 \ -chardev pty,id=charserial0 \ -device isa-serial,chardev=charserial0,id=serial0 \ -chardev pty,id=charserial1 \ -device isa-serial,chardev=charserial1,id=serial1 \ -chardev spicevmc,id=charchannel0,name=vdagent \ -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 \ -device usb-tablet,id=input0 \ -spice port=5900,addr=0.0.0.0,disable-ticketing,seamless-migration=on \ -device qxl-vga,id=video0,bus=pci.0,addr=0x2,romfile=/root/seabios/out/vgabios.bin \ -device AC97,id=sound0,bus=pci.0,addr=0x4 \ -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ -cpu 'SandyBridge,hv-relaxed=on' \ -netdev user,id=hostnet0 \ -device virtio-net-pci,netdev=hostnet0,id=net1,bus=pci.0,addr=0x7 \ -chardev stdio,id=debugcon \ -device isa-serial,iobase=0x0402,chardev=debugcon \ Could anyone provide me some idea? Thanks. eJim Lee

5 years, 3 months

Re: [SeaBIOS] 回复：Re: about ZoneHigh occupying ram from last address of below 4G ram

by Kevin O'Connor

On Thu, Apr 16, 2015 at 10:08:48PM +0800, penghao122(a)sina.com wrote: > I configure ram to 4GB,then the win7-64bit vm can boot successfully > using unmodified seabios. And I find that the vm can boot up after > about 2 hours when configuring ram to 8G using unmodfied seabios. What is your qemu/kvm command line? It works fine for me (with a win7 beta I have locally). I do see a brief pause around the point where you show a 2 hour delay, but the delay for me is only a few seconds. This is the command I used: ../qemu/qemu-2.2.0/x86_64-softmmu/qemu-system-x86_64 -k en-us -snapshot -L test -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios -m 8192 -hda win7beta.img -enable-kvm -vga cirrus -smp 2 -usb I think your issue should be reported on the QEMU/KVM mailing lists. It's common to put reserved memory at the end of ram - for example, run "dmesg | grep e820" on a real machine and see what it reports. So, this doesn't look like a seabios issue to me. -Kevin

5 years, 3 months

Re: [SeaBIOS] SeaBIOS not fully working when compiled on FreeBSD

by Roger Pau Monné

Hello, El 16/04/15 a les 15.29, Idwer Vollering ha escrit: > What does 'readelf -a out/bios.bin.elf' tell you, for each build where > you either override, or aren't overriding, CC with coreboot's > i386-elf-gcc or pkg's gcc48 and/or LD from FreeBSD's base or pkg? > > payloads/external/SeaBIOS/seabios $ gmake CC=gcc48 > LD=/usr/local/bin/ld &>/dev/null ; readelf -h out/bios.bin.elf | egrep > 'OS/ABI' > OS/ABI: UNIX - FreeBSD > > payloads/external/SeaBIOS/seabios $ > PATH=/home/idwer/coreboot/git/coreboot/util/crossgcc/xgcc/bin:$PATH > gmake CROSS_PREFIX=i386-elf- &>/dev/null ; readelf -h out/bios.bin.elf > | egrep 'OS/ABI' > OS/ABI: UNIX - System V I don't seem to have an out/bios.bin.elf after compilation, I only have: out/bios.bin out/bios.bin.prep out/bios.bin.raw Roger.

5 years, 3 months

Re: [SeaBIOS] SeaBIOS not fully working when compiled on FreeBSD

by Roger Pau Monné

El 15/04/15 a les 20.27, Idwer Vollering ha escrit: > 2015-04-15 19:31 GMT+02:00 Roger Pau Monné <roger.pau(a)citrix.com>: >> Hello, >> >> I've compiled SeaBIOS on FreeBSD with gcc48 > > _or_ build and use coreboot's crossgcc toolchain: > PATH=/path/to/coreboot_git_dir/util/crossgcc/xgcc/bin:$PATH gmake > CROSS_PREFIX=i386-elf- I've tried compiling SeaBIOS with gcc and binutils from ports the following way: # pkg install binutils gcc48 # PATH=/usr/local/bin/:$PATH gmake V=1 CC=gcc48 And the result is the same, the binary compiles fine but fails to work as expected. On the other hand, when using the crossgcc toolchain from coreboot the resulting binary seems to be working fine. I've looked at the gcc48 and binutils ports, and they don't seem to contain any patches that would affect SeaBIOS, but I'm not sure: https://svnweb.freebsd.org/ports/head/devel/binutils/files/ https://svnweb.freebsd.org/ports/head/lang/gcc48/files/ Roger.

5 years, 3 months

转发：回复：Re: about ZoneHigh occupying ram from last address of below 4G ram

by penghao122＠sina.com

----- 原始邮件 ----- 发件人：<penghao122(a)sina.com> 收件人："Kevin O'Connor" <kevin(a)koconnor.net> 主题：回复：Re: [SeaBIOS] about ZoneHigh occupying ram from last address of below 4G ram 日期：2015年04月15日 21点15分 ----- 原始邮件 ----- 发件人：Kevin O'Connor <kevin(a)koconnor.net> 收件人：penghao122(a)sina.com 抄送人：seabios <seabios(a)seabios.org> 主题：Re: [SeaBIOS] about ZoneHigh occupying ram from last address of below 4G ram 日期：2015年04月15日 00点45分 On Tue, Apr 14, 2015 at 11:57:08PM +0800, penghao122(a)sina.com wrote: > I'm using seabios 1.7.5-0 for kvm ,and I find some problem when > using windows 7 64bit bandvirtual machine.If I configure the windows > 7 64bit vm memory to 8GB ,the vm can't boot up very often(some > win7-64bit version easy to trigger) .I use trace-cmd tool to trace > it ,the vm just scan from last ram of below 4G(0xc000_0000) to 4G > address byte by byte.This is very time-consuming.From E820 table,the > address range contain nothing(it is an address hole). > > I query clue from seabios because I can't find any problems in kvm > or qemu. seabios keep a range of ram from last address below 4G as > zonehigh ram .I guess the windows os see a not aligned ram address > space and scan from 0xc000_0000. so I try to change the ZoneHigh to > low address space (I choose 128MB,grub use from 1MB address > space).after I changed,I can boot win7-64bit vm normally. > > So I want to know whether changing ZoneHigh to 128MB can be a > general modification. I haven't seen any other reports of issues like this with Win7. I suspect something else is going on. Please provide the full debug log (as described at: http://seabios.org/Debugging ) with an unmodified seabios from both a succesful boot event and a failed boot event. -Kevin I just can' boot succesfully if I use unmodified seabios (vm using 8 GB memory).I will try again. The attachment is the output of seabios when booting failed.

5 years, 3 months

about ZoneHigh occupying ram from last address of below 4G ram

by penghao122＠sina.com

I'm using seabios 1.7.5-0 for kvm ,and I find some problem when using windows 7 64bit bandvirtual machine.If I configure the windows 7 64bit vm memory to 8GB ,the vm can't boot up very often(some win7-64bit version easy to trigger) .I use trace-cmd tool to trace it ,the vm just scan from last ram of below 4G(0xc000_0000) to 4G address byte by byte.This is very time-consuming.From E820 table,the address range contain nothing(it is an address hole). I query clue from seabios because I can't find any problems in kvm or qemu. seabios keep a range of ram from last address below 4G as zonehigh ram .I guess the windows os see a not aligned ram address space and scan from 0xc000_0000. so I try to change the ZoneHigh to low address space (I choose 128MB,grub use from 1MB address space).after I changed,I can boot win7-64bit vm normally. So I want to know whether changing ZoneHigh to 128MB can be a general modification.

5 years, 3 months

[PATCHv3 0/2] Emulate "leal" instruction to workaround x86emu bugs

by Kevin O'Connor

With a few additional checks it's possible to emulate all the leal cases without requiring a function call. Although this makes the vgafixup.py code a little more complex it eliminates the need for the "emulate_leal" function and it produces better code. In my tests, almost all "leal" instructions are replaced with 4 (or fewer) instructions. -Kevin Kevin O'Connor (2): vgabios: Add config option for assembler fixups vgabios: Emulate "leal" instruction Makefile | 21 +++++++++--------- scripts/vgafixup.py | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++--- vgasrc/Kconfig | 10 +++++++++ vgasrc/vgaentry.S | 28 +++++------------------ 4 files changed, 87 insertions(+), 36 deletions(-) -- 1.9.3

5 years, 3 months

[PATCH 0/3] Emulate "leal" instruction to workaround x86emu bugs

by Kevin O'Connor

This series extends the existing "vgafixup.py" assembler patching mechanism to also patch out the "leal" instruction that old versions of x86emu don't support. With this series in place, fc11 and fc12 can now boot into graphics when using qemu with "std" vga. Because the assembler munging is getting a bit complicated, the first patch adds a compile time option to disable all of it. This allows one to build the vgabios without any of the workarounds. The out-of-line emulate_leal function does have a bit of overhead - one x86 instruction is replaced with over 20 instructions. The last patch in the series optimizes the common case so that most leal instructions are replaced with only 4-6 instructions. Also at: https://github.com/KevinOConnor/seabios/tree/testing -Kevin Kevin O'Connor (3): vgabios: Add config option for assembler fixups vgabios: Emulate "leal" instruction vgabios: Optimize leal instruction fixup Makefile | 21 +++++++++--------- scripts/vgafixup.py | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++--- vgasrc/Kconfig | 10 +++++++++ vgasrc/vgaentry.S | 49 +++++++++++++++++++++++------------------- 4 files changed, 107 insertions(+), 35 deletions(-) -- 1.9.3

5 years, 3 months

Re: [SeaBIOS] FreeBSD VESA console not working with SeaBIOS

by Kevin O'Connor

On Thu, Apr 09, 2015 at 11:32:25PM +0200, Jon Doe wrote: > On Thu, Apr 9, 2015 at 6:54 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote: > > I gave it a shot anyway - seabios patch is below. [...] > > I can report that this patch also works for FreeBSD 8.2's VESA > console. There seems to be some unrelated problem when running > 1.8-stable so I applied it to rel-1.7.5.2 I'm not surprised seabios master would still have a problem (due to recently reported issue with smsww), but I am surprised 1.8-stable would have a problem. Can you confirm it was 1.8-stable that was still broken with the patch? -Kevin

5 years, 3 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS April 2015