<NishanthMenon>
Tartarus: thanks. I am just lost on how we maintain bindings.. is kernel the canonical source? Or UBoot binding? I think for kernel dts, kernel binding should be. Thoughts?
slobodan has quit [Ping timeout: 240 seconds]
Forty-Laptop has joined #u-boot
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #u-boot
calebccff has quit [Server closed connection]
calebccff has joined #u-boot
mmu_man has quit [Ping timeout: 240 seconds]
Manouchehri has quit [Server closed connection]
Manouchehri has joined #u-boot
ikarso has joined #u-boot
as_g5pw is now known as g5pw
g5pw is now known as 077AAJ4CU
grgy has quit [Server closed connection]
grgy has joined #u-boot
alan_o has quit [Ping timeout: 252 seconds]
j`ey has quit [Server closed connection]
j`ey has joined #u-boot
sakman_ has quit [Quit: Leaving]
sakman has joined #u-boot
eloy has quit [Server closed connection]
eloy has joined #u-boot
Clamor has joined #u-boot
jsmolic has quit [Server closed connection]
jsmolic has joined #u-boot
bradfa has quit [Server closed connection]
bradfa has joined #u-boot
ndesaulniers has quit [Server closed connection]
ndesaulniers has joined #u-boot
foxtrot has quit [Server closed connection]
foxtrot has joined #u-boot
monstr has joined #u-boot
GNUtoo has quit [Ping timeout: 264 seconds]
GNUtoo has joined #u-boot
goliath has joined #u-boot
naoki has quit [Quit: naoki]
zar has quit [Server closed connection]
zar has joined #u-boot
mckoan|away is now known as mckoan
swiftgeek has quit [Server closed connection]
Clamor has quit [Read error: Connection reset by peer]
Clamor has joined #u-boot
swiftgeek has joined #u-boot
polprog has quit [Server closed connection]
polprog has joined #u-boot
frieder has joined #u-boot
goliath has quit [Quit: SIGSEGV]
sszy has joined #u-boot
tnovotny has joined #u-boot
redbrain has quit [Read error: Connection reset by peer]
prabhakarlad has joined #u-boot
Clamor has quit [Read error: Connection reset by peer]
prabhakar has joined #u-boot
Clamor has joined #u-boot
Blok has joined #u-boot
qsx has quit [Server closed connection]
qsx has joined #u-boot
redbrain has joined #u-boot
jkridner has quit [Server closed connection]
jkridner has joined #u-boot
diederik has quit [Server closed connection]
diederik has joined #u-boot
Clamor has quit [Ping timeout: 260 seconds]
Clamor has joined #u-boot
hsv has quit [Server closed connection]
hsv has joined #u-boot
Clamor has quit [Ping timeout: 260 seconds]
sicelo has quit [Ping timeout: 240 seconds]
sicelo has joined #u-boot
sicelo has joined #u-boot
Clamor has joined #u-boot
davlefou has quit [Ping timeout: 264 seconds]
finga has quit [Ping timeout: 240 seconds]
Clamor has quit [Read error: Connection reset by peer]
finga has joined #u-boot
Clamor has joined #u-boot
ezulian has joined #u-boot
davlefou has joined #u-boot
MWelchUK71 has joined #u-boot
apalos has quit [Server closed connection]
cottsay has quit [Ping timeout: 240 seconds]
cottsay has joined #u-boot
MWelchUK7 has quit [Ping timeout: 240 seconds]
MWelchUK71 is now known as MWelchUK7
apalos has joined #u-boot
paulbarker has quit [Server closed connection]
paulbarker has joined #u-boot
goliath has joined #u-boot
Tartarus has quit [Server closed connection]
Tartarus has joined #u-boot
agraf has quit [Server closed connection]
agraf has joined #u-boot
Blok has quit [Quit: Client closed]
Clamor has quit [Ping timeout: 245 seconds]
Clamor has joined #u-boot
mlaga97 has quit [Server closed connection]
mlaga97 has joined #u-boot
cyrozap has quit [Server closed connection]
cyrozap has joined #u-boot
Clamor has quit [Read error: Connection reset by peer]
Clamor has joined #u-boot
marex has quit [Server closed connection]
marex has joined #u-boot
pivi has quit [Ping timeout: 240 seconds]
pavelow has quit [Server closed connection]
pavelow has joined #u-boot
dhruvag2000 has quit [Server closed connection]
dhruvag2000 has joined #u-boot
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
ex--parrot has quit [Server closed connection]
ex-parrot has joined #u-boot
dsimic has quit [Ping timeout: 240 seconds]
dsimic has joined #u-boot
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
derRichard has quit [Server closed connection]
derRichard has joined #u-boot
Clamor has quit [Read error: Connection reset by peer]
<Clamor>
alpernebbi: irrelevant, kernel doesn't care of size
<mkorpershoek>
please let me know what you find. I imagine that if this has been part of checkpatch.pl for 3 years, it's probably useful !
NishanthMenon has quit [Server closed connection]
NishanthMenon has joined #u-boot
iprusov has quit [Server closed connection]
<Clamor>
mkorpershoek: sure, but you never know what you may find ;)
<broonie>
Clamor: Size makes a difference with the kernel too, the expectation is that if an if unconditionally has one value the compiler will do the right thing with dead code elimination.
iprusov has joined #u-boot
<Clamor>
broonie: I do hope so
<marex>
Clamor: compilers have gone better, hence like broonie said, dead code elimination should work
<marex>
Clamor: the other thing is, compiler can validate the code while compiling it
<marex>
if the code is #ifdef'd out by a preprocessor and dropped by preprocessor, bitrot may set in
<marex>
(and will)
<broonie>
Indeed.
<Clamor>
mkorpershoek marex 8 bytes more per 14 lines of code
<marex>
Clamor: hold on, lemme plug my crystal ball into the USB-C charger, it is discharged ... sec
Clamor has quit [Read error: Connection reset by peer]
Clamor has joined #u-boot
akaWolf has joined #u-boot
<Tartarus>
calebccff: Sync with xypron about sphinx stuff in general, that's one of his areas, and MAINTAINERS should get a small change too, heh, so it's not just relying on git log in there.
<xypron>
Tartarus: Anything in special I should look at?
<Tartarus>
re if (...) vs #if, when we use if (CONFIG_IS_ENABLED(...)) and similar, when false the compiler optimizes things out so there's no size impact, but we do get static checks, etc done. But it's still not a 100% rule in that sometimes that does make readability worse, not better
<Tartarus>
xypron: Just cc'd you on a reply where we need to cherry-pick something from the kernel for newer build hosts
sauce has quit [Server closed connection]
sauce has joined #u-boot
Forty-Bot has quit [Server closed connection]
Forty-Bot has joined #u-boot
<Clamor>
Tartarus: thanks
goliath has quit [Quit: SIGSEGV]
<rfs613>
marex: once you get your crystal ball charged back up, can I borrow it? I'm still struggling to debug this hang, I have run many tests now, have some more data, but not managing to draw any conclusion...
alpernebbi has quit [Server closed connection]
alpernebbi has joined #u-boot
mmu_man has quit [Ping timeout: 246 seconds]
<marex>
rfs613: do you still see the memory content moving around ?
<rfs613>
marex: yes and no ;)
<rfs613>
marex: when I change the test, such as putting in nops, the behaviour changes
<rfs613>
marex: the main new fact is related to caches, when I disable DCACHE, the problem goes away. Changing ICACHE seems to have no effect.
<rfs613>
marex: i narrowed it down more, the problem seems to occur when adding a new environment variable. If I disable dcache just around that step, it is okay too.
<rfs613>
marex: i've been trying to place breakpoints earlier in the boot, to try and spot when things go wrong, but without much luck
<rfs613>
marex: i also found that if I single step my way through, there is no hang, everything works properly.
qqq has quit [Quit: leaving]
mmu_man has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
tucanae47 has quit [Read error: Connection reset by peer]
jybz has quit [Excess Flood]
tucanae47 has joined #u-boot
<rfs613>
marex: I tried the same default uboot environment in the sandbox, and ran it under valgrind a bunch of ways, to try and see if it could catch any out-of-bounds accesss etc, but that didn't turn up anything either.
jybz has joined #u-boot
<marex>
rfs613: dzeez, lovely
<marex>
rfs613: didnt you say if you plugged in different DRAM settings, the issue also went away ?
<marex>
I'd focus on DRAM tbh
<Tartarus>
xypron: I think you forgot a --suppress-cc=default on that patch ;)
<rfs613>
marex: yeah, well, I have two boards, one with 256M and one with 1GB DDR... different chips with different DRAM settings.
<rfs613>
marex: the problem only seems to happen on the 256M board variant. On the 1GB it works fine, even with the exact same binary of u-boot etc.
<rfs613>
marex: I did disable the memory-size probing, forcing the 1GB board to use the settings from 256M baord... and this still passed.
shiz has quit [Server closed connection]
shiz has joined #u-boot
<rfs613>
marex: this was just a hack to see if I could get the 1GB board to fail, if I ran u-boot at the exact same physical address & memory layout. Obviusly it is not really a valid way to operate the 1GB board. And yet, it did not hang.
<rfs613>
marex: both boards pass all the memory diagnostics (mtest with the SYS_ALT_MEMTEST) as well as from linux... I have no reason to suspect the DDR is somehow bad.
prabhakarlad has joined #u-boot
Clamor has quit [Ping timeout: 245 seconds]
Clamor has joined #u-boot
project10 has quit [Ping timeout: 260 seconds]
Clamor has quit [Ping timeout: 245 seconds]
Clamor has joined #u-boot
<marex>
rfs613: have you tried memtester in Linux too ?
<marex>
rfs613: or something like compiling the kernel ?
<marex>
rfs613: that usually triggers all the memory stability corner cases
<rfs613>
marex: memtester under linux, yes.
project10 has joined #u-boot
<rfs613>
these are not new boards, i've been working on them for several years now, and we've not seen this behaviour before.
Clamor has quit [Ping timeout: 245 seconds]
Clamor has joined #u-boot
<marex>
rfs613: but the memory initialization is now different, is it not ?
tnovotny has quit [Ping timeout: 260 seconds]
<rfs613>
marex: yes, but that changed quite some time back, the problem only appeared more recently. As well I have rolled back the mem init change, this was in fact my first guess, but it made no difference.
<marex>
rfs613: did you try to bisect the issue ?
<marex>
(I am confused right now)
<rfs613>
marex: there's not really any difference in the code. Our existing u-boot version (and all the previous ones) have booted fine (and still boot fine).
<rfs613>
marex: the change that triggered the behaviour was to enable CONFIG_CMD_I2C
<rfs613>
marex: though I have subsequently discovered it's not unique to that particular CONFIG symbol
<marex>
rfs613: so did some section (bss ? stack ?) grow a bit too much ?
<rfs613>
marex: there are small changes in text, data, bss size when changing the CONFIG settings.
<rfs613>
nothing drastic though, and I don't see any evidence that we've crossed some hidden threshold
<rfs613>
marex: whats more, when I run the identical binary on the two boards, it only fails on the 256m version. I've even tried removing all the run-time DDR size stuff, so that the 1GB board only uses 256M. This does not hang.
flom84 has joined #u-boot
flom84 has quit [Remote host closed the connection]
<rfs613>
marex: i've currently got u-boot running from SRAM, doing a mtest on the DDR range where things seem to go wrong. No failures observed so far ;-)
<marex>
rfs613: I think I am still confused by this ... with different DRAM config it works, with cache disabled it works, with older version it works ...
<marex>
rfs613: so ... the old version worked by pure chance ?