acpi_extract: detect DeviceOp
added new directives to acpi_extract.py, but didn't
Add documentation at top of file.
Cc: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com>
tools/acpi_extract.py | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/acpi_extract.py b/tools/acpi_extract.py
index ab8ced6..8975b31 100755
@@ -29,6 +29,9 @@
# ACPI_EXTRACT_PROCESSOR_START - start of Processor() block
# ACPI_EXTRACT_PROCESSOR_STRING - extract a NameString from Processor()
# ACPI_EXTRACT_PROCESSOR_END - offset at last byte of Processor() + 1
+# ACPI_EXTRACT_DEVICE_START - start of Device() block
+# ACPI_EXTRACT_DEVICE_STRING - extract a NameString from Device()
+# ACPI_EXTRACT_DEVICE_END - offset at last byte of Device() + 1
# ACPI_EXTRACT_PKG_START - start of Package block
# ACPI_EXTRACT_ALL_CODE - create an array storing the generated AML bytecode
On Wed, Aug 07, 2013 at 11:16:05PM +0200, Mario wrote:
> Since I'm a legal owner of the first generation of Mac Mini with a
> regular Snow Leopard license,I'm trying to follow this tutorial with
> the goal to virtualize Mac Os X with KVM on the second part of the
> hard disk where I have installed Linux Ubuntu. You can find the guide
> here :
> File "./tools/layoutrom.py", line 564, in parseObjDump
> relocsection = sectionmap[sectionname]
> KeyError: '.text.asm./media/ziomario/09274c80-4a49-4f4f-9e2e-83c4a5578a04/OSXGUEST/seabios
This appears to be a build error. These are usually due to toolset
quirks. What OS, compiler, compiler version, ld version are you
using? Also, please include the exact commands you ran and the full
It looks like you patched seabios - make sure you can build a clean
seabios without any patcheds first.
Please also try "make distclean ; make" to verify that the repo is in
a clean state before building.
Since I'm a legal owner of the first generation of Mac Mini with a
regular Snow Leopard license,I'm trying to follow this tutorial with
the goal to virtualize Mac Os X with KVM on the second part of the
hard disk where I have installed Linux Ubuntu. You can find the guide
The problem arises when I have to install/configure the seabios
package. This is what happens :
Compiling whole program out/ccode16.o
Compiling to assembler out/asm-offsets.s
Generating offset file out/asm-offsets.h
Compiling (16bit) out/romlayout.o
Building ld scripts
Traceback (most recent call last):
File "./tools/layoutrom.py", line 669, in
File "./tools/layoutrom.py", line 633, in main
info16 = parseObjDump(infile16, '16')
File "./tools/layoutrom.py", line 564, in parseObjDump
relocsection = sectionmap[sectionname]
make: * [out/romlayout16.lds] Errore 1
Can someone help me to fix this error ? thanks.
I'm doing my own OS and i'm booting it from USB uhci. When it boots and it
arrives to the system code i want reading and writing from USB.
First of all i take the usb.c, util.c, usb.h, usb_uhci.c, usb_uhci.h,
pci.c, pci.h, pciinit.c,... and put it into my sources and i compile it but
i need the romlayout.S that depends directly from bios's idt and not from
the idt from my OS.
How can i do that?
Do i need to call pci_setup() or something in the initialization of my own
Are there some documentation to know how are the files connected and what
do the functions do?
2013/8/6 dunedain1990 <dunedain1990(a)gmail.com>
> I'm doing my own OS and i'm booting it from USB uhci. When it boots and it
> arrives to the system code i want read and write from USB.
> First of all i take the usb.c, util.c, usb.h, usb_uhci.c, usb_uhci.h,
> pci.c, pci.h, pciinit.c,... and put it into my sources and i compile it but
> i need the romlayout.S that depends directly from idt of the bios and not
> from the idt from my OS.
> How can i do that?
> There are documentation for know how the files are connected and functions
On 08/05/2013 10:34 PM, Fred . wrote:
> Maybe rename Windows 2001, 2006, and 2009 to their real names?
The names were decided by Microsoft, not by me.
> Or use their NT kernel name instead, like NT 6.1, NT 6.2, etc.
> Or add a comment in the source code like:
> “Windows 2009” /* Windows 7 */ ||
> "Windows 2012" /* Windows Server 2012 */ ||
Yeah, this can work.
> On Mon, Aug 5, 2013 at 9:11 PM, Paolo Bonzini <pbonzini(a)redhat.com
> <mailto:firstname.lastname@example.org>> wrote:
> > > From my quick research, it looks like "Windows 2006" || "Windows
> > > 2006.1" || "Linux" would work, but I have not tested it.
> > >
> > > Paolo
> > This doesn't work in that it matches linux.
> Note that the above was meant to be a condition for when to _show_
> the PCI hole, i.e. negated compared to your example.
> > ATM it looks like we should test
> > "Windows 2000" ||
> > "Windows 2001" ||
> > "Windows 2001 SP1" ||
> > "Windows 2001.1 SP1"
> Including this may be too strict, what about 98/ME?
> > && !(
> > "Windows 2006" ||
> > "Windows 2006.1" ||
> We know that these are all implied by the following four:
> > "Windows 2006 SP1" ||
> > "Windows 2006 SP2" ||
> > "Windows 2009" ||
> > "Windows 2012" ||
> So it is not necessary to test these four.
> > "Linux" ||
> > "FreeBSD"
> > ) &&
> > _OS == "Microsoft Windows NT"
> > &&
> > _REV == 0x1
> Testing _OS and _REV is probably too strict.
> > This should match XP and 2003 as tightly as possible.
> > Please note "Linux" is there just in case, modern
> > Linux OSPM does not identify itself as "Linux".
> Yeah, I know. I didn't know about FreeBSD, and I agree it is
> better to include it just in case.
> SeaBIOS mailing list
> SeaBIOS(a)seabios.org <mailto:SeaBIOS@seabios.org>
> SeaBIOS mailing list
>> Latest seabios (aka git master, 1.7.3 isn't new enough) can append
>> seabios log to the coreboot logbuffer. So you can use "cbmem -c" to
>> read the logs once the system is up'n'running and find the strings
Then I suggest adding that information to the wiki:
when that feature is in the stable release.
I suggest adding the Open Firmware paths for devices SeaBIOS can boot
(example: /pci@i0cf8/usb@12,2/usb-*@4) to the boot selection screen. I
to buy a serial adapter and a null modem just to get that string. That
is important since you cannot modify the default boot sequence without