1. 11 Dec, 2019 1 commit
    • Matthias Brugger's avatar
      rpi: fix dram bank initialization · e19cfcc0
      Matthias Brugger authored
      To update the dram bank information from device-tree we use
      fdtdec_decode_ram_size() which expectes the the size-cells and
      address-cells to be defined in the memory node. For normal system RAM
      these values are defined in the root node. When the values differ from
      the default values defined in the spec, we can end up with wrong RAM
      bank information.
      
      Switch to the "standard" way to update the RAM bank information to
      avoid this.
      
      Fixes: 9de5b89e
      
       ("rpi4: enable dram bank initialization")
      Signed-off-by: default avatarMatthias Brugger <mbrugger@suse.com>
      e19cfcc0
  2. 02 Dec, 2019 1 commit
  3. 24 Nov, 2019 2 commits
  4. 01 Oct, 2019 1 commit
    • Matthias Brugger's avatar
      rpi4: enable dram bank initialization · 9de5b89e
      Matthias Brugger authored
      
      
      When booting through the efi stub, the memory map get's created by
      reading the dram bank information. Depending on the version of the RPi4
      this information changes. Read the device tree to initialize the dram
      bank data structure. This way the kernel is able to access the whole
      range of available memory.
      Signed-off-by: default avatarMatthias Brugger <mbrugger@suse.com>
      9de5b89e
  5. 06 Sep, 2019 2 commits
  6. 11 Aug, 2019 2 commits
  7. 15 Feb, 2019 1 commit
  8. 03 Dec, 2018 2 commits
  9. 11 Sep, 2018 1 commit
  10. 07 May, 2018 1 commit
    • Tom Rini's avatar
      SPDX: Convert all of our single license tags to Linux Kernel style · 83d290c5
      Tom Rini authored
      
      
      When U-Boot started using SPDX tags we were among the early adopters and
      there weren't a lot of other examples to borrow from.  So we picked the
      area of the file that usually had a full license text and replaced it
      with an appropriate SPDX-License-Identifier: entry.  Since then, the
      Linux Kernel has adopted SPDX tags and they place it as the very first
      line in a file (except where shebangs are used, then it's second line)
      and with slightly different comment styles than us.
      
      In part due to community overlap, in part due to better tag visibility
      and in part for other minor reasons, switch over to that style.
      
      This commit changes all instances where we have a single declared
      license in the tag as both the before and after are identical in tag
      contents.  There's also a few places where I found we did not have a tag
      and have introduced one.
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      83d290c5
  11. 09 Apr, 2018 1 commit
    • Alex Kiernan's avatar
      net: Move enetaddr env access code to env config instead of net config · 9925f1db
      Alex Kiernan authored
      In order that we can use eth_env_* even when CONFIG_NET isn't set, move
      these functions to environment code from net code.
      
      This fixes failures such as:
      
        board/ti/am335x/built-in.o: In function `board_late_init':
        board/ti/am335x/board.c:752: undefined reference to `eth_env_set_enetaddr'
        u-boot/board/ti/am335x/board.c:766: undefined reference to `eth_env_set_enetaddr'
      
      which caters for use cases such as:
      
      commit f411b5cc
      
       ("board: am335x: Always set eth/eth1addr environment
      variable")
      
      when Ethernet is required in Linux, but not U-Boot.
      Signed-off-by: default avatarAlex Kiernan <alex.kiernan@gmail.com>
      9925f1db
  12. 06 Apr, 2018 1 commit
  13. 05 Apr, 2018 1 commit
  14. 28 Jan, 2018 2 commits
    • Alexander Graf's avatar
      rpi: Remove runtime disabling support for serial · 55b8a2dd
      Alexander Graf authored
      
      
      We are switching to a model where our board file can directly fail probing
      of serial devices when they're not usable, so remove the current runtime
      hack we have.
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      55b8a2dd
    • Alexander Graf's avatar
      bcm283x: Add pinctrl driver · caf2233b
      Alexander Graf authored
      
      
      The bcm283x family of SoCs have a GPIO controller that also acts as
      pinctrl controller.
      
      This patch introduces a new pinctrl driver that can actually properly mux
      devices into their device tree defined pin states and is now the primary
      owner of the gpio device. The previous GPIO driver gets moved into a
      subdevice of the pinctrl driver, bound to the same OF node.
      
      That way whenever a device asks for pinctrl support, it gets it
      automatically from the pinctrl driver and GPIO support is still available
      in the normal command line phase.
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      caf2233b
  15. 04 Dec, 2017 1 commit
  16. 16 Aug, 2017 4 commits
  17. 10 May, 2017 6 commits
  18. 24 Jan, 2017 1 commit
  19. 29 Nov, 2016 3 commits
  20. 21 Nov, 2016 1 commit
    • Cédric Schieli's avatar
      rpi: passthrough of the firmware provided FDT blob · ade243a2
      Cédric Schieli authored
      Raspberry firmware used to pass a FDT blob at a fixed address (0x100),
      but this is not true anymore. The address now depends on both the
      memory size and the blob size [1].
      
      If one wants to passthrough this FDT blob to the kernel, the most
      reliable way is to save its address from the r2/x0 register in the
      U-Boot entry point and expose it in a environment variable for
      further processing.
      
      This patch just does this:
      - save the provided address in the global variable fw_dtb_pointer
      - expose it in ${fdt_addr} if it points to a a valid FDT blob
      
      There are many different ways to use it. One can, for example, use
      the following script which will extract from the tree the command
      line built by the firmware, then hand over the blob to a previously
      loaded kernel:
      
      fdt addr ${fdt_addr}
      fdt get value bootargs /chosen bootargs
      bootz ${kernel_addr_r} - ${fdt_addr}
      
      Alternatively, users relying on sysboot/pxe can simply omit any FDT
      statement in their extlinux.conf file, U-Boot will automagically pick
      ${fdt_addr} and pass it to the kernel.
      
      [1] https://www.raspberrypi.org/forums//viewtopic.php?f=107&t=134018
      
      Signed-off-by: default avatarCédric Schieli <cschieli@gmail.com>
      Acked-by: default avatarStephen Warren <swarren@nvidia.com>
      ade243a2
  21. 06 Sep, 2016 1 commit
    • Alexander Graf's avatar
      serial: bcm283x_mu: Detect disabled serial device · 601147b0
      Alexander Graf authored
      
      
      On the raspberry pi, you can disable the serial port to gain dynamic frequency
      scaling which can get handy at times.
      
      However, in such a configuration the serial controller gets its rx queue filled
      up with zero bytes which then happily get transmitted on to whoever calls
      getc() today.
      
      This patch adds detection logic for that case by checking whether the RX pin is
      mapped to GPIO15 and disables the mini uart if it is not mapped properly.
      
      That way we can leave the driver enabled in the tree and can determine during
      runtime whether serial is usable or not, having a single binary that allows for
      uart and non-uart operation.
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      Acked-by: default avatarStephen Warren <swarren@wwwdotorg.org>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      601147b0
  22. 15 Jul, 2016 1 commit
  23. 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: default avatarStephen Warren <swarren@wwwdotorg.org>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      d22a7657
  24. 01 Apr, 2016 2 commits
    • 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: default avatarStephen Warren <swarren@wwwdotorg.org>
      Reviewed-by: default 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: default avatarStephen Warren <swarren@wwwdotorg.org>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      7233fb31