Mt7621, bootargs (command line) from Bootloader


Pulling my hair out with this one - trying to get the u-boot command line (bootargs) in to OpenWrt. I have found a few links with info, but none of them seem to quite work (fully) :frowning_face:. And I understand the comment about not wanting / using u-boot arguments - but I have a dual partition router, I do need those arguments to select the correct partition (and I see this is used / working for some other dual-partition devices, like the EA3500 ... it takes those command line arguments).

I was thinking I could use CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER=y, like in this post. But no joy, it doesn't seem to work.

This one is a bit closer, hacking the of.c file does in fact get the command line (in place), but thinking this really should be through CONFIG values ... agreed?

Once I get past this, the next thing is to set the desired mtd partition name to "ubi", as this is auto-processed (as the root partition). Any thoughts there as well would be greatly appreciated.


Not sure I understand what the expected outcome is supposed to be....?

Sorry, didn't mean to be confusing! Key issue - can't seem to get bootargs / command line from u-boot in to OpenWrt (w/mt7621).


Hmmm - it SEEMS like this is working in the testing kernel 5.10, but not in 5.4. Does that sound right?


Depends on how you're trying to get them to the kernel, I guess....

bootcmd=vmlinuz $bootargs

Is how I remember it, might need () though.
It's been a while.

Bit of digging, found this rather interesting (recent) update. I think this is why the two kernels are acting differently for me ... as this change only seems to be in 5.10 from what I can tell.


Plugging through :grinning_face_with_smiling_eyes:. Think I found my (next?) grief ... LOL. It seems that bootargs is being read from the u-boot (locked) partition, not the u_env partition (which I can modify). Need to find where those addresses are defined.


U-boot-envtools I reckon.

Agreed! But that's once booted, and in the shell => works well. My issue is during boot, it seems the kernel is grabbing the command line from the "wrong" partition (i.e. mtd0, not mtd1). Make sense?

Thinking it's a base address thing, digging.


If you provide more details, perhaps we'd be able to help you better.

Sure, NP. Was trying to dig myself as well though, help others also if I can!

I am finding that with the 5.10 kernel, and the update I linked above - MIPS does now support reading in the u-boot bootargs variable, and adding it to the Kernel command line (is there in 5.4 also, but not working it seems). The issue is that using fw_setenv (or direct serial access), I can set variables in the u-boot environment (like bootargs), but on boot ... it's not taking / using those. Rather, it's using the default (hard coded) variables inside u-boot (partition) itself.

Make sense? Trying to find where / how it goes looking to get those vars, to point it to the right place.


You should be able to dump the whole uboot env partition, hex edit it, and replace the static values with a variable, then work with that variable.

Or replace the pre-installed uboot.

Agreed! That would work for a "one-time" update - but I have a dual-partition router, so need to change the bootargs to switch partitions => need it read/write. Make sense?

It may be possible with the variable, like you say - actually, not sure it would (but I may be wrong!). Because it's not looking at the r/w partition at all right now. :slightly_frowning_face:


Well, you need to establish where it's picking up its hard-coded defaults.

In worst case, they're in the uboot binary itself.

1 Like

Agreed! It does seem to be (like you say), from u-boot itself. Trying to find where that is, not so easy (at least for a Linux source code dummie like me :laughing:).


If they are, they'll be strings in the binary code, you should be able to see them in a hex editor (or just run strings on the file/partition.

I doubt you will find them in the source code, since I'd be expecting it to be a vendor specific thing, not something in the official release.

Unless you're using the official uboot ,)

That makes sense - but it should be possible to read from the u-boot environment (variables) partition, no?


From where, using what?

Sorry, meaning in the code, on boot => use the "correct" (modifable) partition data, for the Kernel command line. If not, there is no real way to switch partitions, agreed?


Like I said, depends on where the hard-coded values sit.

If it's in the binary code itself, you either have to modify the uboot binary, or replace it.

Replacing uboot is always a dangerous operation, since there's a risk of bricking your device.

If the static values are in the uboot env partition, you should be able to hack it. Since it would be a non destructive/bricking operation. It's also possible to take a backup copy of it.

In theory you could have two uboot env dumps.
Swapping between them would make different linuxes boot.

You could try to wipe the uboot env partition, and see what happens during the next boot.

Another possibility might be to try to chain boot an additional uboot, supplied by you, providing the settings and flexibility you desire.
Not sure if it works in real life though :slight_smile:

1 Like