sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
apritzel_ has joined #u-boot
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #u-boot
camus has quit [Ping timeout: 240 seconds]
camus has joined #u-boot
apritzel_ has quit [Ping timeout: 240 seconds]
frieder has joined #u-boot
lucaceresoli has joined #u-boot
mckoan|away is now known as mckoan
chrfle_ has joined #u-boot
chrfle has quit [Ping timeout: 240 seconds]
chrfle_ is now known as chrfle
tre has joined #u-boot
sszy has joined #u-boot
tnovotny has joined #u-boot
jclsn has joined #u-boot
zibolo has joined #u-boot
monstr has joined #u-boot
matthias_bgg has joined #u-boot
apritzel_ has joined #u-boot
lucaceresoli has quit [Remote host closed the connection]
lucaceresoli_ has joined #u-boot
mmu_man has joined #u-boot
matthias_bgg has quit [Ping timeout: 252 seconds]
frieder has quit [Ping timeout: 252 seconds]
matthias_bgg has joined #u-boot
prabhakarlad has joined #u-boot
frieder has joined #u-boot
<marex>
Forty-Bot: dont instantiate devices which are not needed in SPL in the first place, then you need 0 bytes per device instance
<marex>
qyx: mainline u-boot does support arbitrary UART, are you using the downstream stuff from ST maybe ?
sm53 has quit [Ping timeout: 252 seconds]
sm53 has joined #u-boot
sm53 has quit [Remote host closed the connection]
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
mmu_man has quit [Ping timeout: 256 seconds]
haritz has quit [Ping timeout: 252 seconds]
nacre has joined #u-boot
<nacre>
Hello there, I'm trying to use SoC-specific functions that are defined for ARM (arch/arm/include/asm/arch-<SoC>), but for a RISC-V build. Can I simply copy/paste the 'arch-<SoC>' directory in the RISC-V one (arch/riscv/include/) without any issue or is there something else to do for such a case?
<Tartarus>
Erm, is this for the allwinner riscv part?
<nacre>
Yeah, for 'arch-sunxi' I'm trying to use its GPIO within u-boot, but I can't figure out how to access them properly
<nacre>
I might understand things completely wrong about this though, so don't hesitate to tell me if my question doesn't make any sense
haritz has joined #u-boot
haritz has joined #u-boot
<Tartarus>
Seeing how the NXP platforms share code between powerpc and arm is a good general starting path, but it's also not complete there
<Tartarus>
High level, stuff should be out of arch/ and under drivers/gpio/ and pull register locations, etc, from dt
<nacre>
Thanks a lot for the tips, I'll take a look at that
tnovotny has quit [Ping timeout: 256 seconds]
tnovotny has joined #u-boot
<mwalle_>
Tartarus: speaking of NXP, there was still no answer why that code size increased for that CAAM driver, no?
<mwalle_>
it seems like it was working before, though I don't know anything because I'm just a layerscape user
<mwalle_>
(where that is not a hard dependency now)
<Tartarus>
mwalle_: Ah, about imx6dl_mamoj ? I think it was that the board in question enables a bunch of stuff not typically enabled, so that's why it overflows, and the general growth seems to be from the features / conversions the series itself is doing
<mwalle_>
*don't know anything about the HAB boot
<Tartarus>
And "just enable LTO" is the solution for now
<Tartarus>
And this also adds to the pile of "we need to figure out DM/DT stuff but with less size growth" reasons.
<mwalle_>
Tartarus: but what does this code add to HAB which wasn't there before? Or why is it needed at all in SPL
<mwalle_>
sure, you could add stuff and increase the SPL size, but it will be harder everytime to add stuff which might be essential then
<Tartarus>
Yeah, I think the answer is "convert to DM, use more space, lament the state of the world"
<Tartarus>
I forget where the last series of changes sjg1 and, ugh, I'm forgetting if it was Alper or someone else, had going to try have a "DM uses less space" option going, ended up
<mwalle_>
Tartarus: but it looks like both options are still available, eg. CAAM with DM and without, judging by the ifdeffery
torez has joined #u-boot
<Tartarus>
Maybe for the boards that are CAAM and not SPL_DM, as SPL_DM isn't required?
<marex>
qyx: so mainline without the atf nonsense ?
<marex>
what ST calls "basic" config ?
<qyx>
basic is SPL without ATF
<qyx>
another fun part is gonna be LPDDR3, nobody uses that
monstr has quit [Remote host closed the connection]
mmu_man has joined #u-boot
<Forty-Bot>
marex: well, if you don't use so much memory it helps too
<Forty-Bot>
e.g. if you don't have to cache enable/rate counts then you can use maybe ~24 bytes just to store the parent
<marex>
Forty-Bot: if you dont use any memory at all, it is better
<Forty-Bot>
yes, but CCF clocks need to store the parent somewhere
<Forty-Bot>
and a two-part approach is good as well :)
<marex>
qyx: as for LPDDR3, the controller in STM32MP1 is the same as Altera N5X, ZynqMP, some rockchip and allwinner SoCs, iMX8M and I think I forgot a few
<marex>
qyx: so the LPDDR3 is likely tested elsewhere, I wouldn't worry about that too much
<marex>
Forty-Bot: you can still have a considerably reduced clock tree, even if you need the clock parents
<qyx>
marex: oh thanks, good to know
<Forty-Bot>
marex: that sort of change requires per-board/per-arch testing, while ideally reducing bytes used requires testing on one board
<Forty-Bot>
which is why I'm more interested in it
camus has quit [Ping timeout: 268 seconds]
nacre has quit [Quit: leaving]
<marex>
qyx: you're starting the SPL via JTAG btw ?
<marex>
qyx: did you load the SPL including the DT ?
<marex>
Forty-Bot: yes, removing the unused clock altogether would be the more beneficial change, some sort of pseudo-optimization which does not solve the root cause of the problem is pretty much useless, as the problem will grow back sooner or later
<Forty-Bot>
the root cause is that number_of_clocks*bytes_per_clock is too large
<Forty-Bot>
reducing either (or both) will solve the problem
Luker has left #u-boot [Bye Bye]
<marex>
Forty-Bot: the bloat will creep back in over time like it did thus far, just don't register useless clock in the first place
<marex>
use something like assigned-clocks = <...> to specify SPL clocks that should be registered in DT and skip the rest
<Forty-Bot>
how will bloat creep back in?
<marex>
Forty-Bot: just like it did with driver model ;-)
<Forty-Bot>
you can just as easily argue that clocks will creep back in :)
<marex>
no, they won't if you list the clock you require in SPL in DT, like with u-boot,dm-spl;
zibolo has quit [Ping timeout: 256 seconds]
matthias_bgg has quit [Quit: Leaving]
matthias_bgg has joined #u-boot
torez has quit [Remote host closed the connection]
darkapex is now known as jai
jai is now known as darkapex
tre has quit [Remote host closed the connection]
tnovotny has quit [Quit: Leaving]
guillaume_g has quit [Quit: Konversation terminated!]
<qyx>
marex: yeah load to sysram at 0x2ffc2500 (defined in config) and run
<qyx>
I am loading the spl/u-boot-spl.bin, so not the -nodtb one
<qyx>
it has the same sha1 as spl/u-boot-spl-dtb.bin, so I would say yes
<qyx>
but regardless of that, do I assume it correctly that doing while (true) { toggle_led(); } in board_early_init_f() stops the boot and stays toggling forever?
<qyx>
isn't there any kind of watchdog run or a timer with interrupt or whatever I could miss?
<qyx>
it really looks like as if I missed a watchdog reset in the while (true) loop causing the MPU to restart