Proposal: do *not* ignore uboot-env-args if e.g. ubenvar "respect_ubenv=yes" is set

For Developers
1

1. Problem:
OpenWrt (Build 18.06.1) ignores my bootargs=<other-Kernel-Args> (set in the uboot-environment).
I have successfully flashed u-boot, an u-boot-environment & OpenWrt on several o2 6431 routers (see here) but modified bootargs are just ignored.

This is what my test ubootenv looks like - note the mem=61M:

root@OpenWrt:~# fw_printenv
addconsole=setenv bootargs $bootargs console=$consoledev,$baudrate
addeth=setenv bootargs $bootargs ethaddr=$ethaddr
addip=setenv bootargs $bootargs ip=$ipaddr:$serverip::::$netdev:off
addmachtype=setenv bootargs $bootargs machtype=VGV7510KW22
baudrate=115200
bootargs=console=ttyLTQ0,115200 mem=61M vpe1_load_addr=0x83e00000 vpe1_mem=2M maxvpes=1 maxtcs=1 nosmp
bootcmd=bootm ${kernel_addr}
bootdelay=2
consoledev=ttyLTQ1
ethact=ltq-eth
ethaddr=00:01:02:03:04:05
ipaddr=192.168.1.1
kernel_addr=0xB0080000
load-uboot-nor=tftpboot u-boot.bin
load-uboot-norspl=tftpboot u-boot.ltq.norspl
load-uboot-norspl-lzma=tftpboot u-boot.ltq.lzma.norspl
load-uboot-norspl-lzo=tftpboot u-boot.ltq.lzo.norspl
loadaddr=0x81000000
netdev=eth0
serverip=192.168.1.2
stderr=serial
stdin=serial
stdout=serial
write-uboot-nor=protect off 0xB0000000 +$filesize && erase 0xB0000000 +$filesize && cp.b $fileaddr 0xB0000000 $filesize
root@OpenWrt:~#

But cat /proc/cmdline still gives this:
console=ttyLTQ0,115200 mem=62M vpe1_load_addr=0x83e00000 vpe1_mem=2M maxvpes=1 maxtcs=1 nosmp


2. What I did so far:

  1. found the VGV7510KW22.dtsi file with the pre-compiled default boot arguments.
  2. couldn't find anything relating to that in make menuconfig.
  3. found something in make kernel_menuconfig:
[*] Built-in kernel command line
	() Default kernel command string
 [ ]   Built-in command line overrides firmware arguments
  1. found a lot about CONFIG_IMAGE_CMDLINE_HACK and CMDLINE_OVERRIDE but can't really make heads or tails of it and can't find either (neither?) in any of the .dts(i) files concernig the o2 6431 router.
  2. Other files like lantiq/image/Makefile and vr9.dtsi weren't helpful either.

3. Possible solutions:

  1. compile my own kernel without preset bootargs. -> Can only be used if you have a working uboot-env with bootargs set. -> Don't want to do that.

  2. modify the build script / makefile / instructions for the VGV7510KW22NOR-target so that Built-in command line overrides firmware arguments is not set (see 2.3.).

  3. patch/hack/mod the general behavior of the Kernel so that it doesn't ignore the uboot-env if something like respect_ubenv=yes is set in the uboot-env, regardless of any compile-time-bootargs.

If I remember correctly I stumbled over sth. like 3.3. the last time I invested some time into this, but I can't find it anymore.
Anyway 3.3. is my preferred solution, if that's not possible 3.2.'d be it but so far I couldn't figure out how to do this by myself, much less how to get it integrated in future releases.

so help me please?! :-/
First I'd like to test 3.2. but I don't quite understand how to proceed after setting my target in make menuconfig and not finding the pre-compile default boot arguments (from 2.1.) in make kernel_menuconfig ...

I know there are others who would like to be able to do this too...
@slh @Plonk34 @Mijzelf @shm0 @fantom-x

2 Likes
2

yeah........ had me going for a few days too..... the first few times i set it it didn't seem to work some sort of magic not happening..... i was really suspect it was the patches..... something about mtdblock..... being hard coded in there.....

anyway for me i was using usb kernel root= etc.... and i settled on....;

make kernel_menuconfig

CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y ***THIS IS THE ONE

( yours may not be arm? but you have the right area above so do graphically.... )

In hindsight maybe i didn't run make defconfig after setting the options above.... ( sure i tried everything a 1000 times so i think the thing below is what was causing me grief )

the other thing.....

i had to open up the dts for my device and remove the "chosen -> third line "append rootblock", it seemed that the kernel options above weren't honoured if i didn't do that.

I think there is merit in your suggestion of a runtime / uenv flag that can alter this behavior on the fly / lax up the hoops a little.... for newbies like me :wink:

3

Forgot to mention that I don't think that will help. The way I understand it would only allow me to extend the build-in cmdline with additional bootargs from the uboot-env, but I need to remove/replace/modify a few existing arguments (want to be able to disable the sip/FXS/telephony part and use both cpu cores in OpenWrt).

The Buildsystem Userguide is bit confusing in that regard (when to do which step - different orders in the same document) but I think I need to run make defconfig between menuconfig and kernel_menuconfig to get the information (which target and so on) from the 1st to the next/2nd/3rd/other steps.
Will try that later.

4

Your right..... extend for me cause i'm not overwriting stuff.... for you i'd think the top one

( x) Use bootloader kernel arguments if available
() Extend with bootloader kernel arguments
( ) Append rootblock parsing bootloader's kernel arguments

And maybe this 5 options up

-*- Flattened Device Tree support │
[ x] Support for the traditional ATAGS boot data passing

But like i said without the dts mod... they never worked for me....

5

Running make defconfig between menuconfig and kernel_menuconfig did the trick of getting the "Default kernel command string" from the first to the next steps but I can't find your option anywhere in kernel_menuconfig.

Now it looks like this and there are no other options concerning the "kernel command line":

[*] Built-in kernel command line
(console=ttyLTQ0,115200 mem=62M vpe1_load_addr=0x83e00000 vpe1_mem=2M maxvpes=1 maxtcs=1 nosmp) Default kernel command string
[ ]   Built-in command line overrides firmware arguments

I'll build that and try the image since "Built-in command line overrides firmware arguments" isn't set now, but it irritates me that I didn't have to unset it manually since the default build does ignore firmware arguments.

6

Well, if you really gotta get something done;

cat build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x/linux-4.14.63/init/main.c ( ish )

#if defined(CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE)
	//Show bootloader's original command line for reference
	if(of_chosen) {
		const char *prop = of_get_property(of_chosen, "bootloader-args", NULL);
		if(prop)
			pr_notice("Bootloader command line (ignored): %s\n", prop);
		else
			pr_notice("Bootloader command line not present\n");
	}
#endif

#ifdef CONFIG_MANGLE_BOOTARGS
static void __init mangle_bootargs(char *command_line)
{
	char *rootdev;
	char *rootfs;

	rootdev = strstr(command_line, "root=/dev/mtdblock");

	if (rootdev)
		strncpy(rootdev, "mangled_rootblock=", 18);

	rootfs = strstr(command_line, "rootfstype");

	if (rootfs)
		strncpy(rootfs, "mangled_fs", 10);

}
#else
static void __init mangle_bootargs(char *command_line)
{
}
#endif

static void __init setup_command_line(char *command_line)
{
	saved_command_line =
		memblock_virt_alloc(strlen(boot_command_line) + 1, 0);
	initcall_command_line =
		memblock_virt_alloc(strlen(boot_command_line) + 1, 0);
	static_command_line = memblock_virt_alloc(strlen(command_line) + 1, 0);
	strcpy(saved_command_line, boot_command_line);
	strcpy(static_command_line, command_line);
}
7

Did anyone find a way to use boot command lines with the config apps in openwrt (not editing the kernel?)

8

no such thing....

at it's core, openwrt is a source tree that contains patches.

the build system exposes many userlevel and common software configuration settings via the menuconfig interface.... cmdline enable disable is not one of them.

there are are few detailed answers if you search this forum but essentially such and option;

a) Implies advanced user with serial access... in which case a simple menu kernel_config is trivial

b) Exposes internals that will likely lead to bricking a device..... or otherwise interfering with standard usage ....aka rendering known and supported methods incompatible ( think 500 posts here .... i just changed this one setting and now how do I get my oem firmware back )

FWIW though.... moving forward..... support for a config.txt in some form or fashion and maybe and external storage autodetect ( size contraint ) for that would be a nice have down the line..... with most modern devices having usb ports and external storage these days..... i think it will happen. it's basically one level above uboot... so an "early" thing and another level of the failsafe...... but it does add to size ....