Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 17 Jun 2009 16:21:06 -0400
From:      Jung-uk Kim <jkim@FreeBSD.org>
To:        "Moore, Robert" <robert.moore@intel.com>
Cc:        freebsd-acpi@FreeBSD.org
Subject:   Re: [PATCH] acpidump: teach to disassemble arbitrary memory locations as AML code
Message-ID:  <200906171621.13512.jkim@FreeBSD.org>
In-Reply-To: <4911F71203A09E4D9981D27F9D8308582E76D616@orsmsx503.amr.corp.intel.com>
References:  <W6QSpRPwDx1bM%2BckKMKVCUsLU5A@XX1fo6zQUfC4h0jjRC6IBz3oNH4> <200906171442.34101.jkim@FreeBSD.org> <4911F71203A09E4D9981D27F9D8308582E76D616@orsmsx503.amr.corp.intel.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 17 June 2009 03:52 pm, Moore, Robert wrote:
> I think that I was thinking that the ReadMemory interface was too
> low-level. Basically, I wanted an interface to "get me table XXXX,
> I don't care where you got it from."

AFAICT, that interface will cover "--table <SIG> (-t <SIG>)" option 
but we also need to support "--addr <ADDR> (-a <ADDR>)".  Actually, 
that's where we started. :-)

> This might be useful on systems where something like /dev/mem is
> not available, and the ACPI tables are available via some other
> mechanism.

So, you want AcpiTbFindTable()-like OSL interface, correct?

Jung-uk Kim

> >-----Original Message-----
> >From: Jung-uk Kim [mailto:jkim@FreeBSD.org]
> >Sent: Wednesday, June 17, 2009 11:43 AM
> >To: Moore, Robert
> >Cc: rea-fbsd@codelabs.ru; Nate Lawson; freebsd-acpi@FreeBSD.org
> >Subject: Re: [PATCH] acpidump: teach to disassemble arbitrary
> > memory locations as AML code
> >
> >On Wednesday 17 June 2009 02:09 pm, Moore, Robert wrote:
> >> I should point out that acpidump was never "linuxed", it was
> >> simply written as native Linux code.
> >
> >I was afraid of that. :-(
> >
> >IIRC, you once said (on ACPICA devel ML), you may include it in
> > the ACPICA distribution if "read foo table from memory" code
> > moves to OSL interface.  AFAICT, the OSL interface already
> > exists, i.e., AcpiOsReadMemory().  Last time I checked, acpidump
> > from pmtools was just reading it via /dev/mem instead of using
> > the OSL interface, though.
> >
> >FYI...
> >
> >Jung-uk Kim
> >
> >> >-----Original Message-----
> >> >From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd-
> >> >acpi@freebsd.org] On Behalf Of Moore, Robert
> >> >Sent: Wednesday, June 17, 2009 10:06 AM
> >> >To: rea-fbsd@codelabs.ru; Nate Lawson; Jung-uk Kim
> >> >Cc: freebsd-acpi@freebsd.org
> >> >Subject: RE: [PATCH] acpidump: teach to disassemble arbitrary
> >> > memory locations as AML code
> >> >
> >> >The raw ACPICA source code is run through a converter (acpisrc)
> >> > to "linuxize" the code before it is integrated into Linux.
> >> >
> >> >>-----Original Message-----
> >> >>From: rea-fbsd@codelabs.ru [mailto:rea-fbsd@codelabs.ru]
> >> >>Sent: Tuesday, June 16, 2009 11:11 PM
> >> >>To: Nate Lawson; Jung-uk Kim
> >> >>Cc: freebsd-acpi@freebsd.org; Moore, Robert
> >> >>Subject: Re: [PATCH] acpidump: teach to disassemble arbitrary
> >> >> memory locations as AML code
> >> >>
> >> >>Nate, Jung-uk, good day.
> >> >>
> >> >>Fri, Jun 12, 2009 at 02:35:52PM -0700, Nate Lawson wrote:
> >> >>> 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.
> >> >>
> >> >>OK, I'll try to take a look at it.  But this is a future work;
> >> >>meanwhile, can we still extend acpidump in a way I propose.  I
> >> >> have the updated patch that applies on top of the -CURRENT
> >> >> tree after the recent ACPICA import, but I have some troubles
> >> >> with 'make depend' inside usr.sbin/acpi/acpidb, so once I'll
> >> >> resolve them and test the stuff with full buildworld -- I'll
> >> >> post the patch as an update.
> >> >>
> >> >>Fri, Jun 12, 2009 at 06:34:27PM -0400, Jung-uk Kim wrote:
> >> >>> 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. :-(
> >> >>
> >> >>Haven't looked at the source yet, so probably the question is
> >> >> very dumb, but nevertheless: what do you mean by
> >> >> "acpisrc'ified"?
> >> >>
> >> >>And a general question: is there a VCS repository for the
> >> >> pmtools, or at least the download location with
> >> >> snapshots/releases?  My Google-fu fails on this and
> >> >> moblin.org doesn't seem to have this stuff available.
> >> >>
> >> >>Thanks!
> >> >>--
> >> >>Eygene
> >> >> _                ___       _.--.   #
> >> >> \`.|\..----...-'`   `-._.-'_.-'`   #  Remember that it is
> >> >> hard /  ' `         ,       __.--'      #  to read the
> >> >> on-line manual )/' _/     \   `-_,   /            #  while
> >> >> single-stepping the kernel. `-'" `"\_  ,_.-;_.-\_ ',  fsc/as 
> >> >>  #
> >> >>     _.-'_./   {_.'   ; /           #    -- FreeBSD Developers
> >> >> handbook {_.-``-'         {_/            #
> >> >
> >> >_______________________________________________
> >> >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?200906171621.13512.jkim>