ldevulder_ has quit [Remote host closed the connection]
ldevulder_ has joined #linux-rockchip
ldevulder_ has quit [Remote host closed the connection]
ldevulder_ has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
imsherlock has joined #linux-rockchip
<imsherlock>
@here trying to get SPL to verify a u-boot FIT image on the RK3399
<imsherlock>
currently booting TPL -> SPL -> U-Boot -> Kernel
<imsherlock>
I've noticed that when I try to build the TPL+SPL image with the following command "make EXT_DTB=pubkey.dtb", then TPL fails to boot with "DRAM init failed: -19"
<imsherlock>
without EXT_DTB, TPL boots fine but then SPL has no image signature to verify with
<imsherlock>
thoughts on how I can get this to work? Or is the documentation on how to setup up such a configuration with TPL+SPL
vstehle has quit [Ping timeout: 258 seconds]
imsherlock has quit [Remote host closed the connection]
<dhivael>
is there anything we can do to help make kexec work (better)?
<anarsoul>
debug the issue?
<dhivael>
tried it and got nowhere with available skills
<inode>
dhivael: what kind of problems do you experience with kexec?
<dhivael>
inode: after kexec graphics are glitchy, black lines inserted into the display apparently at random but corresponding with display load. mostly usable most of the time, but eg playing a video yields a screen that's flashing black most of the time
<dhivael>
(running on rk3399, pinebook pro)
<dhivael>
even if the first stage kernel does not touch the display at all, with neither drivers for the video units nor the gpu loaded or even compiled
<inode>
do these issues appear if you boot the kernel that you're loading via kexec from a boot loader instead?
<dhivael>
no, that's totally fine
<inode>
have you tried to compare the differences, if any, between the display-related clock summary and the values of display-related registers of the GRF that are reported after a typical load vs. after kexec?
<dhivael>
no idea how to do that
<inode>
for the clock summary you'll need to mount debugfs somewhere, if the kernel includes support for it, ie: mount -t debugfs none /sys/kernel/debug
<inode>
/sys/kernel/debug/clk/clk_summary is probably of interest
<dhivael>
will have to recompile, so it'll be a bit, but that's totally doable
<dhivael>
inode: some clocks are indeed set differently
<dhivael>
pll_bpll is set at almost 5x the rate in the kexec'd kernel
<dhivael>
nothing that looks like graphics to me in there though
<anarsoul>
also check regulators
<anarsoul>
i.e. /sys/kernel/debug/regulator/regulator_summary
<dhivael>
regulators only differ in cpu core voltages, but that's not unexpected
<dhivael>
huh, wait. the min/max points for cpu0 and cpu4 differ too.
<dhivael>
setting the cpufreq governor to performance before kexec makes kexec fail reliably
<anarsoul>
set it to powersave?
<dhivael>
that works, but results in the same glitches
<dhivael>
had schedutil for earlier tests, that probably left the cpu in low frequency states immediately before the kexec jump
<dhivael>
using powersave in the kexec'd stage doesn't improve it much, but it *does* produce fewer glitches
<dhivael>
setting performance in the kexec'd stage gives the same regulator summary as pre-kexec
vagrantc has quit [Ping timeout: 240 seconds]
vagrantc has joined #linux-rockchip
<dhivael>
redid the clock tests with performance governors set while getting the clock summary, they're now the same in both stages except for reordering of the tree
<inode>
are the clock/parent-clock relationships the same?
<dhivael>
yep
warpme_ has quit [Quit: Connection closed for inactivity]
chewitt has quit [Read error: Connection reset by peer]