bootloader support for DTB on x86

[H. Peter Anvin]

On 05/22/2012 12:51 PM, Sebastian Andrzej Siewior wrote:
> 
> It should not be that difficult. 
> - Look how the initrd is loaded. Use the same technique to load the dtb 
>   blob. 
> 
> - Allocate another memory block for setup_data. You need one entry of 
>   type SETUP_DTB pointing to the dtb. If I remember correctly, the 
>   setup_data is thrown away by kernel and the dtb blob itself is  
>   relocated to some place safe.
> 
> - You may need to set hardware_subarch to some similar to 
>   X86_SUBARCH_CE4100. I mean you *may* need your own subarch value but 
>   you can most likely reuse most of the functions that ce4100 is using. 
>   The PCI bus and UART is broken is a special way, everything else is
>   generic. Since we don't have ACPI/SFI,  we need something to find
>   HPET, IO-APIC, irq routing, 
> 

Careful here!

We have just had a long discussion how we want to handle large data
blobs which need bootloader support in x86 space.  The consensus opinion
ended up that they should be prepended to the initramfs, uncompressed,
and using a cpio header with a file name beginning with "kernel/".

Thus, it is logically part of initramfs but can be accessed earlier in
the boot.  This has a number of advantages for the bootloader, including
a modicum of backward compatibility with legacy bootloaders.

Intended users of this mechanism include microcode updates and ACPI
table overrides.

I really don't want to see more ad hockery of the CE4100 variety.

The code for this is still not integrated; I wrote up some cpio parsing
code for this:

http://www.zytor.com/~hpa/kernel/findcpio.c

... but it hasn't been included in any kernel trees yet.  I know Thomas
Renninger said he was going to work on it, but I haven't seen anything.

See the LKML thread "[PATCH] ACPI: Implement overriding of arbitrary
ACPI tables via initrd":

http://lkml.kernel.org/r/1332512984-79664-1-git-send-email-trenn@suse.de

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.