Skip to content
Snippets Groups Projects
  1. Jun 20, 2013
  2. Jun 19, 2013
    • Jim Lin's avatar
      NET: Fix system hanging if NET device is not installed · 7315cfd9
      Jim Lin authored
      
      If we try to boot from NET device, NetInitLoop in net.c will be invoked.
      If NET device is not installed, eth_get_dev() function will return
      eth_current value, which is NULL.
      When NetInitLoop is called, "eth_get_dev->enetaddr" will access
      restricted memory area and therefore cause hanging.
      This issue is found on Tegra30 Cardhu platform after adding
      CONFIG_CMD_NET and CONFIG_CMD_DHCP in config header file.
      
      Signed-off-by: default avatarJim Lin <jilin@nvidia.com>
      Tested-by: default avatarStephen Warren <swarren@nvidia.com>
      7315cfd9
  3. Jun 17, 2013
  4. Jun 14, 2013
  5. Jun 13, 2013
    • Stephen Warren's avatar
      ARM: tegra: make use of negative ENV_OFFSET on NVIDIA boards · 91171091
      Stephen Warren authored
      
      Use a negative value of CONFIG_ENV_OFFSET for all NVIDIA reference boards
      that store the U-Boot environment in the 2nd eMMC boot partition. This
      makes U-Boot agnostic to the size of the eMMC boot partition, which can
      vary depending on which eMMC device was actually stuffed into the board.
      
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Acked-by: default avatarTom Warren <twarren@nvidia.com>
      Signed-off-by: default avatarAndy Fleming <afleming@freescale.com>
      91171091
    • Stephen Warren's avatar
      env_mmc: allow negative CONFIG_ENV_OFFSET · 5c088ee8
      Stephen Warren authored
      
      A negative value of CONFIG_ENV_OFFSET is treated as a backwards offset
      from the end of the eMMC device/partition, rather than a forwards offset
      from the start.
      
      This is useful when a single board may be stuffed with different eMMC
      devices, each of which has a different capacity, and you always want the
      environment to be stored at the very end of the device (or eMMC boot
      partition for example).
      
      One example of this case is NVIDIA's Ventana reference board.
      
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarAndy Fleming <afleming@freescale.com>
      5c088ee8
    • Stephen Warren's avatar
      mmc: report capacity for the selected partition · f866a46d
      Stephen Warren authored
      
      Enhance the MMC core to calculate the size of each MMC partition, and
      update mmc->capacity whenever a partition is selected. This causes:
      
      mmc dev 0 1 ; mmcinfo
      
      ... to report the size of the currently selected partition, rather than
      always reporting the size of the user partition.
      
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarAndy Fleming <afleming@freescale.com>
      f866a46d
    • Stephen Warren's avatar
      README: document CONFIG_ENV_IS_IN_MMC · 06e4ae5f
      Stephen Warren authored
      
      Describe the meaning of CONFIG_ENV_IS_IN_MMC, and all related defines that
      must or can be set when using that option.
      
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Reviewed-by: default avatarPeter Korsgaard <jacmet@sunsite.dk>
      Acked-by: default avatarTom Rini <trini@ti.com>
      Signed-off-by: default avatarAndy Fleming <afleming@freescale.com>
      06e4ae5f
    • Andrew Gabbasov's avatar
      fsl_esdhc: Do not clear interrupt status bits until data processed · 01b77353
      Andrew Gabbasov authored
      
      After waiting for the command completion event, the interrupt status
      bits, that occured to be set by that time, are cleared by writing them
      back. It is supposed, that it should be command related bits (command
      complete and may be command errors).
      
      However, in some cases the DMA already completes by that time before
      the full transaction completes. The corresponding DINT bit gets set
      and then cleared before even entering the loop, waiting for data part
      completion. That waiting loop never gets this bit set, causing the
      operation to hang. This is reported to happen, for example, for write
      operation of 1 sector to upper area (block #7400000) of SanDisk Ultra II
      8GB card.
      
      The solution could be to explicitly clear only command related interrupt
      status bits. However, since subsequent processing does not rely on
      any command bits state, it could be easier just to remove clearing
      of any bits at that point, leaving them all until all data processing
      completes. After that the whole register will be cleared at once.
      
      Also, on occasion, interrupts masking moved to before writing the command,
      just for the case there should be no chance of interrupt between the first
      command and interrupts masking.
      
      Reported-by: default avatarDirk Behme <dirk.behme@de.bosch.com>
      Signed-off-by: default avatarAndrew Gabbasov <andrew_gabbasov@mentor.com>
      Acked-by: default avatarDirk Behme <dirk.behme@de.bosch.com>
      Signed-off-by: default avatarAndy Fleming <afleming@freescale.com>
      01b77353
    • Fabio Estevam's avatar
      mmc: fsl_esdhc: Fix hang after 'save' command · c2137b10
      Fabio Estevam authored
      
      Since commit 48e0b2bd (powerpc/esdhc: Correct judgement for DATA PIO mode)
      we see mx6 systems to hang after doing a 'save' command.
      
      Revert this commit since the original 'ifdef' logic from 7b43db92
      (drivers/mmc/fsl_esdhc.c: fix compiler warnings) was the correct one.
      
      Reported-by: default avatarTapani Utriainen <tapani@technexion.com>
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: default avatarAndy Fleming <afleming@freescale.com>
      c2137b10
    • Ruud Commandeur's avatar
      mmc write bug fix · a586c0aa
      Ruud Commandeur authored
      
      This patch fixes a bug related to mmc writes.
      
      When doing fatwrites on an SD-Card, MMC bus problems can occur. Depending
      on the size of the file, "MMC0: Bus busy timeout!" is reported, resulting
      in an SD-Card that is no longer responding.
      It appears to be, that set_cluster can be called with a size being zero.
      That can be with a file that has a size being an exact multiple
      (including 0) of the clustersize, but also for files that are smaller than
      the size of one cluster.
      The same problem occurs if the "mmc write" command is given with a block
      count being 0.
      
      By adding a check for the block count being zero in mmc_write_blocks
      (drivers/mmc.c), this problem is solved.
      
      Signed-off-by: default avatarRuud Commandeur <rcommandeur@clb.nl>
      Cc: Tom Rini <trini@ti.com>
      Cc: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
      Cc: Mats Karrman <Mats.Karrman@tritech.se>
      Cc: Andy Fleming <afleming@gmail.com>
      Signed-off-by: default avatarAndy Fleming <afleming@freescale.com>
      a586c0aa
    • Jagan Teki's avatar
      mmc: sdhci: Enable 8-bit bus width only for 3.0 spec onwards · 1695b29a
      Jagan Teki authored
      
      CAP register don't have any information for 8-bit buswidth support
      on 2.0 sdhci spec, only from 3.0 onwards bit[18] got this information.
      
      Due to this misassignment in sdhci, mmc is setting 8-bit buswidth using
      mmc_set_bus_width even if controller doesn't support.
      Below change has code information.
      "mmc: Properly determine maximum supported bus width"
      (sha1: 7798f6db)
      
      Bug log: <mmc plus and emmc cards)
      -------
      zynq-uboot> mmcinfo
      Error detected in status(0x208100)!
      Device: zynq_sdhci
      Manufacturer ID: fe
      .....
      
      So enable 8-bit support only for 3.0 spec using CAP and for below 3.0
      assign mmc->host_caps = MMC_MODE_8BIT on respective platform driver
      if host have a support.
      
      Signed-off-by: default avatarJagannadha Sutradharudu Teki <jaganna@xilinx.com>
      Signed-off-by: default avatarAndy Fleming <afleming@freescale.com>
      1695b29a
    • Bo Shen's avatar
      mmc: fix env in mmc with redundant compile error · 5707df77
      Bo Shen authored
      
      The commit d196bd88 (env_mmc: add support for redundant environment)
      introduce the following compile error when enable redundant
      environment support with MMC
      ---8<---
      env_mmc.c:149: error: 'env_t' has no member named 'flags'
      env_mmc.c:248: error: 'env_t' has no member named 'flags'
      env_mmc.c:248: error: 'env_t' has no member named 'flags'
      env_mmc.c:250: error: 'env_t' has no member named 'flags'
      env_mmc.c:250: error: 'env_t' has no member named 'flags'
      env_mmc.c:252: error: 'env_t' has no member named 'flags'
      env_mmc.c:252: error: 'env_t' has no member named 'flags'
      env_mmc.c:254: error: 'env_t' has no member named 'flags'
      env_mmc.c:254: error: 'env_t' has no member named 'flags'
      env_mmc.c:267: error: 'env_t' has no member named 'flags'
      make[1]: *** [env_mmc.o] Error 1
      --->8---
      
      Add this patch to fix it
      
      Signed-off-by: default avatarBo Shen <voice.shen@atmel.com>
      Reviewed-by: default avatarMichael Heimpold <mhei@heimpold.de>
      Signed-off-by: default avatarAndy Fleming <afleming@freescale.com>
      5707df77
Loading