SeaBIOS

seabios@seabios.org

4 participants
3800 discussions

Boot ordering problem with qemu-kvm / seabios / gPXE
by Romain Vrignaud 29 Sep '11

29 Sep '11

Hello everybody. I'm actualy experiencing some problem for ordering my VM boot with qemu-kvm / Seabios and gPXE. I use libvirt's per-device boot option which launch my VM with this options : You can find libvirt's xml there : http://pastebin.com/bqizkLiZ -- /usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 2048 -smp 1,maxcpus=3,sockets=3,cores=1,threads=1 -name vm-name -uuid 32b5bf0d-fe46-2edb-b0d9-c134ba8a7636 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/vm-name.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -drive file=/var/lib/libvirt/images/ploop2.img,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=/var/lib/libvirt/images/vm-name.img,if=none,id=drive-virtio-disk1,format=raw -device virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk1,id=virtio-disk1 -netdev tap,fd=23,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:28:ca:e5,bus=pci.0,addr=0x3,bootindex=2 -netdev tap,fd=24,id=hostnet1 -device rtl8139,netdev=hostnet1,id=net1,mac=52:54:00:28:ca:e6,bus=pci.0,addr=0x4,bootindex=1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -vnc 127.0.0.1:1 -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -- We see the right bootindex option as I want to boot on gPXE from my second NIC (mac=52:54:00:28:ca:e6). The problem is that during my VM boot process, seabios initialise gPXE for my 2 NIC. But then gPXE try to boot (DHCP request) on the first NIC rather than on the second one. It always try to boot first on the first PCI device (00:03.0 instead of 00:04.0). I don't really know if the problem comes from gPXE or Seabios but I have exactly the same problem when I try with Ubuntu's etherboot rom. I got this problem with Ubuntu latest qemu-kvm (0.14.1+noroms-0ubuntu3.11.04.1) / seabios (0.6.2-0ubuntu1) and etherboot (5.4.4-7ubuntu2) and Fedora qemu-kvm (qemu-kvm-0.15.0-4.fc15.x86_64) / Seabios (seabios-bin-0.6.2-2.fc15.noarch) and gPXE (gpxe-roms-qemu-1.0.1-4.fc15.noarch). I also recompiled latest Seabios (pre-0.6.3-20110929) trunk and gPXE (1.0.1+) from Git : the behaviour is exactly the same. I tried with different NIC driver (virtio and rtl8139) with also same behavior. Do you have any idea where my problem can come from ? Thanks in advance for any advice. Regards, Romain Vrignaud

1 0

Re: [SeaBIOS] seabios: About the reset mem address
by Peter Stuge 29 Sep '11

29 Sep '11

Amos Kong wrote: > [CS base address = CS segment selector * 16] > F000H * 16 = F0000H > ^^^^^^ (it's not 0xFFFF0000) > > ==> "CS base address" is not "base address in CS register" ? Study real mode vs. protected mode. x86 starts in real mode. For backwards compatibility, 386 CPUs (the first with full 32-bit addressing) and later also start in real mode, but with CS in a twilight state, so that the first instruction is actually fetched from near top of 4GB, where the boot flash chip is decoded. > 2. If I only compile seabios, and load the bios.bin to qemu, > coreboot will not be used? Of course not. If you compile Linux, and load bzImage from LILO, will gPXE be used? coreboot is one project and SeaBIOS is another. They can both be used together and separately. > what's the relationship between coreboot and seabios ? coreboot picks SeaBIOS as default payload, if the person building coreboot does not explicitly provide a payload. On qemu the initialization done by coreboot is simple, and has been included into SeaBIOS instead, probably for convenience, I don't know. //Peter

2 1

Re: [SeaBIOS] seabios: About the reset mem address
by Kevin O'Connor 28 Sep '11

28 Sep '11

On Wed, Sep 28, 2011 at 12:54:27PM -0400, Amos Kong wrote: > Hi all, > > http://www.coreboot.org/Developer_Manual > Hardware Reset(From Intel's "64 and IA-32 Architectures Software Developer’s Manual" (doc 253668-021 October 2006), Volume 3A, Section 9.1.4:) > [...] > [CS base address = CS segment selector * 16] "CS base address" will be assigned "CS segment selector * 16" when far jumping in 16bit real mode. However, on reset the "CS base address" is set to 0xFFFF0000. > ==> Why the reset mem addresses are different? Which one is correct? They are both correct - the execution address is always CS_base + %eip, and CS_base is set to %cs * 16 when far jumping - however, the machine starts with CS_base set to a value that one couldn't normally obtain by far jumping. > Other Questions: > 1. which point does the BIOS start from? reset_vector? transition32? entry_elf? On QEmu, SeaBIOS starts at 0xfffffff0, which is an alias to reset_vector (QEmu maps the bios to both 0xffff0000 and 0xf0000). reset_vector far jumps to entry_post (f000:e05b), which then calls transition32 to go into 32bit mode and invoke handle_post. On Coreboot, coreboot is called at system start (0xfffffff0) - it does a whole bunch of system initialization and then uncompresses seabios to 0xf0000 and jumps to entry_elf, which then calls handle_post. > 2. If I only compile seabios, and load the bios.bin to qemu, coreboot will not be used? Correct. > what's the relationship between coreboot and seabios ? Coreboot does very early hardware initialization (eg, initializing memory controller). SeaBIOS implements a 16bit legacy BIOS. SeaBIOS is usable by both coreboot and QEmu (and other emulators). -Kevin

1 0

seabios: About the reset mem address
by Amos Kong 28 Sep '11

28 Sep '11

Hi all, http://www.coreboot.org/Developer_Manual Hardware Reset(From Intel's "64 and IA-32 Architectures Software Developer’s Manual" (doc 253668-021 October 2006), Volume 3A, Section 9.1.4:) """ The first instruction that is fetched and executed following a hardware reset is located at physical address 0xFFFFFFF0. This address is 16 bytes below the processor’s uppermost physical address. The EPROM containing the software-initialization code must be located at this address. The address 0xFFFFFFF0 is beyond the 1-MByte addressable range of the processor while in real-address mode. The processor is initialized to this starting address as follows. The CS register has two parts: the visible segment selector part and the hidden base address part. In real-address mode, the base address is normally formed by shifting the 16-bit segment selector value 4 bits to the left to produce a 20-bit base address. However, during a hardware reset, the segment selector in the CS register is loaded with 0xF000 and the base address is loaded with 0xFFFF0000. The starting address is thus formed by adding the base address to the value in the EIP register (that is, 0xFFFF0000 + 0xFFF0 = 0xFFFFFFF0). The first time the CS register is loaded with a new value after a hardware reset, the processor will follow the normal rule for address translation in real-address mode (that is, [CS base address = CS segment selector * 16]). To insure that the base address in the CS register remains unchanged until the EPROM based software-initialization code is completed, the code must not contain a far jump or far call or allow an interrupt to occur (which would cause the CS selector value to be changed). """ [CS base address = CS segment selector * 16] F000H * 16 = F0000H ^^^^^^ (it's not 0xFFFF0000) ==> "CS base address" is not "base address in CS register" ? BOOK: ISA system architecture http://books.google.com/books?id=-pz8rvnhFDkC&lpg=PA115&ots=HIiNT97ZPV&dq=I… CS F0000h IP + FFF0h ------ FFFF0h = physical memory address ==> Why the reset mem addresses are different? Which one is correct? ------------------- Other Questions: 1. which point does the BIOS start from? reset_vector? transition32? entry_elf? 2. If I only compile seabios, and load the bios.bin to qemu, coreboot will not be used? what's the relationship between coreboot and seabios ? Thanks, Amos

1 0

[PATCHv2 0/3] acpi: fix up EJ0 in DSDT
by Michael S. Tsirkin 28 Sep '11

28 Sep '11

This is a second iteration of the patch. The patch has been significantly reworked to address (offline) comments by Gleb. I think the infrastructure created is generic enough to be generally useful beyond the specific bug that I would like to fix. Specifically it will be able to find S3 Name to patch that, or process compiled CPU SSDT to avoid the need for hardcoded offsets. Please comment. Main changes: - tools rewritten in python - Original ASL retains _EJ0 methods, BIOS patches that to EJ0_ - generic ACP_EXTRACT infrastructure that can match Method and Name Operators - instead of matching specific method name, insert tags in original DSL source and match that to AML ----- Here's a bug: guest thinks it can eject VGA device and ISA bridge. [root@dhcp74-172 ~]#lspci 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 00:03.0 PCI bridge: Red Hat, Inc. Device 0001 00:04.0 Ethernet controller: Qumranet, Inc. Virtio network device 00:05.0 SCSI storage controller: Qumranet, Inc. Virtio block device 01:00.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) [root@dhcp74-172 ~]# ls /sys/bus/pci/slots/1/ adapter address attention latch module power [root@dhcp74-172 ~]# ls /sys/bus/pci/slots/2/ adapter address attention latch module power [root@dhcp74-172 ~]# echo 0 > /sys/bus/pci/slots/2/power [root@dhcp74-172 ~]# lspci 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:03.0 PCI bridge: Red Hat, Inc. Device 0001 00:04.0 Ethernet controller: Qumranet, Inc. Virtio network device 00:05.0 SCSI storage controller: Qumranet, Inc. Virtio block device 01:00.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) This is wrong because slots 1 and 2 are marked as not hotpluggable in qemu. The reason is that our acpi tables declare both _RMV with value 0, and _EJ0 method for these slots. What happens in this case is undocumented by ACPI spec, so linux ignores _RMV, and windows seems to ignore _EJ0. The correct way to suppress hotplug is not to have _EJ0, so this is what this patch does: it probes PIIX and modifies DSDT to match. With these patches applied, we get: [root@dhcp74-172 ~]# ls /sys/bus/pci/slots/1/ address [root@dhcp74-172 ~]# ls /sys/bus/pci/slots/2/ address Michael S. Tsirkin (3): acpi: generate and parse mixed asl/aml listing acpi: EJ0 method name patching acpi: remove _RMV Makefile | 10 +- src/acpi-dsdt.dsl | 96 ++++++++----------- src/acpi.c | 31 ++++++ tools/acpi_extract.py | 195 ++++++++++++++++++++++++++++++++++++++ tools/acpi_extract_preprocess.py | 37 +++++++ 5 files changed, 307 insertions(+), 62 deletions(-) create mode 100755 tools/acpi_extract.py create mode 100755 tools/acpi_extract_preprocess.py -- 1.7.5.53.gc233e

3 5

Re: [SeaBIOS] [Qemu-devel] Hang when using 9p mounts after last Seabios update
by Kevin O'Connor 28 Sep '11

28 Sep '11

On Thu, Sep 22, 2011 at 12:45:11PM +0100, Daniel P. Berrange wrote: > I'm doing some experimentation with application sandboxing and running > QEMU with the following command line: > > exec $QEMU \ > -m 64 \ > -nographic \ > -nodefconfig \ > -nodefaults \ > -kernel ./kernel-2.6.40.4-5.fc15.x86_64 \ > -initrd ./initrd-2.6.40.4-5.fc15.x86_64 \ > -append 'init=/bin/sh console=ttyS0 debug' \ > -fsdev local,security_model=passthrough,id=fsdev-fs0,path=/ \ > -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=org.virttools.sandbox:/ \ > -serial stdio > > On 0.14, 0.15 releaes, this all works just fine. On current GIT master, > the guest OS will hang during boot. [...] > I further bisected SeaBios between their 0.6.2 release and the changeset > mentioned above, and got to this changeset in SeaBios: > > > commit 01a5c8813b2e709809c07c5d7fab9d1c3ddb4989 > Author: Gerd Hoffmann <kraxel(a)redhat.com> > Date: Mon Jul 11 09:20:29 2011 +0200 Gerd, any thoughts on what could cause this? -Kevin

1 0

[PATCH 0/4] acpi: fix up EJ0 in DSDT
by Michael S. Tsirkin 27 Sep '11

27 Sep '11

Here's a bug: guest thinks it can eject VGA device and ISA bridge. [root@dhcp74-172 ~]#lspci 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 00:03.0 PCI bridge: Red Hat, Inc. Device 0001 00:04.0 Ethernet controller: Qumranet, Inc. Virtio network device 00:05.0 SCSI storage controller: Qumranet, Inc. Virtio block device 01:00.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) [root@dhcp74-172 ~]# ls /sys/bus/pci/slots/1/ adapter address attention latch module power [root@dhcp74-172 ~]# ls /sys/bus/pci/slots/2/ adapter address attention latch module power [root@dhcp74-172 ~]# echo 0 > /sys/bus/pci/slots/2/power [root@dhcp74-172 ~]# lspci 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:03.0 PCI bridge: Red Hat, Inc. Device 0001 00:04.0 Ethernet controller: Qumranet, Inc. Virtio network device 00:05.0 SCSI storage controller: Qumranet, Inc. Virtio block device 01:00.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) This is wrong because slots 1 and 2 are marked as not hotpluggable in qemu. The reason is that our acpi tables declare both _RMV with value 0, and _EJ0 method for these slots. What happens in this case is undocumented by ACPI spec, so linux ignores _RMV, and windows seems to ignore _EJ0. The correct way to suppress hotplug is not to have _EJ0, so this is what this patch does: it probes PIIX and modifies DSDT to match. With these patches applied, we get: [root@dhcp74-172 ~]# ls /sys/bus/pci/slots/1/ address [root@dhcp74-172 ~]# ls /sys/bus/pci/slots/2/ address I had to add a bit of compile-time infrastructure to handle the runtime patching in a simple way. I expect that it will be possible to reuse it if we need to patch other methods in the future. Michael S. Tsirkin (4): acpi: generate mixed asl/aml listing acpi: add aml/asl parsing script acpi: EJ0 method name patching acpi: remove _RMV Makefile | 10 ++-- src/acpi-dsdt.dsl | 58 +++-------------------- src/acpi.c | 11 ++++ src/find_ej0.pl | 136 +++++++++++++++++++++++++++++++++++++++++++++++++++++ src/splitdsl.pl | 16 ++++++ 5 files changed, 176 insertions(+), 55 deletions(-) create mode 100755 src/find_ej0.pl create mode 100755 src/splitdsl.pl -- 1.7.5.53.gc233e

5 15

[PATCH 0/4] ACPI DSDT simplifications
by Kevin O'Connor 26 Sep '11

26 Sep '11

This patch series simplifies the DSDT code. The goal is to separate out the DSDT into different chunks, and to remove some of the duplicated code by using methods. Kevin O'Connor (4): Delineate ACSP DSL code into sections. Consolidate PCI hotplug definitions together in DSL file. Simplify PCI hotplug acpi macros. Move code from PCI hotplug DSDT macros to methods. src/acpi-dsdt.dsl | 349 +++++++----- src/acpi-dsdt.hex | 1608 ++++++++++++++++++++++------------------------------- 2 files changed, 875 insertions(+), 1082 deletions(-) -- 1.7.6.2

1 5

Re: [SeaBIOS] [PATCH 2/4] acpi: add aml/asl parsing script
by Michael S. Tsirkin 21 Sep '11

21 Sep '11

I've rewritten the script in python. Seems to work but I didn't have time to test - only compiled for now - and needs to move to tools - but I hope this makes review easier. Thanks, --- src/find_ej0.py | 140 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 140 insertions(+), 0 deletions(-) create mode 100755 src/find_ej0.py diff --git a/src/find_ej0.py b/src/find_ej0.py new file mode 100755 index 0000000..75e5491 --- /dev/null +++ b/src/find_ej0.py @@ -0,0 +1,140 @@ +#!/usr/bin/python + +# Process mixed ASL/AML listing (.lst file) produced by iasl -l +# Locate all occurences of Name _ADR followed by Method EJ0_ +# Output slot info from _ADR and offset of method name in AML + +import re; +import sys; +import fileinput; + +aml = [] +asl = [] +output = [] +lineno = 0 +debug = "" + +class asl_line: + line = None + lineno = None + aml_offset = None + +def die(diag): + sys.stderr.write("Error: %s; %s\n" % (diag, debug)) + sys.exit(1) + +#Store an ASL command, matching AML offset, and input line (for debugging) +def add_asl(line): + l = asl_line() + l.line = line + l.lineno = lineno + l.aml_offset = len(aml) + asl.append(l) + +#Store an AML byte sequence +#Verify that offset output by iasl matches # of bytes so far +def add_aml(offset, line): + o = int(offset, 16); + # Sanity check: offset must match size of code so far + if (o != len(aml)): + die("Offset 0x%x != 0x%x" % (o, len(aml))) + # Strip any trailing dots and ASCII dump after " + line = re.sub(r'\s*\.*\s*".*$',"", line) + # Strip traling whitespace + line = re.sub(r'\s+$',"", line) + # Strip leading whitespace + line = re.sub(r'^\s+',"", line) + # Split on whitespace + code = re.split(r'\s+', line) + for c in code: + # Require a legal hex number, two digits + if (not(re.search(r'^[0-9A-Fa-f][0-9A-Fa-f]$', c))): + die("Unexpected octet %s" % c); + aml.append(int(c, 16)); + +# Process aml bytecode array, decoding AML +# Given method offset, find its name offset +def aml_method_name(lineno, offset): + #0x14 MethodOp PkgLength NameString MethodFlags TermList + if (aml[offset] != 0x14): + die( "Method after input line $lineno offset $offset: " + " expected 0x14 actual 0x%x" % aml[offset]); + offset += 1; + # PkgLength can be multibyte. Bits 8-7 give the # of extra bytes. + pkglenbytes = aml[offset] >> 6; + offset += 1 + pkglenbytes; + return offset; + +for line in fileinput.input(): + # Strip trailing newline + line.rstrip(); + # line number and debug string to output in case of errors + lineno = lineno + 1 + debug = "input line %d: %s" % (lineno, line) + #ASL listing: space, then line#, then ...., then code + pasl = re.compile('^\s+([0-9]+)\.\.\.\.\s*') + m = pasl.search(line) + if (m): + add_asl(pasl.sub("", line)); + # AML listing: offset in hex, then ...., then code + paml = re.compile('^([0-9A-Fa-f]+)\.\.\.\.\s*') + m = paml.search(line) + if (m): + add_aml(m.group(1), paml.sub("", line)) + +# Now go over code, look for EJ0_ methods +# For each such method, output slot mask from the +# preceding _ADR line, as well as the method name offset. + +for i in range(len(asl)): + l = asl[i].line + debug = "input line %d: %s" % (asl[i].lineno, asl[i].line) + # match: Method (EJ0_,1) + if (not(re.search(r'^Method\s*$\s*EJ0_\s*[,)]', l))): + # Make sure we do not miss any EJ0_: + # die if EJ0_ is found anywhere else in source code + if (re.search(r'EJ0_', l)): + die("Stray EJ0_ detected"); + continue + # EJ0_ found. Previous line must be _ADR + p = asl[i - 1].line + # match: Name (_ADR, 0x<address>) + padr = re.compile('Name\s*\(\s*_ADR\s*,\s*0x([0-9A-Fa-f]+)\s*$') + m = padr.search(p); + if (not m): + die("_ADR not found before EJ0_ ") + + adr = int(m.group(1), 16) + slot = adr >> 16; + if (slot > 31): + die("_ADR device out of range: actual %d expected 0 to 31" % slot) + + # We have offset of EJ0_ method in code + # Now find EJ0_ itself + ej0 = aml_method_name(asl[i].lineno, asl[i].aml_offset) + # Verify AML: name must be EJ0_: + if ((aml[ej0 + 0] != ord('E')) or + (aml[ej0 + 1] != ord('J')) or + (aml[ej0 + 2] != ord('0')) or + (aml[ej0 + 3] != ord('_'))): + die("AML offset 0x%x does not match EJ0_" % ej0) + + # OK we are done. Output slot mask and offset + output.append(" {.slot_mask = 0x%x, .offset = 0x%x}" % + (0x1 << slot, ej0)) + +debug = "at end of file" + +# Pretty print output +if (not len(output)): + die("No EJ0_ Method found!") + +print ''' +static struct aml_ej0_data { + unsigned slot_mask; + unsigned offset; +} aml_ej0_data[] = {''' + +print ",\n".join(output) +print '};\n' + -- 1.7.5.53.gc233e

1 0

Re: [SeaBIOS] [PATCH 2/4] acpi: add aml/asl parsing script
by Gleb Natapov 21 Sep '11

21 Sep '11

On Wed, Sep 21, 2011 at 03:44:29PM +0300, Michael S. Tsirkin wrote: > script ./src/find_ej0.pl finds all instances of > method named EJ0_ and the matching _ADR information, > and outputs the AML offset and slot mask of each. > There is tools/ directory for such kind of scripts. Most (if not all) of scripts there are in python though. Perl should die painful death. This approach delivers nice result, but since the script does not really decodes AML, but tries to match ASL source code with regular expressions, it introduces some assumptions to the code that make DSDT code less hackable. I'll hate to be the one who will have to change PCI device definitions in DSDT next time. Generally speaking finding an offset of some scope in AML is useful not only for PCI hotplug. For instance we want to make S3/S4 capability configurable by a command line switch, but this also requires DSDT patching and having automatic way to find _S3_/_S4_ offset is required for that too (we do not what to find it by hand each time DSDT is recompiled). > Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> > --- > src/find_ej0.pl | 136 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 136 insertions(+), 0 deletions(-) > create mode 100755 src/find_ej0.pl > > diff --git a/src/find_ej0.pl b/src/find_ej0.pl > new file mode 100755 > index 0000000..37e8a8c > --- /dev/null > +++ b/src/find_ej0.pl > @@ -0,0 +1,136 @@ > +#!/usr/bin/perl > + > +# Process mixed ASL/AML listing (.lst file) produced by iasl -l > +# Locate all occurences of Name _ADR followed by Method EJ0_ > +# Output slot info from _ADR and offset of method name in AML > + > +use strict; > + > +my @aml = (); > +my @asl = (); > +my @asl_lineno = (); > +my @asl_to_aml_offset = (); > +my @output = (); > + > +#Store an ASL command, matching AML offset, and input line (for debugging) > +sub add_asl { > + my $srcline = shift(@_); > + my $line = shift(@_); > + push @asl, $line; > + push @asl_lineno, $.; > + push @asl_to_aml_offset, $#aml + 1; > +} > + > +#Store an AML byte sequence > +#Verify that offset output by iasl matches # of bytes so far > +sub add_aml { > + my $offset = shift(@_); > + my $line = shift(@_); > + my $o = hex($offset); > + # Sanity check: offset must match > + die "Offset $o != " .($#aml + 1) if ($o != $#aml + 1); > + # Strip any traling dots and ASCII dump after " > + $line =~ s/\s*\.*\s*".*//; > + > + my @code = split(' ', $line); > + foreach my $c (@code) { > + if (not($c =~ m/^[0-9A-Fa-f][0-9A-Fa-f]$/)) { > + die "Unexpected octet $c"; > + } > + push @aml, hex($c); > + } > +} > + > +# Process aml bytecode array, decoding AML > +# Given method offset, find its name offset > +sub aml_method_name { > + my $lineno = shift(@_); > + my $offset = shift(@_); > + #0x14 MethodOp PkgLength NameString MethodFlags TermList > + if ($aml[$offset] != 0x14) { > + die "Method after input line $lineno offset $offset: " . > + " expected 0x14 actual ". sprintf("0x%x", $aml[$offset]); > + } > + $offset += 1; > + # PkgLength can be multibyte. Bits 8-7 give the # of extra bytes. > + my $pkglenbytes = $aml[$offset] >> 6; > + $offset += 1 + $pkglenbytes; > + return $offset; > +} > + > +while (<>) { > + #Strip trailing newline > + chomp; > + #ASL listing: space, then line#, then ...., then code > + if (s#^\s+([0-9]+)\.\.\.\.\s*##) { > + add_asl($1, $_); > + } > + # AML listing: offset in hex, then ...., then code > + if (s#^([0-9A-F]+)\.\.\.\.\s*##) { > + add_aml($1, $_); > + } > + # Ignore everything else > +} > + > +# Now go over code, look for EJ0_ methods > +# For each such method, output slot mask from the > +# preceding _ADR line, as well as the method name offset. > +for (my $i = 0; $i <= $#asl; $i++) { > + my $l = $asl[$i]; > + # match: Method (EJ0_,1) > + if (not $l =~ m#^Method\s*$\s*EJ0_\s*[,)]#) { > + # Make sure we do not miss any EJ0_: > + # die if EJ0_ is found anywhere else in source code > + if ($l =~ m#EJ0_#) { > + die "Stray EJ0_ detected at input line $asl_lineno[$i]: $asl[$i]"; > + } > + next; > + } > + # EJ0_ found. Previous line must be _ADR > + my $p = $i > 0 ? $asl[$i - 1] : ""; > + # match: Name (_ADR, 0x<address>) > + if (not ($p =~ m#Name\s*\(\s*_ADR\s*,\s*0x([0-9A-Fa-f]+)\s*$#)) { > + die "_ADR not found before EJ0_ ". > + "at input line $asl_lineno[$i]: $asl[$i]"; > + } > + my $adr = hex($1); > + my $slot = $adr >> 16; > + if ($slot > 31) { > + die "_ADR device out of range: actual $slot " . > + "expected 0 to 31 at input line $asl_lineno[$i]: $asl[$i]"; > + } > + > + # We have offset of EJ0_ method in code > + # Now find EJ0_ itself > + my $offset = $asl_to_aml_offset[$i]; > + my $ej0 = aml_method_name($asl_lineno[$i], $offset); > + # Verify AML: name must be EJ0_: > + if (($aml[$ej0 + 0] != ord('E')) or > + ($aml[$ej0 + 1] != ord('J')) or > + ($aml[$ej0 + 2] != ord('0')) or > + ($aml[$ej0 + 3] != ord('_'))) { > + die "AML after input line $asl_lineno[$i] offset $ej0 " . > + "does not match EJ0_"; > + } > + > + # OK we are done. Output slot mask and offset > + push @output, sprintf(" {.slot_mask = 0x%x, .offset = 0x%x}", > + 0x1 << $slot, $ej0); > +} > + > +# Pretty print output > +if ($#output < 0) { > + die "No EJ0_ Method found!" > +} > +print <<EOF; > +static struct aml_ej0_data { > + unsigned slot_mask; > + unsigned offset; > +} aml_ej0_data[] = { > +EOF > +print join(",\n", @output); > +print <<EOF; > + > +}; > +EOF > + > -- > 1.7.5.53.gc233e -- Gleb.

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS