From nobody Thu May 20 18:30:54 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 6B6168BC90A for ; Thu, 20 May 2021 18:31:04 +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 4FmJGH3Nmvz3k1p; Thu, 20 May 2021 18:31:03 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from [192.168.2.189] (stealth.jnielsen.net [68.69.164.122]) (authenticated bits=0) by webmail5.jnielsen.net (8.15.2/8.15.2) with ESMTPSA id 14KIUsqa022513 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 20 May 2021 12:30:56 -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.189] From: John Nielsen Message-Id: <71CC21D4-897E-4BBB-8D6E-64F055630271@jnielsen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_51E09579-15FE-4A20-82B9-B655B96F99F6" 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: Thu, 20 May 2021 12:30:54 -0600 In-Reply-To: <291E1068-2F9A-4C6B-B7F7-D47B112A2BE5@jnielsen.net> Cc: "freebsd-acpi@freebsd.org" To: Jung-uk Kim References: <6e1f13bd-dc8f-6b30-2b62-2841deea8781@gmail.com> <9f50a0af-9d33-cbdb-7458-a8ffcbabb0be@gmail.com> <291E1068-2F9A-4C6B-B7F7-D47B112A2BE5@jnielsen.net> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4FmJGH3Nmvz3k1p X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of lists@jnielsen.net designates 69.87.218.172 as permitted sender) smtp.mailfrom=lists@jnielsen.net X-Spamd-Result: default: False [-1.78 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+a:mailers.freebsdsolutions.net]; HAS_XAW(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:6364, ipnet:69.87.218.0/24, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.87.218.172:from]; NEURAL_HAM_MEDIUM(-0.98)[-0.977]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[jnielsen.net]; SPAMHAUS_ZRD(0.00)[69.87.218.172:from:127.0.2.255]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-acpi] X-Spam: Yes --Apple-Mail=_51E09579-15FE-4A20-82B9-B655B96F99F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 19, 2021, at 9:41 PM, John Nielsen wrote: >=20 >> 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); >=20 > 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. >=20 > 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=99= s nice to know what they are. I=E2=80=99ll adopt your suggested = approach. In case anyone is actually following along at home, here=E2=80=99s what = I have so far: = https://github.com/jnielsendotnet/isboot/commit/255a01102c345347dece1ed15b= d8675fe3dd1dd9 Which not only compiles but also finds (and is able to correctly decode) = the iBFT on my test system. Hooray! Comments on the patch welcome. Otherwise I=E2=80=99ll move on to the = next issue=E2=80=A6 Thank you again for the help thus far. JN --Apple-Mail=_51E09579-15FE-4A20-82B9-B655B96F99F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = May 19, 2021, at 9:41 PM, John Nielsen <lists@jnielsen.net> = wrote:

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.

In = case anyone is actually following along at home, here=E2=80=99s what I = have so far:
https://github.com/jnielsendotnet/isboot/commit/255a01102c34534= 7dece1ed15bd8675fe3dd1dd9

Which not only compiles but also finds (and is able to = correctly decode) the iBFT on my test system. Hooray!

Comments on the patch = welcome. Otherwise I=E2=80=99ll move on to the next issue=E2=80=A6

Thank you again for = the help thus far.

JN

= --Apple-Mail=_51E09579-15FE-4A20-82B9-B655B96F99F6--