From nobody Wed May 19 17:10:08 2021 X-Original-To: freebsd-acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7FDD28C280F for ; Wed, 19 May 2021 17:10:20 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from webmail5.jnielsen.net (webmail5.jnielsen.net [69.87.218.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.freebsdsolutions.net", Issuer "freebsdsolutions.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FlfWb4xBpz3sLc for ; Wed, 19 May 2021 17:10:19 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from [192.168.2.191] (stealth.jnielsen.net [68.69.164.122]) (authenticated bits=0) by webmail5.jnielsen.net (8.15.2/8.15.2) with ESMTPSA id 14JHAAw6093124 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 19 May 2021 11:10:12 -0600 (MDT) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail5.jnielsen.net: Host stealth.jnielsen.net [68.69.164.122] claimed to be [192.168.2.191] Content-Type: text/plain; charset=utf-8 List-Id: ACPI and power management development List-Archive: http://lists.freebsd.org/acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: How to properly locate/parse ACPI table from kernel module? From: John Nielsen In-Reply-To: <6e1f13bd-dc8f-6b30-2b62-2841deea8781@gmail.com> Date: Wed, 19 May 2021 11:10:08 -0600 Cc: "freebsd-acpi@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <6e1f13bd-dc8f-6b30-2b62-2841deea8781@gmail.com> To: Jung-uk Kim X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4FlfWb4xBpz3sLc X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of lists@jnielsen.net designates 69.87.218.172 as permitted sender) smtp.mailfrom=lists@jnielsen.net X-Spamd-Result: default: False [-1.45 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; HAS_XAW(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.87.218.172:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:6364, ipnet:69.87.218.0/24, country:US]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.66)[-0.655]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[jnielsen.net]; SPAMHAUS_ZRD(0.00)[69.87.218.172:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-acpi] > On May 17, 2021, at 2:27 PM, Jung-uk Kim wrote: >=20 > On 21. 5. 17., John Nielsen wrote: >> I=E2=80=99m not much of a kernel programmer but I=E2=80=99m trying to = maintain/improve the isboot module, which allows booting directly from = iSCSI by reading the iSCSI Boot Firmware Table (iBFT), bringing up the = interface with the details specified therein and connecting to the = specified iSCSI target before trying to mount root. >>=20 >> I=E2=80=99m not the original author but as the port maintainer I am = hosting the code here: https://github.com/jnielsendotnet/isboot >>=20 >> I have a test system where the module loads but fails to find the = iBFT. I reviewed the iBFT code and realized it has a bunch of magic = numbers mixed in with some random memory diving. If I=E2=80=99m reading = it right (see = https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.h#L37 and = https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.c#L521), = it looks like it scans all of the (kernel?) memory between 512K and 1M = in 16-byte increments looking for one beginning with the string = =E2=80=9CiBFT=E2=80=9D, which if it finds will be used as the offset for = reading the table. I don=E2=80=99t know where the 512K and 1M values = came from or if they are correct, but I do have a system where that = method does not work. >>=20 >> IIUC, the iBFT is an ACPI table, and it seems like using ACPI to find = it would be safer and more reliable. So my question is: how does one do = that? Are there other places in the kernel code that do this sort of = thing that I could use as a model? Any gotchas I should know about as a = (less-than) novice kernel programmer? >=20 > You may use AcpiGetTable() and AcpiPutTable(), e.g., >=20 > status =3D AcpiGetTable(ACPI_SIG_IBFT, =E2=80=A6); Thank you (and Andriy) for your responses. Good to know that = ACPI_SIG_IBFT is already defined in the upstream headers. What is the second argument (=E2=80=9CInstance=E2=80=9D) of = AcpiGetTable()? Is it just an offset in case there are multiple = instances of a given table type? Also, when/why should AcpiPutTable() be used? Thanks! JN