From nobody Wed May 19 17:35:52 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 0B2908B7D89 for ; Wed, 19 May 2021 17:35:56 +0000 (UTC) (envelope-from junguk.kim@gmail.com) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Flg576F56z4cgH for ; Wed, 19 May 2021 17:35:55 +0000 (UTC) (envelope-from junguk.kim@gmail.com) Received: by mail-qk1-x736.google.com with SMTP id c20so13538915qkm.3 for ; Wed, 19 May 2021 10:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:references:from:subject:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FWz1UajC6DH5dDXMGhZNNwmsw5EnGwqqHfiugaGc2VM=; b=HF9hHE2nHsefCR+dAM50Cos6yzalxjjEf7nbMQqYq9S4ES3zaLDIu8l4z6uCyC9cXt rPSx0ndERCx+hzxZ+GAyIcOKp9M8bC5ooBbNb9ioxbJ7uONzfAe5wChFecZngbdzz7iN zxuV8SwZ0dL2oOvwa2raPZnJ6XlOet54rXuqxBc8ta1vJ6R1D7O8U/kMr0FZxp8Q/mPX SUfEj0N91rmtom4X1l8v6dtYehgDup7RfZ9849RvNwsbMrGxwsDWmzrnA4UteG0urNKI I7zXWwwOi4bCWX0raSuw6FCWuopS5MksvvXU7MmG0/xaYpK5AD7C7sWvJJkrxmQMKm6U 6VGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FWz1UajC6DH5dDXMGhZNNwmsw5EnGwqqHfiugaGc2VM=; b=p58cZ8e7ZaAxQbaSM1G/Xaw966MJHPo4UXnaXiZu0/Hx0SLbs+igohmJzRVjoVn+y2 eshoKAojaRtXyQCWk/qv6rVBFOjo6hQq1Er74P7xmZiS2MU5tFQmB1AEpebzLujhuD78 OgwUBdnlMAKuarYyjAGkr8/WhitSQKC22PD9rLR8tsH25B+bwnquvbrDWv7GUMHxiNFk VuUGaczSXQ2Nuu3ZF79g1OnsIEfylEezhY75Re1NPS/rzsLkHI9vEM/GtF0K9X29hZCJ VUCeB7efvUAicO19OBzl0VNv1eS+PAmo8UZ9TBq/9264gT6YvMh6a3nI2aTSc5CBRSXi 1sKA== X-Gm-Message-State: AOAM530ELh41DdKyQOi6UH99L71oz+qtkujP/PCHMPCI9zdS0XieC2Pg uvJQV3oCxnAB+hdtRtiQHnGlMcxR9cegMQ== X-Google-Smtp-Source: ABdhPJxLaqi98SfS2D78A11f8x9VJaDv2OHLm+Ac82RadGpk8vU6fNXGXT9rjDA/mWh1CVbEybETZA== X-Received: by 2002:a37:638e:: with SMTP id x136mr502462qkb.109.1621445754423; Wed, 19 May 2021 10:35:54 -0700 (PDT) Received: from hammer.mj.niksun.com (pool-100-8-53-238.nwrknj.fios.verizon.net. [100.8.53.238]) by smtp.gmail.com with ESMTPSA id k10sm50362qtm.73.2021.05.19.10.35.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 May 2021 10:35:53 -0700 (PDT) To: John Nielsen Cc: "freebsd-acpi@freebsd.org" References: <6e1f13bd-dc8f-6b30-2b62-2841deea8781@gmail.com> From: Jung-uk Kim Subject: Re: How to properly locate/parse ACPI table from kernel module? Message-ID: <9f50a0af-9d33-cbdb-7458-a8ffcbabb0be@gmail.com> Date: Wed, 19 May 2021 13:35:52 -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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Flg576F56z4cgH X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_FROM(0.00)[]; REPLY(-4.00)[] 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’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