<jpsollie>
Kwiboo: I know, but the data training error is of 2022.07
<jpsollie>
2022.04 is ok
akaWolf has joined #u-boot
naoki has quit [Quit: naoki]
<Kwiboo>
ahh, I only tested if TPL could continue to next stage, since my rk3328 got stuck in TPL, did not look at anything related to training error :)
akaWolf has quit [Ping timeout: 248 seconds]
<jpsollie>
yeah, in 2023.4-rc1, I got the "out of memory" error
<jpsollie>
so it's also something related to memory
<jpsollie>
but not completely the same
thopiekar has quit [Ping timeout: 260 seconds]
mmu_man has quit [Ping timeout: 246 seconds]
thopiekar has joined #u-boot
akaWolf has joined #u-boot
zibolo has joined #u-boot
akaWolf has quit [Ping timeout: 248 seconds]
<qschulz>
how does one debug a size increase between compiler output for the same source?
<qschulz>
my TPL is too big when built with Yocto's gcc 11.3 but not with Fedora's gcc 12.2
<qschulz>
288 bytes difference ~3% size increase
clarity has quit [Ping timeout: 268 seconds]
clarity has joined #u-boot
clarity has quit [Ping timeout: 260 seconds]
clarity has joined #u-boot
camus has quit [Quit: camus]
<qschulz>
mmmm I downloaded a gcc 11.3.0 toolchain and there's no size increase... let's go down the rabbit hole of flags......
akaWolf has joined #u-boot
<marex>
qschulz: LTO ?
<jpsollie>
maybe no_inline?
<marex>
qschulz: look at objdump/readelf, binman also has some size change tracking functionality
<qschulz>
marex: 2019.10 version, definitely not using binman :)
<marex>
qschulz: buildman ... sorry
<marex>
qschulz: I confused my men
akaWolf has quit [Ping timeout: 268 seconds]
akaWolf has joined #u-boot
ldevulder has quit [Remote host closed the connection]
ldevulder has joined #u-boot
akaWolf has quit [Ping timeout: 255 seconds]
akaWolf has joined #u-boot
mmu_man has joined #u-boot
mmu_man has quit [Ping timeout: 265 seconds]
<Forty-Bot>
jpsollie: try bloatometer from Linux
<marex>
Forty-Bot: wow
<Forty-Bot>
err, I guess I should have pinged qschulz ?
mncheck has quit [Remote host closed the connection]
<sjg1>
You have to do the building step first, then use '-s' to check it
<Forty-Bot>
I like bloatometer for one-offs since it is easier to set up
<Tartarus>
But, that's a lot harder to do when the change is "changed compiler" not "changed code"
<Tartarus>
qschulz: I'd go and take the u-boot-spl.map from both compilers, and do some reg'ing to get something you can use diff to compare with
<sjg1>
Tartarus: Er, yes, in fact it isn't supported. Neither is checking bloat between random commits, which would be a nice feature (e.g. to compare releases)
<Tartarus>
Well, you can kinda do random commits with --step 0, but, it's not going to be as interesting as you might think, just because every commit changes things a little, just about
<Tartarus>
--step 0 -b v2022.07..v2023.01 or so, works
<sjg1>
Tartarus: Ah OK, just for two releases, yes. If there are boards that don't get touched for a few releases, it could be useful
<Tartarus>
sjg1: There's global changes all the time
<Tartarus>
I size check 95% of the PRs I get :)
<Tartarus>
(maybe a bit higher)
<sjg1>
Tartarus: Yes I know :-)
<jpsollie>
arch/arm/lib/crt0_64.S:85: Error: constant expression expected at operand 2 -- `ldr x0,=((CONFIG_SYS_INIT_RAM_ADDR+CONFIG_SYS_INIT_RAM_SIZE-480))' <-- anyone who knows where those missing variables in my config file might be?
<jpsollie>
it looks like " ldr x0, =(SYS_INIT_SP_ADDR)" gets expanded, but it should go through it a second time ... is this a wrong ordering of includes?
prabhakarlad has quit [Quit: Client closed]
<Tartarus>
grep around for them without the CONFIG prefix
<Tartarus>
they might have been renamed to CFG
rburkholder has quit [Remote host closed the connection]
akaWolf has quit [Ping timeout: 268 seconds]
f_ has joined #u-boot
<f_>
Hi all.
<f_>
I'm having problems compiling U-Boot v2020.07
<f_>
LD u-boot
<f_>
/usr/bin/ld.bfd: read-only segment has dynamic relocations
<f_>
make: *** [Makefile:1755: u-boot] Error 1
<f_>
/usr/bin/ld.bfd: warning: u-boot has a LOAD segment with RWX permissions
<f_>
Does anyone know what's the problem?
<f_>
It went pretty smoothly until that point.
<marex>
add --no-warn-rwx-segments to LDFLAGS
<marex>
toolchain is too new, that's the problem
<f_>
Yeah. That's not the problem. The second message ld prints to the screen appears to be the problem though.
<f_>
I did try adding that to LDFLAGS and I still got the same error, just without the warning.
<marex>
is that stock 2020.07 or some vendor downstream fork ?
<Tartarus>
Is that clang?
<f_>
Stock v2020.07 with a patch on top.
<f_>
(Just changes a defconfig)
<marex>
does it work with current mainline ?
<f_>
What works with mainline?
<marex>
i.e. u-boot/master
<Tartarus>
searching current tree git log for "dynamic relocations" shows a few things that might be needed
akaWolf has joined #u-boot
<marex>
well, git bisect should tell you where it went wrong then ?
<marex>
should be like 10 steps
<f_>
I'm stuck with v2020.07 because HDMI and ethernet broke on newer versions on my board.
<f_>
I would love if someone has a solution to that though.
<marex>
once you find the commit fix, you can backport it
<f_>
marex: What's ...strange is the fact that it compiles fine on my computer, but it doesn't work in the alpine chroot.
<f_>
(this is pmbootstrap BTW. I'm porting a device to postmarketOS)
<marex>
git bisect start u-boot/master v2020.07 .... build, if fail "git bisect good" , if pass "git bisect bad" , repeat until you reach the commit
<f_>
Sure.
<marex>
yes, the bisect good/bad is reversed in this case
<marex>
I think you can even script it, and let it run for a bit
mmu_man has joined #u-boot
<f_>
marex: As said before, it works fine on my computer, but when building with `pmbootstrap` (which builds in an alpine chroot) it fails.
<marex>
look around the memory map, make sure the MMU tables are set correctly
<marex>
oh, is that CA7 ?
<rfs613>
yes, it's not rmobile
<marex>
technically, everything is mach-rmobile
<marex>
because legacy
<marex>
rfs613: so same question -- are you MMU tables set correctly ?
<marex>
arch/arm/cpu/armv7/cache_v7.c that's part of it
<rfs613>
marex: will have a look.. but the odd bit to me is that dcache_enable() seems to work (and do the right thing) if called later in the u-boot boot.
<marex>
arch/arm/lib/cache-cp15.c that is the other one iirc
<marex>
rfs613: well, could it be the mmu tables are set up by then ?
<marex>
there is another odd thing to it, hold on
<marex>
arch/arm/lib/cache.c arm_reserve_mmu()
<marex>
make sure that is called before you enable the dcache
<marex>
make sure tlb_addr is set correctly
<rfs613>
ok, thanks, that gives me two good things to take a look at
<marex>
oh ... are you enabling dcache before reloc ?
<Tartarus>
sjg1: Oh, as I skim the subject lines again, I wonder if a few more of the def_bool n patches couldn't be avoided by just moving the Makefile lines to existing hunks of "don't build these directories for xPL_BUILD being set"
<rfs613>
marex: possibly... I haven't looked at it in a while (other than to confirm the issue still exists after rebasing my patches to lastest master)
<marex>
rfs613: why are these patches not in mainline btw ?