sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
camus has quit [Remote host closed the connection]
camus has joined #u-boot
apritzel_ has joined #u-boot
urja has quit [Quit: WeeChat 3.3]
urja has joined #u-boot
milkylainen has quit [Remote host closed the connection]
v0|d has quit [Ping timeout: 260 seconds]
mmu_man has joined #u-boot
milkylainen has joined #u-boot
michalkotyla has quit [Ping timeout: 256 seconds]
michalkotyla has joined #u-boot
michalkotyla has quit [Ping timeout: 240 seconds]
michalkotyla has joined #u-boot
michalkotyla_ has joined #u-boot
michalkotyla has quit [Ping timeout: 268 seconds]
camus has quit [Ping timeout: 256 seconds]
camus has joined #u-boot
sdfgsdfg has quit [Quit: ZzzZ]
claussenj has joined #u-boot
claussenj has quit [Client Quit]
coldspark29 has joined #u-boot
<coldspark29>
Hi, can anyone tell me how to permanently erase my environment variables? U-Boot doesn't load the defaults on boot
<Forty-Bot>
env default -a; env save
<Forty-Bot>
I think there is also an env erase?
<coldspark29>
I already tried that
<coldspark29>
I don't have env erase though
<Forty-Bot>
what do you want to happen?
<coldspark29>
env delete I do
<coldspark29>
Well U-Boot tries to boot from the wrong MMC_ROOT
<rfs613>
coldspark29: there's a default env built into u-boot, and then there is run-time environment which the user can modify and (optionally) save to flash for next time.
<coldspark29>
I already set that in the board config, but an old environment is always loaded
<coldspark29>
I can see the default when using env default -a, but it is not persistent
<rfs613>
sounds like "env save" is not working then...
<coldspark29>
How do I reply to people here?
<coldspark29>
Yeah seems like it
mmu_man has quit [Ping timeout: 245 seconds]
<rfs613>
coldspark29: the normal IRC method is just to prefix the username, like I just did.
<coldspark29>
It says
<coldspark29>
u-boot=> saveenv
<coldspark29>
Saving Environment to MMC... Writing to MMC(1)... OK
<coldspark29>
though
<coldspark29>
rfs613: Ok thanks
<coldspark29>
This is really an ancient messenger
<rfs613>
coldspark29: it's almost as old as me ;-)
<coldspark29>
I successfully avoided it and SAP until this year
<rfs613>
coldspark29: oh, don't compare it to SAP, that's not fair at all...
<coldspark29>
Hahahaha
<coldspark29>
SAP is worse. I give you that
<rfs613>
oh yes, I'm sure.
<coldspark29>
I think it is designed to be as counter-intuitive as possible, so they can sell classes for it
<rfs613>
coldspark29: bingo, you just figured out the business model
<rfs613>
anyhow, when you start your board, shortly after the u-boot version number, you should see "Loading Environment from ..."
<coldspark29>
Yeah
<coldspark29>
Loading Environment from MMC... OK
<rfs613>
ah but it wrote to MMC(1), that might be different from MMC without the (1)
* rfs613
isn't sure, none of my boards store the env on MMC
<rfs613>
when you build u-boot, there are several configuration options regarding where to store the env.
<coldspark29>
You mean here
<rfs613>
one of them is CONFIG_ENV_IS_NOWHERE, which might be useful for you, it means only the compiled-in env will be used.
<rfs613>
coldspark29: which versio of u-boot is this?
<coldspark29>
uboot-imx from NXP
<coldspark29>
We relied on this for Android
<coldspark29>
It is horrible. We might use mainline for our Yocto project
<rfs613>
in the past you used #defines for this in your board config file.
<coldspark29>
Although after over a month I completely figured out HAB and patched it to eat FIT images
<rfs613>
but nowadays it is configured through u-boots "menuconfig" and stored in a defconfig, like the kernel
<coldspark29>
So I am probably using an outdated method here?
<rfs613>
it depends how old your uboot is, that's why i was asking...
<coldspark29>
U-Boot 2018.03-00083-g8e96dd0f52
<coldspark29>
A bit old I guess
<rfs613>
perhaps
<coldspark29>
#define CONFIG_ENV_IS_NOWHERE 1
<coldspark29>
Didn't seem to have worked
<rfs613>
coldspark29: the file where you found those #defines, might be a generated file, based on the "menuconfig" settings.
<rfs613>
from what I can tell, the CONFIG_ENV_* settings were moved to menuconfig before 2018
<coldspark29>
Yeah it is
<coldspark29>
Can't find MMC_ROOT in menuconfig though
<rfs613>
coldspark29: I don't see MMC_ROOT either, that one seems to be board-specifc, and likely is being used to create the default env
<coldspark29>
The thing is we already have some hard-coded boot scripts in those configs. I don't want to overwrite them with menuconfig now
<rfs613>
coldspark29: well, if you change CONFIG_ENV_IS_IN_MMC=n and then CONFIG_ENV_IS_NOWHERE=y, then at boot, u-boot won't go looking for an env... and it will use whatever is compiled in. (And also, you won't be able to 'env save' as there is nowhere defined to save it to).
<rfs613>
else, you have to sort out why 'env save' is seeminly not writing to the same spot where it loads from at startup.
* rfs613
should add that is is quite unusual for the 'env save' and 'env load' to use different location. I'm not even sure how it is possible, they are compiled using the same CONFIG_ENV_* settings.
<rfs613>
perhaps there is something else going on...
<coldspark29>
I tried that but the old environment is still loaded
gsz has quit [Ping timeout: 240 seconds]
<rfs613>
hmm, are you sure you're actually running your modified u-boot binary?
<coldspark29>
This is weird
<coldspark29>
I can't use savenenv anymore
<coldspark29>
But the default env is not loaded
<coldspark29>
I guess, because your settings worked
<rfs613>
right, so maybe what you consider the default env is actually what's stored in MMC
<rfs613>
and now that's not being loaded, so you get what is compiled into the u-boot binary.
<rfs613>
(that's what is normally meant by "default env" BTW)
<coldspark29>
No I donÄt
<coldspark29>
On boot
<coldspark29>
mmcroot=/dev/mmcblk2p2 rootwait rw
<coldspark29>
After env default -a
<coldspark29>
mmcroot=/dev/mmcblk1p2 rootwait rw
<rfs613>
maybe try "printenv" to see all variables, search for anything that might be setting mmcroot to mmcblk2p2
<coldspark29>
There is nothing
<rfs613>
hrm, well it's got to be coming from somewhere... i wonder if they have some "clever" autodetection logic that tries to set mmcroot for you.
<rfs613>
is their source tree (git repo) publically availalbe somewhere i can look at?
<coldspark29>
I actually don't know
<coldspark29>
Should be opensource though
<coldspark29>
I have been searching for it in the past but couldn't find it
<rfs613>
hopefully your customers (if any) never ask for the source ;-)
<rfs613>
so as a band-aid fix, you could try modifying your 'bootcmd', to have it set mmcroot back to the value you want.
<coldspark29>
My colleague probably knows
<coldspark29>
Yeah I know, but that is ugly
<rfs613>
I completely agree, it would be hack. Better to figure out what's really going on, so there's no more magic to trip you up. But not everybody has the patience/time for that ;-)
<rfs613>
maybe you can pastebin your "printenv" output, or mail it to me, before we dig into the C code...