From nobody Thu May 20 18:45:22 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 9A6E58C5C74 for ; Thu, 20 May 2021 18:45:29 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FmJZx3hhZz3qX9; Thu, 20 May 2021 18:45:29 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (pool-100-8-53-238.nwrknj.fios.verizon.net [100.8.53.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jkim/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 58C722BD1C; Thu, 20 May 2021 18:45:29 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: How to properly locate/parse ACPI table from kernel module? To: John Nielsen Cc: "freebsd-acpi@freebsd.org" References: <6e1f13bd-dc8f-6b30-2b62-2841deea8781@gmail.com> <9f50a0af-9d33-cbdb-7458-a8ffcbabb0be@gmail.com> <291E1068-2F9A-4C6B-B7F7-D47B112A2BE5@jnielsen.net> <71CC21D4-897E-4BBB-8D6E-64F055630271@jnielsen.net> From: Jung-uk Kim Organization: FreeBSD.org Message-ID: <11e31efe-5d4f-6ad3-c78d-94155d0e0c01@FreeBSD.org> Date: Thu, 20 May 2021 14:45:22 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 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 In-Reply-To: <71CC21D4-897E-4BBB-8D6E-64F055630271@jnielsen.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5rHCiLh9Z6MotwDOow71cO7msenb9LjYs" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5rHCiLh9Z6MotwDOow71cO7msenb9LjYs Content-Type: multipart/mixed; boundary="NanaW2UoaYP03tVTssiyo8LuFQ6pLiunF"; protected-headers="v1" From: Jung-uk Kim To: John Nielsen Cc: "freebsd-acpi@freebsd.org" Message-ID: <11e31efe-5d4f-6ad3-c78d-94155d0e0c01@FreeBSD.org> Subject: Re: How to properly locate/parse ACPI table from kernel module? References: <6e1f13bd-dc8f-6b30-2b62-2841deea8781@gmail.com> <9f50a0af-9d33-cbdb-7458-a8ffcbabb0be@gmail.com> <291E1068-2F9A-4C6B-B7F7-D47B112A2BE5@jnielsen.net> <71CC21D4-897E-4BBB-8D6E-64F055630271@jnielsen.net> In-Reply-To: <71CC21D4-897E-4BBB-8D6E-64F055630271@jnielsen.net> --NanaW2UoaYP03tVTssiyo8LuFQ6pLiunF Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 21. 5. 20., John Nielsen wrote: >> On May 19, 2021, at 9:41 PM, John Nielsen > > wrote: >> >>> On May 19, 2021, at 12:21 PM, Jung-uk Kim >> > 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 >>>>> > wrote: >>>>>> >>>>>> On 21. 5. 17., John Nielsen wrote: >>>>>>> I=E2=80=99m not much of a kernel programmer but I=E2=80=99m tryin= g 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 r= oot. >>>>>>> >>>>>>> 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#L= 37 >>>>>>> >>>>>>> and >>>>>>> https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.c#L= 521 >>>>>>> ), >>>>>>> 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 val= ues 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_boot_fi= rmware_table_v1.03.pdf >>>> >>>> >>>> 1.4.3.1 Locating the iBFT >>>> >>>> The iBFT is located by the following methods. A platform shall imple= ment >>>> one or more of these methods. >>>> >>>> 1. The ACPI Method. The iBFT is pointed to by an entry in the RSDT/X= SDT. >>>> 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. =C2=A0I do= n't >>>> understand the "HOWEVER" part, though. >>> >>> I did little more research. =C2=A0It seems iSCSI spec. predates ACPI >>> standardization and IBM kept on using "iBFT" instead of ACPI spec. >>> "IBFT". =C2=A0Because this confusion, some systems use "iBFT" and som= e use >>> "IBFT". =C2=A0Therefore, 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 t= o 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= =2E >=20 > In case anyone is actually following along at home, here=E2=80=99s what= I have > so far: > https://github.com/jnielsendotnet/isboot/commit/255a01102c345347dece1ed= 15bd8675fe3dd1dd9 > >=20 > Which not only compiles but also finds (and is able to correctly decode= ) > the iBFT on my test system. Hooray! Good to hear it. > Comments on the patch welcome. Otherwise I=E2=80=99ll move on to the ne= xt issue=E2=80=A6 You don't need to define USE_ACPI. It should be spelled "DEV_ACPI", e.g.= , #ifndef DEV_ACPI > Thank you again for the help thus far. Glad to help. Jung-uk Kim --NanaW2UoaYP03tVTssiyo8LuFQ6pLiunF-- --5rHCiLh9Z6MotwDOow71cO7msenb9LjYs Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAmCmrkIFAwAAAAAACgkQfJ+WJvzb8UZy Mgf/WQa4THlBCXO2VyFmUzYQpr89hTQLQ/qaHw5dlSy/QxA5Iv/DSRHqVreL58Xi03o5ZQvdmloy UPODuv/N0Dug5Hh8mIJb9VvNEoj8SScqUbWugX2k86aZLFxbqCKMdIbhN4QOz8v4VyKx86/cjYoI F61GURht9HBiMb+PTMfWh+eQ5hSXyd8la4+qb6DprpAsIRNVxd1BJnfvjWimSCuEy1faNfli/PQE +7Se3rZtRnFg8KBNPjlxyfWwHUywDziiQTke/O2Qqqd5TtnA7QT1eF/pfOws/l3NuF5+KYUuLuif DAIV5xmeISNzlwsj728FrTWsQBJ4s5EETQtHFc54eg== =SEiW -----END PGP SIGNATURE----- --5rHCiLh9Z6MotwDOow71cO7msenb9LjYs--