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

[Ard Biesheuvel]

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.