Re: acpidump replaces acpidmp

Re: acpidump replaces acpidmp

[Voluspa]

On 2005-07-23 0:35:38 Len Brown wrote:

>ps. I shall delete /proc/fadt and /proc/dsdt when I return
>from Ottawa unless somebody can convince me they should live.

Please do not! Not until a reliable userspace program can be easily
found for retrieving the dsdt on my pure X86_64 AMD system:

loke:sleipner:/home/net/acer/acpi/len_brown/pmtools-20050722$ uname -r
2.6.13-rc3
loke:sleipner:/home/net/acer/acpi/len_brown/pmtools-20050722$ make
for i in acpidump; do make -C $i all; done
make[1]: Entering directory
`/home/net/acer/acpi/len_brown/pmtools-20050722/acpidump'
cc -Wall -Wstrict-prototypes -O2 -D_LINUX -DDEFINE_ALTERNATE_TYPES
-I../include  acpidump.c -o acpidump
In file included from acpidump.c:49:
../include/acpi/actypes.h:115: error: parse error before
"acpi_native_int"
../include/acpi/actypes.h:115: warning: type defaults to `int' in
declaration of `acpi_native_int'
../include/acpi/actypes.h:115: warning: data definition has no type or
storage class
acpidump.c: In function `acpi_dump_RSDT':
acpidump.c:222: warning: cast to pointer from integer of different size
acpidump.c:246: warning: cast to pointer from integer of different size
acpidump.c:259: warning: cast to pointer from integer of different size
acpidump.c:266: warning: cast to pointer from integer of different size
acpidump.c:308: warning: cast to pointer from integer of different size
acpidump.c:350: warning: cast to pointer from integer of different size
acpidump.c:357: warning: cast to pointer from integer of different size
acpidump.c: In function `acpi_dump_XSDT':
acpidump.c:425: warning: cast to pointer from integer of different size
acpidump.c:438: warning: cast to pointer from integer of different size
make[1]: *** [acpidump] Error 1
make[1]: Leaving directory
`/home/net/acer/acpi/len_brown/pmtools-20050722/acpidump'
make: *** [all] Error 2

Mvh
Mats Johannesson
--


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Re: acpidump replaces acpidmp

[Thomas Renninger]

Voluspa wrote:
> On 2005-07-23 0:35:38 Len Brown wrote:
> 
>>ps. I shall delete /proc/fadt and /proc/dsdt when I return
>>from Ottawa unless somebody can convince me they should live.
> 
> Please do not! Not until a reliable userspace program can be easily
> found for retrieving the dsdt on my pure X86_64 AMD system:
> 
> loke:sleipner:/home/net/acer/acpi/len_brown/pmtools-20050722$ uname -r
> 2.6.13-rc3
> loke:sleipner:/home/net/acer/acpi/len_brown/pmtools-20050722$ make
> for i in acpidump; do make -C $i all; done
> make[1]: Entering directory
> `/home/net/acer/acpi/len_brown/pmtools-20050722/acpidump'
> cc -Wall -Wstrict-prototypes -O2 -D_LINUX -DDEFINE_ALTERNATE_TYPES
> -I../include  acpidump.c -o acpidump
> In file included from acpidump.c:49:
> ../include/acpi/actypes.h:115: error: parse error before
> "acpi_native_int"
> ../include/acpi/actypes.h:115: warning: type defaults to `int' in
> declaration of `acpi_native_int'
> ../include/acpi/actypes.h:115: warning: data definition has no type or
> storage class
> acpidump.c: In function `acpi_dump_RSDT':
> acpidump.c:222: warning: cast to pointer from integer of different size
> acpidump.c:246: warning: cast to pointer from integer of different size
> acpidump.c:259: warning: cast to pointer from integer of different size
> acpidump.c:266: warning: cast to pointer from integer of different size
> acpidump.c:308: warning: cast to pointer from integer of different size
> acpidump.c:350: warning: cast to pointer from integer of different size
> acpidump.c:357: warning: cast to pointer from integer of different size
> acpidump.c: In function `acpi_dump_XSDT':
> acpidump.c:425: warning: cast to pointer from integer of different size
> acpidump.c:438: warning: cast to pointer from integer of different size
> make[1]: *** [acpidump] Error 1
> make[1]: Leaving directory
> `/home/net/acer/acpi/len_brown/pmtools-20050722/acpidump'
> make: *** [all] Error 2
> 
../include/acpi/actypes.h:115
Replace s64 with u64 and it at least compiles.
I tried it out on two (x86_64) machines.
On the one I got no output at all, on the other I got a segfault in
acpidump.c:104.

Why is acpidmp replaced?

Thanks,

       Thomas


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Re: acpidump replaces acpidmp

[Voluspa]

On Wed, 27 Jul 2005 13:05:29 +0200 Thomas Renninger wrote:
> Voluspa wrote:
> > On 2005-07-23 0:35:38 Len Brown wrote:
> > make[1]: *** [acpidump] Error 1
> > make[1]: Leaving directory
> > `/home/net/acer/acpi/len_brown/pmtools-20050722/acpidump'
> > make: *** [all] Error 2
> > 
> ../include/acpi/actypes.h:115
> Replace s64 with u64 and it at least compiles.

Heh, when I saw the s64 that was my first thought. But being a newbie to
C it seemed like a wild goose chase. Yes, compiles after that edit.

> I tried it out on two (x86_64) machines.
> On the one I got no output at all, on the other I got a segfault in
> acpidump.c:104.

I get a segfault with "./acpidump --table DSDT" after quit a bit of
output (down to 5e40: 57 12 06 02 0a 00 0a 03). No .c linenumber.
Straight "./acpidump" completes, but how do I know it _is_ complete...
A diff between /proc/acpi/dsdt and the output of "./acpidump --binary"
differ, and not by a small amount:

24 -r--------  1 root root  24136 Jul 27 14:47 dsdt
28 -rw-r--r--  1 root root  24743 Jul 27 14:52 dsdt.acpidump

Mvh
Mats Johannesson
--


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Re: acpidump replaces acpidmp

[Voluspa]

24 -r--------  1 root root   24136 Jul 27 14:47 dsdt
28 -rw-r--r--  1 root root   24743 Jul 27 14:52 dsdt.acpidump

OK, I now know that acpidump gives me both fadt and dsdt and something
more, hence the difference. But this is usability madness; 1) The
documentation of program switches, Both README and source, swing between
mildly accurate and inaccurate; 2) Having to dump/decode in several
steps here (not really knowing if you've made an error) and then later
in iasl as well.

Compared to just copying dsdt from /proc and following all the tutorials
online on how to modify it, this hackery is not sane.

Mvh
Mats Johannesson
--


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

RE: Re: acpidump replaces acpidmp

[Brown, Len]

feel free to send me a patch to fix it.

thanks,
-Len 

>-----Original Message-----
>From: Voluspa [mailto:voluspa-zq6IREYz3ykAvxtiuMwx3w@public.gmane.org] 
>Sent: Wednesday, July 27, 2005 9:45 AM
>To: Thomas Renninger
>Cc: Brown, Len; acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>Subject: Re: [ACPI] Re: acpidump replaces acpidmp
>
>
>24 -r--------  1 root root   24136 Jul 27 14:47 dsdt
>28 -rw-r--r--  1 root root   24743 Jul 27 14:52 dsdt.acpidump
>
>OK, I now know that acpidump gives me both fadt and dsdt and something
>more, hence the difference. But this is usability madness; 1) The
>documentation of program switches, Both README and source, 
>swing between
>mildly accurate and inaccurate; 2) Having to dump/decode in several
>steps here (not really knowing if you've made an error) and then later
>in iasl as well.
>
>Compared to just copying dsdt from /proc and following all the 
>tutorials
>online on how to modify it, this hackery is not sane.
>
>Mvh
>Mats Johannesson
>--
>


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click

Re: Re: acpidump replaces acpidmp

[Thomas Renninger]

Voluspa wrote:
> 24 -r--------  1 root root   24136 Jul 27 14:47 dsdt
> 28 -rw-r--r--  1 root root   24743 Jul 27 14:52 dsdt.acpidump
> 
> OK, I now know that acpidump gives me both fadt and dsdt and something
> more, hence the difference. But this is usability madness; 1) The
> documentation of program switches, Both README and source, swing between
> mildly accurate and inaccurate; 2) Having to dump/decode in several
> steps here (not really knowing if you've made an error) and then later
> in iasl as well.
> 
> Compared to just copying dsdt from /proc and following all the tutorials
> online on how to modify it, this hackery is not sane.
> 
It's not that bad:
(using the old acpidmp. I expect it works the same with acpidump, but
I couldn't get any output with my short tries ...)

acpidmp > /tmp/acpidmp
acpixtract dsdt /tmp/acpidmp >/tmp/dsdt
acpixtract ssdt /tmp/acpidmp >/tmp/ssdt

iasl -d /tmp/dsdt
if you have a ssdt:
iasl -d /tmp/ssdt

Now you can edit /tmp/ssdt.dsl and /tmp/dsdt.dsl

     Thomas


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

RE: Re: acpidump replaces acpidmp

[Brown, Len]

 
>> ../include/acpi/actypes.h:115
>> Replace s64 with u64 and it at least compiles.

I published this initial version while at OLS,
having tested it only on ia32.

I tested it now on x86_64 and ran into the same problem as you.
The fix, however, is to use the typedef used in the kernel,
a signed long long, in this case.

After this change it works fine for me on x86_64 -- I'll
push a new version momentarily.

cheers,
-Len



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click

Re: Re: acpidump replaces acpidmp

[Thomas Renninger]

[-- Attachment #1: Type: text/plain, Size: 852 bytes --]

Brown, Len wrote:
>  
>>>../include/acpi/actypes.h:115
>>>Replace s64 with u64 and it at least compiles.
> 
> I published this initial version while at OLS,
> having tested it only on ia32.
> 
> I tested it now on x86_64 and ran into the same problem as you.
> The fix, however, is to use the typedef used in the kernel,
> a signed long long, in this case.
> 
> After this change it works fine for me on x86_64 -- I'll
> push a new version momentarily.
> 
Thanks.

Works with -O2 compile flag, it segfaults with -g.

The bad line is:
memcpy(&rsdt, tbl, tbl->length);  (line 196)

The rsdt has an undefined amount of pointers to other ACPI
tables in the end, therefore tbl->length > sizeof(struct rsdt),
memcpy writes outside &rsdt.

Patch to avoid memcpy attached. Don't know how to integrate it nicer/shorter,
please review.

Thanks,

      Thomas




[-- Attachment #2: acpidump_memcpy_beyond_rsdt_struct.diff --]
[-- Type: text/x-patch, Size: 6619 bytes --]

--- x/acpidump/acpidump.c	2005-07-29 14:10:09.000000000 +0200
+++ y/acpidump/acpidump.c	2005-07-29 14:18:30.000000000 +0200
@@ -188,20 +188,20 @@
 
 static acpi_status acpi_dump_RSDT(int fd, struct rsdp_descriptor *rsdp)
 {
-	struct acpi_table_header *tbl =
+	struct acpi_table_header *tbl;
+	struct acpi_table_header *rsdt_header =
 	    acpi_map_table(rsdp->rsdt_physical_address, RSDT_SIG);
-	if (!tbl)
+	RSDT_DESCRIPTOR *rsdt = (RSDT_DESCRIPTOR*) rsdt_header;
+	if (!rsdt_header)
 		return AE_NOT_FOUND;
-	RSDT_DESCRIPTOR rsdt;
-	memcpy(&rsdt, tbl, tbl->length);
+
 	void *addr;
-	acpi_unmap_table(tbl);
-	int num = (rsdt.length - sizeof(RSDT_DESCRIPTOR)) / sizeof(u32) + 1;
+	int num = (rsdt_header->length - sizeof(RSDT_DESCRIPTOR)) / sizeof(u32) + 1;
 	int dsdt_idx = -1, facs_idx = -1, fadt1_idx = -1, fadt2_idx =
 	    -1, fadt2m_idx = -1;
 	int i;
 	for (i = 0; i < num; ++i) {
-		tbl = acpi_map_table(rsdt.table_offset_entry[i], 0);
+		tbl = acpi_map_table(rsdt->table_offset_entry[i], 0);
 		if (!tbl)
 			continue;
 		if (!memcmp(tbl->signature, FADT_SIG, 4)) {
@@ -221,9 +221,9 @@
 			} else if (!memcmp(tbl->signature, FACS_SIG, 4)) {
 				facs_idx = i;
 			}
-			addr = (void *)rsdt.table_offset_entry[i];
+			addr = (void *)rsdt->table_offset_entry[i];
 			if (connect) {
-				rsdt.table_offset_entry[i] =
+				rsdt->table_offset_entry[i] =
 				    lseek(fd, 0, SEEK_CUR);
 			}
 			write_table(fd, tbl, addr);
@@ -232,19 +232,23 @@
 	}
 	if (fadt1_idx != -1) {
 		tbl =
-		    acpi_map_table(rsdt.table_offset_entry[fadt1_idx],
+		    acpi_map_table(rsdt->table_offset_entry[fadt1_idx],
 				   FADT_SIG);
-		if (!tbl)
+		if (!tbl){
+			acpi_unmap_table(rsdt_header);
 			return AE_NOT_FOUND;
+		}
 		struct fadt_descriptor_rev1 x;
 		memcpy(&x, tbl, sizeof(struct fadt_descriptor_rev1));
 		acpi_unmap_table(tbl);
 		if (dsdt_idx != -1) {
-			x.dsdt = rsdt.table_offset_entry[dsdt_idx];
+			x.dsdt = rsdt->table_offset_entry[dsdt_idx];
 		} else {
 			tbl = acpi_map_table(x.dsdt, DSDT_SIG);
-			if (!tbl)
+			if (!tbl){
+				acpi_unmap_table(rsdt_header);
 				return AE_NOT_FOUND;
+			}
 			addr = (void *)x.dsdt;
 			if (connect) {
 				x.dsdt = lseek(fd, 0, SEEK_CUR);
@@ -253,11 +257,13 @@
 			acpi_unmap_table(tbl);
 		}
 		if (facs_idx != -1) {
-			x.firmware_ctrl = rsdt.table_offset_entry[facs_idx];
+			x.firmware_ctrl = rsdt->table_offset_entry[facs_idx];
 		} else {
 			tbl = acpi_map_table(x.firmware_ctrl, FACS_SIG);
-			if (!tbl)
+			if (!tbl){
+				acpi_unmap_table(rsdt_header);
 				return AE_NOT_FOUND;
+			}
 			addr = (void *)x.firmware_ctrl;
 			if (connect) {
 				x.firmware_ctrl = lseek(fd, 0, SEEK_CUR);
@@ -265,28 +271,32 @@
 			write_table(fd, tbl, addr);
 			acpi_unmap_table(tbl);
 		}
-		addr = (void *)rsdt.table_offset_entry[fadt1_idx];
+		addr = (void *)rsdt->table_offset_entry[fadt1_idx];
 		if (connect) {
-			rsdt.table_offset_entry[fadt1_idx] =
+			rsdt->table_offset_entry[fadt1_idx] =
 			    lseek(fd, 0, SEEK_CUR);
 		}
 		write_table(fd, (struct acpi_table_header *)&x, addr);
 	}
 	if (fadt2_idx != -1) {
 		tbl =
-		    acpi_map_table(rsdt.table_offset_entry[fadt2_idx],
+		    acpi_map_table(rsdt->table_offset_entry[fadt2_idx],
 				   FADT_SIG);
-		if (!tbl)
+		if (!tbl){
+			acpi_unmap_table(rsdt_header);
 			return AE_NOT_FOUND;
+		}
 		struct fadt_descriptor_rev2 x;
 		memcpy(&x, tbl, sizeof(struct fadt_descriptor_rev2));
 		acpi_unmap_table(tbl);
 		if (dsdt_idx != -1) {
-			x.Xdsdt = rsdt.table_offset_entry[dsdt_idx];
+			x.Xdsdt = rsdt->table_offset_entry[dsdt_idx];
 		} else {
 			tbl = acpi_map_table(x.Xdsdt, DSDT_SIG);
-			if (!tbl)
+			if (!tbl){
+				acpi_unmap_table(rsdt_header);
 				return AE_NOT_FOUND;
+			}
 			addr = (void *)(unsigned long)x.Xdsdt;
 			if (connect) {
 				x.Xdsdt = lseek(fd, 0, SEEK_CUR);
@@ -295,11 +305,13 @@
 			acpi_unmap_table(tbl);
 		}
 		if (facs_idx != -1) {
-			x.xfirmware_ctrl = rsdt.table_offset_entry[facs_idx];
+			x.xfirmware_ctrl = rsdt->table_offset_entry[facs_idx];
 		} else {
 			tbl = acpi_map_table(x.xfirmware_ctrl, FACS_SIG);
-			if (!tbl)
+			if (!tbl){
+				acpi_unmap_table(rsdt_header);
 				return AE_NOT_FOUND;
+			}
 			addr = (void *)(unsigned long)x.xfirmware_ctrl;
 			if (connect) {
 				x.xfirmware_ctrl = lseek(fd, 0, SEEK_CUR);
@@ -307,28 +319,32 @@
 			write_table(fd, tbl, addr);
 			acpi_unmap_table(tbl);
 		}
-		addr = (void *)rsdt.table_offset_entry[fadt2_idx];
+		addr = (void *)rsdt->table_offset_entry[fadt2_idx];
 		if (connect) {
-			rsdt.table_offset_entry[fadt2_idx] =
+			rsdt->table_offset_entry[fadt2_idx] =
 			    lseek(fd, 0, SEEK_CUR);
 		}
 		write_table(fd, (struct acpi_table_header *)&x, addr);
 	}
 	if (fadt2m_idx != -1) {
 		tbl =
-		    acpi_map_table(rsdt.table_offset_entry[fadt2m_idx],
+		    acpi_map_table(rsdt->table_offset_entry[fadt2m_idx],
 				   FADT_SIG);
-		if (!tbl)
+		if (!tbl){
+			acpi_unmap_table(rsdt_header);
 			return AE_NOT_FOUND;
+		}
 		struct fadt_descriptor_rev2_minus x;
 		memcpy(&x, tbl, sizeof(struct fadt_descriptor_rev2_minus));
 		acpi_unmap_table(tbl);
 		if (dsdt_idx != -1) {
-			x.V1_dsdt = rsdt.table_offset_entry[dsdt_idx];
+			x.V1_dsdt = rsdt->table_offset_entry[dsdt_idx];
 		} else {
 			tbl = acpi_map_table(x.V1_dsdt, DSDT_SIG);
-			if (!tbl)
+			if (!tbl){
+				acpi_unmap_table(rsdt_header);
 				return AE_NOT_FOUND;
+			}
 			addr = (void *)(unsigned long)x.V1_dsdt;
 			if (connect) {
 				x.V1_dsdt = lseek(fd, 0, SEEK_CUR);
@@ -337,11 +353,13 @@
 			acpi_unmap_table(tbl);
 		}
 		if (facs_idx != -1) {
-			x.V1_firmware_ctrl = rsdt.table_offset_entry[facs_idx];
+			x.V1_firmware_ctrl = rsdt->table_offset_entry[facs_idx];
 		} else {
 			tbl = acpi_map_table(x.V1_firmware_ctrl, FACS_SIG);
-			if (!tbl)
+			if (!tbl){
+				acpi_unmap_table(rsdt_header);
 				return AE_NOT_FOUND;
+			}
 			addr = (void *)(unsigned long)x.V1_firmware_ctrl;
 			if (connect) {
 				x.V1_firmware_ctrl = lseek(fd, 0, SEEK_CUR);
@@ -349,9 +367,9 @@
 			write_table(fd, tbl, addr);
 			acpi_unmap_table(tbl);
 		}
-		addr = (void *)rsdt.table_offset_entry[fadt2m_idx];
+		addr = (void *)rsdt->table_offset_entry[fadt2m_idx];
 		if (connect) {
-			rsdt.table_offset_entry[fadt2m_idx] =
+			rsdt->table_offset_entry[fadt2m_idx] =
 			    lseek(fd, 0, SEEK_CUR);
 		}
 		write_table(fd, (struct acpi_table_header *)&x, addr);
@@ -360,7 +378,8 @@
 	if (connect) {
 		rsdp->rsdt_physical_address = lseek(fd, 0, SEEK_CUR);
 	}
-	write_table(fd, (struct acpi_table_header *)&rsdt, addr);
+	write_table(fd, (struct acpi_table_header *)rsdt_header, addr);
+	acpi_unmap_table(rsdt_header);
 	return AE_OK;
 }
 

Re: RE: acpidump replaces acpidmp

[Bjorn Helgaas]

On Tuesday 16 August 2005 12:23 pm, Brown, Len wrote:
> Mats,
> Does the latest acpidump work for you now?
> can we obsolete /proc/acpi/fadt,dsdt?

pmtools-20050804 doesn't work at all on ia64, because
the RSDP doesn't live where you expect it.  We export
/sys/firmware/efi/systab with the addresses you want.

The attached patch adds this, fixes a bunch of
documentation errors, and fixes some broken if/else
blocking.  There are still a number of warnings when
building on ia64; I didn't bother to fix those, sorry.

diff -u -ur pmtools-20050804/README pmtools/README
--- pmtools-20050804/README	2005-07-21 23:19:03.000000000 -0600
+++ pmtools/README	2005-08-16 15:02:25.000000000 -0600
@@ -8,37 +8,38 @@
 -----------------
 This utility dumps a system's ACPI tables to an ASCII file.
 
-Typically it is used to grab all the ACPI tables
-to attach to a bug report for later examination.
+Typically it is used to dump all the ACPI tables
+to attach to a bug report for later examination:
 
-# acpidump > acpidump.out
+    # ./acpidump > acpidump.out
 
-It can also grab a specific binary table
+It can also dump a specific table:
 
-# acpidump DSDT > DSDT
+    # ./acpidump -t DSDT > DSDT
+
+./acpidump/acpixtract
+--------------------
+Convert ASCII acpidump output to raw binary table:
+
+    # ./acpidump -t DSDT | ./acpixtract > DSDT
+    $ cat email | ./acpixtract DSDT > DSDT
 
 ./acpidump/acpitbl
 -----------------
-Perl script to dump the table header or contents
-of a binary ACPI table.  eg.
+Dump the table header or contents of a raw ACPI table:
 
-# acpidump FACP | acpitbl
-
-./acpidump/acpixtract
---------------------
-Perl script to extract raw table from ASCII acpidump output eg. 
-$ cat acpidump.out | acpixtract DSDT > DSDT
-or
+    # ./acpidump -t FACP | ./acpixtract | ./acpitbl
+    $ cat email | ./acpixtract FACP | ./acpitbl
 
 Disassembler
 ------------
-Note that the acpidisasm has been deleted, in favor of iasl:
+Note that acpidisasm has been deleted, in favor of iasl:
 http://www.intel.com/technology/IAPC/acpi/downloads.htm
 
 Which creates DSDT.dsl this way:
 
-$ acpixtract DSDT acpidump.out
-$ iasl -d DSDT
+    # ./acpidump -t DSDT | ./acpixtract > DSDT
+    $ iasl -d DSDT
 
 
 pmtest -- does not work
diff -u -ur pmtools-20050804/acpidump/acpidump.c pmtools/acpidump/acpidump.c
--- pmtools-20050804/acpidump/acpidump.c	2005-08-04 11:03:32.000000000 -0600
+++ pmtools/acpidump/acpidump.c	2005-08-16 15:51:29.000000000 -0600
@@ -65,6 +65,18 @@
 static int connect;
 static u8 select_sig[4];
 
+static void read_efi_systab(unsigned long *base)
+{
+	FILE *f = fopen("/sys/firmware/efi/systab", "r");
+	if (!f)
+		return;
+	unsigned long addr;
+	int n = fscanf(f, "ACPI20=0x%lx", &addr);
+	if (n == 1)
+		*base = addr;
+	fclose(f);
+}
+
 static u8 *acpi_map_memory(unsigned long where, unsigned length)
 {
 	int fd = open("/dev/mem", O_RDONLY);
@@ -552,18 +564,17 @@
 	printf
 	    ("%s [--addr 0x1234][--table DSDT][--output filename][--binary][--length 0x456][--help]\n",
 	     progname);
-	puts("\t--addr 0x1234 or -a 0x1234 -- look for tables at this phisical address");
+	puts("\t--addr 0x1234 or -a 0x1234 -- look for tables at this physical address");
 	puts("\t--table DSDT or -t DSDT -- only dump table with DSDT signature");
 	puts("\t--output filename or -o filename -- redirect output from stdin to filename");
 	puts("\t--binary or -b -- dump data in binary form rather than in hex-dump format");
-	puts("\t--length 0x456 or -l 0x456 -- works only with --addr, dump phisical memory\n\t\tregion without trying to understand it's contents");
+	puts("\t--length 0x456 or -l 0x456 -- works only with --addr, dump physical memory\n\t\tregion without trying to understand its contents");
 	puts("\t--help or -h -- this help message");
 	exit(0);
 }
 struct rsdp_descriptor rsdpx;
 int main(int argc, char **argv)
 {
-
 	memset(select_sig, 0, 4);
 	unsigned long addr = 0;
 	unsigned long length = 0;
@@ -637,9 +648,16 @@
 		connect = 1;
 	}
 	psz = sysconf(_SC_PAGESIZE);
-	unsigned long base = (addr) ? addr : ACPI_HI_RSDP_WINDOW_BASE;
+	unsigned long base = 0;
+	if (addr)
+		base = addr;
+	else {
+		read_efi_systab(&base);
+		if (!base)
+			base = ACPI_HI_RSDP_WINDOW_BASE;
+	}
 	unsigned long size =
-	    (addr) ? sizeof(struct rsdp_descriptor) : ACPI_HI_RSDP_WINDOW_SIZE;
+		    (addr) ? sizeof(struct rsdp_descriptor) : ACPI_HI_RSDP_WINDOW_SIZE;
 	size = (length) ? length : size;
 	u8 *raw = acpi_map_memory(base, size);
 	if (!raw)
@@ -670,7 +688,8 @@
 		if (rsdpx.rsdt_physical_address) {
 			if (acpi_dump_RSDT(fd, &rsdpx) == AE_OK)
 				success = 1;
-		if (!success && rsdpx.revision > 1)
+		}
+		if (!success && rsdpx.revision > 1) {
 			if (acpi_dump_XSDT(fd, &rsdpx) == AE_OK)
 				success = 1;
 		}
diff -u -ur pmtools-20050804/acpidump/acpitbl pmtools/acpidump/acpitbl
--- pmtools-20050804/acpidump/acpitbl	2001-07-30 19:04:59.000000000 -0600
+++ pmtools/acpidump/acpitbl	2005-08-16 14:55:26.000000000 -0600
@@ -2,7 +2,7 @@
 #
 # acpitbl - ACPI table dumper
 #
-# Example: ./acpidmp FACP | ./acpitbl
+# Example: ./acpidump -t FACP | ./acpixtract | ./acpitbl
 #
 
 ($ME = $0) =~ s|.*/||;
diff -u -ur pmtools-20050804/acpidump/acpixtract pmtools/acpidump/acpixtract
--- pmtools-20050804/acpidump/acpixtract	2003-12-10 09:50:40.000000000 -0700
+++ pmtools/acpidump/acpixtract	2005-08-16 14:31:09.000000000 -0600
@@ -1,6 +1,6 @@
 #!/usr/bin/perl
 #
-# acpixtract - extract raw table from acpidmp output
+# acpixtract - extract raw table from acpidump output
 #
 # Example: cat mail.txt | ./acpixtract DSDT > DSDT
 # iasl -d DSDT


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: RE: acpidump replaces acpidmp

[Voluspa]

On Tue, 16 Aug 2005 15:32:34 -0600 Bjorn Helgaas wrote:
> On Tuesday 16 August 2005 12:23 pm, Brown, Len wrote:
> > Mats,
> > Does the latest acpidump work for you now?
> > can we obsolete /proc/acpi/fadt,dsdt?
> 
> pmtools-20050804 doesn't work at all on ia64, because
> the RSDP doesn't live where you expect it.  We export
> /sys/firmware/efi/systab with the addresses you want.
> 
> The attached patch adds this, fixes a bunch of

./acpidump -t DSDT | ./acpixtract > DSDT
or
./acpidump -b -t DSDT > DSDT

show no difference to /proc/acpi/dsdt in
pmtools-20050804 both with and without Bjorns patch.

And I guess /proc/acpi/fadt shouldn't be exactly as
./acpidump -b -t FACP > FACP 'cos it's not.

So, it's working on my end.

Mvh
Mats Johannesson
--


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: RE: acpidump replaces acpidmp

[Len Brown]

On Tue, 2005-08-16 at 17:32 -0400, Bjorn Helgaas wrote:
> On Tuesday 16 August 2005 12:23 pm, Brown, Len wrote:
> > Mats,
> > Does the latest acpidump work for you now?
> > can we obsolete /proc/acpi/fadt,dsdt?
> 
> pmtools-20050804 doesn't work at all on ia64, because
> the RSDP doesn't live where you expect it.  We export
> /sys/firmware/efi/systab with the addresses you want.
> 
> The attached patch adds this, fixes a bunch of
> documentation errors, and fixes some broken if/else
> blocking.  There are still a number of warnings when
> building on ia64; I didn't bother to fix those, sorry.

Thanks Bjorn.
Alexey included your patch in pmtools-20050823,
and has now tested the latest on IA64 systems with
and without /sys/firmware/efi.

http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools-20050823.tar.gz

cheers,
-Len




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf