Skip to content
Snippets Groups Projects
  1. Jul 22, 2017
  2. Jul 19, 2017
  3. Jul 18, 2017
  4. Jul 14, 2017
    • Fabio Estevam's avatar
      mx6cuboxi: Move CONFIG_CMD_SATA to Kconfig · 651782a0
      Fabio Estevam authored
      
      Move CONFIG_CMD_SATA option to Kconfig to fix the following build
      error:
      
      In file included from include/configs/mx6cuboxi.h:137:0,
                       from include/config.h:7,
                       from include/common.h:21,
                       from common/env_common.c:11:
      include/config_distro_bootcmd.h:161:2: error: expected '}' before 'BOOT_TARGET_DEVICES_references_SATA_without_CONFIG_SATA'
        BOOT_TARGET_DEVICES_references_SATA_without_CONFIG_SATA
      
      Reported-by: default avatarStefano Babic <sbabic@denx.de>
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      651782a0
  5. Jul 13, 2017
  6. Jul 12, 2017
    • Tom Rini's avatar
      Merge git://www.denx.de/git/u-boot-marvell · e14b1169
      Tom Rini authored
      e14b1169
    • Patrick Bruenn's avatar
      imx: cx9020: try pxe boot, if no vmlinuz on mmc · bc104a70
      Patrick Bruenn authored
      
      If no vmlinuz is found on mmc, try to boot from pxe.
      
      Signed-off-by: default avatarPatrick Bruenn <p.bruenn@beckhoff.com>
      bc104a70
    • Patrick Bruenn's avatar
      imx: cx9020: use fdt_addr_r and ramdisk_addr_r · f8e63850
      Patrick Bruenn authored
      
      Replace fdtaddr and rdaddr variable names with u-boot standard names
      fdt_addr_r and ramdisk_addr_r.
      This will make the use of pxe boot more easy.
      
      Signed-off-by: default avatarPatrick Bruenn <p.bruenn@beckhoff.com>
      f8e63850
    • Diego Dorta's avatar
      mx6sabreauto: Add Falcon mode support · 07f6ddb6
      Diego Dorta authored
      
      Add support for Falcon mode and explain in the README the steps to
      boot the kernel directly without loading the full U-Boot.
      
      Signed-off-by: default avatarDiego Dorta <diego.dorta@nxp.com>
      Acked-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      07f6ddb6
    • Fabio Estevam's avatar
      warp: Use PARTUUID to specify the rootfs location · 283c2a65
      Fabio Estevam authored
      
      warp can run different kernel versions, such as NXP 4.1 or
      mainline.
      
      Currently the rootfs location is passed via mmcblk number and the
      problem with this approach is that the mmcblk number for the eMMC
      changes depending on the kernel version.
      
      In order to avoid such issue, use UUID method to specify the rootfs
      location.
      
      Succesfully tested booting a NXP 4.1 and also a mainline 4.12 kernel.
      
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      Acked-by: default avatarOtavio Salvador <otavio@ossystems.com.br>
      283c2a65
    • Fabio Berton's avatar
      embestmx6boards: Use PARTUUID to specify the rootfs location · 0f29a61c
      Fabio Berton authored
      
      Currently the rootfs location is passed via mmcblk number and the
      problem with this approach is that the mmcblk number for the eMMC
      changes depending on the kernel version.
      
      In order to avoid such issue, use UUID method to specify the rootfs
      location.
      
      Also add CONFIG_BOOTCOMMAND to run finduuid function and distro_bootcmd.
      
      This change was made based on U-Boot commit:
      
        - ca4f338e
      
      Signed-off-by: default avatarFabio Berton <fabio.berton@ossystems.com.br>
      Signed-off-by: default avatarOtavio Salvador <otavio@ossystems.com.br>
      Reviewed-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      0f29a61c
    • Fabio Berton's avatar
      mx6cuboxi: Use PARTUUID to specify the rootfs location · 35ba390d
      Fabio Berton authored
      
      Currently the rootfs location is passed via mmcblk number and the
      problem with this approach is that the mmcblk number for the eMMC
      changes depending on the kernel version.
      
      In order to avoid such issue, use UUID method to specify the rootfs
      location.
      
      This change was made based on U-Boot commit:
      
        - ca4f338e
      
      Signed-off-by: default avatarFabio Berton <fabio.berton@ossystems.com.br>
      Signed-off-by: default avatarOtavio Salvador <otavio@ossystems.com.br>
      Reviewed-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      35ba390d
    • Fabio Berton's avatar
      wandboard: Use PARTUUID to specify the rootfs location · 84b4690f
      Fabio Berton authored
      
      Currently the rootfs location is passed via mmcblk number and the
      problem with this approach is that the mmcblk number for the eMMC
      changes depending on the kernel version.
      
      In order to avoid such issue, use UUID method to specify the rootfs
      location.
      
      This change was made based on U-Boot commit:
      
        - ca4f338e
      
      Signed-off-by: default avatarFabio Berton <fabio.berton@ossystems.com.br>
      Signed-off-by: default avatarOtavio Salvador <otavio@ossystems.com.br>
      Reviewed-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      84b4690f
    • Fabio Estevam's avatar
      mx6sabre: Use PARTUUID to specify the rootfs location · 00f43e51
      Fabio Estevam authored
      
      mx6sabre boards can run different kernel versions, such as NXP 4.1 or
      mainline.
      
      Currently the rootfs location is passed via mmcblk number and the
      problem with this approach is that the mmcblk number for the eMMC
      changes depending on the kernel version.
      
      In order to avoid such issue, use UUID method to specify the rootfs
      location.
      
      Succesfully tested booting a NXP 4.1 and also a mainline kernel on a
      mx6qsabresd and mx6dlsabreauto.
      
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      00f43e51
    • Fabio Estevam's avatar
      mx6sabreauto: Do not enable WEIM by default · ca62e5d0
      Fabio Estevam authored
      
      WEIM cannot be used when I2C3 is enabled due to pin conflict, so keep
      WEIM disabled by default.
      
      I2C3 controls GPIO I2C expander (USB host and OTG have VBUS controlled by
      the GPIO I2C expander), magnetometer, accelerometer.
      
      Not disabling WEIM in U-Boot causes I2C3 to behave badly when booting
      a NXP 4.1 kernel, which leads to probe failure on several devices,
      including the lack of USB:
      
      imx_usb 2184000.usb: Can't register ci_hdrc platform device, err=-517
      
      By keeping WEIM disabled in U-Boot these kernel issues are gone.
      
      Reported-by: default avatarTakashi Matsuzawa <tmatsuzawa@xevo.com>
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      ca62e5d0
    • Stefano Babic's avatar
      imx: reorganize IMX code as other SOCs · 552a848e
      Stefano Babic authored
      
      Change is consistent with other SOCs and it is in preparation
      for adding SOMs. SOC's related files are moved from cpu/ to
      mach-imx/<SOC>.
      
      This change is also coherent with the structure in kernel.
      
      Signed-off-by: default avatarStefano Babic <sbabic@denx.de>
      
      CC: Fabio Estevam <fabio.estevam@nxp.com>
      CC: Akshay Bhat <akshaybhat@timesys.com>
      CC: Ken Lin <Ken.Lin@advantech.com.tw>
      CC: Marek Vasut <marek.vasut@gmail.com>
      CC: Heiko Schocher <hs@denx.de>
      CC: "Sébastien Szymanski" <sebastien.szymanski@armadeus.com>
      CC: Christian Gmeiner <christian.gmeiner@gmail.com>
      CC: Stefan Roese <sr@denx.de>
      CC: Patrick Bruenn <p.bruenn@beckhoff.com>
      CC: Troy Kisky <troy.kisky@boundarydevices.com>
      CC: Nikita Kiryanov <nikita@compulab.co.il>
      CC: Otavio Salvador <otavio@ossystems.com.br>
      CC: "Eric Bénard" <eric@eukrea.com>
      CC: Jagan Teki <jagan@amarulasolutions.com>
      CC: Ye Li <ye.li@nxp.com>
      CC: Peng Fan <peng.fan@nxp.com>
      CC: Adrian Alonso <adrian.alonso@nxp.com>
      CC: Alison Wang <b18965@freescale.com>
      CC: Tim Harvey <tharvey@gateworks.com>
      CC: Martin Donnelly <martin.donnelly@ge.com>
      CC: Marcin Niestroj <m.niestroj@grinn-global.com>
      CC: Lukasz Majewski <lukma@denx.de>
      CC: Adam Ford <aford173@gmail.com>
      CC: "Albert ARIBAUD (3ADEV)" <albert.aribaud@3adev.fr>
      CC: Boris Brezillon <boris.brezillon@free-electrons.com>
      CC: Soeren Moch <smoch@web.de>
      CC: Richard Hu <richard.hu@technexion.com>
      CC: Wig Cheng <wig.cheng@technexion.com>
      CC: Vanessa Maegima <vanessa.maegima@nxp.com>
      CC: Max Krummenacher <max.krummenacher@toradex.com>
      CC: Stefan Agner <stefan.agner@toradex.com>
      CC: Markus Niebel <Markus.Niebel@tq-group.com>
      CC: Breno Lima <breno.lima@nxp.com>
      CC: Francesco Montefoschi <francesco.montefoschi@udoo.org>
      CC: Jaehoon Chung <jh80.chung@samsung.com>
      CC: Scott Wood <oss@buserror.net>
      CC: Joe Hershberger <joe.hershberger@ni.com>
      CC: Anatolij Gustschin <agust@denx.de>
      CC: Simon Glass <sjg@chromium.org>
      CC: "Andrew F. Davis" <afd@ti.com>
      CC: "Łukasz Majewski" <l.majewski@samsung.com>
      CC: Patrice Chotard <patrice.chotard@st.com>
      CC: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
      CC: Hans de Goede <hdegoede@redhat.com>
      CC: Masahiro Yamada <yamada.masahiro@socionext.com>
      CC: Stephen Warren <swarren@nvidia.com>
      CC: Andre Przywara <andre.przywara@arm.com>
      CC: "Álvaro Fernández Rojas" <noltari@gmail.com>
      CC: York Sun <york.sun@nxp.com>
      CC: Xiaoliang Yang <xiaoliang.yang@nxp.com>
      CC: Chen-Yu Tsai <wens@csie.org>
      CC: George McCollister <george.mccollister@gmail.com>
      CC: Sven Ebenfeld <sven.ebenfeld@gmail.com>
      CC: Filip Brozovic <fbrozovic@gmail.com>
      CC: Petr Kulhavy <brain@jikos.cz>
      CC: Eric Nelson <eric@nelint.com>
      CC: Bai Ping <ping.bai@nxp.com>
      CC: Anson Huang <Anson.Huang@nxp.com>
      CC: Sanchayan Maity <maitysanchayan@gmail.com>
      CC: Lokesh Vutla <lokeshvutla@ti.com>
      CC: Patrick Delaunay <patrick.delaunay@st.com>
      CC: Gary Bisson <gary.bisson@boundarydevices.com>
      CC: Alexander Graf <agraf@suse.de>
      CC: u-boot@lists.denx.de
      Reviewed-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      Reviewed-by: default avatarChristian Gmeiner <christian.gmeiner@gmail.com>
      552a848e
    • Peng Fan's avatar
      mmc: fsl_esdhc: drop CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT · f34ccce5
      Peng Fan authored
      
      CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT is not the correct method
      to set I/O to 1.8. To boards that does not support vqmmc-supply,
      use vs18_enable in fsl_esdhc_cfg. If regulator is supported,
      use fixed 1.8V regulator for vqmmc-supply.
      
      Signed-off-by: default avatarPeng Fan <peng.fan@nxp.com>
      Cc: Jaehoon Chung <jh80.chung@samsung.com>
      Cc: York Sun <york.sun@nxp.com>
      Cc: Stefano Babic <sbabic@denx.de>
      f34ccce5
    • Peng Fan's avatar
      dm: mmc: fsl_esdhc: handle vqmmc supply · 4483b7eb
      Peng Fan authored
      
      Handle vqmmc supply. Some boards have a fixed I/O voltage
      at 1.8V for emmc, so the usdhc also needs to be configured
      as 1.8V by setting VSELECT bit. The vs18_enable is the one
      that used to checking whether setting VSELECT or not in
      the driver. So if vqmmc supply is 1.8V, set vs18_enable,
      the driver will set VSELECT.
      
      Signed-off-by: default avatarPeng Fan <peng.fan@nxp.com>
      Cc: Jaehoon Chung <jh80.chung@samsung.com>
      Cc: York Sun <york.sun@nxp.com>
      Cc: Stefano Babic <sbabic@denx.de>
      Reviewed-by: default avatarJaehoon Chung <jh80.chung@samsung.com>
      4483b7eb
Loading