alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - - Logs - <daniels> avoiding X is a huge feature
chewitt has joined #panfrost
cwabbott has quit [Ping timeout: 245 seconds]
cwabbott has joined #panfrost
cwabbott has quit [Client Quit]
cwabbott has joined #panfrost
stikonas has quit [Ping timeout: 258 seconds]
cwabbott has quit [Ping timeout: 258 seconds]
alyssa has joined #panfrost
<alyssa> Oops, I made the blob crash
<alyssa> Tut tut.
* alyssa wonders if that would work over WebGL
<alyssa> :p
<alyssa> I concede it's my own fault and not actually a bug in the blob :p
<alyssa> -----Although, huh, right, ok
alyssa has quit [Client Quit]
cwabbott has joined #panfrost
<urjaman> o.O
<urjaman> hanetzer: anything i should NOT do when setting up u-boot on the C201? :P (== yeah i'm considering/researching it for the 4GB one...)
<hanetzer> urjaman: yeah, use it at HEAD. HEAD is currently broken
<urjaman> hmm, what would be a working version then?
<hanetzer> honestly unsure.
<urjaman> 2019.01? (head is 2019.04-rc4 ...)
<urjaman> do you have a link to something saying broken in what way? :P
<hanetzer> check the links :P
<urjaman> thanks
alyssa---- has joined #panfrost
alyssa---- has left #panfrost [#panfrost]
<urjaman> darn it now i want to investigate this ... which would involve disassembling the C201
<urjaman> (btw in other news: my testing of 5.1-rc1 on C201 has been surprisingly functional so far :P)
<urjaman> also, this is some kind of a record on time from me reporting/noticing a bug (of some sort) and the fix getting into mainline :P
chewitt has quit [Quit: Adios!]
samueldr has quit [Ping timeout: 246 seconds]
samueldr has joined #panfrost
cwabbott has quit [Ping timeout: 252 seconds]
cwabbott has joined #panfrost
tgall_foo has quit [Ping timeout: 244 seconds]
afaerber has joined #panfrost
pH5 has quit [Quit: bye]
pH5 has joined #panfrost
afaerber has quit [Ping timeout: 246 seconds]
stikonas has joined #panfrost
<tomeu> got a clear job running successfully in igt :)
<daniels> tomeu: \o/ what was the problem?
<tomeu> not really sure, tbh, I just ran kmscube with no rendering under pantrace, then made sure that the magic numbers in igt matched
<tomeu> some values differ between 64bit and 32bit, so we'll have to make that configurable when making it run on rk3399
<tomeu> pantrace is great
<tomeu> now we're able to submit a clear job from igt and check that the colors match afterwards
<tomeu> we can also cause a hang, so I have a failing test for resets that we need to get passing :)
stikonas has quit [Remote host closed the connection]
<urjaman> ... (C201 vs C201? :P) ... now to figure out that serial port -.-
tgall_foo has joined #panfrost
<paulk-leonov> urjaman, it's on the servo connector, not easy to solder on at all sadly
<urjaman> yeah i'm aware, but could you say whether i need UART1 or UART2? :P
<urjaman> why couldnt they have named these signals UART_EC and UART_AP or whatever ...
<paulk-leonov> urjaman, sure, gimme a minute
<paulk-leonov> urjaman, UART2 is AP and UART1 is EC
<urjaman> thanks
<mmind00> urjaman: alternatively, you could use the uart output via the usb-pins
<urjaman> done the soldering already :P
<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
<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;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)
<mmind00> urjaman: re ice-cream: :-P [from Mel Brooks' Blazing saddles]
<urjaman> "
* urjaman fails with keyboard
cwabbott has quit [Read error: Connection reset by peer]
cwabbott has joined #panfrost