- 10 Aug, 2019 2 commits
-
-
Ben Avison authored
A following register read (after exit from the function) could bypass the write buffer. Version 0.16. Tagged as 'SDIODriver-0_16'
-
Ben Avison authored
The new SDHCI controller in the Pi 4 appears to follow the spec in this regard also.
-
- 15 Jul, 2019 4 commits
-
-
John Ballance authored
Version 0.15. Tagged as 'SDIODriver-0_15'
-
John Ballance authored
-
John Ballance authored
-
Ben Avison authored
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.
-
- 02 Jul, 2019 4 commits
-
-
Ben Avison authored
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.
-
Ben Avison authored
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.
-
Ben Avison authored
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.
-
Ben Avison authored
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.
-
- 24 Jun, 2019 1 commit
-
-
Ben Avison authored
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'
-
- 17 Jan, 2018 1 commit
-
-
Robert Sprowson authored
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.
-
- 17 Jan, 2017 1 commit
-
-
Robert Sprowson authored
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'
-
- 20 May, 2015 1 commit
-
-
Robert Sprowson authored
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'
-
- 02 Feb, 2015 1 commit
-
-
Ben Avison authored
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'
-
- 05 Nov, 2014 1 commit
-
-
Ben Avison authored
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'
-
- 31 Oct, 2014 1 commit
-
-
Ben Avison authored
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'
-
- 14 Jul, 2014 1 commit
-
-
Ben Avison authored
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'
-
- 01 Apr, 2013 1 commit
-
-
Jeffrey Lee authored
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'
-
- 24 Jan, 2013 1 commit
-
-
Robert Sprowson authored
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'
-
- 06 Jul, 2012 1 commit
-
-
Ben Avison authored
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'
-
- 03 Jul, 2012 1 commit
-
-
Ben Avison authored
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'
-
- 01 Jul, 2012 1 commit
-
-
Ben Avison authored
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'
-
- 15 Jun, 2012 1 commit
-
-
Ben Avison authored
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'
-
- 07 Jun, 2012 1 commit
-
-
Ben Avison authored
-