From mboxrd@z Thu Jan 1 00:00:00 1970 From: jhugo@codeaurora.org (Jeffrey Hugo) Date: Tue, 7 Feb 2017 12:07:56 -0700 Subject: [PATCH] efi/libstub/arm*: Set default address and size cells values for an empty dtb In-Reply-To: <20170207190113.GG26173@leverpostej> References: <1486490390-25251-1-git-send-email-jhugo@codeaurora.org> <1f47fcdd-c5d8-4082-70a3-ca9b1746d7ca@codeaurora.org> <20170207190113.GG26173@leverpostej> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 2/7/2017 12:01 PM, Mark Rutland wrote: > On Tue, Feb 07, 2017 at 11:54:55AM -0700, Jeffrey Hugo wrote: >> On 2/7/2017 11:12 AM, Ard Biesheuvel wrote: >>> On 7 February 2017 at 17:59, Jeffrey Hugo wrote: >>>> From: Sameer Goel >>>> >>>> In cases where a device tree is not provided (ie ACPI based system), an >>>> empty fdt is generated by efistub. Sets the address and size cell values >>>> in a generated fdt to support 64 bit addressing. >>>> >>>> This enables kexec/kdump on Qualcomm Technologies QDF24XX platforms as those >>>> utilities will read the address/size values from the fdt, and such values >>>> may exceed the range provided by the 32 bit default. >>>> >>> >>> As far as I know, those properties are explicitly associated with the >>> 'reg' properties of subordinate nodes. So which nodes are we talking >>> about here? Are we producing an incorrect DT by not setting these? Or >>> is this simply a convenience to work around bugs in the tooling? >> >> I think we are producing an incorrect DT, in some instances. >> >> So we are starting from the same baseline, this is specific to ACPI >> systems, as an ACPI system won't have a DT from the bootloader. DT >> based systems will already have a DT from the bootloader which is >> assumed to be correct. On ACPI systems without a DT, efistub >> generates a default one. >> >> That default is assumed to be for a 32-bit system. The cell width >> defaults to 1, which is 4 bytes. You cannot represent a 64-bit >> value in that instance. >> >> What happens is that kexec inserts properties into the fdt which >> contain the start address and size on the crash kernel. On our >> system, the start address is a 64-bit value, and while its not the >> case today, I see no reason why size could not also be a 64-bit >> value. However the values that are inserted into the fdt are >> governed by the address and size cell values already present in the >> fdt. >> >> Kexec attempts to insert these values in the fdt. The fdt only >> accepts 32-bit values, so it truncates what is put in. Then later >> kexec/kdump read the values from the fdt, and get garbage. > > I take it this is specific to the kdump properties? > > I can't immediately see what would matter for the !kdump case. > properties inserted under /chosen are not truncated? The kexec/kdump properties are added under /chosen, therefore yes, properties added under /chosen are truncated, per our observations. > >> By changing the defaults to 2 (the proposed change), 64-bit values >> can be inserted into the fdt, so the values we put in don't get >> truncated, and thus kexec/kdump read the correct thing when they >> need the values. >> >> I don't see how the tools could be fixed - fdt is truncating the >> values, and the generated fdt is already "static" at the point the >> tools run. We haven't had luck changing the cell size at the point >> the tools run. Additionally, this seems to be an issue for >> everything using the fdt - pushing the problem to every tool instead >> of fixing once at the top seems like playing a game of whack-a-mole. >> >> Does that clarify that issue for you? Obviously the commit text >> needs some work, but I'd like to get on the same page first. > > If you could update the commit message to explicitly mention the > properties being inserted for which this matters, this generally sounds > fine to me. > > Please Cc me on v2. > > Thanks, > Mark. > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- Jeffrey Hugo Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.