From nobody Thu May 20 03:41:56 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 EACFA8BB164 for ; Thu, 20 May 2021 03:42:01 +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 4FlwXT5Csxz4ZJ9; Thu, 20 May 2021 03:42:01 +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 14K3fudS007008 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 19 May 2021 21:41:59 -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] From: John Nielsen Message-Id: <291E1068-2F9A-4C6B-B7F7-D47B112A2BE5@jnielsen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_CA23D759-B102-45E6-AA8F-5B26F2CA9D0F" 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? Date: Wed, 19 May 2021 21:41:56 -0600 In-Reply-To: Cc: "freebsd-acpi@freebsd.org" To: Jung-uk Kim References: <6e1f13bd-dc8f-6b30-2b62-2841deea8781@gmail.com> <9f50a0af-9d33-cbdb-7458-a8ffcbabb0be@gmail.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4FlwXT5Csxz4ZJ9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes --Apple-Mail=_CA23D759-B102-45E6-AA8F-5B26F2CA9D0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 19, 2021, at 12:21 PM, Jung-uk Kim wrote: >=20 > On 21. 5. 19., Jung-uk Kim wrote: >> On 21. 5. 19., John Nielsen wrote: >>>> 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); >>>=20 >>> Thank you (and Andriy) for your responses. Good to know that = ACPI_SIG_IBFT is already defined in the upstream headers. >>=20 >> It seems there are two methods. >>=20 >> = ftp://ftp.software.ibm.com/systems/support/bladecenter/iscsi_boot_firmware= _table_v1.03.pdf >>=20 >> 1.4.3.1 Locating the iBFT >>=20 >> The iBFT is located by the following methods. A platform shall = implement >> one or more of these methods. >>=20 >> 1. The ACPI Method. The iBFT is pointed to by an entry in the = RSDT/XSDT. >> Note that ACPI [ACPI=3D3.0b] specifies the string in the pointer as >> =E2=80=9CIBFT=E2=80=9D (all upper case) HOWEVER the signature in the = table being pointed >> to is=E2=80=9CiBFT=E2=80=9D (note the mixed case). >>=20 >> 2. The Low RAM Method. Scan for the table header signature in system >> memory between 512K and 1024K. The scan MUST be done starting at >> the lower address scanning forward to the higher address. When using = the >> Low RAM Method the table header must be aligned on a 16-byte >> boundary. >>=20 >> Note: A system operating in UEFI mode shall utilize only the ACPI = method. >>=20 >> For modern system, it seems you should be using Method 1. I don't >> understand the "HOWEVER" part, though. >=20 > I did little more research. It seems iSCSI spec. predates ACPI > standardization and IBM kept on using "iBFT" instead of ACPI spec. > "IBFT". Because this confusion, some systems use "iBFT" and some use > "IBFT". Therefore, it seems you need to test both, e.g., >=20 > status =3D AcpiGetTable(ACPI_SIG_IBFT, 0, &ibft); > if (ACPI_FAILURE(status)) > status =3D AcpiGetTable("iBFT", 0, &ibft); Very helpful once again, thank you. My test machine (either the = motherboard or the NIC) has a buggy BIOS that prevents it from booting = in legacy mode with iSCSI so I=E2=80=99m using UEFI whether I wanted to = or not. I=E2=80=99m glad that my theory that the Low RAM Method might = not work in UEFI has some merit. I did notice that Linux looks for both iBFT and IBFT in its driver; the = existence of two standards is alluded to in the comments but it=E2=80=99s = nice to know what they are. I=E2=80=99ll adopt your suggested approach. JN --Apple-Mail=_CA23D759-B102-45E6-AA8F-5B26F2CA9D0F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = May 19, 2021, at 12:21 PM, Jung-uk Kim <jkim@freebsd.org> = wrote:

On 21. 5. 19., Jung-uk Kim wrote:
On = 21. 5. 19., John Nielsen wrote:
On May 17, 2021, at 2:27 = PM, Jung-uk Kim <junguk.kim@gmail.com> wrote:

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.

I=E2=80=99m not the original author but as the = port maintainer I am hosting the code here: https://github.com/jnielsendotnet/isboot

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.

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?

You may use = AcpiGetTable() and AcpiPutTable(), e.g.,

= 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.

It seems = there are two methods.

ftp://ftp.software.ibm.com/systems/support/bladecenter/iscsi_bo= ot_firmware_table_v1.03.pdf

1.4.3.1 = Locating the iBFT

The iBFT is located by = the following methods. A platform shall implement
one or = more of these methods.

1. The ACPI Method. = The iBFT is pointed to by an entry in the RSDT/XSDT.
Note = that ACPI [ACPI=3D3.0b] specifies the string in the pointer as
=E2=80=9CIBFT=E2=80=9D (all upper case) HOWEVER the signature = in the table being pointed
to is=E2=80=9CiBFT=E2=80=9D = (note the mixed case).

2. The Low RAM = Method. Scan for the table header signature in system
memory= between 512K and 1024K. The scan MUST be done starting at
the lower address scanning forward to the higher address. = When using the
Low RAM Method the table header must be = aligned on a 16-byte
boundary.

Note: A system operating in UEFI mode shall utilize only the = ACPI method.

For modern system, it seems = you should be using Method 1.  I don't
understand the = "HOWEVER" part, though.

I did little more research. =  It seems iSCSI spec. predates ACPI
standardization and IBM kept on using "iBFT" instead of ACPI = spec.
"IBFT". =  Because this confusion, some systems use "iBFT" and some = use
"IBFT". =  Therefore, it seems you need to test both, e.g.,

status =3D = AcpiGetTable(ACPI_SIG_IBFT, 0, &ibft);
= if = (ACPI_FAILURE(status))
= status =3D = AcpiGetTable("iBFT", 0, &ibft);

Very helpful once again, thank you. My test = machine (either the motherboard or the NIC) has a buggy BIOS that = prevents it from booting in legacy mode with iSCSI so I=E2=80=99m using = UEFI whether I wanted to or not. I=E2=80=99m glad that my theory that = the Low RAM Method might not work in UEFI has some merit.

I did notice that Linux = looks for both iBFT and IBFT in its driver; the existence of two = standards is alluded to in the comments but it=E2=80=99s nice to know = what they are. I=E2=80=99ll adopt your suggested approach.

JN

= --Apple-Mail=_CA23D759-B102-45E6-AA8F-5B26F2CA9D0F--