Re: Adding support for device tree and command line

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

On Mon, 2016-05-23 at 23:34 +0200, Hauke Mehrtens wrote:
> On 05/23/2016 11:14 PM, Hauke Mehrtens wrote:
> > Section 3 of this document defines some interfaces how a boot loader
> > could forward a command line *or* a device tree to the kernel:
> > http://wiki.prplfoundation.org/w/images/4/42/UHI_Reference_Manual.pdf
> > This allows only a device tree *or* a command line, not both.
> > 
> > The Linux kernel also supports an appended device tree. In this case the
> > early code overwrites the fw_args to look like the boot loader added a
> > device tree. This is done when CONFIG_MIPS_RAW_APPENDED_DTB is activated.
> > 
> > The problem is when we use an appended device tree and the boot loader
> > adds some important information in the kernel command line. In this case
> > the command line gets overwritten and we do not get this information.
> > This is the case for some lantiq devices were the boot loader provides
> > the mac address to the kernel via the kernel command line.
> > 
> > My proposal to solve this problem is to extend the interface and add a
> > option to provide the kernel command line *and* a device tree from the
> > boot loader to the kernel.
> > 
> > a) use fw_arg0 ($a0) = -2 and fill the unused registers fw_arg2 ($a2)
> > and fw_arg3 ($a3) with argv and envp.
> > 
> > b) add a new boot protocol $a0 = -3 with $a1 = DT address, $a2 = argv
> > and $a3 = envp.
> 
> I just looked a little bit more closely and saw that the command line
> uses 3 args. One for the count, one argv and one envp.
> 
> I would then only support device tree + count and argv, so the new
> interface would not support envp.
> 
> > 
> > I would prefer solution b).
> > 
> > This way we would not loose the kernel command line when appending a
> > device tree and this could also be used by the boot loader if someone
> > wants to.
> > 
> > Should I send a patch for this?
> > 
> > Hauke

It was because I looked through the above-linked UHI spec that I became
concerned about CONFIG_MIPS_RAW_APPENDED_DTB only mimicking, rather than
fully implementing, real UHI. In the upstream kernel, the new $a0 == -2
code can be a starting point for adding UHI argv/envp parsing for when a
UHI-compliant bootloader is used. However, on the head.S side, what I
propose for the lantiq target is to remove CONFIG_MIPS_RAW_APPENDED_DTB
from the kernel config, and reintroduce this as a platform patch:
https://github.com/openwrt/openwrt/blob/b3158f781f24ac2ec1c0da86479bfc156c52c80b/target/linux/lantiq/patches-4.4/0036-owrt-generic-dtb-image-hack.patch
The brcm63xx target could then retain CONFIG_MIPS_RAW_APPENDED_DTB, or
not, depending on bootloader specifics there, which I have not
investigated, and likewise the various other targets to which
CONFIG_MIPS_RAW_APPENDED_DTB has since been extended even though it was
apparently initially only an expedient hack only for brcm63xx.

Using $a0 = -3 is expressly prohibited in the above UHI document, and
using $a2/$a3 "would risk becoming incompatible with existing UHI
compliant implementations."