Re: [SeaBIOS] Error while compiling Seabios for Arch Linux ARM

2016-02-17 Thread Kevin O'Connor 
On Wed, Feb 17, 2016 at 06:14:25PM +0200, Xavier de Rauville wrote:
> Greetings
> 
> I am currently trying to compile Seabios for Arch Linux ARM and I've
> encountered an error during the compilation that appears to be caused by a
> misconfiguration in the file downloaded from here:
> http://code.coreboot.org/p/seabios/downloads/get/seabios-1.9.0.tar.gz
> 
> I have attached a log containing the entire stdout and stderr stream output
> for Arch Linux's makepkg command but I think these might be the only lines
> of interest:
>   Compile checking out/src/misc.o
> cc -Iout/ -Isrc -Os -MD -g -Wall -Wno-strict-aliasing -Wold-style-definition
> -Wtype-limits -m32 -march=i386 -mregparm=3 -mpreferred-stack-boundary=2
> -minline-all-stringops -fomit-frame-pointer -freg-struct-return
> -ffreestanding -fno-delete-null-pointer-checks -ffunction-sections
> -fdata-sections -fno-common -fno-merge-constants  -fno-stack-protector
> -fstack-check=no -DMODE16=0 -DMODESEGMENT=0 -c src/misc.c -o out/src/misc.o
> cc: error: unrecognized argument in option '-march=i386'

SeaBIOS implements an x86 legacy BIOS.  As such, it requires an x86
compiler.  So, you need to either compile on an x86 machine or setup
and use an x86 cross compilation toolchain.

-Kevin

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] Error while compiling Seabios for Arch Linux ARM

2016-02-17 Thread Xavier de Rauville 

Greetings

I am currently trying to compile Seabios for Arch Linux ARM and I've 
encountered an error during the compilation that appears to be caused by 
a misconfiguration in the file downloaded from here: 
http://code.coreboot.org/p/seabios/downloads/get/seabios-1.9.0.tar.gz


I have attached a log containing the entire stdout and stderr stream 
output for Arch Linux's makepkg command but I think these might be the 
only lines of interest:

  Compile checking out/src/misc.o
cc -Iout/ -Isrc -Os -MD -g -Wall -Wno-strict-aliasing 
-Wold-style-definition -Wtype-limits -m32 -march=i386 -mregparm=3 
-mpreferred-stack-boundary=2 -minline-all-stringops -fomit-frame-pointer 
-freg-struct-return -ffreestanding -fno-delete-null-pointer-checks 
-ffunction-sections -fdata-sections -fno-common -fno-merge-constants  
-fno-stack-protector -fstack-check=no -DMODE16=0 -DMODESEGMENT=0 -c 
src/misc.c -o out/src/misc.o

cc: error: unrecognized argument in option '-march=i386'
cc: note: valid arguments to '-march=' are: armv2 armv2a armv3 armv3m 
armv4 armv4t armv5 armv5e armv5t armv5te armv6 armv6-m armv6j armv6k 
armv6s-m armv6t2 armv6z armv6zk armv7 armv7-a armv7-m armv7-r armv7e-m 
armv7ve armv8-a armv8-a+crc iwmmxt iwmmxt2 native

cc: error: unrecognized command line option '-m32'
cc: error: unrecognized command line option '-mregparm=3'
cc: error: unrecognized command line option '-mpreferred-stack-boundary=2'
cc: error: unrecognized command line option '-minline-all-stringops'
Makefile:133: recipe for target 'out/src/misc.o' failed

The files Arch Linux uses to compile Seabios can be found here if 
needed: 
https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/seabios
Can anyone help me get this error fixed? If a developer reads this and 
there is a bug in the code, would it be possible to fix it? Help will be 
greatly appreciated.


Kind regards
Xavier de Rauville
==> Making package: seabios 1.9.0-1 (Sun Feb  7 19:38:17 SAST 2016)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found seabios-1.9.0.tar.gz
  -> Found config.coreboot
  -> Found config.seabios-128k
  -> Found config.seabios-256k
  -> Found config.vga.isavga
  -> Found config.vga.stdvga
  -> Found config.csm
  -> Found config.vga.cirrus
  -> Found config.vga.qxl
  -> Found config.vga.vmware
==> Validating source files with sha1sums...
seabios-1.9.0.tar.gz ... Passed
config.coreboot ... Passed
config.seabios-128k ... Passed
config.seabios-256k ... Passed
config.vga.isavga ... Passed
config.vga.stdvga ... Passed
config.csm ... Passed
config.vga.cirrus ... Passed
config.vga.qxl ... Passed
config.vga.vmware ... Passed
==> Extracting sources...
  -> Extracting seabios-1.9.0.tar.gz with bsdtar
==> Starting prepare()...
==> Removing existing $pkgdir/ directory...
==> Starting build()...
mkdir -p out//scripts/kconfig/lxdialog
mkdir -p out//include/config
mkdir -p out/src out/src/hw out/src/fw out/vgasrc
make -C out/ -f /home/share/Seabios/src/seabios-1.9.0/scripts/kconfig/Makefile 
srctree=/home/share/Seabios/src/seabios-1.9.0 src=scripts/kconfig 
obj=scripts/kconfig Q= 
Kconfig=/home/share/Seabios/src/seabios-1.9.0/src/Kconfig  oldnoconfig
make[1]: Entering directory '/home/share/Seabios/src/seabios-1.9.0/out'
cc -Iscripts/kconfig -I/home/share/Seabios/src/seabios-1.9.0/scripts/kconfig   
-DCURSES_LOC="" -DLOCALE  -c -o scripts/kconfig/conf.o 
/home/share/Seabios/src/seabios-1.9.0/scripts/kconfig/conf.c
cat /home/share/Seabios/src/seabios-1.9.0/scripts/kconfig/zconf.tab.c_shipped > 
scripts/kconfig/zconf.tab.c
cat /home/share/Seabios/src/seabios-1.9.0/scripts/kconfig/zconf.lex.c_shipped > 
scripts/kconfig/zconf.lex.c
cat /home/share/Seabios/src/seabios-1.9.0/scripts/kconfig/zconf.hash.c_shipped 
> scripts/kconfig/zconf.hash.c
cc -Iscripts/kconfig -I/home/share/Seabios/src/seabios-1.9.0/scripts/kconfig  
-Iscripts/kconfig -DCURSES_LOC="" -DLOCALE  -c -o 
scripts/kconfig/zconf.tab.o scripts/kconfig/zconf.tab.c
cc  -o scripts/kconfig/conf scripts/kconfig/conf.o scripts/kconfig/zconf.tab.o  
scripts/kconfig/conf --olddefconfig 
/home/share/Seabios/src/seabios-1.9.0/src/Kconfig
#
# configuration written to /home/share/Seabios/src/seabios-1.9.0/.config
#
make[1]: Leaving directory '/home/share/Seabios/src/seabios-1.9.0/out'
mkdir -p out//scripts/kconfig/lxdialog
mkdir -p out//include/config
mkdir -p out/src out/src/hw out/src/fw out/vgasrc
make -C out/ -f /home/share/Seabios/src/seabios-1.9.0/scripts/kconfig/Makefile 
srctree=/home/share/Seabios/src/seabios-1.9.0 src=scripts/kconfig 
obj=scripts/kconfig Q= 
Kconfig=/home/share/Seabios/src/seabios-1.9.0/src/Kconfig  silentoldconfig
make[1]: Entering directory '/home/share/Seabios/src/seabios-1.9.0/out'
  Build Kconfig config file
mkdir -p include/config include/generated
scripts/kconfig/conf --silentoldconfig 
/home/share/Seabios/src/seabios-1.9.0/src/Kconfig
make[1]: Leaving directory

Re: [SeaBIOS] INT 1A - PCI Services supported?

2016-02-17 Thread Bob Moore 
Sorry for the bother people.  I now see that PCI Services is supported (and 
configured in my source tree).  I am now executing code in the 16 bit handler.

Thanks.

Bob

From: Bob Moore
Sent: Tuesday, February 16, 2016 4:50 PM
To: 'seabios@seabios.org'
Subject: INT 1A - PCI Services supported?

Hello again,

I have a need in my option ROM to interrogate devices identified by the BIOS 
PCI bus enumeration process.  It seems like the most straight forward way to do 
this would be to use INT 1A assuming seaBios supports PCI 2.0 or later, to 
search for all instances of devices which I'm interested in.  Can anyone 
confirm whether seaBios supports PCI 2.0 or later?  I see a hardcoded org at 
0xfe6e in romlayout.S that appears to be the entry to that handler.  I've tried 
using the INT instruction as well as calling directly to 0xf000fe6e.  Direct 
calls result in KVM crash as below.  I suspect this is due to not using the 
proper 16/32 bit call interface.  Using INT 1A I don't appear to be going 
through this code at all.

Thanks.

Bob

Running option rom at ca80:0003
KVM internal error. Suberror: 1
emulation failure
EAX=b102 EBX= ECX=8547 EDX=11f8
ESI= EDI=58b0 EBP= ESP=6e4c
EIP=f000fe6e EFL=00010202 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =f000 000f  00809300
CS =ca80 000ca800  00809b00
SS =   00809300
DS =   00809300
FS =   00809300
GS =   00809300
LDT=   8200
TR =   8b00
GDT= 000f59c0 0037
IDT=  03ff
CR0=0010 CR2= CR3= CR4=
DR0= DR1= DR2= 
DR3=
DR6=0ff0 DR7=0400
EFER=
Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
qemu: terminating on signal 2

Robert (Bob) L Moore
Firmware Engineer
CIBU Platform
o: 719-799-4642 (ext. 244642)
robert.mo...@hgst.com

[cid:image001.png@01D13689.346E0520]
1975 Research Pkwy, Suite 135
Colorado Springs, CO 80920
www.wdc.com

Western Digital Corporation (and its subsidiaries) E-mail Confidentiality 
Notice & Disclaimer:

This e-mail and any files transmitted with it may contain confidential or 
legally privileged information of WDC and/or its affiliates, and are intended 
solely for the use of the individual or entity to which they are addressed. If 
you are not the intended recipient, any disclosure, copying, distribution or 
any action taken or omitted to be taken in reliance on it, is prohibited. If 
you have received this e-mail in error, please notify the sender immediately 
and delete the e-mail in its entirety from your system.
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [RFC PATCH v4] fw/pci: Add support for mapping Intel IGD via QEMU

2016-02-17 Thread Alex Williamson 
On Wed, 17 Feb 2016 11:09:49 +
"Tian, Kevin"  wrote:

> > From: Alex Williamson
> > Sent: Wednesday, February 17, 2016 5:39 AM
> > 
> > QEMU provides two fw_cfg files to support IGD.  The first holds the
> > OpRegion data which holds the Video BIOS Table (VBT).  This needs to
> > be copied into reserved memory and the address stored in the ASL
> > Storage register of the device at 0xFC offset in PCI config space.
> > The OpRegion is generally 8KB.  This file is named "etc/igd-opregion".
> > 
> > The second file tells us the required size of the stolen memory space
> > for the device.  This is a dummy file, it has no backing so we only
> > allocate the space without copying anything into it.  This space
> > requires 1MB alignment and is generally either 1MB or 2MB, depending
> > on the hardware config.  If the user has opted in QEMU to expose
> > additional stolen memory beyond the GTT (GGMS), the GMS may add an
> > additional 32MB to 512MB.  The base address of the reserved memory
> > allocated for this is written back to the Base Data of Stolen Memory
> > register (BDSM) at PCI config offset 0x5C on the device.  This file is
> > named "etc/igd-bdsm".  
> 
> What would happen if guest tries to access this range while there is
> no actual memory behind? Isn't it more clear to hide stolen memory
> at all instead of reporting a dummy range?

It's a fw_cfg file, it's not exposed to the guest, the purpose is to
convey the size of stolen memory, which the BIOS then allocates as
reserved memory and writes back to the BDSM register.  It would be more
clean to ignore stolen memory, but in cases where we need the vBIOS,
such as laptops, where my LCD panel won't turn on without it, we don't
have that luxury.  The vBIOS programs the device to use stolen memory,
at least 1MB, I assume for GTT purposes, and makes use of that for VESA
modes.  So, we need the vBIOS to support laptop panels, the vBIOS needs
stolen memory for GTT space, therefore we need to provide some stolen
memory.

This support is enabled in QEMU by using a vBIOS, I assume vGPUs won't
expose a ROM BAR and therefore won't enable this.  Additionally for
BDW/SKL+ (gen8+) GPUs, if the user specifies rombar=0 then all of this
is disabled, including the hostbridge and ISA bridge manipulation in
order to support UPT mode.  Thanks,

Alex

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios