[PATCH v2 1/2] of/fdt: export fdt blob as /sys/firmware/fdt

Ard Biesheuvel ard.biesheuvel at linaro.org
Tue Nov 11 12:34:26 PST 2014

On 11 November 2014 21:08, Grant Likely <grant.likely at linaro.org> wrote:
> On Tue, Nov 11, 2014 at 4:25 PM, Rob Herring <robherring2 at gmail.com> wrote:
>> On Tue, Nov 11, 2014 at 8:42 AM, Grant Likely <grant.likely at linaro.org> wrote:
>>> On Mon, 10 Nov 2014 19:47:01 +0100
>>> , Ard Biesheuvel <ard.biesheuvel at linaro.org>
>>>  wrote:
>>>> Create a new /sys entry '/sys/firmware/fdt' to export the FDT blob
>>>> that was passed to the kernel by the bootloader. This allows userland
>>>> applications such as kexec to access the raw binary. The blob needs to
>>>> be preserved as early as possible by calling preserve_fdt().
>>>> The fact that this node does not reside under /sys/firmware/device-tree
>>>> is deliberate: FDT is also used on arm64 UEFI/ACPI systems to
>>>> communicate just the UEFI and ACPI entry points, but the FDT is never
>>>> unflattened and used to configure the system.
>>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>>> On further thought, nak. I want tree modifications to be treated as
>>> bugs. Do a checksum CRC32 or check. It's simpler and it can be extended
>>> to us an in-blob CRC when the file format gets upreved to include one.
>> Why? MIPS Octeon is full of them BTW. So the rule is any modifications
>> or fixups have to be on the unflattened tree?
> That, or we require the fixups to explicitly clean up the CRC after
> themselves. That will force them to be visible. Anything using the
> fdt_*() write functions could potentially take care of it
> automatically. That would make it immediately discoverable where
> changes are being made in the tree.

Doesn't that defeat the purpose of capturing the FDT as it was passed
by the bootloader? Those fixups will be reapplied by the kexec'ed
kernel anyway.

More information about the linux-arm-kernel mailing list