1. 20 Jul, 2015 1 commit
  2. 01 Jul, 2015 4 commits
  3. 29 Jun, 2015 1 commit
    • Daniel Schwierzeck's avatar
      mtd, spi: Add MTD layer driver · 9fe6d871
      Daniel Schwierzeck authored
      Add MTD layer driver for spi, original patch from:
      http://git.denx.de/?p=u-boot/u-boot-mips.git;a=commitdiff;h=bb246819cdc90493dd7089eaa51b9e639765cced
      
      Changes from Heiko Schocher against this patch:
      - Remove compile error if not defining CONFIG_SPI_FLASH_MTD:
      
        LD      drivers/mtd/spi/built-in.o
      drivers/mtd/spi/sf_probe.o: In function `spi_flash_mtd_unregister':
      /home/hs/abb/imx6/u-boot/drivers/mtd/spi/sf_internal.h:168: multiple definition of `spi_flash_mtd_unregister'
      drivers/mtd/spi/sf_params.o:/home/hs/abb/imx6/u-boot/drivers/mtd/spi/sf_internal.h:168: first defined here
      drivers/mtd/spi/sf_ops.o: In function `spi_flash_mtd_unregister':
      /home/hs/abb/imx6/u-boot/drivers/mtd/spi/sf_internal.h:168: multiple definition of `spi_flash_mtd_unregister'
      drivers/mtd/spi/sf_params.o:/home/hs/abb/imx6/u-boot/drivers/mtd/spi/sf_internal.h:168: first defined here
      make[1]: *** [drivers/mtd/spi/built-in.o] Fehler 1
      make: *** [drivers/mtd/spi] Fehler 2
      
      - Add a README entry.
      - Add correct writebufsize, to fit with Linux v3.14
        MTD, UBI/UBIFS sync.
      
      Note (From Jagan): For testing raw mtd parition erase/read/write operations
      using cmd_sf, sf_mtd should be required to register the spi flash device to
      MTD layer but the sf_mtd_info ops were not required until and unless if we
      use any flash filesystem layer say for example UBI. Due to this the foot-print
      got increased ~290bytes in non-UBI case here that should be acceptible.
      Signed-off-by: default avatarDaniel Schwierzeck <daniel.schwierzeck@gmail.com>
      Signed-off-by: default avatarHeiko Schocher <hs@denx.de>
      Tested-by: default avatarJagannadh Teki <jteki@openedev.com>
      Reviewed-by: default avatarJagannadh Teki <jteki@openedev.com>
      9fe6d871
  4. 26 Jun, 2015 1 commit
  5. 19 Jun, 2015 1 commit
  6. 08 Jun, 2015 1 commit
  7. 21 May, 2015 1 commit
  8. 19 May, 2015 3 commits
    • Joe Hershberger's avatar
      net: Remove all references to CONFIG_ETHADDR and friends · 92ac5208
      Joe Hershberger authored
      We really don't want boards defining fixed MAC addresses in their config
      so we just remove the option to set it in a fixed way. If you must have
      a MAC address that was not provisioned, then use the random MAC address
      functionality.
      Signed-off-by: default avatarJoe Hershberger <joe.hershberger@ni.com>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      92ac5208
    • Joe Hershberger's avatar
      net: Implement random ethaddr fallback in eth.c · bef1014b
      Joe Hershberger authored
      Implement the random ethaddr fallback in eth.c so it is in a common
      place and not reimplemented in each board or driver that wants this
      behavior.
      Signed-off-by: default avatarJoe Hershberger <joe.hershberger@ni.com>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      bef1014b
    • Hans de Goede's avatar
      console: Fix pre-console flushing via cfb_console being very slow · a8552c7c
      Hans de Goede authored
      On my A10 OlinuxIno Lime I noticed a huge (5+ seconds) delay coming from
      console_init_r. This turns out to be caused by the preconsole buffer flushing
      to the cfb_console. The Lime only has a 16 bit memory bus and that is already
      heavy used to scan out the 1920x1080 framebuffer.
      
      The problem is that print_pre_console_buffer() was printing the buffer once
      character at a time and the cfb_console code then ends up doing a cache-flush
      for touched display lines for each character.
      
      This commit fixes this by first building a 0 terminated buffer and then
      printing it in one puts() call, avoiding unnecessary cache flushes.
      
      This changes the time for the flush from 5+ seconds to not noticable.
      
      The downside of this approach is that the pre-console buffer needs to fit
      on the stack, this is not that much to ask since we are talking about plain
      text here. This commit also adjusts the sunxi CONFIG_PRE_CON_BUF_SZ to
      actually fit on the stack. Sunxi currently is the only user of the pre-console
      code so no other boards need to be adjusted.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      a8552c7c
  9. 08 May, 2015 1 commit
  10. 30 Apr, 2015 1 commit
  11. 23 Apr, 2015 4 commits
  12. 18 Apr, 2015 3 commits
  13. 10 Apr, 2015 1 commit
  14. 31 Mar, 2015 1 commit
  15. 28 Mar, 2015 1 commit
  16. 13 Mar, 2015 5 commits
  17. 06 Mar, 2015 1 commit
  18. 04 Mar, 2015 2 commits
    • Simon Glass's avatar
      arm: spl: Allow board_init_r() to run with a larger stack · db910353
      Simon Glass authored
      At present SPL uses a single stack, either CONFIG_SPL_STACK or
      CONFIG_SYS_INIT_SP_ADDR. Since some SPL features (such as MMC and
      environment) require a lot of stack, some boards set CONFIG_SPL_STACK to
      point into SDRAM. They then set up SDRAM very early, before board_init_f(),
      so that the larger stack can be used.
      
      This is an abuse of lowlevel_init(). That function should only be used for
      essential start-up code which cannot be delayed. An example of a valid use is
      when only part of the SPL code is visible/executable, and the SoC must be set
      up so that board_init_f() can be reached. It should not be used for SDRAM
      init, console init, etc.
      
      Add a CONFIG_SPL_STACK_R option, which allows the stack to be moved to a new
      address before board_init_r() is called in SPL.
      
      The expected SPL flow (for CONFIG_SPL_FRAMEWORK) is documented in the README.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      For version 1:
      Acked-by: default avatarAlbert ARIBAUD <albert.u.boot@aribaud.net>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      Tested-by: default avatarBo Shen <voice.shen@atmel.com>
      Acked-by: default avatarBo Shen <voice.shen@atmel.com>
      Acked-by: default avatarHeiko Schocher <hs@denx.de>
      Tested-by: default avatarHeiko Schocher <hs@denx.de>
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      db910353
    • Stephen Warren's avatar
      ARM: tegra: support running in non-secure mode · 73c38934
      Stephen Warren authored
      When the CPU is in non-secure (NS) mode (when running U-Boot under a
      secure monitor), certain actions cannot be taken, since they would need
      to write to secure-only registers. One example is configuring the ARM
      architectural timer's CNTFRQ register.
      
      We could support this in one of two ways:
      1) Compile twice, once for secure mode (in which case anything goes) and
         once for non-secure mode (in which case certain actions are disabled).
         This complicates things, since everyone needs to keep track of
         different U-Boot binaries for different situations.
      2) Detect NS mode at run-time, and optionally skip any impossible actions.
         This has the advantage of a single U-Boot binary working in all cases.
      
      (2) is not possible on ARM in general, since there's no architectural way
      to detect secure-vs-non-secure. However, there is a Tegra-specific way to
      detect this.
      
      This patches uses that feature to detect secure vs. NS mode on Tegra, and
      uses that to:
      
      * Skip the ARM arch timer initialization.
      
      * Set/clear an environment variable so that boot scripts can take
        different action depending on which mode the CPU is in. This might be
        something like:
        if CPU is secure:
          load secure monitor code into RAM.
          boot secure monitor.
          secure monitor will restart (a new copy of) U-Boot in NS mode.
        else:
          execute normal boot process
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarTom Warren <twarren@nvidia.com>
      73c38934
  19. 25 Feb, 2015 1 commit
  20. 24 Feb, 2015 1 commit
  21. 17 Feb, 2015 1 commit
  22. 07 Feb, 2015 1 commit
  23. 30 Jan, 2015 1 commit
  24. 29 Jan, 2015 1 commit
  25. 16 Jan, 2015 1 commit