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."