09:47 <marcan> alyssa: dcpext[0-3]

09:47 <marcan> told you it was just going to be copied and pasted

09:48 <marcan> for those keeping count, that's at least 15 coprocessors per chip now

09:50 <ar> but will they ever beat tegra in the coprocessor count contest? ;)

10:48 <kettenis> http://www.genesyslogic.com/en/product_view.php?show=80

10:48 <kettenis> looks like that's the SD card controller

10:48 <kettenis> should be standard SDHC

11:58 <alyssa> marcan: hilarious

12:20 <marcan> kettenis: yeah, the SD is just pcie

12:45 <alyssa> which machine has an SD card?

12:46 <alyssa> the new mbps?

12:46 <alyssa> ar: they sure are trying

12:48 <kettenis> alyssa: yes

12:50 <alyssa> ah

13:12 <arnd> marcan: how many different instruction sets in those 15 coprocessors? The highest I'm aware of on that scale was Snapdragon, but I forget the exact number that I was told

13:13 <alyssa> snapdragon dsp was wacky iirc

13:16 <alyssa> also, do you count AGX? what about the ANE?

13:18 <sven> i think most of them are just arm64 cores

13:18 <sven> dcp, ans and smc definitely are

13:18 <alyssa> agx too, funnily

13:18 <alyssa> iirc

13:20 <sven> i also finally got around to figure out how this DART subpage protection works: there's still some weirdness but afaict you clear BIT(1) in the PTE to enable it and then bits 63,52 are the start and 51,40 the end offset>>2 inside the page that's allowed. any access outside that range will just be blocked

13:21 <alyssa> fun

13:21 <alyssa> do we ever need to use that on linux?

13:21 <sven> maybe, it would allow us to skip swiotlb entirely if this can be hooked up in a sane way to the iommu subsystem

13:22 <sven> might make sense if it's much faster

13:22 <alyssa> nod

13:23 <alyssa> OD

13:31 <alyssa> i miss working on the asahi mesa driver

14:59 <kettenis> sven: does that work on all the DARTs?

15:00 <sven> kettenis: not sure yet

15:01 <sven> it works on the usb ones and on the audio/aes/whatever (dart-sio)

15:01 <sven> still have to test the pcie ones

15:02 <sven> but if you want a simple test: just setup the range to only the first 0x10 bytes of a page and then trigger a DMA request with more than 0x10 bytes

15:03 <sven> it'll trigger an error interrupt and the fault address with be 0x10 bytes into the page

15:05 <kettenis> just figured out why the wifi wasn't working for me in OpenBSD

15:07 <kettenis> so I'll look into that later today or tomorrow

16:05 <marcan> arnd: 2

16:05 <marcan> there's some cortex-m3s (ARMv7-M) and some chinooks (ARMv8-A).

16:06 <marcan> though that's not counting the DCP m3s

16:06 <marcan> that adds another 5 v7-Ms :p

16:06 <marcan> so we're up to 20 copros on the Max, at *least*

16:06 <arnd> ah, so you are not even counting the ARC cores in the XHCI then

16:06 <marcan> are those a thing?

16:06 <marcan> dwc3 uses ARC?

16:07 <arnd> I haven't seen a confirmation for those, but I'm pretty sure that any XHCI needs to have firmware running on some MCU, and ARC is what Designware tends to use because they ownit

16:08 <marcan> I don't think I've seen any indication of dynamically loaded firmware for those

16:08 <arnd> no, I don't think they do that, maybe some maskrom inside the dwc3 block though

16:09 <marcan> yeah, could be

16:09 <marcan> but hey, RMS doesn't count that either

16:09 <marcan> "it's hardware!"

16:09 <marcan> "this bluetooth dongle with half a megabyte of proprietary stack in ROM Respects Your Freedom!"

16:10 <alyssa> marcan: well as long as the cpu doesn't touch the scary proprietary firmware i guess it's ok

16:10 <arnd> xhci-tegra and xhci-rcar call request_firmware()

16:10 <marcan> I wonder though, if Apple had any visibility into this they would've probably insisted it be SRAM and part of their secureboot

16:11 <marcan> I know most xHCI controllers are complex enough to need firmware

16:11 <marcan> though I *guess* you could state machine everything in principle

16:11 <marcan> though in the end you'd probably end up with some CPU-looking things either way

21:15 <jeffmiw> alyssa: using your mu-one/20211018 branch, I'm getting an early kernel crash "Unable to handle kernel NULL pointer" in mbox_request_channel during dcp_platform_probe/rtkit_init. Before digging into it, just want to check if it is known.

21:15 <jeffmiw> I'm on mba

21:15 <jeffmiw> 2021015 branch was booting fine

21:16 <j_ey> jeffmiw: you need to modify the mboxes in the device tree

21:16 <j_ey> at least that's what im guessing it is, from: mboxes = <&foo>; to mboxes = <&foo 0>;

21:17 <jeffmiw> j_ey: thanks, that rings some bell, let me give it a try

21:35 <jeffmiw> it seems it needs more than that or I screwed it. I'll spend more time on it tomorrow.