Previously we commandeered GPIO extender IO4 to be told whether eMMC is fitted or not, and only if we're certain it is via opt-in (the line being actively pulled low) would SDFS treat that as a fixed disc. Unfortunately, extender IO4 is used to set 1.8V versus 3.3V signalling on the SDIO bus - so some brands of SD card would not work as SD_VDD_override was pulled high to 1.8V signalling when 3.3V was needed.
ROOL (66d0d6ce) at 20 Mar 22:31
[611][512] Detect CM4 Lite variant using a mailbox tag
When I close tickets in the tracker I do add a note referencing the tag in which they are fixed, from which the log can be found for an explanation. It's the log that gets turned into the release notes too.
I've duplicated the text into the merge request description so you can enjoy reading it again.
Discussion of exactly why this fixes bug 611 is currently missing both from the bug tracker page and from this MR's summary. Yes, it's in the commit log, but I kinda feel it should be more prominent!
Previously we commandeered GPIO extender IO4 to be told whether eMMC is fitted or not, and only if we're certain it is via opt-in (the line being actively pulled low) would SDFS treat that as a fixed disc. Unfortunately, extender IO4 is used to set 1.8V versus 3.3V signalling on the SDIO bus - so some brands of SD card would not work as SD_VDD_override was pulled high to 1.8V signalling when 3.3V was needed.
The SDHOST controller is used for the SD slot on WiFi-capable Pi models prior to the Raspberry Pi 4, and for any SD card HATs on generation-4 Raspberry Pis.
With certain SD cards, certain patterns of reads and writes would occasionally cause a transfer (always a write transfer) to time out. This wasn't reproducible 100% of the time, and replaying only the failing write transfer - however many times - wouldn't trigger the failure. Changing the screen mode could also affect the reproducibility - meaning it was very timing sensitive.
Under observation with a logic analyser, it was clearer what was happening. The controller is gating the SDCLK signal so that it only transitions while activity is occurring on the other lines of the SD bus (this is a fairly common practice, performed for the sake of reducing power consumption but at the cost of breaking compatibility with IO cards). But in the problem cases, SDCLK is stopped before the transfer has completed. Specifically, it looks as though the card is stuck signalling "busy" on DAT0 - a condition intended to allow the card to hold off further activity from the host while it performs flash programming. But in the absence of any further SDCLK transitions, the card appears unable to ever signal it is no longer busy. Eventually the software timeout in SDIODriver triggers and it retries the operation, but as far as the card is concerned, it's seeing a new write operation start before the old one finishes, which isn't supposed to happen, and how it handles the situation is undefined. Data corruption under such circumstances is quite possible.
The workaround relies on the fact that the (e)MMC and SD standards support two different types of multi-block data transfer operations: open-ended (which is terminated by a CMD12) and pre-defined (which is preceded by a CMD23 to specify the number of blocks). (e)MMC cards (except the earliest ones that don't support multi-block transfers at all) support both CMD12 and CMD23. Early SD cards only support CMD12 - only once you reach UHS-I cards capable of SDR104 bus speeds does the standard specify that they must support CMD23. Nevertheless, you'd normally want to use CMD23 wherever possible so as to give the on-card controller the best chance to manage its flash programming strategy. But it stands to reason that the SDHOST controller must be snooping the argument to CMD23 in order to know when to gate SDCLK. And indeed, when we only use CMD12, the transfers always appear to run to completion.
For reference, the Linux driver also disables CMD23, although it only does so for write operations. I tried a similar strategy but still observed frozen transfer operations, so I'm using CMD12 for both reads and writes.
See also RiscOS/Sources/HWSupport/SD/SDIODriver!8 and RiscOS/Sources/FileSys/SDFS/SDFS!4
ROOL (79a0d834) at 11 Mar 15:40
Suppress use of CMD23 for multi-block SD transfers on SDHOST
The SDHOST controller is used for the SD slot on WiFi-capable Pi models prior to the Raspberry Pi 4, and for any SD card HATs on generation-4 Raspberry Pis.
With certain SD cards, certain patterns of reads and writes would occasionally cause a transfer (always a write transfer) to time out. This wasn't reproducible 100% of the time, and replaying only the failing write transfer - however many times - wouldn't trigger the failure. Changing the screen mode could also affect the reproducibility - meaning it was very timing sensitive.
Under observation with a logic analyser, it was clearer what was happening. The controller is gating the SDCLK signal so that it only transitions while activity is occurring on the other lines of the SD bus (this is a fairly common practice, performed for the sake of reducing power consumption but at the cost of breaking compatibility with IO cards). But in the problem cases, SDCLK is stopped before the transfer has completed. Specifically, it looks as though the card is stuck signalling "busy" on DAT0 - a condition intended to allow the card to hold off further activity from the host while it performs flash programming. But in the absence of any further SDCLK transitions, the card appears unable to ever signal it is no longer busy. Eventually the software timeout in SDIODriver triggers and it retries the operation, but as far as the card is concerned, it's seeing a new write operation start before the old one finishes, which isn't supposed to happen, and how it handles the situation is undefined. Data corruption under such circumstances is quite possible.
The workaround relies on the fact that the (e)MMC and SD standards support two different types of multi-block data transfer operations: open-ended (which is terminated by a CMD12) and pre-defined (which is preceded by a CMD23 to specify the number of blocks). (e)MMC cards (except the earliest ones that don't support multi-block transfers at all) support both CMD12 and CMD23. Early SD cards only support CMD12 - only once you reach UHS-I cards capable of SDR104 bus speeds does the standard specify that they must support CMD23. Nevertheless, you'd normally want to use CMD23 wherever possible so as to give the on-card controller the best chance to manage its flash programming strategy. But it stands to reason that the SDHOST controller must be snooping the argument to CMD23 in order to know when to gate SDCLK. And indeed, when we only use CMD12, the transfers always appear to run to completion.
For reference, the Linux driver also disables CMD23, although it only does so for write operations. I tried a similar strategy but still observed frozen transfer operations, so I'm using CMD12 for both reads and writes.
See also RiscOS/Sources/HWSupport/SD/SDIODriver!8 and RiscOS/Sources/FileSys/SDFS/SDFS!4
While investigating support for the Micrel PHY on the Pi 400 things got very confusing when the MDIO became unreliable, caused by an unrelated pull resistor setting causing the (incorrect) soft copy to be written back to the MDIO lines.
ROOL (d7df3b5c) at 04 Sep 19:33
Preserve MDIO pull resistor settings for GENET
While investigating support for the Micrel PHY on the Pi 400 things got very confusing when the MDIO became unreliable, caused by an unrelated pull resistor setting causing the (incorrect) soft copy to be written back to the MDIO lines.
When reading a file fragment that was just a shade over a natural-number of DMA bounce buffers in length (256 KiB), it was possible for the code that copies the data from the DMA buffer to the scatter list to merge the distinct events of the completion of the final two DMA buffers, leading to the part of the destination memory corresponding to the final partial DMA buffer being left uninitialised.
Also spotted in passing: the code that detects DMA buffer overrun had an exception for when two DMA buffers or less remained to be copied. This should only have applied to read transfers; for a write transfer, the DMA controller should only ever be allowed to get close to the scatterlist-to-bounce-buffer copying process if zero bytes remain to be copied in software.
Note, as this only applies to the SDHOST controller, the affected platforms were 3B, 3B+, 3A+, Zero W, Zero 2W, or the HAT on a generation-4 Pi.
Also apply workaround for Cortex-A53 errata
Cortex-A53 errata 819472, 824069, 826319 and 855873 all relate to the CP15 DCCMVAC operation (Data Cache Clean by (Modified) Virtual Address to PoC) and advocate for replacing it by the equivalent clean-and-invalidate operation, DCCIMVAC.
When reading a file fragment that was just a shade over a natural-number of DMA bounce buffers in length (256 KiB), it was possible for the code that copies the data from the DMA buffer to the scatter list to merge the distinct events of the completion of the final two DMA buffers, leading to the part of the destination memory corresponding to the final partial DMA buffer being left uninitialised.
Also spotted in passing: the code that detects DMA buffer overrun had an exception for when two DMA buffers or less remained to be copied. This should only have applied to read transfers; for a write transfer, the DMA controller should only ever be allowed to get close to the scatterlist-to-bounce-buffer copying process if zero bytes remain to be copied in software.
Note, as this only applies to the SDHOST controller, the affected platforms were 3B, 3B+, 3A+, Zero W, Zero 2W, or the HAT on a generation-4 Pi.
Also apply workaround for Cortex-A53 errata
Cortex-A53 errata 819472, 824069, 826319 and 855873 all relate to the CP15 DCCMVAC operation (Data Cache Clean by (Modified) Virtual Address to PoC) and advocate for replacing it by the equivalent clean-and-invalidate operation, DCCIMVAC.
The comment above ReadSafetyCatch about the CM4Lite catch pulling low was factually incorrect: it's always been a pull-up. It's just that we keep changing our minds about whether the catch is fitted for the Lite boards vs the ones with eMMC populated. I believe we eventually settled on CM4 and earlier boards being treated the same, therefore there is no longer any need to conditionally EOR the result based on the generation of board.
ROOL (526995f7) at 30 Jan 21:06
Regularise polarity of safety catch across Compute Modules
The comment above ReadSafetyCatch about the CM4Lite catch pulling low was factually incorrect: it's always been a pull-up. It's just that we keep changing our minds about whether the catch is fitted for the Lite boards vs the ones with eMMC populated. I believe we eventually settled on CM4 and earlier boards being treated the same, therefore there is no longer any need to conditionally EOR the result based on the generation of board.