overlays: Add overlay for the Pineboards Hat Ai!

[mikegapinski]

This overlay simplifies the configuration of the Coral Edge TPU (Single and Dual Edge) on the Pi 5.

On top of the msi-parent change the Gasket driver does need the 4K page kernel right now (/boot/firmware/config.txt -> kernel=kernel8.img)

[mikegapinski]

@popcornmix may I request a review for this? Having this merged would make our lives a little bit easier. The Coral (even dual edge) works very well on the Pi and this is essentially the only blocker.

[popcornmix]

@pelwell may be better for overlay changes.

[pelwell]

You haven't said why you need to change the msi-parent - what effect does it have?

[mikegapinski]

@pelwell the Gasket driver for Coral won't init without init the interrupts without this change. It was originally suggested on the forums by jdb back in November when we were trying to get Coral running for the first time. https://forums.raspberrypi.com/viewtopic.php?p=2157674#p2157674 (https://www.jeffgeerling.com/blog/2023/pcie-coral-tpu-finally-works-on-raspberry-pi-5)

People have been manually editing the DTB in order to switch this since we started selling the Coral HAT back in January but this is not sustainable at a larger scale.

[6by9]

@P33M

Why is this named after one specific product if it is only making a generic PCIe configuration change?
It feels like it's in the same boat as the pcie-32bit-dma overlay and should have a generic name based on what it does.

[P33M]

The pcie-32bit-dma overlay shouldn't make assumptions about the endpoint's ability to generate MSIs >32bits (since they're plain data writes as well) so that needs fixing up. Is the bug with the Coral stick simply that it can't do MSIs targeting >4GB? In which case the "32bit" overlay should probably grow an option to move MSI target address as well as (or instead of) limiting the inbound window.

Edit: re-read my own post: the endpoint needs more vectors than MIP1 can provide. So it's not related to 32-bitness at all in this case.

[mikegapinski]

@6by9 I chose the product-specific name since it allows us to flash it to the EEPROM on the upcoming HAT+ board (that has the Coral chip soldered, not a generic board with an M.2 A+E slot). There is no clear guideline on naming right now and that is how it's been done before for audio boards (most of them are compatible with the Hifiberry overlay but each vendor has their own overlay)

[mikegapinski]

Another thing worth noting is that Coral itself is very picky and it doesn't work on all PCIe HATs.

Some of them start working when our flex cable is used (there are things we did that are above the suggested standard since it didn't exist at all when they were designed), some boards simply don't work at all (routing issues?). That's why I assumed that a board related overlay makes sense here.

[pelwell]

Given the reasons outlined above I'm happy to merge this as is. If we end up with multiple requests for identical overlays for use from HAT EEPROMs we can support them via the overlay_map.

[P33M]

Another thing worth noting is that Coral itself is very picky and it doesn't work on all PCIe HATs.

Some of them start working when our flex cable is used (there are things we did that are above the suggested standard since it didn't exist at all when they were designed), some boards simply don't work at all (routing issues?). That's why I assumed that a board related overlay makes sense here.

From my own testing, the Coral chip is very sensitive to TX/RX crosstalk, causing link instability. You mostly get away with it on CM4 due to reference clock spread-spectrum, but that's not possible on Pi 5. Good PCB and flexi design is required.