From mboxrd@z Thu Jan 1 00:00:00 1970 From: jhugo@codeaurora.org (Jeffrey Hugo) Date: Tue, 7 Feb 2017 12:29:38 -0700 Subject: [PATCH] efi/libstub/arm*: Set default address and size cells values for an empty dtb In-Reply-To: <20170207191320.GI26173@leverpostej> References: <1486490390-25251-1-git-send-email-jhugo@codeaurora.org> <1f47fcdd-c5d8-4082-70a3-ca9b1746d7ca@codeaurora.org> <20170207190113.GG26173@leverpostej> <20170207191320.GI26173@leverpostej> Message-ID: <252539a6-72f6-1afa-6ed5-3cf6a1aa24c2@codeaurora.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 2/7/2017 12:13 PM, Mark Rutland wrote: > On Tue, Feb 07, 2017 at 12:07:56PM -0700, Jeffrey Hugo wrote: >> 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. > > Sorry for the dodgy (and confusing) reply above. > > What I was trying to ask was does this *only* affect kdump properties? > I note that kdump is not yet upstream for arm64. > > Or are there regular kexec properties that this affects? > > Or !kdump && !kexec properties? > > Can you please enumerate the set of properties for which this matters? "linux,elfcorehdr" and "linux,usable-memory-range" We are not aware of !kdump && !kexec properties where this is an issue. > > 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.