Date: Wed, 19 May 2021 13:35:52 -0400 From: Jung-uk Kim <junguk.kim@gmail.com> 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: <9f50a0af-9d33-cbdb-7458-a8ffcbabb0be@gmail.com> In-Reply-To: <A63CF8E2-F185-495A-99C1-421781356D8B@jnielsen.net> References: <BCFCDCE9-F169-4C1C-AD0C-FDE511C0BC11@jnielsen.net> <6e1f13bd-dc8f-6b30-2b62-2841deea8781@gmail.com> <A63CF8E2-F185-495A-99C1-421781356D8B@jnielsen.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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’m not much of a kernel programmer but I’m 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’m 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’m 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 “iBFT”, which if it finds will be used as the offset for reading the table. I don’t 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 = AcpiGetTable(ACPI_SIG_IBFT, …); > > 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_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=3.0b] specifies the string in the pointer as “IBFT” (all upper case) HOWEVER the signature in the table being pointed to is“iBFT” (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. > What is the second argument (“Instance”) of AcpiGetTable()? Is it just an offset in case there are multiple instances of a given table type? Yes. https://acpica.org/sites/acpica/files/acpica-reference_18.pdf 8.2.9 AcpiGetTable Instance Which table instance, if multiple instances of the table are allowed (SSDTor UEFI). One based (1...n). This document is little out-dated, though. > Also, when/why should AcpiPutTable() be used? To free the table after use. Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9f50a0af-9d33-cbdb-7458-a8ffcbabb0be>