Clamor has quit [Read error: Connection reset by peer]
Clamor has joined #u-boot
ezulian has joined #u-boot
mripard has joined #u-boot
ezulian has quit [Quit: ezulian]
ezulian has joined #u-boot
sszy has joined #u-boot
tnovotny has joined #u-boot
gmcastil has quit [Read error: Connection reset by peer]
gmcastil has joined #u-boot
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
mmu_man has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
slobodan has joined #u-boot
naoki has quit [Quit: naoki]
pbsds has quit [Ping timeout: 248 seconds]
pbsds has joined #u-boot
<Xogium>
am I correct in my thinking, that libubootenv doesn't handle env stored in eeprom ?
<Xogium>
I've been stracing it and it behaves extremely weirdly, like asking for 8192 sectors and receiving 4096 which is bogus either way since eeprom are not addressable by sectors bytes
<Xogium>
err, not by sectors but bytes, rather
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #u-boot
dsimic has quit [Ping timeout: 258 seconds]
dsimic has joined #u-boot
gsz has quit [Ping timeout: 240 seconds]
dsimic has quit [Quit: Going offline for now]
dsimic has joined #u-boot
sukrutb has joined #u-boot
Mis012 has quit [Ping timeout: 252 seconds]
sukrutb has quit [Ping timeout: 240 seconds]
Mis012 has joined #u-boot
Clamor has quit [Ping timeout: 244 seconds]
Clamor has joined #u-boot
fltrz has quit [Quit: leaving]
haritz has quit [Ping timeout: 240 seconds]
haritz has joined #u-boot
haritz has quit [Changing host]
haritz has joined #u-boot
gsz has joined #u-boot
Clamor has quit [Ping timeout: 258 seconds]
Clamor has joined #u-boot
f_ has joined #u-boot
gsz has quit [Ping timeout: 244 seconds]
<rfs613>
Xogium: I haven't used that myself (last time I did, fw_getenv/putenv were still in fashion).
<rfs613>
But from a quick look, it seems to use 'envsize' parameter, from the MTD layer.
<rfs613>
not sure how that works with EEPROM ;-)
Stat_headcrabed has joined #u-boot
Stat_headcrabed has quit [Client Quit]
<rfs613>
there does seem to be a PR#10 from 2020 to fix EEPROM read/write. Maybe double check that the version you have includes this fix?
<Xogium>
that's an idea... It should have though, but I'll check
gsz has joined #u-boot
<Xogium>
I'm not sure what I must do, to be honest. I set it so offset = 0x2080, size = 0x2000. I wasn't sure if it needs sector size and number of sector
mmu_man has quit [Ping timeout: 258 seconds]
<rfs613>
"if the Flash Sector Size is omitted, this value is assumed to be the same as the Environment Size"
<Xogium>
hmm
<rfs613>
it shouldn't matter for eeprom since there is no need to erase eeprom before writing.
<Xogium>
well, it is also totally confusing to me
<Xogium>
I'll do a strace and pastebin it so you can see what is going on, one moment
thopiekar has quit [Ping timeout: 240 seconds]
thopiekar has joined #u-boot
<rfs613>
it looks like the tool supports three options: file, mtd, or ubi. IN your case i think you want "file".
<rfs613>
(unless you have the eeprom being handled by MTD layer)
<rfs613>
so it looks to be trying to read 8192 bytes from /sys/devices/platform/soc/40012000.i2c/i2c-0/0-0050/0-00501/nvmem
<rfs613>
the 1st read only returns 4096, so it does a second read, getting another 4096...
<rfs613>
the data read seems like it could be a uboot environment...
<Xogium>
yeah that's what gets me weirded out
<Xogium>
I guess it is actually treating it as a file in this configuration, right ?
<rfs613>
no, it read the config file earlier
<rfs613>
we can see it doing lseek to 8320 offset also
<Xogium>
right
<rfs613>
my guess here, is that your env size is perhaps not correct.
<rfs613>
the environment is basically a bunch of name=value separated by NULL byte.
<Xogium>
well, it's definitely 0x2000 in u-boot menuconfig
<rfs613>
but at the very end (hoewever large it is defined to be) is a CRC checksum
<rfs613>
we can't see the value of that checksum in the strace, since it only shows the first few bytes of the two read() calls.
<Xogium>
hmm, makes sense, yes
mmu_man has joined #u-boot
<Xogium>
well I could dump the entire eeprom in a file and share this, if you want to look at it
<Xogium>
I have actually confugred redundant env. So first env is at 0x40, with 0x2000 size, and second is is 0x2080 with the same size
<Xogium>
0x40 / 0x2000 works with fw_printenv, but I think this is only luck by now, as for whatever reason 0x2080 doesn't work
ladis has joined #u-boot
mckoan is now known as mckoan|away
mmu_man has quit [Ping timeout: 245 seconds]
<rfs613>
Xogium: hmm, that's curious. Maybe just hexdump the whole eeprom under linux to a file. Then compare the bytes from 40+0x2000, against the ones at 0x2080+0x2000
<rfs613>
in fact you could use dd to extract two files, and cmp/diff on them.
<rfs613>
oh, the 5th byte differs, 00 versus 01, that might be the indicator of being the redundant copy..
<Xogium>
oh right
<Xogium>
that'd make sense
<Xogium>
because otherwise how would it know which one is which
<rfs613>
i forget if the CRC covers the magic bytes and flags at the start
<rfs613>
anyhow it seems like you have two valid copies of the env
<rfs613>
so I can't explain why the tool loads the 1st but not the 2nd
<Xogium>
I'd assume so. U-boot itself is pretty happy when using printenv
<rfs613>
perhaps, since you have to describe both 1st and 2nd in the config file, the way to get it to load the 2nd one is to intentionally corrupt the 1st.
<rfs613>
(eg. by specifying invalid offset/size for the 1st one, or by actually writing some garabge into that part of the eeprom)
<rfs613>
then the tool should go try to use the 2nd one...
<Xogium>
I can try. I was mostly just specifying this one alone to see if it would use it, but lets try using a wrong offset for the first
<Xogium>
hmmm I'm going to wipe the first env from the eeprom
<Xogium>
that will be way more conclusive
<Xogium>
alright so it does it
<Xogium>
that's weird, why doesn't it read the redundant env when it's just that one being set? Or more like, reads it then tells you sorry, can't read that ?
macromorgan has joined #u-boot
stefanro has quit [Quit: Leaving.]
Clamor has quit [Ping timeout: 246 seconds]
Clamor has joined #u-boot
Clamor has quit [Read error: Connection reset by peer]
Clamor has joined #u-boot
<rfs613>
looking at the code, it seems to read both copies, and then (if both have a valid CRC) then uses the flags field (5th byte) to select which one it uses. Thoughte logic seems kind of complex, it's got a mode with just 0 and 1, but also an incremental mode where value increase (and I guess you ping-pong which copy is "current").
<Xogium>
rfs613: right that would make sense. I'm unsure why it tells you that it can't read it though. Probably a false error in this case
mmu_man has joined #u-boot
<rfs613>
you'd have to step through it with gdb, or sprinkle in a bunch of prints, to find out.
<Xogium>
yeah hmm
<rfs613>
if you copy the entire contents of the eeprom to a file, and pass that filename to the tool (insteead of eeprom access) does it still reproduce?
<Xogium>
lets see
<Xogium>
yes
<rfs613>
okay, maybe we can transfer that to desktop/laptop, easier to run gdb there...
<Xogium>
definitely
vagrantc has joined #u-boot
prabhakarlad has joined #u-boot
<Xogium>
I think it's really returning the wrong error
<Xogium>
so the error itself is bogus, and it should probably tell you something like 'seems this is redundant copy of the env, and you haven't set up the main copy in fw_env.config'
<Xogium>
or something like that
<rfs613>
well if you can reproduce it easily on PC using config file + your eeprom contents, then you could log a bug... or maybe even provide a fix ;-)
<Xogium>
yea
<Xogium>
I'll see what I can do
<rfs613>
i was able to build a debug-enabled version on x86_64 fairly easily, just some cmake voodoo to enable debug build (so we have symbols in gdb)
<Xogium>
nice
Mis012- has joined #u-boot
<Xogium>
I'll take a break for now, it's been quite a day :)
<Xogium>
thank you so much for your help, once again :D
Mis012 has quit [Ping timeout: 252 seconds]
gsz has quit [Quit: leaving]
tnovotny has quit [Quit: Leaving]
monstr has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #u-boot
gmcastil has quit [Read error: Connection reset by peer]
gmcastil has joined #u-boot
macromorgan has quit [Read error: Connection reset by peer]