Re: [PATCH v2] Re: Adding support for device tree and command line

[Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>]

On Sun, 2016-05-29 at 21:01 +0200, Jonas Gorski wrote:
> On 29.05.2016 20:38, Daniel Gimpelevich wrote:
> > On Sun, 2016-05-29 at 12:53 +0200, Jonas Gorski wrote:
> >> This will break/won't compile for ZBOOT_APPENDED_DTB as __appended_dtb
> >> is
> >> part of the wrapping decompressor, and the kernel has no knowledge of
> >> this
> >> this symbol.
> > 
> > If this were true, it wouldn't compile with the code you added to
> > compressed/head.S, either. You're referencing it as an external symbol,
> > which is exactly the same thing I'm doing here.
> 
> There are two different __appended_dtb definitions: the one for the
> (uncompressed) kernel appended one that is visible to the kernel (in
> kernel/vmlinux.lds.S), and one in boot/compressed/ld.script that is
> visible only to the wrapping decompressor.
> 
> Since the wrapping decompressor is built *after* the kernel was compiled
> and compressed, there is no way to tell the kernel where __appended_dtb is
> relative to the decompressor, so for ZBOOT_APPENDED_DTB you cannot
> reference __appended_dtb from kernel code.
> 
>  Your proposed
> > alternatives are functionally almost equivalent to your earlier rejected
> > patches:
> 
> These weren't rejected, just deemed insufficient (mostly by me myself).
> 
> And only to this one is similar:
> > https://patchwork.linux-mips.org/patch/7274/
> 
> But in contrast to this one, it doesn't populate initial_boot_params auto-
> matically, but instead still requires the mach to do that (by calling
> __dt_setup_arch()). I dropped that because IIRC at that time I read that
> initial_boot_params isn't supposed to be directly accessed.
> Also not populating initial_boot_params is IMHO better as just because
> a0 says -2 it doesn't mean a1 references a dtb - that should still be up
> to the mach to say that it expects a dtb to be passed.
> 
> 
> > https://patchwork.linux-mips.org/patch/7313/
> 
> This one was only missing alignment for the !SMP case but is otherwise
> equivalent to what is in the kernel now.
> 
> 
> Jonas

I see, and you are absolutely right in what you now suggest. What
escapes me at the moment, though, is how to reconcile all this with UHI.
UHI bootloaders may pass an external DTB, and it should be
indistinguishable by the boot code from an appended DTB. Thoughts?