Date: Thu, 20 May 2021 14:45:22 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: John Nielsen <lists@jnielsen.net> Cc: "freebsd-acpi@freebsd.org" <freebsd-acpi@FreeBSD.org> Subject: Re: How to properly locate/parse ACPI table from kernel module? Message-ID: <11e31efe-5d4f-6ad3-c78d-94155d0e0c01@FreeBSD.org> In-Reply-To: <71CC21D4-897E-4BBB-8D6E-64F055630271@jnielsen.net> References: <BCFCDCE9-F169-4C1C-AD0C-FDE511C0BC11@jnielsen.net> <6e1f13bd-dc8f-6b30-2b62-2841deea8781@gmail.com> <A63CF8E2-F185-495A-99C1-421781356D8B@jnielsen.net> <9f50a0af-9d33-cbdb-7458-a8ffcbabb0be@gmail.com> <f960181c-7c23-f4a1-2754-5be14bba5991@FreeBSD.org> <291E1068-2F9A-4C6B-B7F7-D47B112A2BE5@jnielsen.net> <71CC21D4-897E-4BBB-8D6E-64F055630271@jnielsen.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jkim@FreeBSD.org> To: John Nielsen <lists@jnielsen.net> Cc: "freebsd-acpi@freebsd.org" <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: <BCFCDCE9-F169-4C1C-AD0C-FDE511C0BC11@jnielsen.net> <6e1f13bd-dc8f-6b30-2b62-2841deea8781@gmail.com> <A63CF8E2-F185-495A-99C1-421781356D8B@jnielsen.net> <9f50a0af-9d33-cbdb-7458-a8ffcbabb0be@gmail.com> <f960181c-7c23-f4a1-2754-5be14bba5991@FreeBSD.org> <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 <lists@jnielsen.net >> <mailto:lists@jnielsen.net>> wrote: >> >>> On May 19, 2021, at 12:21 PM, Jung-uk Kim <jkim@freebsd.org >>> <mailto: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 >>>>>> <mailto: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 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 >>>>>>> <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 >>>>>>> <https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.h#= L37> >>>>>>> and >>>>>>> https://github.com/jnielsendotnet/isboot/blob/master/src/ibft.c#L= 521 >>>>>>> <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 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 >>>> <ftp://ftp.software.ibm.com/systems/support/bladecenter/iscsi_boot_f= irmware_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 > <https://github.com/jnielsendotnet/isboot/commit/255a01102c345347dece1e= d15bd8675fe3dd1dd9> >=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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?11e31efe-5d4f-6ad3-c78d-94155d0e0c01>