1. 18 Apr, 2016 5 commits
  2. 14 Apr, 2016 1 commit
  3. 13 Apr, 2016 4 commits
  4. 12 Apr, 2016 7 commits
  5. 11 Apr, 2016 1 commit
    • Stephen Warren's avatar
      ARM: add Raspberry Pi 3 64-bit config · d22a7657
      Stephen Warren authored
      On all Pis so far, the VC FW provides a short stub to set up the ARM CPU
      before entering the kernel (a/k/a U-Boot for us). This feature is not
      currently supported by the VC FW when booting in 64-bit mode. However,
      this feature will likely appear in the near future, and this U-Boot port
      assumes that such a feature is in place. Without that feature, or a
      temporary workaround described below, U-Boot will not boot.
      
      Once the VC FW does provide the ARM stub, u-boot.bin built for rpi_3 can
      be used drectly as kernel7.img, in the same way as any other RPi port. The
      following config.txt is required:
      
          # Fix mini UART input frequency, and setup/enable up the UART.
          # Without this option, U-Boot will not boot, even if you don't care
          # about the serial console. This option will always be required for
          # all RPi3 use-cases, unless the PL011 UART is used, which is not
          # yet supported by rpi_3* builds of U-Boot.
          enable_uart=1
          # Boot in AArch64 (64-bit) mode.
          # It is possible that a future VC FW will remove the need for this
          # option, instead auto-setting 32-/64-bit mode based on the "kernel"
          # filename present on the SD card.
          arm_control=0x200
      
      Prior to the VC FW providing the ARM boot stub, you can use the following
      steps to build an equivalent stub into the U-Boot binary:
      
      git clone https://github.com/swarren/rpi-3-aarch64-demo.git \
          ../rpi-3-aarch64-demo
      (cd ../rpi-3-aarch64-demo && ./build.sh)
      Build U-Boot for rpi_3 in the usual way
      cat ../rpi-3-aarch64-demo/armstub64.bin u-boot.bin > u-boot.bin.stubbed
      Use u-boot.bin.stubbed as kernel7.img on the Pi SD card.
      
      In this case, the following additional entries are required in config.txt:
      
          # Tell the FW to load the kernel image at address 0, the reset vector.
          kernel_old=1
      Signed-off-by: 's avatarStephen Warren <swarren@wwwdotorg.org>
      Reviewed-by: 's avatarTom Rini <trini@konsulko.com>
      d22a7657
  6. 10 Apr, 2016 1 commit
    • Marek Vasut's avatar
      arm: socfpga: sockit: Use more relaxed DRAM timings · 4d74c027
      Marek Vasut authored
      The currently present DRAM timings generated from GHRD 14.0 did
      not work on SoCkit rev. D because they were too tight. Load the
      DRAM timings from GHRD 13.0 which are more relaxed and work with
      SoCkit rev. D.
      Signed-off-by: 's avatarMarek Vasut <marex@denx.de>
      Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
      Cc: Chin Liang See <clsee@altera.com>
      4d74c027
  7. 06 Apr, 2016 2 commits
  8. 04 Apr, 2016 7 commits
  9. 03 Apr, 2016 3 commits
  10. 01 Apr, 2016 9 commits
    • Mateusz Kulikowski's avatar
      board: Add Qualcomm Dragonboard 410C support · 626f048b
      Mateusz Kulikowski authored
      This commit add support for 96Boards Dragonboard410C.
      It is board based on APQ8016 Qualcomm SoC, complying with
      96boards specification.
      Features (present out of the box):
      - 4x Cortex A53 (ARMv8)
      - 2x USB Host port
      - 1x USB Device port
      - 4x LEDs
      - 1x HDMI connector
      - 1x uSD connector
      - 3x buttons (Power, Vol+, Vol-/Reset)
      - WIFI, Bluetooth with integrated antenna
      - 8GiB eMMC
      
      U-Boot boots chained with fastboot in 64-bit mode.
      For detailed build instructions see readme.txt in board directory.
      Signed-off-by: 's avatarMateusz Kulikowski <mateusz.kulikowski@gmail.com>
      Tested-by: 's avatarSimon Glass <sjg@chromium.org>
      626f048b
    • Mateusz Kulikowski's avatar
      usb: Rename ehci-fsl.h to ehci-ci.h · e162c6b1
      Mateusz Kulikowski authored
      Most of ehci-fsl header describe USB controller
      designed by Chipidea and used by various SoC vendors.
      
      This patch renames it to a generic header: ehci-ci.h
      Contents of file are not changed (so it contains several
      references to freescale SoCs).
      Signed-off-by: 's avatarMateusz Kulikowski <mateusz.kulikowski@gmail.com>
      Acked-by: 's avatarMarek Vasut <marex@denx.de>
      Tested-by: 's avatarSimon Glass <sjg@chromium.org>
      e162c6b1
    • Dan Murphy's avatar
      board: ti: DRA7: Add DP83867 TI phy for rev c · 39fbac91
      Dan Murphy authored
      Enable the TI DP83867 Giga bit phy on the
      dra7 rev c board.  The rx and tx internal
      delays are need for this board so the usage
      of RGMII_ID is required.
      Signed-off-by: 's avatarDan Murphy <dmurphy@ti.com>
      Acked-by: 's avatarMugunthan V N <mugunthanvnm@ti.com>
      Reviewed-by: 's avatarTom Rini <trini@konsulko.com>
      39fbac91
    • Paul Kocialkowski's avatar
      sniper: Change vendor name from lge to lg, matching devicetree vendor prefix · 41582e2e
      Paul Kocialkowski authored
      This moves the sniper board from the lge to lg, in order to match the devicetree
      vendor prefix already defined in the kernel.
      Signed-off-by: 's avatarPaul Kocialkowski <contact@paulk.fr>
      41582e2e
    • Paul Kocialkowski's avatar
      kc1: Proper reboot mode and boot reason validation · 523849a0
      Paul Kocialkowski authored
      With the previous implementation, rebooting without registering a recognized
      reboot mode would end up with U-Boot checking for a valid power-on reason, which
      might result in the device turning off (e.g. with no USB cable attached and no
      buttons pressed).
      
      Since this approach is not viable (breaks reboot in most cases), the validity of
      the reboot reason is checked (in turn, by checking that a warm reset happened,
      as there is no magic) to detect a reboot and the 'o' char is recognized to
      indicate that power-off is required. Still, that might be overridden by the
      detection of usual power-on reasons, on purpose.
      Signed-off-by: 's avatarPaul Kocialkowski <contact@paulk.fr>
      523849a0
    • Paul Kocialkowski's avatar
      sniper: Proper reboot mode and boot reason validation · c15ab5be
      Paul Kocialkowski authored
      With the previous implementation, rebooting without registering a recognized
      reboot mode (despite registering the magic) would end up with U-Boot checking
      for a valid power-on reason, which might result in the device turning off (e.g.
      with no USB cable attached and no buttons pressed).
      
      This was designed to catch reboots that are actually intended to be power-off,
      something that old Android kernels do, instead of properly turning the device
      off using the TWL4030.
      
      However, since this approach is not viable (breaks reboot in most cases), the
      validity of the reboot mode magic is checked to detect a reboot and the 'o' char
      is recognized to indicate that power-off is required. Still, that might be
      overridden by the detection of usual power-on reasons, on purpose.
      Signed-off-by: 's avatarPaul Kocialkowski <contact@paulk.fr>
      c15ab5be
    • Stephen Warren's avatar
      rpi: BCM2837 and Raspberry Pi 3 32-bit support · f031f501
      Stephen Warren authored
      The Raspberry Pi 3 contains a BCM2837 SoC. The BCM2837 is a BCM2836 with
      the CPU complex swapped out for a quad-core ARMv8. This can operate in 32-
      or 64-bit mode. 32-bit mode is the current default selected by the
      VideoCore firmware on the Raspberry Pi 3. This patch adds a 32-bit port of
      U-Boot for the Raspberry Pi 3.
      
      >From U-Boot's perspective, the only delta between the RPi 2 and RPi 3 is a
      change in usage of the SoC UARTs. On all previous Pis, the PL011 was the
      only UART in use. The Raspberry Pi 3 adds a Bluetooth module which uses a
      UART to connect to the SoC. By default, the PL011 is used for this purpose
      since it has larger FIFOs than the other "mini" UART. However, this can
      be configured via the VideoCore firmware's config.txt file. This patch
      hard-codes use of the mini UART in the RPi 3 port. If your system uses the
      PL011 UART for the console even on the RPi 3, please use the RPi 2 U-Boot
      port instead. A future change might determine which UART to use at
      run-time, thus allowing the RPi 2 and RPi 3 (32-bit) ports to be squashed
      together.
      
      The mini UART has some limitations. One externally visible issue in the
      BCM2837 integration is that the UART divides the SoC's "core clock" to
      generate the baud rate. The core clock is typically variable, and under
      control of the VideoCore firmware for thermal management reasons. If the
      VC FW does modify the core clock rate, UART communication will be
      corrupted since the baud rate will vary from the expected value. This was
      not an issue for the PL011 UART, since it is fed by a fixed 3MHz clock. To
      work around this, the VideoCore firmware can be told not to modify the SoC
      core clock. However, the only way this can happen and be thermally safe is
      to limit the core clock to a low/minimum frequency. This leaves
      performance on the table for use-cases that don't care about a UART
      console. Consequently, use of the mini UART console must be explicitly
      requested by entering the following line into config.txt:
      
          enable_uart=1
      
      A recent version of the VC firmware is required to ensure that the mini
      UART is fully and correctly initialized by the VC FW; at least
      firmware.git 046effa13ebc "firmware: arm_loader: emmc clock depends on
      core clock See: https://github.com/raspberrypi/firmware/issues/572".
      Signed-off-by: 's avatarStephen Warren <swarren@wwwdotorg.org>
      Reviewed-by: 's avatarTom Rini <trini@konsulko.com>
      f031f501
    • Stephen Warren's avatar
      rpi: add Raspberry Pi 3 board ID · 7233fb31
      Stephen Warren authored
      This allows U-Boot to known the name of the board.
      
      The existing rpi_2_defconfig can operate correctly on the Raspberry Pi 3
      in 32-bit mode /if/ you have configured the firmware to use the PL011 UART
      as the console UART (the default is the mini UART). This requires two
      things:
      a) config.txt should contain dtoverlay=pi3-miniuart-bt
      b) You should run the following to tell the VC FW to process DT when
      booting, and copy u-boot.bin.img (rather than u-boot.bin) to the SD card
      as the kernel image:
      
         path/to/kernel/scripts/mkknlimg --dtok u-boot.bin u-boot.bin.img
      
      This works as of firmware.git commit 046effa13ebc "firmware: arm_loader:
      emmc clock depends on core clock See:
      https://github.com/raspberrypi/firmware/issues/572".
      Signed-off-by: 's avatarStephen Warren <swarren@wwwdotorg.org>
      Reviewed-by: 's avatarTom Rini <trini@konsulko.com>
      7233fb31
    • Stephen Warren's avatar
      rpi: use constant "unknown board" DT filename · 29937caa
      Stephen Warren authored
      To simplify support for new SoCs, just use a constant filename
      for the unknown case. In practice this case shouldn't be hit anyway, so
      the filename isn't relevant, and certainly doesn't need to differentiate
      between SoCs. If a user has an as-yet-unknown board, they can override
      this value in the environment anyway.
      Signed-off-by: 's avatarStephen Warren <swarren@wwwdotorg.org>
      Reviewed-by: 's avatarTom Rini <trini@konsulko.com>
      29937caa