<sjg1>
jpsollie: Can't see the pastbin...but anyone, you could try adding '#define LOG_DEBUG' to the top of common/spl/spl.c - one question is whether it is dying in TPL , or getting to SPL. You can also bisect it
<mps>
alpernebbi: would you tell a little more about you message posted last night, about cros-ec spi problem
<mps>
any hint could be useful
akaWolf has joined #u-boot
akaWolf has quit [Ping timeout: 248 seconds]
akaWolf has joined #u-boot
<hays>
Ok, I've tried a bunch of iterations to flash u-boot on my odroid-N2L and nothing is working
<hays>
I have followed the following steps (1) clone repo from master (2) make odroid-n2l_defconfig (3) clone the libreelec utilities and run the script (4) flash uboot.bin.sd.bin with the "hole"
<alpernebbi>
it's sending a EC_CMD_GET_NEXT_EVENT that peach-pi doesn't support, and falls back to older methods if it gets EC_RES_INVALID_COMMAND
sakman_ is now known as sakman
<alpernebbi>
your irc log says `cros_ec_command: Returned status 1`, where EC_RES_INVALID_COMMAND is also 1
<alpernebbi>
but in the end I guess that printf() should be a debug() or support other EC_RES_* in include/ec_commands.h
frieder has quit [Ping timeout: 252 seconds]
mckoan is now known as mckoan|away
<sjg1>
alpernebbi: Ah, yes OK in that case it should be a debug
<sjg1>
or log_debug() perhaps
vagrantc has joined #u-boot
naoki has quit [Quit: naoki]
<mps>
alpernebbi: ah good, now understand
<jpsollie>
sjg1: any idea how I could bisect it?
<jpsollie>
and why adding it to the top of spl? is this a typo? or intentional?
mmu_man has joined #u-boot
<Forty-Bot>
needs to be at the top so it is defined before common.h is included
<jpsollie>
yes, but why spl? shouldn't it be at the top of tpl?
<Forty-Bot>
yes
<Forty-Bot>
but spl is also good
<jpsollie>
because?
<Forty-Bot>
tpl isn't very chatty, and it could be failing after TPL starts SPL but before SPL prints its banner
<jpsollie>
aha
<jpsollie>
ok, I'll try that
<jpsollie>
is it possible there's an issue when the system moves from early debug uart stage to really "initialized" serial port?
<Forty-Bot>
yes; you can try enabling the debug uart if you think that is the case
<jpsollie>
that's what I meant: the early debug uart option is marked, so is it possible it is initializing the serial port and the uart2 doesn't recover from re-initialization?
<Forty-Bot>
generally, debug uart doesn't do any initialization, however your board can always be doing its own init
<Forty-Bot>
read your serial driver
<jpsollie>
"Error: SPL image is too large (size 0xa000 than 0x7000)" --> looks like I got some trimming to do with LOG_DEBUG enabled :)
<Forty-Bot>
try enabling LTO if you haven't
<Forty-Bot>
and try just enabling debug for spl.c
<Forty-Bot>
since that is a lot fewer prints
<jpsollie>
does LTO work with GCC these days?
<Forty-Bot>
yes
<Tartarus>
Blah
mmu_man has quit [Ping timeout: 260 seconds]
<Tartarus>
test/lib/lmb.c has I think all of the ut_asserteq call arguments backwards
<Tartarus>
And I only notice / care since fixing my mistake, then changing the default from 8 to 16 is failing in non-obvious ways
<Tartarus>
Not just because the test is hard-coded to 8
<Tartarus>
debug prints to the rescue, heh
<Tartarus>
Yup, there we go, OK
mmu_man has joined #u-boot
<jpsollie>
/usr/lib/gcc/aarch64-unknown-linux-gnu/12.2.0/../../../../aarch64-unknown-linux-gnu/bin/ar: /usr/lib/gcc/aarch64-unknown-linux-gnu/12.2.0/../../../../aarch64-unknown-linux-gnu/bin/ar: cannot execute binary file <--looks like GCC doesn't like LTO ... something I can do about it? or some fat objects which usually aren't that important so I can strip them?
<Tartarus>
Your toolchain installation is broken, jpsollie
<Tartarus>
We have a number of targets in CI that are aarch64 and default to LTO, using the kernel.org gcc
<Tartarus>
Or if not your toolchain, do a realclean and try again
<rfs613>
it seems quite common to call dcache_enable() in a board-specific enable_caches() function. When i try that on my armv7 board, it hangs the board.
<rfs613>
however if I skip the call in enable_caches(), I can get to the u-boot prompt, and from there I can turn on dcache successfully via cmd/cache.c (which calls dcache_enable())
<rfs613>
any idea why it would fail when called from enable_caches()?
<Tartarus>
sjg1: Can you check what I did for the tests please?
<Tartarus>
rfs613: What do you mean? That's not the common case for ARM/RISC-V
<Tartarus>
common/board_r.c calls enable_caches() there
<rfs613>
Tartarus: right, with enable_caches() typically containing a call to dcache_enable()
<rfs613>
i'm seeing a hang if I put in that call to dcache_enable()
<rfs613>
and yet if I call dcache_enable after reaching u-boot prompt, it seems to work fine (and memory tests run faster, so it seems to really be enabling the cache)
<rfs613>
I'm sure it is something I've botched up... just can't quite put my finger on what it might be
<Tartarus>
What SoC are you on?
<Tartarus>
This, generally, should be done already
<Tartarus>
So I am a tad confused
<rfs613>
Tartarus: it's the RZ/N1 which I am trying to bring upstream
<rfs613>
to clarify my original question, I wrote "board-specific enabe_caches()" but I should have said arch- or subarch-specific.
<Tartarus>
And that's not settting CONFIG_RCAR_GEN3 ?
<Tartarus>
I keep getting back to this since my first guess is trying to re-enable already enabled caches might go badly
<Tartarus>
Dunno if marex has any ideas here
<rfs613>
Tartarus: it's not RCAR architecture, despite the somewhat similar name.
<rfs613>
that was from a while, back, I have commented out the call to dcache_enable()
<jpsollie>
Tartarus: make distclean didn't help
<rfs613>
trying to sort that out properly now... will chat with marex next time
<jpsollie>
the toolchain is for gentoo cross compiling, and in the build system -flto is no issue
<Tartarus>
jpsollie: Then something is wrong with your toolchain? the kernel.org one works fine for a number of platforms, maybe use buildman to fetch a copy
<jpsollie>
do you think so?
<jpsollie>
any way I can check that aside from recompiling gcc from scratch?
<Tartarus>
I mean, grab one of the pre-builts from kernel.org and use that
<Tartarus>
If that works, there's something odd with your toolchain
<Tartarus>
and not the code base/etc
<jpsollie>
spl_early_init
<jpsollie>
alloc space exhausted
<jpsollie>
this is what a defconfig prints
<jpsollie>
after the TPL banner
<jpsollie>
i recreated the defconfig and enabled all possible console / logging / etc
<jpsollie>
and the DEBUG define in spl.c
<Tartarus>
jpsollie: OK, sorry, lemme re-read everything from the top, again
<jpsollie>
nono, this is what I got with a new build
<jpsollie>
not with the one 5 hours ago
<Tartarus>
OK, so, the root problem you have is that nanopi-r2s-rk3328_defconfig isn't booting on top of tree right now