Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2025.01, v2025.04-rc2 are OUT / Merge Window is CLOSED, next branch is OPEN / Release v2025.04 is scheduled for 07 April 2025 / Channel archives at https://libera.irclog.whitequark.org/u-boot
ikarso has quit [Quit: Connection closed for inactivity]
goliath has quit [Quit: SIGSEGV]
alpernebbi has quit [Ping timeout: 248 seconds]
alpernebbi has joined #u-boot
mmu_man has quit [Ping timeout: 244 seconds]
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #u-boot
Daanct12 has joined #u-boot
flyback has quit [Remote host closed the connection]
flyback has joined #u-boot
Forty-Bot has joined #u-boot
chili-b_ is now known as chili-b
clamor has joined #u-boot
Danct12 has quit [Quit: ZNC 1.9.1 - https://znc.in]
Danct12 has joined #u-boot
clamor has quit [Ping timeout: 252 seconds]
clamor has joined #u-boot
enok has joined #u-boot
enok has quit [Client Quit]
enok has joined #u-boot
enok has quit [Ping timeout: 252 seconds]
enok has joined #u-boot
enok has quit [Client Quit]
enok71 has joined #u-boot
enok71 has quit [Client Quit]
enok has joined #u-boot
ikarso has joined #u-boot
monstr has joined #u-boot
clamor has quit [Ping timeout: 260 seconds]
clamor has joined #u-boot
monstr has quit [Ping timeout: 252 seconds]
rockosov has quit [Ping timeout: 276 seconds]
rockosov has joined #u-boot
<clamor> sjg1: I have an issue with the nyan-big test. May you have a look? It seems that tegra124-u-boot.dtsi was not applied for some reason. I have sent an email about related commit
clamor has quit [Read error: Connection reset by peer]
clamor has joined #u-boot
Jones42 has joined #u-boot
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #u-boot
naoki has quit [Ping timeout: 248 seconds]
<Jones42> How do I "env save" when I have ENV in both MMC and NOWHERE? I'm trying to lock down my environment and only allow writing to selected variables ( https://trac.gateworks.com/wiki/secure_boot#SecureU-Boot , second option )
<Jones42> After the initial flashing, my mmc-environment is not initialized yet. "env save" then gives me a "Saving Environment to nowhere... not possible"
Jones42 has quit [Quit: Client closed]
Jones42 has joined #u-boot
mmu_man has joined #u-boot
clamor has quit [Ping timeout: 260 seconds]
clamor has joined #u-boot
Jones42 has quit [Quit: Client closed]
naoki has joined #u-boot
naoki has quit [Ping timeout: 276 seconds]
haritz is now known as saimazoon
goliath has joined #u-boot
naoki has joined #u-boot
Jones42 has joined #u-boot
monstr has joined #u-boot
eballetbo has joined #u-boot
jclsn has quit [Quit: WeeChat 4.5.1]
jclsn has joined #u-boot
Jones42 has quit [Ping timeout: 240 seconds]
Jones42 has joined #u-boot
Jones47 has joined #u-boot
Jones42 has quit [Ping timeout: 240 seconds]
<marex> Jones47: isnt this WRITEABLE_ENV stuff what IOT2050 does ?
<marex> enable env in MMC, select vars which should be writeable (ideally bools or integers only, strings can contain scripts) and done ?
monstr has quit [Read error: Connection reset by peer]
monstr has joined #u-boot
leah has quit [Ping timeout: 272 seconds]
<Jones47> marex: I'm confused because multiple sources also mention to add "ENV_IS_NOWHERE" to ensure that non-writable variables are loaded from default environment.
monstr has quit [Ping timeout: 252 seconds]
leah has joined #u-boot
<Jones47> according to https://lists.denx.de/pipermail/u-boot/2021-April/446461.html , "having two ENV drivers is mandatory"
leah has quit [Quit: WeeChat 3.8]
<marex> Jones47: ah right ... the writeable env thing basically works this way
<marex> env save ... entire env is written out to storage (e.g. mmc)
<marex> env load (or boot) ... default env is imported, external env (in emmc) is read, select variables (the writeable ones) are imported
<Jones47> marex: but that's my issue: "env save" gives me a "Saving Environment to nowhere... not possible"
<marex> Jones47: do you maybe have ... sec
<marex> env_get_location() implemented somewhere ?
<marex> maybe that picks the wrong env of the two ?
leah has joined #u-boot
<Jones47> will check, thanks!
<Jones47> I'm using the weak default implementation in env/env.c - currently figuring out how the priorization works...
<sjg1> clamor: OK, I can't find the right email
<clamor> sjg1: re-sent just now
<clamor> sjg1: I have tested that commit on mocha (t124 mi pad) and it does not throw that error.
<sjg1> clamor: OK, I'm not immediately sure what is going on, but I assume that one of the devices is not present pre-relocation?
<clamor> Nyan throws that dc1 is not present
<clamor> All I did was moving bootph-all from nyan uboot tree to common t124 uboot tree
leah has quit [Ping timeout: 260 seconds]
<clamor> I have not touched anything else related to nyan setup
naoki has quit [Read error: Connection reset by peer]
naoki1 has joined #u-boot
leah has joined #u-boot
naoki1 is now known as naoki
Jones47 has quit [Quit: Client closed]
Jones42 has joined #u-boot
<Jones42> marex: when booting/loading it checks prio 0 first (mmc), fails (bad crc), then checks prio 1 (nowhere) and succeeds. when doing "env save" it directly checks prio 1 (nowhere) and fails. I'm currently figuring out why it doesn't try prio 0 (mmc)
Daanct12 has quit [Quit: WeeChat 4.5.1]
<Jones42> marex: env_load sets env_load_prio=1 when loading from nowhere succeeds.
<Jones42> env_save then only checks drv = env_driver_lookup(ENVOP_SAVE, gd->env_load_prio)
<Jones42> So I assume this means I need a properly initialized environment in mmc?
<sjg1> clamor: So if you just changed the DT source, did you see any change in u-boot.dtb ? If so, that might be a clue?
<clamor> sjg1: since I do not own nyan I did not check it, but mocha works perfectly fine. Lemmy check rm the tree
Peng_Fan has quit [Quit: Connection closed for inactivity]
<clamor> sjg1: bootph-all is not applied
<clamor> At the same time the mocha tree has them applied
<sjg1> clamor: Well you don't need a nyan to check the u-boot.dtb for any differences
<sjg1> clamor: You should be able to test on my lab now. You can craft a .gitlab ymal file which just has that one board
<clamor> It is not about nyan but why it ignores tegra124-u-boot.dtsi
<clamor> Oh, it seems that I know the solution
<sjg1> clamor: OK good. You can use the '# Uncomment for debugging' in Makefile.lib
<clamor> sjg1: that won't be needed I hope, but thank you for a hint
<Jones42> marex: is there a simple solution to dump the internal env to mmc when there is no environment there? I'm trying to avoid having to build+integrate an env image (yocto/wic)
leah has quit [Ping timeout: 245 seconds]
leah has joined #u-boot
<marex> Jones42: saveenv or mkenvimage+dd
<Jones42> marex: saveenv doesn't work (see above). I can't make it force to save to mmc, can I? the mkenvimage is really not the road I want to go down...
<Jones42> I'm thinking about patching the code, i.e.: save the environment to somewhere else instead of NOWHERE, but I figure that would have bad chances of ending upstream
<mkorpershoek> Jones42: Are you perhaps using a defconfig fragment? I remember that I had to explicitely set `CONFIG_ENV_IS_NOWHERE=n` in fragment if the main defconfig had this set. See: https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?h=ti-u-boot-2023.04&id=9f0d18e7f655b4fb855853f21cf75ddcdf77cec3
<marex> Jones42: you need to figure out why saveenv does not pick emmc env driver and why it picks nowhere env driver
<Jones42> marex: see above: the env_load sets the env_load_prio to the nowhere-driver, because that's the one that succeeds
<Jones42> marex: then when I try to save, it only uses  gd->env_load_prio, which points to "nowhere"
<Jones42> mkorpershoek: I'm not using any fragments. I think `CONFIG_ENV_IS_NOWHERE=y` is right in my case.
<mkorpershoek> Jones42: can you check in your `.config` if you have both `CONFIG_ENV_IS_NOWHERE` *and* `CONFIG_ENV_IS_IN_MMC` ?
<Jones42> mkorpershoek: yep. that's alright
<mkorpershoek> Per my understanding, if you want to save to MMC, you should disable `CONFIG_ENV_IS_NOWHERE`
<Jones42> I think the issue is that my mmc-env is not initialized. env_load then first tries to load from mmc (fails) and then from default/nowhere (succeeds)
<mkorpershoek> I had that exact same issue, and setting `CONFIG_ENV_IS_NOWHERE=n` solved it for me
<mkorpershoek> even with `CONFIG_ENV_IS_NOWHERE=n` you will still have the default environment in the code. and that will be loaded an a CRC failures happens on mmc-env
<Jones42> mkorpershoek: that will make it work, but then the "filtering mechanism" won't work anymore, no?
<Jones42> I've posted two links some hours ago, and both cases mention that I need to have both environments set. (I'll give it a try, just to be sure)
<Jones42> if the initial load from mmc would succeed, then the save would also write to mmc.
<Jones42> it's all about the gd->env_load_prio in env_save / env_load: https://source.denx.de/u-boot/u-boot/-/blob/master/env/env.c?ref_type=heads#L166
<mkorpershoek> Yeah I just scrolled back and read through all that. Sorry I don't know about the "filtering mechanism" part. I'd try it out if I were you.
<marex> mkorpershoek: for the writeable env, you need both env drivers, NOWHERE and MMC
<marex> Jones42: maybe try and check older U-Boot version and see if something didn't get broken in this env stuff ?
<mkorpershoek> I see, sigh.
Jones42 has quit [Quit: Client closed]
Jones42 has joined #u-boot
<Jones42> marex: It looks alright... I guess the comment here explains that it's just behaving like it should: https://source.denx.de/u-boot/u-boot/-/blob/master/env/env.c?ref_type=heads#L208
<Jones42> marex: so the issue seems to be simply that my mmv-env is not initialized after flasting and it all goes south from there on
<marex> Jones42: I did recently notice some weird behavior of mmc env , when saveenv did not write the redundant copy until reboot
<marex> that weirded me out ... maybe something is broken in the env itself ?
<Jones42> marex: I think I'm on to something. Probably has nothing to do with redundant env, but the behaviour is inconsistent with the comment.
<marex> Jones42: git log -p env ... start reverting a bit ... see if you can narrow it down ?
<Jones42> it *should* take the bad-crc-env as default location
<Jones42> have to read some code first. not sure if it's a regression at all
<Jones42> marex: nope, works just as intended. I just misread the comment.
<Jones42> if there's no valid env in mmc, the "best choice" is the default/nowhere. and from then on, saveenv only takes nowhere as destination - and fails.
<Jones42> so I either somehow patch the code or go the mkenvimage+dd route
<Jones42> if the mmc is initialized, everything works fine...
Jones3 has joined #u-boot
Jones42 has quit [Ping timeout: 240 seconds]
rvalue- has joined #u-boot
Jones3 is now known as Jones42
<marex> Jones3: I think it should pick the writeable one, which is MMC
<Jones42> (sorry for the inconsistent nickmanes - i really have to fix my irc...)
rvalue has quit [Ping timeout: 265 seconds]
<Jones42> marex: I'll happily write a patch, but I'd like to know what the exact behaviour should be.
<Jones42> env_load takes the only readable env as "prio". that's `nowhere`
<Jones42> env_load takes the only readable env as "prio". that's `nowhere`, unless mmc works fine
<marex> Jones42: lemme have a look
<Jones42> marex: thanks.   It's really just an issue iff (a) nowhere is enabled *and* (b) mmc env has a bad crc
<marex> Jones42: a1bc4f1937a0 ("smegw01: Add lockdown U-Boot env support")
<marex> look at that
rvalue- is now known as rvalue
<Jones42> marex: thanks a lot, that should do it.
<Jones42> I hadn't thought about adding board specific code. all the examples online made me think it should work with just a few configs enabled
<marex> 13:35 < marex> env_get_location() implemented somewhere ?
<marex> Jones42: and yes, I also thought Jan added some generic goo, maybe I was wrong there
<marex> oh well
<Jones42>  13:52 <Jones47> I'm using the weak default implementation in env/env.c - currently figuring out how the priorization works...
<Jones42> I wasn't aware that that was meant to be overridden
sally has quit [Ping timeout: 272 seconds]
<marex> Jones42: I was not entirely sure, I was still under the impression there was generic stuff in place
<Jones42> marex: if you think it makes sense to make it more generic, I can submit something. But then again it seems to be quite a niche thing
<Jones42> I can also ask Jan (is he in here?) for his opinion.
mmu_man has quit [Ping timeout: 245 seconds]
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
mripard has quit [Quit: WeeChat 4.5.1]
leah has quit [Quit: WeeChat 3.8]
mmu_man has joined #u-boot
leah has joined #u-boot
crb has quit [Quit: Leaving]
slow99_ has quit [Quit: slow99_]
slow99 has joined #u-boot
crb has joined #u-boot
crb has quit [Client Quit]
dsimic has quit [Ping timeout: 260 seconds]
clamor has quit [Ping timeout: 244 seconds]
dsimic has joined #u-boot
clamor has joined #u-boot
Peng_Fan has joined #u-boot
Slimey has quit [Remote host closed the connection]
Jones42 has quit [Quit: Client closed]
Jones42 has joined #u-boot
vagrantc has joined #u-boot
enok71 has joined #u-boot
enok has quit [Ping timeout: 260 seconds]
enok71 is now known as enok
Jones42 has quit [Quit: Client closed]
Jones42 has joined #u-boot
clamor has quit [Read error: Connection reset by peer]
zsoltiv_ has quit [Ping timeout: 246 seconds]
Jones42 has quit [Quit: Client closed]
sally has joined #u-boot
Peng_Fan has quit [Quit: Connection closed for inactivity]
mmu_man has quit [Ping timeout: 252 seconds]
mmu_man has joined #u-boot
zsoltiv_ has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
enok has quit [Ping timeout: 276 seconds]
MyNetAz has quit [Remote host closed the connection]
clamor has joined #u-boot
MyNetAz has joined #u-boot
tlwoerner has quit [Remote host closed the connection]
<Tartarus> mkorpershoek: I assigned Jon's series to you just now in patchwork, but if you'd rather xypron take it, that's fine, I know everyone will check in with everyone else to make sure there's no more feedback before someone merges it and sends it on to me.
tlwoerner has joined #u-boot
clamor has quit [Ping timeout: 265 seconds]
<marex> the Edge-Lock Enclave is ... sigh ... 256 kiB blob right at the start of boot process ...
<marex> totally inspires much confidence in platform security
clamor has joined #u-boot
crb has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]