1. 02 Feb, 2015 2 commits
    • Ben Avison's avatar
      Fix for disc error 08 immediately after module reinit on Raspberry Pi B+ and 2 · 30493587
      Ben Avison authored
        On these boards, because there's no card-detect line, SDIODriver only
        issues the UnitAttached and UnitDetached service calls in its module
        init/final code and when one of the rescan SWIs are called (usually by
        SDFS). The "maybe-changed" timer is implemented within SDFS; when it has
        elapsed, any DiscOp will try to select a card with the last-known-good ID
        in that slot; if this fails (because there's no card, or the card has
        changed, or even if the same card has been removed and reinserted) SDFS
        will get SDIODriver to rescan the slot, at which point SDFS is re-entered
        via the UnitAttached service call, which resets the "maybe-changed" timer
        to 1 second.
        The problem was that SDFS reused the same function that handles
        Service_SDIOUnitAttached during its module initialisation, so for the
        first second of SDFS's life, it believed the card ID which it was
        informed of by SDIODriver is valid and has been accessed within the last
        second. Except that if the card has actually been removed and reinserted,
        the command issued by SDFS ends up timing out, resulting in disc error 08.
        Tested on Pi B+ (assumed identical behaviour on Pi 2)
      Version 0.08. Tagged as 'SDFS-0_08'
    • Ben Avison's avatar
      Add Raspberry Pi Compute module support · 7592adfe
      Ben Avison authored
        The eMMC chip on the Compute module is now treated as a hard drive by SDFS.
        A number of bugs (relating to top-bit-set disc addresses for example) were
        required to facilitate this. If a board has an eMMC chip, then the default
        SDFS drive is drive 4 rather than drive 0; this doesn't require any change
        to the default CMOS values in the kernel or HAL (SDFS adjusts its
        interpretation of the CMOS byte instead).
        Tested on a Compute module (of course).
      Version 0.07. Tagged as 'SDFS-0_07'
  2. 31 Oct, 2014 1 commit
    • Ben Avison's avatar
      Drive (lack of) allocation for permanent SDIO devices fixed · 8683288a
      Ben Avison authored
        Non-removable SDIO devices were never supposed to be allocated an SDFS
        drive, but were by accident in the secondary (UnitAttached rather than
        SlotAttached) service call.
        Applies to boards such as the IGEPv2, with SDIO WiFi chips on the board.
      Version 0.06. Tagged as 'SDFS-0_06'
  3. 14 Jul, 2014 1 commit
    • Ben Avison's avatar
      Support the Raspberry Pi model B+ · 8d0bd7b6
      Ben Avison authored
        For removable slots without a card detect pin, use an alternate state
        machine based upon timeouts to detect card removal or card changes. Note
        that this requires cooperation from FileCore (the same code paths as with
        selected floppy drives that had faulty disc changed pins) to avoid data
        loss by assuming that a disc might need remounting if a certain time has
        elapsed since the last successful operation. To avoid a significant speed
        penalty from deselecting and reselecting cards, remounting isn't used for
        rapid back-to-back operations.
        Already in use in RC12a.
      Version 0.05. Tagged as 'SDFS-0_05'
  4. 29 Apr, 2014 1 commit
  5. 30 Sep, 2012 1 commit
    • Jeffrey Lee's avatar
      Fix SD slots not always appearing on iconbar · df682e08
      Jeffrey Lee authored
        c/module - A typo in the startup code resulted in the service_SDIOSlotAttached 'integrated' parameter being calculated incorrectly.
        Tested on Pandora
        2nd SD slot now appears on iconbar if slot is empty on boot (previously would only appear if slot occupied)
      Version 0.03. Tagged as 'SDFS-0_03'
  6. 16 Jul, 2012 1 commit
    • Ben Avison's avatar
      Fix for bug that meant that several cards only worked in drive 0 · 14356c66
      Ben Avison authored
        MiscOp 0 turns out to pass the drive number *both* in R1 and in the top
        3 bits of R2. SDFS was failing to mask the drive bits out of R2, which
        caused some (but not all) cards to generate an error. Obviously, this
        didn't affect drive 0.
        Tested on Beagleboard "Zippy" expansion card
      Version 0.02. Tagged as 'SDFS-0_02'
  7. 07 Jun, 2012 1 commit