5 ms·

Implicit assumption that the Pi's PCIe doesn't follow the spec? There is a lot of room between "it works in our target market" and "it follows the spec". I only

Implicit assumption that the Pi's PCIe doesn't follow the spec? There is a lot of room between "it works in our target market" and "it follows the spec". I only mention that because I have come across a number of situations where the specifications related to "downsizing" the interface when insufficient resources are detected are often ignored when the target platform is invested in providing only the maximum amount of resources. Think USB2.0 high speed devices failing to down throttle in a USB 1.1 port and still work as an example. That said, there are often latent bugs in these situations that this sort of research/experimentation can uncover. Manufacturers would do well to invest the time in understanding why it doesn't work because those reasons can often lead to problems that are hard to catch when it is working.

manv1 4y ago
FTA there seem to be at least 2 problems: "the Pi has problems with cache coherency on the PCI Express bus beyond 32-bits. And many (well, all nowadays) of the drivers expect that to function." Yeah, that's a problem. "there were issues with the BAR (Base Address Register) space allocated on the Pi's OS." From the GitHub link: # The default BAR address space available on the CM4 may be too small to allow # some devices to initialize correctly. To avoid 'failed to assign memory' These don't look like implementation quirks, they are just flat-out errors.
- simcop2387 4y ago
  I believe from previous articles/videos from Jeff that the BAR one is at least addressable via a custom kernel or device tree that sets up a large enough BAR space for those devices. That said I would be surprised if there's a way to easily fix the first problem in software aside from forcing constant cache flushes when dealing with MMIO registers which would be a huge undertaking and probably tank performance in ways that nobody would want since this should be handled by the controller on an as needed basis instead.
rustybolt 4y ago
I would think "buggy" implies "has bugs" as in "does not follow specifications".
- ChuckMcM 4y ago
  I also refers to "doesn't interpret the meaning of the specification in the same way."

manv1 4y ago

FTA there seem to be at least 2 problems: "the Pi has problems with cache coherency on the PCI Express bus beyond 32-bits. And many (well, all nowadays) of the drivers expect that to function." Yeah, that's a problem. "there were issues with the BAR (Base Address Register) space allocated on the Pi's OS." From the GitHub link: # The default BAR address space available on the CM4 may be too small to allow # some devices to initialize correctly. To avoid 'failed to assign memory' These don't look like implementation quirks, they are just flat-out errors.

simcop2387 4y ago
I believe from previous articles/videos from Jeff that the BAR one is at least addressable via a custom kernel or device tree that sets up a large enough BAR space for those devices. That said I would be surprised if there's a way to easily fix the first problem in software aside from forcing constant cache flushes when dealing with MMIO registers which would be a huge undertaking and probably tank performance in ways that nobody would want since this should be handled by the controller on an as needed basis instead.

rustybolt 4y ago

I would think "buggy" implies "has bugs" as in "does not follow specifications".

ChuckMcM 4y ago
I also refers to "doesn't interpret the meaning of the specification in the same way."