<alyssa>
(Well, yesterday morning. Then yesterday evening something splatted)
<Lyude>
mm, usually serial console is the first place I start for issues like that
<Lyude>
(unrelated-but if any of the kernel people in here know how to answer the question I asked in #dri-devel that would help a ton)
Ashy has left #panfrost ["WeeChat 1.9.1"]
* alyssa
grumbles
<alyssa>
So, it looks like the RP64 is probably fried
<alyssa>
(I confirmed that the microSD is fine, I switched out video cables, power is fine since LEDs come on)
Kwiboo has joined #panfrost
<alyssa>
Which means I'm out a system, it seems..
<memeka>
alyssa: use a XU4 :P
<alyssa>
That's not a T860
<memeka>
alyssa: perfect, more work to fix :P
<alyssa>
memeka: RK3399 is my target platform
<memeka>
:(
<memeka>
T628 still at: [10927.224503] mali 11800000.mali: GPU Fault 0x00000080 (DELAYED_BUS_FAULT) at 0x000000010c040000
<memeka>
[10927.224520] mali 11800000.mali: error detected from slot 1, job status 0x00000043 (JOB_WRITE_FAULT)
<Lyude>
someone's forgotten to turn on their clocks
<Lyude>
:)
<Lyude>
or wait, no is that the job submission issue from before?
stikonas_ has quit [Remote host closed the connection]
<HdkR>
Lyude: Different issue. Seems more like framebuffer isn't mapped in to GPU space for some reason. Or it goes past the bounds
<HdkR>
memeka: It's going to have to end up just being a thing until someone can get around to fixing it. It isn't high priority and whinging about it won't fix it faster this time
<memeka>
HdkR: it's past the job submission issue. alyssa had some fixes for 32bit/T7xx and she got kmscube working on rk3288... shoud've worked on T6xx too, but it did not :(
<HdkR>
Lyude: btw, image that shipped on my board originally couldn't mount the rootfs from the emmc for some reason. So I had to move it over to a USB flash drive :P
<Lyude>
huh
<HdkR>
Might not be an issue for yours
* alyssa
rewrites nontrivial chunks of Panfrost
<alyssa>
*Panwrap
<Lyude>
HdkR: mine didn't come with any image on the emmc it looks like
<Lyude>
(no bootloader either)_
<HdkR>
ah. Do you have the emmc->USB reader?
<Lyude>
I got emmc->SD
<Lyude>
erm, emmc->mSD->SD->USB
<HdkR>
lol, wacky
<Lyude>
hehe
<Lyude>
longest SD card ever
<HdkR>
`Chamferwm: A Vulkan-Powered X11 Window Manager` Neat. Sounds like we need Vulkan :P
<Lyude>
lapis lives!
<HdkR>
Is it named lapis because of the colour of the heatsink?
<Lyude>
huh? my heatsink is black, but the board is blue!
<HdkR>
Oh, retail heatsink is black. derp
<HdkR>
Mine is blue and confused me :P
<Lyude>
I try to name basd on the color of the board but that usually doesn't work
<cyrozap>
Unfortunately, that adapter is designed for a clone of an Apple SD-to-USB adapter, which has a shorter-than-normal SD slot (the card sticks out of the slot quite a bit).
<cyrozap>
But SD-to-USB adapters don't expose the BOOT0, BOOT1, or RPMB partitions to the operating system, only the user data.
<HdkR>
(Unfortunately I think that'll only come about once ROCm steals away enough cuda customers that they realize they need to change)
<cyrozap>
Unfortunately again, the slot on the cable was too long for the BGA-to-SD adapter card, and it still wasn't able to make electrical contact with my laptop's SD card slot (which is connected to a real eMMC controller).
<cyrozap>
So I ended up taking some pliers and wire-cutters and cutting off the excess PCB and metal on the slot on the cable :P
<cyrozap>
And it works!
<alyssa>
cyrozap: Get back to reversing DPTX ;P
<cyrozap>
And surprisingly there don't seem to be any major signal integrity issues.
<cyrozap>
alyssa: YOU'RE NOT MY SUPERVISOR!
<alyssa>
!!!!
* alyssa
supervises
<alyssa>
What are you up to these days? More MediaTek I guess?
<cyrozap>
alyssa: Yeah, we finally got arbitrary code exec through the USB download mode of the BROM on the MT6735, MT6737M, MT6797, and MT8163, even on devices with preloader and download agent signature checking enabled. There'll be a postmarketOS blog post about this freedom-preserving feature after I've written some demo code for people to try (right now you have to provide your own aarch32 binary). But right
<cyrozap>
now I'm taking a little break from that.
<alyssa>
cyrozap: Oh, man, that's awesome!
<cyrozap>
And btw that list of devices is pretty easily expanded--really all that's needed is a BROM dump from the device to find the right global variable offsets and it'll work once they're added to the script.
<alyssa>
It doesn't rely on some easily patchable bug?
<alyssa>
I guess if it's ROM, that's game
<cyrozap>
They're global variables in internal SRAM that are used by the BROM--the only way to disable this is to either blow the efuse that disables BROM download mode or to patch the bug and update the mask ROMs for each IC for later production runs.
<cyrozap>
Because as long as the download mode isn't disabled you can always enter that mode by shorting the eMMC clock line to ground.
<alyssa>
Cute :)
<cyrozap>
So the next steps are to port the U-Boot SPL (so we can get rid of the proprietary "preloader") and U-Boot (to get rid of the proprietary LK) and find a way to bypass the signature check when booting from flash so we don't have to always boot our devices "tethered" over USB.
<alyssa>
Nice :)
<alyssa>
(That last bit probably shouldn't be too bad if you have arbitrary code exec)
<cyrozap>
Meanwhile, I also figured out how to write code to run on the baseband processor (a Cortex-R4) without crashing, so now I have a little utility that can poke at memory within the baseband processor's address space, so now I can finally try bringing up the DSP using my own code and RE-ing its instruction set.
<alyssa>
Adooorable!
<alyssa>
What's the DSP for?
<cyrozap>
Well, we have arbitrary code exec over USB, but not from flash, so to run your own code from flash you'd have to connect to a computer first while booting and shorting the eMMC clock to ground, which isn't super convenient. So it still requires more BROM code RE and is orthogonal to the USB code exec efforts.
<cyrozap>
The DSP is for the LTE PHY, so it's what converts the "magic energy waves" into bits, which are DMA'd to the Cortex-R4 for higher-layer processing.
<alyssa>
Oh, neat
<alyssa>
Something something FFTs
<cyrozap>
Yeah pretty much
<alyssa>
Update on my panwrap overhaul:
<alyssa>
I now have a fork of panwrap that's able to produce a machine-readable trace to disk
<alyssa>
I also have a standalone program (developing inside mesa) that's able to parse said trace.
<alyssa>
Next step is to hook up that program to the actual panwrap decoder
<robher>
tomeu: I pushed some code to power up various components and to throttle jobs. Seems to run though I can't really verify and things go south when stopping kmscube. Seems like a refcounting problem somewhere.
TheKit has quit [Ping timeout: 246 seconds]
TheKit has joined #panfrost
<HdkR>
alyssa: 10/10, would want again
<alyssa>
Alright, I just forward ported the last good panwrap and tied it up as a standalone tool, so now we can parse and dump the cmdstream traces
<alyssa>
I also just hooked it up to the Midgard disassembler, so we get that too
<alyssa>
(Now I'm just cleaning up pandecode; going to send it off to the lists before I go to bed)
<tomeu>
good morning/evening!
<tomeu>
robher: ok, I guess you don't get any error conditions from the interrupts?
<alyssa>
Evening tomeu :)
<tomeu>
alyssa: how many descriptors besides the atoms themselves we'd need for a minimal job?
<tomeu>
would be great to run at least something from IGT tests
<alyssa>
tomeu: Uh, minimal would be a compute job I guess
<alyssa>
But I don't have any tests with compute shaders
<alyssa>
So next best would be a vertex job without tiler/fragment (which acts like comptue)
<tomeu>
alyssa: are we far away from that?
<tomeu>
ah, that sounds doable
<alyssa>
No, it's just been super low prio since I don't need it for my dev and compute shaders are new shiny (ES3) which I'm prohibited from looking at yet ;)
<alyssa>
tomeu: Anyways, minimal vertex would be a few hundred lines of code, but you could copy paste from a trace
<tomeu>
alyssa: and how many other descriptors that would need?
* alyssa
shrugs
<alyssa>
tomeu: Few hundred lines of descriptors I mean
<tomeu>
you mean a few hundred lines of code to allocate, populate and setup the descriptors?
<alyssa>
I mean a few hundred lines of the descriptors themselves :p
<tomeu>
ah, got it
<tomeu>
wonder if we want to ship those headers in igt itself
<alyssa>
tomeu: I'd advise against it heavily
<alyssa>
Since the only place I care about is mesa, yeah?
<alyssa>
Those headers change a _lot_; it's mesa-internal and there's a gaurentee of API breakage
<alyssa>
Although if the goal is just to send _something_, maybe that doesn't matter..?
<tomeu>
oh, thought the structs that define the descriptors contents were defined by the silicon?
<alyssa>
They are, but we're constantly refactoring / changing names / etc as we understand more
<tomeu>
yeah, I think we only want to send something that actually runs, and doesn't hang the machine
<tomeu>
though ideally we would be able to exercise other stuff such as dependencies between atoms
<tomeu>
but at some point igt would have to embed mesa :p
<alyssa>
In that case, I guess just including the headers is fine, but then there'll be divergence
<alyssa>
Yeah ;P
<tomeu>
guess the alternative is to send some crap that we know/expect not to break the HW
<alyssa>
"Expect" Welcome to embedded systems :p
<alyssa>
I just sent the (2000+ insertions) patch for pandecode to the lists
<tomeu>
robher, alyssa: I think job submission is working now, because the machine hangs hard as soon as we submit something :)
<alyssa>
tomeu: Delightful ;P
<alyssa>
cwabbott: ^^ See backlog, but tl;dr I separated panwrap-syscall.c (panwrap) from panwrap-decoder.c (pandecode), so panwrap is a small downstream library that does little more than memory dumps to the file system; pandecode is a standalone utility living within mesa (compiled with mesa) to parse it. Benefits of this approach should be pretty obvious. Patch for pandecode is on the mesa-dev and should be merged soon; I'll post appropriate
<alyssa>
panwraps (for various kernels?) to gitlab when I get some spare time this week. Once this settles down, presumably going forward you'll want to do dev against upstream mesa, etc. (This should make your life easier, except for the whole "don't break mesa" part ;P)
<cwabbott>
alyssa: Ok, that sounds good... so I can build panwrap using the weirdo android toolchain, then just ssh the trace to my machine and use my mesa to decode it?
Elpaulo has quit [Ping timeout: 246 seconds]
Elpaulo has joined #panfrost
pH5 has joined #panfrost
<tomeu>
robher: guess it would be a good moment to get rid of the ip thing
<tomeu>
before we add more code
<tomeu>
robher: if it helps to debug, commenting out the body of panfrost_gem_free_object will avoid the neverending warns on exit