<d1b2>
<josHua> potentially cmake should cry with a more pointed message about that
<d1b2>
<azonenberg> if you can figure out a way to tell if a submodule is out of date, i'm all ears
<d1b2>
<prostephenfalken> ngscopeclient in MacOS: Is there an equivalent of the "middle mouse button" to auto-scale the signal while using the Apple trackpad? (if not/don't know: Is there a menu option to achieve the same auto-scale?) Thanks!
<d1b2>
<azonenberg> Not to my knowledge. File a ticket and I'll try to add an option for it
<d1b2>
<prostephenfalken> I've been googling a bit and it seem that the only way to have middle button in MacOS is installing third party tools which I don't think is a good idea. This is a very useful option to have. Thanks for the offering. I will 👍
sgstair_ has quit [Read error: Connection reset by peer]
<d1b2>
<josHua> compare the submodule to make sure it contains the desired submodule commit (and, failing that, to make sure that it has a file there to indicate that it has been checked out, if ther eis no .git)
<azonenberg>
File a ticket with that info, probably won't happen super soon
<azonenberg>
but will be worht playing with
<d1b2>
<josHua> wilco
<d1b2>
<altracer> get ready to patch out all the I2C communications with STPMIC2 then, I guess... or did they implement it in OSTL normally? Bootchain up to Linux but without it will fit on w25q512, and then you can tell uboot to launch the cm4 cm33 firmware and ca35 kernel, if any
<d1b2>
<azonenberg> I wasn't planning to run linux or even their FSBL
<d1b2>
<azonenberg> Bare metal event loop on the a35 and m33
<d1b2>
<azonenberg> that was part of the challenge, see how hard it will be to get an a35 and pcie working without an OS
<d1b2>
<azonenberg> my firmware will probably be 200 kB or so total
<d1b2>
<altracer> pcie?!
<d1b2>
<azonenberg> yes. pcie from the mp2 to an fpga
<d1b2>
<azonenberg> point to point, no hotplug, basically ignore all the descriptors
<d1b2>
<azonenberg> just bring up the phy and map one bar at a fixed virtual address
<dingwat>
just like god intended
<d1b2>
<altracer> They ship FreeRTOS for MP13x, maybe MP2 will have some RTOS that is not as bloated as linux-6?
<d1b2>
<azonenberg> basically use it like i use the FMC on the stm32h7 now, but with two diffpairs rather than ~30 pins
<d1b2>
<azonenberg> I don't even have malloc in my firmware
<d1b2>
<altracer> and who's the busmaster, root complex or endpoint? Or it implements bidirectional/both?
<d1b2>
<azonenberg> my H7 firmwares are a single elf image
<d1b2>
<azonenberg> all memory statically allocated
<d1b2>
<altracer> with C++ you don't need malloc Ig
<d1b2>
<azonenberg> you can't use RTTI or exceptions with my newlib-nano config if you disable malloc, but if you do that then it works fine
<d1b2>
<azonenberg> i actually have the linker forcibly undefine mallloc so it'll fail to build if i accidentally call a libc function (like printf) that calls malloc under the hood
<d1b2>
<azonenberg> along with a few other functions related to dynamic allocs
<d1b2>
<azonenberg> (and yes i implemented a whole tcp/ip stack and sshd like this)
<d1b2>
<azonenberg> fits in a few tens of kB each of flash and ram, maybe 100 kB of ram if you want several concurrent ssh console sessions with a couple packets of tcp window each
<d1b2>
<azonenberg> my dream processor would be a GHz M85 with like a megabyte or two each of sram and flash, and a pcie root complex
<d1b2>
<azonenberg> it doesnt exist so i'm exploring how close i can get :p
<d1b2>
<azonenberg> anyway, my test board is going to have the fpga and soc connected by both the FMC and PCIe
<d1b2>
<azonenberg> so i can use FMC for initial bringup then switch over to pcie if and when i get it working
<d1b2>
<azonenberg> it also looks like the MP2 supports a m33-first boot configuration
<d1b2>
<azonenberg> so if i want a low effort initial proof of concept i can run my entire firmware on the M33 and just forget the A cores exist
<d1b2>
<azonenberg> and it'll be just like using an rp2350 or esp32 or i.mx rt or similar cortex-m that boots from external flash
<d1b2>
<azonenberg> @altracer (I had to write my own stack because i couldn't find any other tcp/ip and ssh platform that was sufficiently lightweight and compatible with my use case, and permissively licensed)
<d1b2>
<azonenberg> the closest i saw was wolfssh which is fairly light but i don't think supported no-malloc, but it was GPL'd
<d1b2>
<azonenberg> and having code reviewed wolf* in the paast i wouldn't touch it with a ten foot pole
<d1b2>
<altracer> FMC would definitely be visible to CM33, I'm not sure about PCIe
<d1b2>
<altracer> you don't need to touch MMU, there should be an IOMMU probably, but TZ firewall has to be up somehow
<d1b2>
<azonenberg> @altracer PCIe is not, however i think the pcie config SFRs are. also several DMAs can access it
<d1b2>
<azonenberg> so i could do indirect config
<d1b2>
<altracer> wicked
<d1b2>
<azonenberg> I havent looked at the TZ config, my assumption was that it would be wide open with everything running in secure mode on reset
<d1b2>
<azonenberg> so unless i dropped privileges i'd be in supervisor + secure mode on everything?
<d1b2>
<altracer> I think USBOTG-HS was available to CM4, but not USBH, and I didn't bother to verify
<d1b2>
<azonenberg> I won't be using USB
<d1b2>
<altracer> for core yes, for busmatrix firewalls unsure
<d1b2>
<azonenberg> plan is for the FPGA to have a 10G SFP+ with MAC and TX/RX FIFOs, plus a RGMII PHY with MAC and TX/RX FIFOs, accessible via APB/AHB/AXI over FMC/PCIe
<d1b2>
<azonenberg> then a second RGMII PHY to the SoC
<d1b2>
<azonenberg> so i can play with both options
<d1b2>
<altracer> SoC has 2-3 RGMII
<d1b2>
<azonenberg> Correct
<d1b2>
<azonenberg> for most real world deployments i intend to have the SFP+ be the primary interface and have the high speed datapath in the FPGA
<d1b2>
<altracer> which is anyway better than fiddling with USB3 if it has any
<d1b2>
<azonenberg> with the SoC just handling ssh and scpi and such
<d1b2>
<azonenberg> and possibly tcp setup/teardown
<d1b2>
<azonenberg> i still need to work out the details of how the gateware/software split will work, my old stack was either full software or full gateware and i dont have a good platform for hybrid yet
<d1b2>
<azonenberg> that avoids burning fpga resources e.g. answering pings and arp queries
<d1b2>
<azonenberg> while still being able to saturate 10GbE with data plane traffic
<d1b2>
<azonenberg> but the intent was for this board to be one of the platforms to develop that new setup on
<d1b2>
<azonenberg> For most of my planned projects H735 is more than enough, but i figured i'd slap a mp2 on this board as a test to gain some experience working with A's and see how much worse it was
<d1b2>
<azonenberg> as a low level guy i had always shied away from them due to the amount of setup work required vs just jtagging an elf image onto flash and running my firmware straight out of reset with the interrupt vector table pointing at _start
<d1b2>
<altracer> Okay, it has a single 5Gbps COMBOPHY that is shared between USB3 DRD and PCIe Gen2
<d1b2>
<azonenberg> (and i hate embedded linux... linux is a desktop OS)
<d1b2>
<azonenberg> yep
<d1b2>
<azonenberg> i already have about half the schematic for that done
<d1b2>
<azonenberg> including hooking the combophy up to a kintex7 gtx
<d1b2>
<azonenberg> the other stretch goal was to see how hard it would be to get the GPU up bare metal as a DSP accelerator
<d1b2>
<azonenberg> forget rendering i just want to compile a compute shader to a native binary (can precompile this on PC) and launch it on user specified data in dram
<d1b2>
<azonenberg> realistically i think the combination of the FPGA and a full GPU on a PC is going to be more than enough DSP for me, but as long as the mp257 has one i figured if i am ever bored i can try to bring it up :p
<d1b2>
<altracer> But you still don't want to make it into a standalone oscilloscope instrument?
<d1b2>
<azonenberg> Correct
<d1b2>
<azonenberg> The mcu/soc is intended to just be a "state machine accelerator" that lets me offload control plane tasks from gateware to something easier to write and that doesn't compete for fpga resources
<d1b2>
<altracer> Sure, the capture data is streamed to desktop, but you might as well preview it on a DSI panel
<d1b2>
<azonenberg> Where would i put it
<d1b2>
<azonenberg> this thing is going to be 1U with sixteen probe inputs on the front
<d1b2>
<azonenberg> there's barely going to be space for a tiny e-ink display to show the IP address and firmware version
<d1b2>
<altracer> hmm, rack is limiting
<d1b2>
<azonenberg> I have limited space on my bench. most of it is occupied by front panels i don't use because all the gear is remote controlled anyway
<d1b2>
<azonenberg> i have 1U free on the left rack for the trigger crossbar and like 5U free on the right
<d1b2>
<azonenberg> all of my future instrumentation has to fit in that
<d1b2>
<altracer> but also nobody on your team likely fancies porting half of scopehal to openstlinux and bothering with that GPU (vulkan?)
<d1b2>
<azonenberg> it does support vulkan. but again, that was never the intent
<d1b2>
<azonenberg> the other thing is this is a platform i'll be using for more than just this scope
<d1b2>
<azonenberg> i want to make an AWG, a BERT, a 48 port ethernet switch, etc
<d1b2>
<azonenberg> all using a common fpga+arm architecture, same 48V power module, etc
<d1b2>
<azonenberg> The intended form factor for all the test equipment is 48VDC power, trig in, trig out, 10 MHz in, serial console, SFP+ on the back
<d1b2>
<azonenberg> and probes/rf outputs on the front
<d1b2>
<azonenberg> in 1U
sgstair_ is now known as sgstair
<d1b2>
<azonenberg> basically a jesd204 to 10GbE bridge with some ddr in between to buffer
<d1b2>
<azonenberg> and enough of a control plane to run a scpi server for configuring the frontends and triggers
<d1b2>
<azonenberg> honestly you could run most of this probably on an M4, the only reason i even use the H735 is because i don't like waiting for a ssh session to initialize
<d1b2>
<azonenberg> so i wanted as much oomph as i could throw at the ssh pubkey stuff (this is also why i implemented the curve25519 fpga accelerator)
<d1b2>
<azonenberg> i think i got ssh session startup on the h735 + kintex7 combo down to like 30ms from tcp syn to shell
<d1b2>
<azonenberg> the mp2 is overkill but i want to have it as a tool in my box before i need it, and have familiarity with what it can and can't do
<d1b2>
<azonenberg> knowing that i can likely fall back to the m33 and still do everything i need worst case
<d1b2>
<azonenberg> the main things attractive to me about the MP2 are the pcie and the higher IO count than the h7
<d1b2>
<azonenberg> meaning i can get more GPIOs, plus use less pins on both the soc and the fpga connecting the two
<d1b2>
<azonenberg> a h7 plus pcie would be great 😛
<d1b2>
<josHua> "a STM32H7 would be great" is something I rarely find myself saying
<d1b2>
<josHua> the errata list and internal xbar architecture on that device family is just too much suffering
<d1b2>
<josHua> and this is coming from a guy who willingly went to go race a bicycle offroad in 40 degree rain on Saturday
<d1b2>
<azonenberg> lol
<d1b2>
<azonenberg> The only errata i've had issues with are a) the octospi is evil, you're better off just pretending it doesn't edxist
<d1b2>
<azonenberg> and b) the FMC adds two dummy cycles after a read operation which hurts performance but has no other real effect
<d1b2>
<vegard_e> but is it if you're using it for its intended purpose? (plain memories)
<gruetzkopf>
ooh we had some fun with stm32h7 when we tried doing "interesting" things
<d1b2>
<josHua> "the memory system pipelining needs to be turned off or it'll sometimes give the wrong answers" was an erratum that cost me a lot of hair
<gruetzkopf>
like interrupting and restarting dma-driven SPI transfers (while being controller)
<gruetzkopf>
(well, not restarting, continuing)
<gruetzkopf>
and clocking is.. inflexible in certain annoying spots
<d1b2>
<azonenberg> "memory system pipelining"?
<d1b2>
<azonenberg> apparently if you have both your stack and code in octospi memory and you hit certain combinations of interrupts
<d1b2>
<azonenberg> it will hard lock the axi bus
<d1b2>
<azonenberg> i dont know all the details, dmitrygr says its horribly cursed
<d1b2>
<azonenberg> i've found lots of horrors around the octospi related to using it for fpga interfacing
<d1b2>
<azonenberg> things like a prefetch cache you can't turn off and corrupting data in between consecutive transactions because it tries to use a DM pin even if you don't have one
<dingwat>
I don't remember seeing that feature in the STM presentation
<d1b2>
<azonenberg> tl;dr if you have a board using the octospi for talking to an FPGA, and you do not break out the DQS pin (as i do, the trigger crossbar)
<d1b2>
<azonenberg> you must
<d1b2>
<azonenberg> 1) align all of your SFRs to 32 byte boundaries
<d1b2>
<azonenberg> 2) make all of your SFRs 32 bits wide, only accessed as an entire 32 bit word
<d1b2>
<azonenberg> 3) not put anything in between them
<d1b2>
<azonenberg> 4) any register you wish to poll must be mapped twice, 32 bytes or more apart
<d1b2>
<azonenberg> and you ping-pong between them to force cache misses
<d1b2>
<azonenberg> 5) not have side effects on read
<dingwat>
69 pages of errata. owch
<d1b2>
<azonenberg> oh looks like i dodged a bullet there on the h735
<d1b2>
<azonenberg> it's not affected (only 47 pages of errata lol)
<gruetzkopf>
guess who has both a h742 and a h743 in the same project
<gruetzkopf>
but our FPGA is only QSPI mapped :D
<dingwat>
I can't help but notice the numerous and sundry QSPI errata lol
<d1b2>
<vegard_e> I had a go at the XSPI (hexadeca) on the H7S recently, so far it's been working well after I remembered to configure the GPIO speed to high
sgstair_ has joined #scopehal
sgstair has quit [Ping timeout: 260 seconds]
_sgstair has joined #scopehal
sgstair_ has quit [Ping timeout: 248 seconds]
<dingwat>
has anyone used/heard of Cleverscope CS328A? for what appears to be a 10(?) year old device, the hardware is surprisingly capable on paper: 2x 12-bit analog channels, 100Msps, 100MHz analog bw, 8Mpts per channel, 8 digital inputs at 100Msps, USB 2.0 or 10/100 Ethernet
<dingwat>
never heard of it before
<dingwat>
interesting, seems like their focus now is optically isolated scopes for power electronics, nifty stuff. I pray I never need to come near something that needs 30kV of isolation between probe inputs...