First revision of the board came in some weeks ago. First mistake was with populating the Teensy4.0. As almost all available pins are used in the design, including the SD-card interface ones, great care has to be put into soldering it down. I chose a rather rigid wire for these SD-card pads, and behold, it ripped the traces right off. Not all is lost tough, plenty of initial prototyping can be done without those. Second mistake was more severe, I left the SCLK line to the DevTerm unconnected in the schematic. A simple bodge wire to the pad on the PCI-E connector was no problem, altough not recommended since it does leave a dent in the recepting connectors' plastic.

From a mechanical standpoint, the design so far is solid. The USB ports, mounting holes, cartridge connector, everything lines up as it should, with the exception of the Teensy which is soldered with standard 2.54mm headers and stands off a bit too far. For the second prototype, a thinner header row is already ordered which should fit. The DevTerm barely can be reassembled with a little flex in the cover. Besides that, plugging in a cartridge is satisfying after many hours spent in FreeCAD.

The firmware is based on PlatformIO's Zephyr environment for the Teensy4.0. I recommend using Zephyrs' drivers only after you checked the sources. I tried a slave configuration for the SPI communicating with the DevTerm, with no errors. This was a fatal mistake, as the driver does accept a slave configuration, but instead configures the SPI as a master. Now I had two masters pushing and pulling on the same lines. I could have known something was up due to the whack scope measurements, but I chalked it up to bad routing distorting the signals. The result is that the DevTerms' CS0.0 seems fried, it doesn't pull down as it used to. I moved forward using a Raspberry Pi 3, which I should have done in the first place to prevent this setback. Lesson learned is that you don't use your expensive unit to test. One interesting thing to note is that the firmware embeds Lua, which should allow easy download of cartridge specific functionality in firmware via Lua bytecode. Right now, bytecode can be loaded with the `bload('-',1)` statement via the USB ACM, later it should be possible to upload and run bytecode via SPI. The plan here is to use the I2C EEPROM in a cartrige to store said bytecode, which can be used to initialize the Teensys' peripherals but there's potential for more. This depends on a more clever implementation of the communication protocol used: Right now it's just a simple command word with an argument resulting in a response at the next transaction, with a 32-bit buffer in each transaction containing additional information. I tried implementing a protocol with varying transaction sizes to be more efficient, but with no success so far.

Latest thing I tried was populating the USB hub. Initially, it looked dire: No oscillation of the quartz, and dmesg reporting an ERRNO -32 for the device. Sleeping over it, I found the culprits: bad choice of TVS diodes shorting out various lines and R115.
Now, this series resistor is recommended by TI to prevent large currents at the crystal, and usually the reason why a design around the TUSB2036 doesn't work. Either the resistor wasn't soldered on correctly, or this did prevent the chip working.
Anyhow, by bridging this resistor, the hub enumerates and works a charm.

For the next round of boards, the newest revision fixes the missing SCLK line and adds a few pads to solder the Teensy's main USB to the internal hub. Alternatively, the Teensys' host USB pins can be selected for this USB downstream line via jumpers.
Theoretically, one could use the MCUXpresso library directly in PlatformIO and configure USB2 as a device, but until then I'll connect the Teensy via a chopped Micro-USB cable on USB1.