<tnt>
azonenberg: Huh, no. I think we talked about compute shaders and opencl back then because I work on some apps and thinking of moving them from opencl to compute shader instead because it's easier to find platforms with compute shader than opencl (especially opencl with opengl interop support).
<tnt>
I have done tests on some Mali GPU that support OpenCL though and from what I remember, it worked fine ... but I had to use the vendor kernel/driver combo to get closed drivers running (which often meant rather old kernel).
<azonenberg>
Yeah the RK3399 apparently supports opencl 1.2 and opengl es... 3.2?
<tnt>
Not sure if the situation has improved nowadats.
<azonenberg>
so, backstory
<azonenberg>
i ordered a RK3399 based SBC (RockPro64) for use as a test/demo platform for glscopeclient
<azonenberg>
it's the lowest cost, smallest computer i've found that has a full sized pcie slot
<azonenberg>
which will make it a great benchtop demo platform for sniffing highish speed signals
<azonenberg>
i plan to plug a pcie 1000base-X NIC into it and then you can probe both the pci and the sfi links
<azonenberg>
but i'm now idly wondering if running glscopeclient on the thing might be plausible too :p
<azonenberg>
I bought it as a DUT, not a host
<azonenberg>
but hey, if it can be both... ;)
<azonenberg>
anyway, i'll try and we'll see what happens
<azonenberg>
if it doesn't work it still fulfills the purpose i originally bought it for
<tnt>
Hehe. Yeah, I looked at the same board not long ago for the exact same reason (pcie slot). Curious to see how it works out.
<azonenberg>
i plan to use it in my probing class since it fits on a lab bench much easier than a full PC with an atx supply etc
<azonenberg>
i can run it off a bench supply
<azonenberg>
and if a student fries it, it's much less of a big deal lol
whitequark has quit [Quit: Bridge terminating on SIGTERM]
fridtjof[m] has quit [Quit: Bridge terminating on SIGTERM]
sajattack[m] has quit [Quit: Bridge terminating on SIGTERM]
mikolajw has quit [Quit: Bridge terminating on SIGTERM]
mikolajw has joined #scopehal
sajattack[m] has joined #scopehal
whitequark has joined #scopehal
fridtjof[m] has joined #scopehal
<Degi>
The current drivers only seem to initialize PCIe properly when the card supports at least 5 GT/s
<tnt>
Degi: of the rockpro64 ?
<Degi>
Yes
<tnt>
That's ... huh ... weird. But also speed negotiation should be purely hardware, part of LTSSM process, driver shouldn't have much influence on it. (I guess it's always possible some custom debug style register isn't set properly but ...)
<Degi>
At least it doesn't even try to read configuration memory with a Gen 1 card and then the CPU just crashes or does nothing. Not entirely sure if that's a driver issue or hardware bug
<Degi>
(The LTSSM does work fine though)
sajattack[m] has quit [Quit: User was banned]
whitequark has quit [Quit: User was banned]
mikolajw has quit [Quit: User was banned]
fridtjof[m] has quit [Quit: User was banned]
<Degi>
azonenberg: Otherwise one of the newer raspberry pis might be neat, they have a PCIe link on board and a PCIe to LAN bridge, then you could demonstrate the probes too
mikolajw has joined #scopehal
whitequark has joined #scopehal
sajattack[m] has joined #scopehal
fridtjof[m] has joined #scopehal
<azonenberg>
Degi: interesting. So a 2.5-only card won't work?
<azonenberg>
i'll investigate
<Degi>
At least mine didn't
<Degi>
If you find a way it does, please tell me
<Degi>
(Usually the LTSSM initializes, then after a while either it resets or nothing happens and it doesn't show up in lspci either)
<Degi>
(I tried 3 or 4 different cards of PCIe 1 and one with PCIe 3 which did work (some 10 Gb/s ethernet SFP card), at least the PCIe initialization part)
<azonenberg>
I'll see what happens. Could be an IP bug. in any case i can always slap a 5 GT/s card in there worst case
<azonenberg>
but i do have the right gear to debug link startup issues lol
<Degi>
true
<azonenberg>
one thing my protocol decodes in glscopeclient do not handle yet, btw, is link startup
<azonenberg>
and power management
<azonenberg>
i assume you have a continuous, fixed rate 8b10b stream for the moment
<azonenberg>
so that is something i will need to add in the future i guess
<Degi>
Hm, if its 2.5 GT/s yes
<Degi>
(True, power management might be a problem)
<azonenberg>
on the pi there is a special register i poke for my current tests
<Degi>
(But the continuous 8b10b stream shouldn't change from when it first locks the CDR I think, if its only 2.5 GT/s)
<azonenberg>
to disable power management and keep the link sending constant idles
<azonenberg>
i dont know if the rockchip has something similar and if so what the register is
<Degi>
Oh, also can you compare eye pattern of the fourth lane compared to the first three, at least on my board its slightly different
<Degi>
(Might be good for seminars to demonstrate what effect small differences can have on a signal)
<azonenberg>
I'll check when i actually get the hardware
<azonenberg>
i placed the order and it showed in stock
<Degi>
Thanks
<azonenberg>
but i dont physically have it yet
<Degi>
Good that it is in stock lol, nowadays with many ICs not even having a date on when they'll be there
<azonenberg>
yeeah lol
<azonenberg>
i'm getting ready to send a test board out to oshpark with a TQFP-64 PIC32MX695F512H on it lol
<azonenberg>
i got a ton of PIC32 samples when i was an undergraduate and didnt use a lot of them
<azonenberg>
(mostly because i started to prefer BGA/QFN and ARM)
<azonenberg>
these are MIPS MCUs with 2010 date codes
<azonenberg>
but they also have a fair bit of ram/flash and are in my physical possession :p
<azonenberg>
which counts for a lot these days lol
<Degi>
Somehow I always get solder bridging with QFNs
<azonenberg>
i have the opposite
<azonenberg>
i get bridging with TQFP and my QFN yield is excellent
<Degi>
(I think I only use SOICs otherwise, so no idea about TQFP)
<azonenberg>
i only use QFP if i absolutely need to use that part in particular, and there's no other package options
<azonenberg>
usually i start by filtering on digikey for QFN/DFN/BGA packages
<Degi>
I wonder if I just mis-apply my paste and it is too thick or the stencil holes are too big
<azonenberg>
and if there's no results I expand to include qfp/soic/tssop
<Degi>
Though nice that you have a lot of PICs xD
<azonenberg>
Anyway so i'm throwing together a quick test board to try and get an open source toolchain together
<azonenberg>
using 4-wire EJTAG instead of the microchip proprietary SWD-esque ICSP protocol (the chip supports both)
<azonenberg>
and mips-elf-gcc instead of microchip XC32 which is a fork of gcc with some small tweaks and addition of some DRM bs to make you pay for it
<azonenberg>
(its still open source but is such a pain to compile yourself most people dont)
<azonenberg>
I may or may not ever do a real design with these chips but i want to have the flow figured out for if/when i exhaust my current stash of stm32s
<azonenberg>
i have a lot of small stm32s (f031/l031)
<azonenberg>
but am very light on the big ones
<azonenberg>
and i have a fair number of midrange pic32s (M4K at 80 MHz, 128 kB RAM, 512 kB flash, MII/RMII)
<azonenberg>
they have no crypto core but i can hang an atsha/atecc off them to use as a random number generator then do software aes/sha in a pinch
<azonenberg>
i also have some higher end (I think 200 MHz microAptiv, 640 kB RAM, 2 MB flash, MII/RMII, crypto, optional DDR2) PIC32s on order that were listed as in stock
<azonenberg>
those are the recent PIC32MZ family
<azonenberg>
And i think are viable stm32f777 replacements if they come first
<d1b2>
<j4cbo> no you can’t, those are unobtanium too (unless you have a source for atecc’s in which case I am very interested)
<d1b2>
<j4cbo> (I have an order out for atecc508s from Mouser for which apparently Microchip has missed 3 ship dates to Mouser so far)
<azonenberg>
j4cbo: i have 25 atecc508a's in soic sitting around that i've had for years and never did anything with
<azonenberg>
i also have a bunch of pic32mx's
<azonenberg>
so if i need a single/low double digit number of boards where the only requirement is "has a mcu with a fair bit of ram/flash" and "has crypto" i can make it work
<azonenberg>
i just have no path to scaling up
<electronic_eel>
how about rp2040? they are cheap, readily available and have even more ram and processing power
<electronic_eel>
the integrated rng is not really the best choice for crypto though
<azonenberg>
They beat a pic32mx but probably not a MZ in performance
<azonenberg>
I have some MZs on the way with 200 MHz CPUs and 640 kB of sram + 2 MB on die flash
<azonenberg>
also the rp2040 lacks on die flash
<azonenberg>
no ethernet
<electronic_eel>
external flash is easy and cheap
<electronic_eel>
but for ethernet you'd need something like a enc424j600 or lan9250
<electronic_eel>
(which are either expensive or hard to get)
<azonenberg>
I actually have some enc424j600s sitting around. but my typical application for these would be hanging them off an FPGA
<azonenberg>
in which case i guess i can always use a spi interface instead of rmii
<azonenberg>
since internally the fpga is going to have gig or 10gig to the real LAN and a MAC
<azonenberg>
plus some bridging to take management traffic and send to the MCU while the rest goes to some fpga accelerators
<electronic_eel>
yeah, for the setups where the actual ethernet is done by an fpga you could use some spi protocol with a small buffer in the fpga
<azonenberg>
yeah thats what basically all of my projects are
<azonenberg>
if i put ethernet on something i'm moving a lot of data
<azonenberg>
and a dinky mcu with a 10/100 mac can't handle that
<azonenberg>
so i generally split control and data plane
<azonenberg>
so i effectively have a 2-port switch on the FPGA with 1/10G to the FPGA and 10/100 from FPGA to the management MCU
<azonenberg>
and the fast data plane traffic staying on FPGA
<azonenberg>
(not a true switch as it's not based on MAC address, i usually either do UDP/TCP or port number based split)
<azonenberg>
and the fpga+mcu collectively present as a single mac address
<azonenberg>
@louis: just checking in on what you're up to. Working on the flow control stuff yet?
<azonenberg>
@mubes: There is a SDS2104X+ demo unit en route to me from siglent ohio now
<azonenberg>
Plan is to do some experimental work on write queueing with it
<d1b2>
<mubes> I doubt that will get too far until the outstanding bugs are fixed. Patches are promised but as I said its been a bit radio silence for a while.
<azonenberg>
@mubes: which bugs?
<azonenberg>
i thought most had been addressed by now
<d1b2>
<mubes> I'll send you a link to the bugsheet.
<azonenberg>
ok
<azonenberg>
and yeah my main focus was just on using it as a test platform. it's OK if it doesnt actually work fully
<d1b2>
<mubes> There's only one hairy one really, related to multi command handling.
<d1b2>
<mubes> The driver has some command pacing built in because you can't tell when the previous command has completed so you have to slow stuff down. Once that's fixed life will get easier. Right, bedtime, night.