<urjaman>
also yeah i knew that that would be possible but wasnt thaat into it ... (mostly so that i dont need to guess whether the problem is with the usb-uart thing or something else)
<urjaman>
but yeah thanks for the picture paulk-leonov, spared me a lot of frustrating pin counting and wondering
<paulk-leonov>
:)
<paulk-leonov>
urjaman, I'd recommend that you add some paste on top of the soldering to avoid tearing the pad off if there is too high a mechanical constraint on the wire
<paulk-leonov>
I used blu tack for that
<paulk-leonov>
urjaman, note that the rockchip debug UART is UART2 btw
<paulk-leonov>
(from the SOC's perspective)
<urjaman>
yeah i noticed :P (was just doubly testing it by trying to echo out something from cros ... ttyS2 geeze :P)
<urjaman>
atleast ChromeOS prints a login, but man that was a _silent_ boot
<paulk-leonov>
indeed
<paulk-leonov>
they removed all output from coreboot/kmsg to get a slightly faster boot
<paulk-leonov>
upstream coreboot has it enabled though
<urjaman>
(by default that is, i was kinda just expecting atleast a "hello" from each stage)
shenghaoyang has joined #panfrost
BenG83 has joined #panfrost
shenghaoyang has quit [Remote host closed the connection]
pH5 has quit [Quit: Lost terminal]
pH5 has joined #panfrost
austriancoder has quit [Ping timeout: 252 seconds]
narmstrong has quit [Ping timeout: 252 seconds]
marex-cloud has quit [Ping timeout: 252 seconds]
austriancoder has joined #panfrost
narmstrong has joined #panfrost
chewitt has joined #panfrost
<chewitt>
bumping mesa to "panfrost: Properly align stride" results in a compile failure for me http://ix.io/1E3J
<chewitt>
previous build was 'whatever mesa version included a panfrost change'
* urjaman
has just gotten really annoyed about device trees and other dynamic stuff ...
<urjaman>
yeah i did figure out an u-boot version that does boot (roughly 2019.01, but add the C201 patches :P), but i'd really like to just use the newest
<urjaman>
(i'm actually legit lost on why these people want to put so much stuff into SPL... just fricking hard code to do what is needed (DRAM i guess) and load the actual u-boot (from one fixed place) and it should easily fit in the 32k but hey why not put in FDT parsers and a driver model and whatever else you feel like (there's options to have like FAT write support in SPL... beats me) in there...)
<urjaman>
/rant :P
krh has joined #panfrost
<mmind00>
urjaman: in theory having the driver model in spl could help in reusing generic drivers ... for example, I'm currently experimenting with getting rk3288 into arm-trusted-firmware, which needs real mmc-support in spl (and tpl before that, as the sram is too small) ... but at least for the sdram-init it is really not that helpful, as it really ends up as one sdram-driver per soc anyway
<mmind00>
urjaman: what irks me slightly more is that uboot on Rockchip socs seems to fall apart waaaay too often
stikonas has joined #panfrost
<urjaman>
my SPL (the one that never manages to even print a greeting... it's supposedly small enough to fit but i'm just feeling like something collided...) for some reason has driver info for the VOPs in there :P (not a lot of bytes that, but shows how messy this is...)
<mmind00>
urjaman: you could try enabling the debug serial output? ... and also all the debug-calls in the sdram driver I guess
<urjaman>
mmind00: what would be the config option for that? (also, does it fit in like 2kB? :P)
<mmind00>
urjaman: looking at http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-rockchip/rk3288-board-spl.c;h=93c772184d330a59f14c5c2b17d8d6a3434d0335;hb=HEAD#l107 it seems that the uart is enabled in all cases ... as for debug(), I also don't know what the correct way is ... for me I'm mostly just putting a "#define debug printf" in the the relevant files (after the includes) ;-)
<mmind00>
urjaman: correct files in this case being rk3288-board-spl.c and drivers/ram/rockchip/sdram-rk3288.c I guess
<urjaman>
include/log.h seems to say the correct way would be to #define DEBUG in that file
<urjaman>
i'll give that a try
<urjaman>
okay, i suppose that is an improvement (i got a whole log of: "spl: debug uart enabled in board_init_f"... so it never gets to trying to init the dram i think, that would be the next debug that was there in the normal case)
<urjaman>
(i've so far chased it to dying inside "dm_init_and_scan" ... taking a break for some ice cream :P)