How to modify kernel parameters / command line after flashing?

Installing and Using OpenWrt
17

Okay, after having let the information from you two (@anon50098793, @slh) sink in some more I've come to the conclusion that a third image is in fact completely unnecessary as long as future release of the default images are modified in such a way that they work in all of the following setups:

  • BRN-boot, 1st flash of brn-squashfs-factory.bin without working uboot environment. I assume this is the most used first stage for the o2 6431 / vgv7510kw22 router.
  • BRN-boot, update-flash nor-squashfs-sysupgrade.bin still without ubootenv.
  • u-boot, only ever nor-sysupgrade images, without ubootenv and possible remains from when BRN-boot was still flashed (dunno if this can happen. couldn't happen for me because I used a mostly empty 16MiB image to overwrite the whole flash once with uboot, oWRT and a copy of the original board_config partition -> all possible remains where the ubootenv partition is were overwritten).
  • u-boot, only ever nor-sysupgrade images, with working ubootenv (w/w/o bootargs defined). This is the setup I'm using.

To achieve this the following conditions must/should be met (I think):

  1. integration of @slh's patch from #14.
    As I understand it this would enable the uboot-envtools (fw_printenv, fw_setenv) to create an ubootenv automatically the first time they're used? Or does this somehow trigger an installed u-boot to automatically create the proper environment? Kinda confused what the purpose is if that's not the case. Or is this just a patch to let fw_setenv know where to write on this specific device, when no ubootenv exists yet?
    Would this do something to routers still with BRN-boot?
  2. The user needs to be able to write to the ubootenv partition. Be that with insmod mtd-rw i_want_a_brick=1 (doesn't work AToW) or with a change in VGV7510KW22NOR.dts.
    Since all partitions would remain write protected (most of the time) either way in BRN setups (VGV7510KW22BRN.dts) most of my other concerns are baseless anyway, aren't they? :wink:
  3. Some kernel compile parameters concerning the cmdline/bootargs need to be changed but this can't mess with setups without a working ubootnev or wonky remains.
CONFIG CMDLINE 
CONFIG_CMDLINE_BOOL=y
# CONFIG_CMDLINE_OVERRIDE is not set
# CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND is not set
CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER=y

CONFIG_CMDLINE="console=ttyLTQ0,115200 mem=62M vpe1_load_addr=0x83e00000 vpe1_mem=2M maxvpes=1 maxtcs=1 nosm" should stay in its predefined way as it is now.
Dunno if the CMDLINE DTB entries are of concern...

  1. The normal images with noSMP+FXS shouldn't be much larger then a theoretical default image without the necessary packages for telephony. That's already the case imho.
  2. Overriding the built-in cmdline with console=ttyLTQ0,115200 must disable all non-SMP VPE activity. I think I'm still getting some unnecessary action there:
some kernel boot messages with vmmc/vpe stuff?! 
[    0.504545] lantiq,vmmc 1f103000.vmmc: requested GPIO 465
[    0.509865] lantiq,vmmc 1f103000.vmmc: requested GPIO 493
[    0.515332] lantiq,vmmc 1f103000.vmmc: requested GPIO 492
[    0.520782] lantiq,vmmc 1f103000.vmmc: reserved 1MB at 0x03b00000
@/after 59MiB?

[    0.649305] No VPEs reserved for AP/SP, not initialize VPE loader
[    0.649305] Pass maxvpes=<n> argument as kernel argument
[    0.660678] No TCs reserved for AP/SP, not initializing RTLX.
[    0.660678] Pass maxtcs=<n> argument as kernel argument
[    0.673549] Crashlog allocated RAM at address 0x3f00000
[    0.679552] workingset: timestamp_bits=30 max_order=14 bucket_order=0
@/after 63MiB?

Any further hints/ideas an how I can make sure none of the usual setups/constellations can lead to oWRT booting with an unintentional cmdline?

Open questions (from my perspective):

  1. Is the area where the ubootenv is placed erased regardless of the way you install uboot+oWRT?
    The ToH page explains a way to install both over a serial connection and step three of "Install OpenWrt from u-boot" is "Erase the flash area where u-boot and it's environment are stored" but the command looks like it only erases the area/partition for oWRT???
  2. Is it actually problematic if it's not erased?
  3. (pure curiosity) Why do neither .dts-file mention/define the board_config @ 0xfe0000 (16MiB - 128KiB)?
  4. Whats happening at 5. (see above)?
  5. Am I missing a downside to making the ubotenv partition writable from within oWRT?
  6. Should I just try to introduce the necessary patches with a pull request in github? (have I done enough preliminary work?
Mt7621, bootargs (command line) from Bootloader