<marex>
Forty-Bot: patch is out, can you double check ?
<marex>
Forty-Bot: funny thing, I am just playing around with rev.200 board and rev.200 SoM , i.e. the production stuff :)
<Forty-Bot>
yeah, that works
* Forty-Bot
is staring at assembly diffs
* Forty-Bot
wishes arm64 had better density
thopiekar has quit [Ping timeout: 245 seconds]
thopiekar has joined #u-boot
qschulz has quit [Read error: Connection reset by peer]
qschulz has joined #u-boot
mmu_man has quit [Read error: Connection reset by peer]
<Forty-Bot>
Tartarus: do you remember if the "sandbox_spl/vpl/noinst" stuff was still failing in CI? https://paste.debian.net/1297166/
mmu_man has joined #u-boot
mmu_man has quit [Read error: Connection reset by peer]
ikarso has quit [Quit: Connection closed for inactivity]
mmu_man has joined #u-boot
apritzel has quit [Ping timeout: 240 seconds]
mmu_man has quit [Read error: Connection reset by peer]
<marex>
Forty-Bot: like SH4 assembler ? :)
<Forty-Bot>
like x86 or thumb :P
<Forty-Bot>
clearing a register takes four bytes!
<marex>
Forty-Bot: x86 is like eating pasta through your nose 3/
<Forty-Bot>
yeah, well, I don't have to eat it :)
<Forty-Bot>
but I do have to fit the pasta in the box somehow
<marex>
Forty-Bot: isnt there some 2 byte something ?
<marex>
I guess no thumb on arm64 ?
<Forty-Bot>
nope :(
<Forty-Bot>
I mean, you could switch to 32-bit mode
<Forty-Bot>
and use thumb
<Forty-Bot>
but that's above my pay grade
<marex>
and it sucks in other ways
vagrantc has joined #u-boot
<Forty-Bot>
the really funny thing is that THUMB_BUILD isn't default y
<marex>
Forty-Bot: btw maybe you can compress the u-boot binary, that should make it fit on the machine, esp. if the DTs and pinmux/clock tables are the source of growth
<marex>
Forty-Bot: I'm doing that on R-Car Gen3
<marex>
u-boot is 1 MiB uncompressed, some 500 kiB compressed
<marex>
gzip
<Forty-Bot>
my current woes are sama5d27_wlsom1_ek_mmc which I believe has literally under 10 bytes to spare
<Forty-Bot>
that may work for U-Boot, but probably not SPL
<marex>
oh jeeze
<marex>
that
<marex>
but that isnt arm64, is it ?
<marex>
Forty-Bot: in these cases, I set the size limit a bit larger, I let the blob compile, and then look at readelf output to find out which symbol hogs the most space
<Forty-Bot>
well, I just sent out my "fix"
mmu_man has joined #u-boot
<Forty-Bot>
and yeah, I've been doing that
<Forty-Bot>
but at some point it's very difficult to squeeze any further bytes
<marex>
Forty-Bot: I know
<marex>
Forty-Bot: I guess no DM in SPL already ?
<Forty-Bot>
it's enabled actually
<marex>
bah
<Forty-Bot>
maybe I can try enabling the dtoc stuff
<marex>
that , or some single-device variant of DM, would likely save a lot of space
mmu_man has quit [Read error: Connection reset by peer]
<Forty-Bot>
of course, all this is a bit difficult without any hardware
<marex>
Forty-Bot: DM optimization could be done in sandbox :)
<Forty-Bot>
how?
<marex>
Forty-Bot: sandbox supports DM in SPL :)
<marex>
see sandbox_spl_defconfig
<Forty-Bot>
yeah, but that's only for generic stuff
<marex>
yes of course, single device DM would likely be generic anyway
Mis012 has quit [Remote host closed the connection]
Mis012 has joined #u-boot
rfried has quit [Client Quit]
rfried has joined #u-boot
Clamor has quit [Ping timeout: 264 seconds]
Clamor has joined #u-boot
<rfried>
Hi tartarus, et all. I Was drafted for reserves duty, I'm unavailable, please proceed with networking, I won't be able to reach it in the upcoming months.
Clamor has quit [Read error: Connection reset by peer]
Clamor has joined #u-boot
flom84 has joined #u-boot
flom84 has quit [Remote host closed the connection]
flom84 has joined #u-boot
apritzel has joined #u-boot
mmu_man has quit [Ping timeout: 264 seconds]
mmu_man has joined #u-boot
flom84 has quit [Quit: Leaving]
dsimic has quit [Ping timeout: 246 seconds]
dsimic has joined #u-boot
apritzel has quit [Ping timeout: 260 seconds]
Clamor has quit [Ping timeout: 258 seconds]
Clamor has joined #u-boot
Clamor has quit [Ping timeout: 240 seconds]
Clamor has joined #u-boot
___nick___ has joined #u-boot
<Tartarus>
rfried: Ah, understood.
<rfs613>
Forty-Bot: was thinking this corruption some more. Let's assume .text is being mangled some time earlier, as you suggested. This would be data writes (like a bad memcpy) and goes into dcache. Sometime later, it gets flushed to DDR, and then even later, it may appear in the instruction stream when icache misses.
<rfs613>
This is all assuming there are no explicit cache flush operations in the meantime.
<rfs613>
But when I am using JTAG to disassemble parts of the .text segment, or equivalently, to just dump the memory contents in hex, those are *data* reads. So I would expect to see whatever the CPU would read as data.
<rfs613>
It seems that the *data* suddenly changes, just as the CPU executes (in this case) a "bl" instruction that jumps to env_flags_init()
<rfs613>
if it was corrupted earlier on, and just didn't appear in the instruction stream yet, then JTAG read should still see the bad data, prior to the "bl"
<marex>
rfs613: you can try invalidate_dcache_all()/invalidate_icache_all() or dcache_disable()/dcache_enable() cycle and see if the corruption happens before/after the cycle
rvalue has joined #u-boot
persmule has joined #u-boot
apritzel has quit [Ping timeout: 260 seconds]
mmu_man has quit [Read error: Connection reset by peer]
Mis012- has joined #u-boot
Mis012 has quit [Ping timeout: 256 seconds]
Gravis has quit [Ping timeout: 240 seconds]
Gravis has joined #u-boot
prabhakarlad has joined #u-boot
prabhakar has joined #u-boot
macromorgan has quit [Quit: Leaving]
<Forty-Bot>
why does buildman rebuild old commits?
<Forty-Bot>
and if I then modify my_branch (but not its upstream), buildman will rebuild the upstream again, as well as my_branch
<Forty-Bot>
shouldn't it see that the upstream is already built?
mmu_man has joined #u-boot
<Tartarus>
It would be a nice enhancement to buildman to see that in that case it could re-use your output branch, for commits that have the same hash, yes.
<Forty-Bot>
If I run with e.g. `-c 1` and then do -SsB will I be able to get the summary?
<Tartarus>
So yes, so long as you don't start adding/changing commits, buildman will let you do whatever you want
<Tartarus>
Right now my "problem" is that the size of "your branch is behind by X commits" keeps growing, and that will bite me once there's buildman changes, like right now
<Forty-Bot>
yeah, you sent them in ~july I think
apritzel has joined #u-boot
macromorgan has joined #u-boot
<Tartarus>
Few tweaks since then to better handle branches other than master being the upstream, and merge commits
slobodan has joined #u-boot
qqq has joined #u-boot
mmu_man has quit [Ping timeout: 255 seconds]
mmu_man has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
<Forty-Bot>
Tartarus: unfortunately, -c and then -s doesn't work
<Forty-Bot>
and it deletes the old builds :l
<Forty-Bot>
what's the point of --force-build when buildman always force builds?
apritzel has quit [Ping timeout: 264 seconds]
Clamor has quit [Read error: Connection reset by peer]
___nick___ has quit [Ping timeout: 264 seconds]
<Tartarus>
sjg1: please make sure to try v2 of your series with Image.xz or whatever too
<Tartarus>
Forty-Bot: could be I don't need it, yeah. I've had this script for forever
jclsn23 has joined #u-boot
jclsn23 has left #u-boot [#u-boot]
<sjg1>
Tartarus: Do you mean the one I just sent? I tried it with .gzip and it seemed OK. I was just surprised that compression didn't seem to work
<Tartarus>
To be clear, I mean booti Image.gz, not bootm. The booti case should be fine, so long as the required env vars were set already
apritzel has joined #u-boot
<Forty-Bot>
ok, so if you don't change anything
<Forty-Bot>
then old builds will be reused
<Forty-Bot>
so you can e.g. run buildman once and then say "hm, what about boards X Y and Z" and include those too