Skip to content

U
U-Boot.Mirror

OS / U-Boot.Mirror

通知 1
Star 0
Fork 0
U
U-Boot.Mirror

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 21 7月, 2015 1 次提交
  3. 02 7月, 2015 3 次提交
  5. 01 7月, 2015 1 次提交
  7. 30 6月, 2015 1 次提交
    • D
      mtd, spi: Add MTD layer driver · 9fe6d871
      由 Daniel Schwierzeck 提交于 
      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: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>
Signed-off-by: NHeiko Schocher <hs@denx.de>
Tested-by: NJagannadh Teki <jteki@openedev.com>
Reviewed-by: NJagannadh Teki <jteki@openedev.com>
      9fe6d871
  9. 26 6月, 2015 1 次提交
  11. 20 6月, 2015 1 次提交
  13. 08 6月, 2015 1 次提交
  15. 21 5月, 2015 1 次提交
  17. 20 5月, 2015 3 次提交
    • J
      net: Remove all references to CONFIG_ETHADDR and friends · 92ac5208
      由 Joe Hershberger 提交于 
      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: NJoe Hershberger <joe.hershberger@ni.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
      92ac5208
    • J
      net: Implement random ethaddr fallback in eth.c · bef1014b
      由 Joe Hershberger 提交于 
      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: NJoe Hershberger <joe.hershberger@ni.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
      bef1014b
    • H
      console: Fix pre-console flushing via cfb_console being very slow · a8552c7c
      由 Hans de Goede 提交于 
      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: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
      a8552c7c
  19. 09 5月, 2015 1 次提交
  21. 30 4月, 2015 1 次提交
  23. 23 4月, 2015 4 次提交
  25. 19 4月, 2015 2 次提交
  27. 18 4月, 2015 1 次提交
  29. 10 4月, 2015 1 次提交
  31. 31 3月, 2015 1 次提交
  33. 28 3月, 2015 1 次提交
  35. 13 3月, 2015 5 次提交
  37. 06 3月, 2015 1 次提交
  39. 05 3月, 2015 2 次提交
    • S
      arm: spl: Allow board_init_r() to run with a larger stack · db910353
      由 Simon Glass 提交于 
      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: NSimon Glass <sjg@chromium.org>
For version 1:
Acked-by: NAlbert ARIBAUD <albert.u.boot@aribaud.net>
Reviewed-by: NStefan Roese <sr@denx.de>
Tested-by: NBo Shen <voice.shen@atmel.com>
Acked-by: NBo Shen <voice.shen@atmel.com>
Acked-by: NHeiko Schocher <hs@denx.de>
Tested-by: NHeiko Schocher <hs@denx.de>
Signed-off-by: NTom Rini <trini@konsulko.com>
      db910353
    • S
      ARM: tegra: support running in non-secure mode · 73c38934
      由 Stephen Warren 提交于 
      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: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NTom Warren <twarren@nvidia.com>
      73c38934
  41. 26 2月, 2015 1 次提交
  43. 25 2月, 2015 1 次提交
  45. 17 2月, 2015 1 次提交
  47. 08 2月, 2015 1 次提交
  49. 30 1月, 2015 2 次提交
  51. 16 1月, 2015 1 次提交