<d-s-e>
I'm trying master after having some problems with v2022.01, now I have no virtio devices anymore. Any ideas?
mckoan is now known as mckoan|away
torez has joined #u-boot
<ccf>
lpddr4_set_ctl: channel 0 training pass
<ccf>
Finish SDRAM initialization...
<ccf>
lpddr4_set_ctl: channel 1 training pass
<ccf>
lpddr4_set_rate: change freq to 800MHz 1, 0
<ccf>
Missing DTB
<ccf>
... These are the last lines of custom rk3399 board, I cannot get it to boot further (current next). I guess it is the SPL (after TPL) telling "Missing DTB", right?
d-s-e has quit [Ping timeout: 246 seconds]
d-s-e has joined #u-boot
d-s-e has quit [Ping timeout: 255 seconds]
d-s-e has joined #u-boot
<d-s-e>
klankermeier
<d-s-e>
sorry, ignore that, wrong window.
Net147 has quit [Ping timeout: 255 seconds]
Net147 has joined #u-boot
Net147 has joined #u-boot
Net147 has quit [Changing host]
<marex>
qschulz: ^
mmu_man has quit [Ping timeout: 246 seconds]
macromorgan has quit [Quit: Leaving]
mmu_man has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
sauce has quit [Quit: sauce]
redbrain has quit [Read error: Connection reset by peer]
sauce has joined #u-boot
redbrain has joined #u-boot
<ccf>
Any ideas how to debug "Missing DTB" on rk3399?
monstr has quit [Remote host closed the connection]
matthias_bgg has quit [Ping timeout: 246 seconds]
hanetzer has quit [Ping timeout: 246 seconds]
hanetzer has joined #u-boot
<marex>
ccf: a good start would be to pastebin the entire log, not just random fragment of it
<d-s-e>
After failing with EFI, I tried another approach with a bare u-boot on qemu. Loading and running a script works fine, but now booting the kernel is not working anymore: https://paste.debian.net/hidden/c6401d47/
frieder has quit [Remote host closed the connection]
<d-s-e>
Any ideas what's going wrong here?
<Tartarus>
d-s-e: I wonder if these days you need to use EFI boot stub really
<marex>
do s@puts.*@printf("Missing DTB at %x\n", blob);@ and see what's up
<marex>
maybe the blob is really missing, or the header is broken
<marex>
did it ever work before or is this a new hardware ?
<marex>
Tartarus: as long as Marcel is fine with that ... the menlo board does not use CAAM anyway, but uh, where is the CAAM inited in SPL if arch_misc_init() isn't called ?
<sjg1>
d-s-e: Are you booting from 64-bit U-Boot to 64-bit Linux? We don't have CI tests for this at present. Which U-Boot board are you building?
<sjg1>
xypron: What test suite do you use for U-Boot's UEFI support?
<xypron>
sjg1 UEFI SCT
GNUtoo has quit [Remote host closed the connection]
<apalos>
and that thing checks the TPM code conformance as well wrt to the TCG specs
<apalos>
but it does take some time to run on real boards, on qemu it's saner
<apalos>
IIRC u-boot is compliant since 2021.04, there have been fixes here and there since then though
<xypron>
apalos: SCT runs fastest on the sandbox
<apalos>
xypron: sure, but I want to test secure EFI variableson RPMB etc
<apalos>
I have a very ugly hacky patch somewhere, emulating an RPMB in software for my own testing
<apalos>
perhaps i should try and send that
advi[1] has quit [Quit: Client closed]
<marex>
Tartarus: why not turn all the hooks into weak functions and be done with it ?
<Tartarus>
Well first, sjg1 would yell about weak functions being ugly :)
<Tartarus>
And second, there's already some hooks, I think that make use of weaks, so it's not quite cut and dry
<marex>
is that a personal opinion or is there some reason behind that too ?
<marex>
Tartarus: I have to say, I am a big fan of the weak functions
<Tartarus>
But also also, that would lead to a little bloat each time, even with LTO I don't think many empty functions optimize down to 1
<marex>
when done properly, they make it very easy to override parts of the code
<marex>
multi-level weak would be nice
<Tartarus>
I also like weak functions, when done properly
<Tartarus>
I think sjg1 has an issue since they're sometimes to often, not
<marex>
Tartarus: arent empty weak functions optimized to nothing when done properly ?
<marex>
lets wait for sjg1 input
<Tartarus>
marex: If you have weak foo_init_r and real foo_init_r, the weak one is discarded, yes
<Tartarus>
If you only have weak foo_init_r (returns 0), we still have that mini function
<Tartarus>
and if we also have weak bar_init_r (returns 0), we get that function too, not just a single onee
<marex>
Tartarus: err, dont we have LTO to inline the empty function ?
<Tartarus>
I don't know that does in all cases, esp for some of these hooks
<marex>
have you got an example ?
<Tartarus>
I mean, they're entries in static init_fnc_t init_sequence_r[]
<Tartarus>
so I don't know that it knows it can do something smart there
<Tartarus>
We also aren't yet to the point of globally doing LTO by default
advi[1] has joined #u-boot
<marex>
oh those things ... ugh
<marex>
Tartarus: well, I wonder ... if those were all converted into a long list of function calls, each of which would be weak and default to empty ...
<marex>
like ... int init_sequence_r() { func1(); func2(); ... };
<Tartarus>
For the moment, I want to make it harder to incorrectly configure a board
<marex>
and each __weak funcN() {} would have weak default implementation ...
<marex>
I think that would be very nice to have, since all the Kconfig madness would just go away
<marex>
the board/arch/... would just default the appropriate weak functions, no config options needed, problem solved
<marex>
I had this in mind for a while in fact
<Tartarus>
how far have you gotten with that experiment?
torez has quit [Remote host closed the connection]
<marex>
Tartarus: still in my head really
naoki has joined #u-boot
prabhakarlad has joined #u-boot
advi[1] has quit [Quit: Client closed]
prabhakarlad has quit [Quit: Client closed]
<sjg1>
apalos: thanks for the details. Yes emulators in U-Boot are good :-) I will reply to your email
<sjg1>
marex: Tatarus: I don't like weak functions since it is so hard to figure out what is going on. I end up disassembling U-Boot to try to work it out
<sjg1>
I think it is better to use linker lists or drivers, where there is some kind of interface
<sjg1>
But otherwise, I think events are good, as it is possible to list them (either outside or inside U-Boot). They are still somewhat 'magic', but more discoverable
<sjg1>
Maybe there is a perfect way of doing this sort of thing
<sjg1>
But I would like to drop things like the reserve functions in board_f. Also we have EVT_FT_FIXUP as a way to do DT fixups, which currently use weak functions and are a mess IMO
<marex>
sjg1: surely that part of weak functions can be solved
<marex>
sjg1: e.g. by looking at the map file
<marex>
sjg1: it really is no different then greping for Kconfig symbol
<marex>
so I am not buying that argument
goliath has quit [Quit: SIGSEGV]
<sjg1>
How does the map file help? I don't know which function is being called