1. 07 Jul, 2018 1 commit
  2. 21 Feb, 2017 1 commit
    • Robert Sprowson's avatar
      Add support for CM3 and CM3L with or without eMMC · 6eeefb37
      Robert Sprowson authored
      The SDIO HAL device reports when it is sure fixed disc media is attached (ie. eMMC soldered on the same PCB) which causes SDFS to report this to FileCore as a fixed disc, skipping the removable safety checks.
      However, CM3 and CM3L both return the same board id so we can't work out which is which. Additionally, someone could attach an external eMMC in theory on a custom expansion board (instead of an SD card socket like the CMIO has).
      To resolve this, we assign IO expander line 6 of U8 to be a safety catch. If that line is held low, it signifies this is definitely a CM3 - in effect this is a "definitely has eMMC" or "maybe has eMMC" switch.
      Tested on CM1, CM3, CM3L, and a suitably modified CM3 with the help of Chris Hall.
      Version 0.69. Tagged as 'BCM2835-0_69'
  3. 22 Oct, 2016 1 commit
  4. 15 Oct, 2016 1 commit
    • Robert Sprowson's avatar
      Move CMOS settings out of riscos.img · afc8ef8d
      Robert Sprowson authored
      The Pi is unusual in self modifying the ROM image when a CMOS setting was changed (due to there being none on the PCB), with the potential of ending up with a corrupt OS image on disc.
      Remove this code and emulate the CMOS using normal RAM, and using the Pi firmware to load the CMOS file in for us (like fatload does on OMAP based designs) by using its ability to load a second arbitrary file at an address, intended in the Linux world to load a disc image.
      To use this you will need to add
      to config.txt which loads it 5MB (ie. ImageSize) above the default load address (&8000), though as noted in the changes to BCM2835-0_60 we don't really need to load at offset &8000 but generally do since that's the Pi firmware's default.
      New workspace to hold our CMOS copy.
      Remove the 2k magic block, add a simple bytewise copy loop implementation.
      Extend ADR range.
      Copy what the Pi firmware loads somewhere safe until the MMU is on, then copy it back (converting from logical to physical order along the way).
      Change other values recovered from pre-MMU times using advanced post indexed addressing technology (TM) rather than switching around sb a lot.
      Tested on a Pi 3, with and without an initial CMOS file present.
      Version 0.61. Tagged as 'BCM2835-0_61'
  5. 09 May, 2016 1 commit
    • Jeffrey Lee's avatar
      GET Hdr:CPU.Arch · 2b6c0909
      Jeffrey Lee authored
        s/SDIO - Add a GET of Hdr:CPU.Arch, as it's now required for use of the DivRem macro
        Tested on Raspberry Pi
      Version 0.58. Tagged as 'BCM2835-0_58'
  6. 04 Apr, 2016 1 commit
    • Jeffrey Lee's avatar
      Fix sticky SD activity LED on Pi 3 B · 486e778f
      Jeffrey Lee authored
        s/SDIO - Signed counter wrap-around once &80007fff was reached was causing the code to think the activity LED was permanently off, resulting in the code only making "turn on" requests. Calculating the difference as a (signed) 16bit value solves the problem.
        Tested on Pi 3 B
        Fixes SD activity LED being stuck on after e.g. letting Verify run for a few seconds.
      Version 0.57. Tagged as 'BCM2835-0_57'
  7. 26 Mar, 2016 1 commit
    • Jeffrey Lee's avatar
      Fix SD card activity LED on Pi 3B · 3e87de33
      Jeffrey Lee authored
        hdr/BCM2835 - Remove mailbox definitions - use the ones exported by BCMSupport to avoid needless duplication
        hdr/StaticWS, s/Messaging, s/Top - Use the mailbox property interface to request & map in the virtual GPIO buffer (if present)
        s/SDIO - On the Pi 3B, the GPIO that was used for the SD activity GPIO is now used for a different purpose. To control the activity LED we need to go via an I2C attached GPIO extender, which itself is exposed to the ARM via the new "virtual GPIO" buffer
        s/VCHIQ - Update to use BCMSupport mailbox definitions
        Tested on Pi 1B, 3B
      Version 0.54. Tagged as 'BCM2835-0_54'
  8. 03 Feb, 2015 1 commit
    • Ben Avison's avatar
      Properly supports new board revision scheme for SD source file · 1b785be4
      Ben Avison authored
        Parses the revision ID bitfield for new-style revisions - should provide
        some level of forward compatibility at last. The equivalent code in s.GPIO
        hasn't been tackled yet, mainly because it requires some thought about how
        best to handle the Compute module (given that the daughter card can be
        plugged into any number of devices, each of which will use GPIO differently).
        Tested on Compute module and Pi 2 with latest firmware.
      Version 0.42. Tagged as 'BCM2835-0_42'
  9. 02 Feb, 2015 2 commits
    • Ben Avison's avatar
      Adapt to release version of Raspberry Pi 2 firmware · 0f6c0f83
      Ben Avison authored
        The board revision scheme has changed since pre-release firmware, so the
        previous version of the SD code would have misidentified a Pi 2 (as well
        as the model A+) as a Compute module. It looks like in future, board
        revisions could be a more meaningful bitfield rather than the order-of-
        release index that's been used up to now, but at this point we can still
        manage with a cunning combination of CMP and TEQ tests. Note that the GPIO
        part of the HAL hasn't yet been updated to be aware of the new board
      Version 0.41. Tagged as 'BCM2835-0_41'
    • Ben Avison's avatar
      Add support for Raspberry Pi Compute module and Raspberry Pi 2 · 60752490
      Ben Avison authored
        * Compute module support consists of eMMC support in the SDHCI driver. The
          eMMC chip on the Compute module only works reliably if under-clocked to
          25 MHz.
        * Pi 1 vs Pi 2 differences are selected at runtime by checking the CPU ID,
          so a single ROM image will work with both boards.
        * Added ARMv7 cache maintenance routine for use on Pi 2.
        * The physical address of the peripherals has moved in Pi 2 to make space
          for the 1 GB of RAM.
        * The ARM physical address space is mapped differently onto the GPU
          address space in Pi 2 because the ARM now uses the L2 cache that comes
          with the Cortex-A7 instead of the GPU's L2 cache.
        * Still waiting for confirmation on the board revision ID that will be
          used for Pi 2, so may require further tweaks for production releases.
      Version 0.40. Tagged as 'BCM2835-0_40'
  10. 30 Oct, 2014 1 commit
  11. 14 Jul, 2014 1 commit
    • Ben Avison's avatar
      Support the Raspberry Pi model B+ · 4830dcfe
      Ben Avison authored
        The activity GPIO pin has been reassigned and its sense is inverted,
        compared to earlier boards. More importantly, the SD card detect pin has
        been removed entirely, so we need to signal to the SD stack to use its
        new timeout-based state machine (rather than polling for card presence).
        Already in use in RC12a.
      Version 0.35. Tagged as 'BCM2835-0_35'
  12. 01 Jul, 2012 1 commit
    • Ben Avison's avatar
      Fixes for SD support · 60ebea68
      Ben Avison authored
        * Engage the GPIO controller's pull-up resistors on SDCLK, CMD and DAT0-DAT3.
          In tests, this seems to address the worst of the unreliability we have
          seen previously.
        * Remove the entry to change the bus between push-pull and open-drain modes.
          The BCM2835 simply doesn't seem to be able to do this. Fortunately, all
          the cards I have tested seem to be OK with the GPIO controller's pull-up
          on the CMD line (however strong that is - it's undocumented) engaged at
          all times.
        * Time a dummy command in order to calculate the speed of the input clock
          to the SD controller block (there doesn't appear to be any way to read
          its speed directly!) This is necessary because recent versions of the
          firmware have not only changed the default clock speed, but even made it
          a user-configurable option in config.txt. It's very important that we
          know how fast it is - if we set the dividers so SDCLK is too slow, then
          the workaround for the register write bug won't work, too fast and we
          overclock the cards, potentially damaging them.
        * Re-enable high speed mode. As long as we don't use the High Speed Enable
          bit in Host Control 1 (see change in SDIODriver 0.03) this seems to work
          for me.
        Tested against my collection of test cards on a Raspberry Pi with the
        firmware from the 2012-06-22 commit on github, and with
        init_emmc_clock=100000000 in config.txt (though other values, or the
        absence of that line, or the entire file, should also work). The only
        issues I had appeared to be due to mechanical problems with the SD socket,
        and went away after the card was reseated one or more times.
      Version 0.10. Tagged as 'BCM2835-0_10'
  13. 15 Jun, 2012 1 commit
    • Ben Avison's avatar
      SD support, and miscellaneous other changes · 981cfe6d
      Ben Avison authored
        * Bugfix to HAL_FIQDisableAll - it wasn't clearing the FIQ register (would
          only have caused trouble in practice if the same device was subsequently
          enabled as an IRQ).
        * Added a load of memory barriers to s.Interrupts and s.Timers to conform
          to the requirement stated in 1.3 of the datasheet.
        * Added a HAL device for the Arasan SDHCI controller. Note that this does
          not currently work reliably, and results vary from card to card. High
          speed support is currently disabled until we are able to verify that it
          works reliably.
        * Added a sprinkling of "GET Hdr:ListOpts" because the space reserved for
          the SDHCI HAL device in hdr.StaticWS is determined by including
          Hdr:HALDevice and Hdr:SDHCIDevice, which need it.
        * When support for saving "CMOS" to the SD card is added, the ROM image
          file (kernel.img) is the only one we can count on the bootloader
          installing in memory, so I think we're going to have to work using the
          table in s.CMOS. Broadcom seems to like messing around with the space
          just after the processor vector table, so rather than adding a pointer
          to the table there, I've opted to mark it using a magic word.
        Tested on a Raspberry Pi - as noted above, there are reliability issues.
      Version 0.09. Tagged as 'BCM2835-0_09'