1. 16 Sep, 2016 20 commits
  2. 07 Sep, 2016 5 commits
  3. 06 Sep, 2016 7 commits
    • Tom Rini's avatar
      TI: Rework SRAM definitions and maximums · fa2f81b0
      Tom Rini authored
      On all TI platforms the ROM defines a "downloaded image" area at or near
      the start of SRAM which is followed by a reserved area.  As it is at
      best bad form and at worst possibly harmful in corner cases to write in
      this reserved area, we stop doing that by adding in the define
      NON_SECURE_SRAM_IMG_END to say where the end of the downloaded image
      area is and make SRAM_SCRATCH_SPACE_ADDR be one kilobyte before this.
      At current we define the end of scratch space at 0x228 bytes past the
      start of scratch space this this gives us a lot of room to grow.  As
      these scratch uses are non-optional today, all targets are modified to
      respect this boundary.
      
      Tested on OMAP4 Pandaboard, OMAP3 Beagle xM
      
      Cc: Albert Aribaud <albert.u.boot@aribaud.net>
      Cc: Nagendra T S <nagendra@mistralsolutions.com>
      Cc: Vaibhav Hiremath <hvaibhav@ti.com>
      Cc: Lokesh Vutla <lokeshvutla@ti.com>
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Igor Grinberg <grinberg@compulab.co.il>
      Cc: Nikita Kiryanov <nikita@compulab.co.il>
      Cc: Paul Kocialkowski <contact@paulk.fr>
      Cc: Enric Balletbo i Serra <eballetbo@gmail.com>
      Cc: Adam Ford <aford173@gmail.com>
      Cc: Steve Sakoman <sakoman@gmail.com>
      Cc: Stefan Roese <sr@denx.de>
      Cc: Thomas Weber <weber@corscience.de>
      Cc: Hannes Schmelzer <oe5hpm@oevsv.at>
      Cc: Thomas Chou <thomas@wytron.com.tw>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Simon Glass <sjg@chromium.org>
      Cc: Joe Hershberger <joe.hershberger@ni.com>
      Cc: Sam Protsenko <semen.protsenko@linaro.org>
      Cc: Heiko Schocher <hs@denx.de>
      Cc: Samuel Egli <samuel.egli@siemens.com>
      Cc: Michal Simek <michal.simek@xilinx.com>
      Cc: Wolfgang Denk <wd@denx.de>
      Cc: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
      Cc: Ben Whitten <ben.whitten@gmail.com>
      Cc: Stefano Babic <sbabic@denx.de>
      Cc: Bin Meng <bmeng.cn@gmail.com>
      Cc: Sekhar Nori <nsekhar@ti.com>
      Cc: Mugunthan V N <mugunthanvnm@ti.com>
      Cc: "B, Ravi" <ravibabu@ti.com>
      Cc: "Matwey V. Kornilov" <matwey.kornilov@gmail.com>
      Cc: Ladislav Michl <ladis@linux-mips.org>
      Cc: Ash Charles <ashcharles@gmail.com>
      Cc: "Kipisz, Steven" <s-kipisz2@ti.com>
      Cc: Daniel Allred <d-allred@ti.com>
      Signed-off-by: 's avatarTom Rini <trini@konsulko.com>
      Tested-by: 's avatarLokesh Vutla <lokeshvutla@ti.com>
      Acked-by: 's avatarLokesh Vutla <lokeshvutla@ti.com>
      Tested-by: 's avatarLadislav Michl <ladis@linux-mips.org>
      fa2f81b0
    • Beniamino Galvani's avatar
      meson: odroid-c2: enable Ethernet support through the device tree · cfe25561
      Beniamino Galvani authored
      Remove the device definition from board file, update the driver with
      the new compatible property and update config with necessary options.
      Signed-off-by: 's avatarBeniamino Galvani <b.galvani@gmail.com>
      Reviewed-by: 's avatarSimon Glass <sjg@chromium.org>
      cfe25561
    • Beniamino Galvani's avatar
      arm: dts: update DTS files for meson-gxbb and odroid-c2 · dd83840e
      Beniamino Galvani authored
      Import DTS files and dt-bindings includes from Linux 4.8-rc1.
      Signed-off-by: 's avatarBeniamino Galvani <b.galvani@gmail.com>
      Reviewed-by: 's avatarSimon Glass <sjg@chromium.org>
      dd83840e
    • Alexander Graf's avatar
      bcm2835_gpio: Implement GPIOF_FUNC · 04a993fe
      Alexander Graf authored
      So far we could only tell the gpio framework that a GPIO was mapped as input or
      output, not as alternative function.
      
      This patch adds support for determining whether a function is mapped as
      alternative.
      Signed-off-by: 's avatarAlexander Graf <agraf@suse.de>
      Reviewed-by: 's avatarSimon Glass <sjg@chromium.org>
      Acked-by: 's avatarStephen Warren <swarren@wwwdotorg.org>
      04a993fe
    • Fabio Estevam's avatar
      mx6: ddr: Allow changing REFSEL and REFR fields · edf00937
      Fabio Estevam authored
      Currently MX6 SPL DDR initialization hardcodes the REF_SEL and
      REFR fields of the MDREF register as 1 and 7, respectively for
      DDR3 and 0 and 3 for LPDDR2.
      
      Looking at the MDREF initialization done via DCD we see that
      boards do need to initialize these fields differently:
      
      $ git grep 0x021b0020 board/
      board/bachmann/ot1200/mx6q_4x_mt41j128.cfg:DATA 4 0x021b0020 0x00005800
      board/ccv/xpress/imximage.cfg:DATA 4 0x021b0020 0x00000800 /* MMDC0_MDREF */
      board/freescale/mx6qarm2/imximage.cfg:DATA 4 0x021b0020 0x7800
      board/freescale/mx6qarm2/imximage.cfg:DATA 4 0x021b0020 0x00005800
      board/freescale/mx6qarm2/imximage_mx6dl.cfg:DATA 4 0x021b0020 0x00005800
      board/freescale/mx6qarm2/imximage_mx6dl.cfg:DATA 4 0x021b0020 0x00005800
      board/freescale/mx6qsabreauto/imximage.cfg:DATA 4 0x021b0020 0x00005800
      board/freescale/mx6qsabreauto/mx6dl.cfg:DATA 4 0x021b0020 0x00005800
      board/freescale/mx6qsabreauto/mx6qp.cfg:DATA 4 0x021b0020 0x00005800
      board/freescale/mx6sabresd/mx6dlsabresd.cfg:DATA 4      0x021b0020 0x00005800
      board/freescale/mx6sabresd/mx6q_4x_mt41j128.cfg:DATA 4 0x021b0020 0x00005800
      board/freescale/mx6slevk/imximage.cfg:DATA 4 0x021b0020 0x00001800
      board/freescale/mx6sxsabreauto/imximage.cfg:DATA 4 0x021b0020 0x00000800
      board/freescale/mx6sxsabresd/imximage.cfg:DATA 4 0x021b0020 0x00000800
      board/warp/imximage.cfg:DATA 4 0x021b0020 0x00001800
      
      So introduce a mechanism for users to be able to configure
      REFSEL and REFR fields as needed.
      
      Keep all the mx6 SPL users in their current REF_SEL and REFR values,
      so no functional changes for the existing users.
      Signed-off-by: 's avatarFabio Estevam <fabio.estevam@nxp.com>
      Reviewed-by: 's avatarEric Nelson <eric@nelint.com>
      edf00937
    • Akshay Bhat's avatar
      arm: imx: Add support for Advantech DMS-BA16 board · ff383220
      Akshay Bhat authored
      Add support for Advantech DMS-BA16 board. The board is based on Advantech
      BA16 module which has a i.MX6D processor. The board supports:
       - FEC Ethernet
       - USB Ports
       - SDHC and MMC boot
       - SPI NOR
       - LVDS and HDMI display
      
      Basic information about the module:
       - Module manufacturer: Advantech
       - CPU: Freescale ARM Cortex-A9 i.MX6D
       - SPECS:
           Up to 2GB Onboard DDR3 Memory;
           Up to 16GB Onboard eMMC NAND Flash
           Supports OpenGL ES 2.0 and OpenVG 1.1
           HDMI, 24-bit LVDS
           1x UART, 2x I2C, 8x GPIO,
           4x Host USB 2.0 port, 1x USB OTG port,
           1x micro SD (SDHC),1x SDIO, 1x SATA II,
           1x 10/100/1000 Mbps Ethernet, 1x PCIe X1 Gen2
      Signed-off-by: 's avatarAkshay Bhat <akshay.bhat@timesys.com>
      Cc: u-boot@lists.denx.de
      Cc: sbabic@denx.de
      ff383220
    • Mugunthan V N's avatar
      ARM: dts: dra72-evm: fix broken ethernet · 0068dd68
      Mugunthan V N authored
      With commit ceec08f5, phy is connected to slave 0, but
      changing the phy node was missed, fix it by populating the
      phy node to proper cpsw slave node.
      
      Fixes: ceec08f5 ("ARM: dts: dra72-evm: Add mode-gpios entry for mac node")
      Signed-off-by: 's avatarMugunthan V N <mugunthanvnm@ti.com>
      Cc: Vignesh R <vigneshr@ti.com>
      Tested-by: 's avatarTom Rini <trini@konsulko.com>
      0068dd68
  4. 03 Sep, 2016 5 commits
  5. 01 Sep, 2016 1 commit
  6. 30 Aug, 2016 2 commits
    • Stephen Warren's avatar
      ARM: tegra: use numeric versioning for p2771-0000 · 7932d3e4
      Stephen Warren authored
      The board ID EEPROM and board ID stickers on p2771-0000 will use a numeric
      versioning scheme, with version numbers such as 000/100/200/300/400/500.
      Within NVIDIA, these versions are also known as A00/A01/A02/A03/A04/B00.
      However, that numbering scheme is not easily visible outside of NVIDIA,
      and so does not make much sense to use. Convert U-Boot to use the readily
      visible numeric scheme.
      
      Also, it turns out that the current A02 DT actually applies to board
      versions 000/100/200 (A00..A02). Consequently rename this to 000 not 200
      so that all U-Boot builds are named after the first version of the HW they
      support.
      Signed-off-by: 's avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: 's avatarTom Warren <twarren@nvidia.com>
      7932d3e4
    • Bin Meng's avatar
      x86: efi: Fix EFI 64-bit payload build warnings · 3e6cc35f
      Bin Meng authored
      There are lots of warnings when building EFI 64-bit payload.
      
      include/asm-generic/bitops/__fls.h:17:2:
        warning: left shift count >= width of type
        	if (!(word & (~0ul << 32))) {
      			^
      
      In fact, U-Boot itself as EFI payload is running in 32-bit mode.
      So BITS_PER_LONG needs to still be 32, but EFI status codes are
      64-bit when booting from 64-bit EFI. Introduce EFI_BITS_PER_LONG
      to bridge those status codes with U-Boot's BITS_PER_LONG.
      Signed-off-by: 's avatarBin Meng <bmeng.cn@gmail.com>
      Reviewed-by: 's avatarSimon Glass <sjg@chromium.org>
      3e6cc35f