GitLab

A following register read (after exit from the function) could bypass the
write buffer.

Version 0.16. Tagged as 'SDIODriver-0_16'

The new SDHCI controller in the Pi 4 appears to follow the spec in this regard
also.

Version 0.15. Tagged as 'SDIODriver-0_15'

These are identified by a different value in the major version field, and are
intended for SD controllers that implement a register set that does not follow
the SDHCI standard. All interaction with the controller is performed via
function calls into such a HAL device, and a few of these are new.

A couple of other changes that were made in passing:

* device_added() now calls set_activity() and thereby avoids a branch through
  zero if a device indicates that the SDHCI host_control1 register should be
  used for setting the activity indicator.
* HAL device deactivate entry is now called before OS_ReleaseDeviceVector so
  that it can be used to mask interrupts in the host controller. Since no
  current versions of the module use interrupts, this is a safe change.

This is now split into an outer function that does locking, iterates over
the operation list and interacts with the OS and SDIODriver's clients, and
an inner function op_poll_sdhci() which codifies the wait states of a
standards-compliant SDHCI controller and does the register bashing. This
internal API is now pretty close to what is required for a soft controller.

Three members of sdioop_t are particularly closely tied to the state machine
for SDHCI controllers, and so are likely to differ for soft controllers.
Create sdhci_op_t to hold these, and introduce a variable-length array member
at end of sdioop_t to hold it. Allocate sdioop_t more dyamically in
preparation for soft controllers.

This is made up of 11 former members of sdioop_t. These will become part
of the new "soft" controller API, so refactor the code to expose them as
a new struct type, and use that internally.

A lot of state doesn't actually care whether a controller's register layout
follows the SDHCI standard or not. To reduce future confusion, most internal
types and pointer variables are hereby renamed from 'sdhci' to a more generic
'ctrl', short for 'controller'. Exceptions are sdhci_regset_t and
sdhci_writebuffer_t, which are intimately tied to register accesses.

Public data types and definitions (and the names of the exported header files)
retain the original names, for the sake of not breaking all the other
components that rely on them.

The new SDHCI controller in Pi 4 actually follows the spec in this regard
(allegedly - not yet measured in practice)

Version 0.14. Tagged as 'SDIODriver-0_14'

Static analysis highlighted a do/while as a potential error
  https://www.riscosopen.org/forum/forums/4/topics/9503#posts-72623
Clarify the original intent with some braces.
Retagged as SDIODriver-0_13; binary unchanged.

When COMMAND_DATA doesn't return an error, SDIODriver was still trying to check the error number in the error block, causing an abort.
Fixes problem spotted by Chris Hall on Pi Compute with its unusual eMMC chip.

Version 0.13. Tagged as 'SDIODriver-0_13'

Looks like a factor of 2 the wrong way 14<-28->56, though SDIODriver doesn't actually use those high up registers fortunately.
Not tested, given that fact, but matches the comments now.

Version 0.12. Tagged as 'SDIODriver-0_12'

Detail:
  This is the first board supported by RISC OS that has an eMMC chip. This
  is a non-removable flash memory device which obeys a recent revision of
  the MMC bus protocol, which has many similarities with the SD bus.
  * Flags added to low-level and high-level APIs to identify the device as
    a hard drive under SDFS (affects the media search algorithms).
  * For a sector-addressed MMC device (over 2 GB), CMD1 needs HCS set in
    the command or it won't respond.
  * The MMC device needed to be selected when reading the EXT_CSD (which is
    only present in sector-addressed MMC cards).
  * Added the generic SDHCI fallback versions of some HAL device routines.
Admin:
  Tested on a Compute module (of course).

Version 0.11. Tagged as 'SDIODriver-0_11'

Detail:
  Before this version gets too widely used in the wild, I'm taking the
  opportunity to correct the new call so that it takes the slot parameter
  like all the other calls do.


Version 0.10. Tagged as 'SDIODriver-0_10'

Detail:
  * Important data loss bug rectified: the retry mechanism inadvertently
    failed to pass back over data that had been transmitted to the card but
    not written successfully, instead picking up afterwards and swallowing
    the error. Therefore, only repeatable errors such as card timeouts were
    being reported correctly, and user data could be lost with no indication
    until it failed to read back correctly.
  * Supports controllers with the following quirks:
    1) Error bit in interrupt status register not implemented
    2) Non-standard method of triggering SD bus command
  * Reports non-standard error number 12 reported by some controllers
  * Checks for a major version match on SDHCI HAL devices before using them
    (should have been doing this all along, but fortunately there are no
    plans for incompatible changes that would force a major version change
    in the forseeable future).

Version 0.09. Tagged as 'SDIODriver-0_09'

Detail:
  For removable slots without a card detect pin, disable the ticker routine
  to poll for the card-detect state, because the HAL is unable to report
  any meaningful result. Pass through the fact that it is one of these types
  of slots to SDFS, where card removal / change is detected by use of
  timeouts instead.
Admin:
  Already in use in RC12a.

Version 0.08. Tagged as 'SDIODriver-0_08'

Detail:
  c/module, cmhg/SDIOHdr - Instead of initialising the device list inside a callback, we now initialise it when we receive our ModulePostInit service call.
  This fixes SDCMOS initialisation; both SDCMOS and SDIODriver were using callbacks to initialise themselves, but the recent fixes to callback triggering during ROM init meant that the SDIODriver callback was no longer guaranteed to occur before the SDCMOS callback. This was preventing SDCMOS from initialising properly as SDFS/SDIODriver wouldn't have been available yet.
Admin:
  Tested on Raspberry Pi and Pandora with SDCMOS-friendly SD cards


Version 0.07. Tagged as 'SDIODriver-0_07'

Spotted a product name which didn't have a terminator, and *SDIODEVICES spewed out whatever else was on the stack until a 0 terminator was found. Bounded the product name with the printf() formatter.

Version 0.06. Tagged as 'SDIODriver-0_06'

Detail:
  Now uses OS_Hardware 5 if it is available, so that SD controllers are
  allocated in the order in which they were registered, irrespective of
  whether they were registered before or after SDIODriver initialised.
Admin:
  Builds, but not tested

Version 0.05. Tagged as 'SDIODriver-0_05'

Detail:
  The OMAP4 SD controller is more fussy about how it is reset than the OMAP3
  and BCM2835 controllers - more details in inline comments. Issue identified
  by Willi Theiss, but I have implemented the fix differently. Also added
  Willi's support for DebugLib debugging.
Admin:
  Tested on Beagleboard, Raspberry Pi and Pandaboard, and with the usual
  set of 30+ cards.

Version 0.04. Tagged as 'SDIODriver-0_04'

Detail:
  * On SD memory cards and SDIO cards, disengage the card's internal pull-up
    resistor on DAT3. This is designed to function as part of the card detect
    mechanism on some boards (not any of the ones we support) but this is
    probably desirable in order to ensure the impedance of all the DAT lines
    match.
  * Pace data buffer reads by polling the Present State register rather than
    using the Read Buffer Ready interrupt. This is because the controller on
    the BCM2835 occasionally fails to issue the interrupt (another clock
    domain crossing bug in the chip?) so we end up waiting for a timeout and
    then retrying, with the overall effect appearing as variable data transfer
    rates. When background transfers are implemented, we will need to rely on
    TickerV to do this polling. Fortunately, the OMAP3 controller seems to be
    unaffected by this change.
  * Don't use the High Speed Enable bit in the Host Control 1 register - it
    seems to cause more trouble than it's worth (more discussion in inline
    comments).
Admin:
  Tested on my full collection of test cards on both beagleboard and RPi.

Version 0.03. Tagged as 'SDIODriver-0_03'

Detail:
  The Arasan controller, unlike the OMAP3 one, pays attention to the HSE
  bit in the Control 1 register. This wasn't being reset before starting
  up the next card to be inserted, which caused some cards to fail to
  initialise.
Admin:
  Tested on Raspberry Pi, should have no effect on OMAP3.

Version 0.02. Tagged as 'SDIODriver-0_02'