Date: Fri, 12 Jun 2009 18:34:27 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: freebsd-acpi@FreeBSD.org Cc: "Moore, Robert" <robert.moore@intel.com> Subject: Re: [PATCH] acpidump: teach to disassemble arbitrary memory locations as AML code Message-ID: <200906121834.30294.jkim@FreeBSD.org> In-Reply-To: <4911F71203A09E4D9981D27F9D8308582E6840C8@orsmsx503.amr.corp.intel.com> References: <W6QSpRPwDx1bM%2BckKMKVCUsLU5A@XX1fo6zQUfC4h0jjRC6IBz3oNH4> <4A32CA38.4020806@root.org> <4911F71203A09E4D9981D27F9D8308582E6840C8@orsmsx503.amr.corp.intel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 12 June 2009 06:02 pm, Moore, Robert wrote: > Actually, we don't distribute an acpidump (yet) in ACPICA. The > Linux version is part of the "pmtools" package. > > It is of course, linux-specific. I won't distribute it with ACPICA > until we have an OS-independent version. It is on our list of > things to-do. FYI, it won't be terribly hard to port it because we also use /dev/mem. However, the source is acpisrc'ified and we cannot undo it to make it compile on FreeBSD. :-( Jung-uk Kim > The formatting code is rather simple, but it would be best to have > one instance of the code, part of acpica. > > It would go like this: > > Get rsdt/xsdt -> call to OSL > For all tables: > Get acpi table -> call to OSL > Dump the table > > >-----Original Message----- > >From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- > >acpi@freebsd.org] On Behalf Of Nate Lawson > >Sent: Friday, June 12, 2009 2:36 PM > >To: Eygene Ryabinkin > >Cc: freebsd-acpi@freebsd.org > >Subject: Re: [PATCH] acpidump: teach to disassemble arbitrary > > memory locations as AML code > > > >Eygene Ryabinkin wrote: > >> It is not uncommon when some chunks of the AML code are loaded > >> by DSDT from the memory locations that aren't part of the DSDT > >> itself, but one wants to see what's inside. It can be achieved > >> with 'dd' and 'iasl', but it is better to implement this > >> machinery inside acpidump to ease the life of both users and > >> develepers that needs to see the full picture of the ACPI stuff > >> from foreign machines. > >> > >> This commit also have some small fixes: > >> > >> - verbose output (going to stderr) isn't mixed with normal > >> output that goes to stdout -- the latter is made unbuffered; > >> > >> - we're using IASL's logics to get the name of the output file > >> and, moreover, we prevent two simultaneous invocations of > >> acpidump to hose other's output; > >> > >> - IASL exit code is checked and if disassembler exited > >> abnormally or was failed to do its job, the warning is produced > >> to give the reader an idea on what's going on. > >> > >> Signed-off-by: Eygene Ryabinkin <rea-fbsd@codelabs.ru> > > > >I appreciate your work. What we need to do though is remove > > acpidump(8) from the system and import Intel's acpidmp utility. > > It's included in the ACPI-CA distribution and is functional > > enough that we can use it. > > > >Any functions we need that it doesn't yet have can be submitted to > > Intel to merge. > > > >Thanks, > >-- > >Nate > >_______________________________________________ > >freebsd-acpi@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > >To unsubscribe, send any mail to > > "freebsd-acpi-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to > "freebsd-acpi-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200906121834.30294.jkim>