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:
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.
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.).
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 ...
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....;
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
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.
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":
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.
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 ....