Hi.
I use uboot 2011.5 (or 2012? I have to double check later). I'm booting Debian via USB stick, everything is working fine so far. But there seems to be a problem with UBootEnvVariables: some parameters are ignored, i.e. if I enter /usr/sbin/fw_setenv serverip=172.17.0.3, it's not listed in output of fw_printenv. Thus netconsole is not working. It's weird, because it has been working before I was reflashing uboot during setup of a new USB stick. Furthermore some parameters are accepted and stored, like "/usr/sbin/fw_setenv if_netconsole=ping $serverip" after I entered serverip=172.17.0.3, so it's not a general issue. Is my env flash memory faulty?

cholat,

You are using an old u-boot. The new u-boot is here.

However, that's not relevant (both netconsole work the same way). The problem is the command yous use have wrong syntax.

There should be no = sign. Like this:

fw_setenv serverip 172.17.0.3

and

fw_setenv if_netconsole 'ping $serverip'

Note the single quotes in the 2nd command above, when there are spaces, the quotes ensure the whole string will be stored in the variable.

-bodhi
===========================
Forum Wiki
bodhi's corner

Damn
a) you're right. Output of fw_printenv was fooling me
b) how could it have ever been worked before? Weird
c) Don't want to break the "never touch a working uboot"-rule, though 2017.07 features sound promising. But I'm a sissy.

Quote
cholat
c) Don't want to break the "never touch a working uboot"-rule, though 2017.07 features sound promising. But I'm a sissy.

I'm glad I'm not the only one with this rule.

All,

Understood this is a good rule if you don't want to understand how the boot loader works during the boot phase. And willing to spend time building your own kernel to get around the booting problem caused by the fact that you are using a modern kernel with a very old u-boot.

With that said :)

If you have serial console, and use it to set u-boot envs temporarily, you will not mess with u-boot in any way. Just never do saveenv (u-boot command to commit the envs changes) in serial console without testing the changes thouroughly.

Note that fw_setenv commits the changes permanently. If you are using fw_setenv in user space, you've already mess with u-boot.

Rescue issue: It also depends on which box you have, i.e. that whether you can run UART booting to rescue the box when you cannot boot because of a bad u-boot image or envs image flashing. If you box has this capability, then it is almost impossible to brick it.

-bodhi
===========================
Forum Wiki
bodhi's corner