Skip to content

U
U-Boot.Mirror

OS / U-Boot.Mirror

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

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

切换分支/标签
  1. 08 6月, 2015 1 次提交
  3. 21 5月, 2015 1 次提交
  5. 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
  7. 09 5月, 2015 1 次提交
  9. 30 4月, 2015 1 次提交
  11. 23 4月, 2015 4 次提交
  13. 19 4月, 2015 2 次提交
  15. 18 4月, 2015 1 次提交
  17. 10 4月, 2015 1 次提交
  19. 31 3月, 2015 1 次提交
  21. 28 3月, 2015 1 次提交
  23. 13 3月, 2015 5 次提交
  25. 06 3月, 2015 1 次提交
  27. 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
  29. 26 2月, 2015 1 次提交
  31. 25 2月, 2015 1 次提交
  33. 17 2月, 2015 1 次提交
  35. 08 2月, 2015 1 次提交
  37. 30 1月, 2015 2 次提交
  39. 16 1月, 2015 1 次提交
  41. 06 1月, 2015 2 次提交
  43. 19 12月, 2014 2 次提交
    • T
      ARM: Implement non-cached memory support · 1dfdd9ba
      由 Thierry Reding 提交于 
      Implement an API that can be used by drivers to allocate memory from a
pool that is mapped uncached. This is useful if drivers would otherwise
need to do extensive cache maintenance (or explicitly maintaining the
cache isn't safe).

The API is protected using the new CONFIG_SYS_NONCACHED_MEMORY setting.
Boards can set this to the size to be used for the non-cached area. The
area will typically be right below the malloc() area, but architectures
should take care of aligning the beginning and end of the area to honor
any mapping restrictions. Architectures must also ensure that mappings
established for this area do not overlap with the malloc() area (which
should remain cached for improved performance).

While the API is currently only implemented for ARM v7, it should be
generic enough to allow other architectures to implement it as well.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NTom Warren <twarren@nvidia.com>
      1dfdd9ba
    • T
      ARM: Implement non-cached memory support · ed710457
      由 Thierry Reding 提交于 
      Implement an API that can be used by drivers to allocate memory from a
pool that is mapped uncached. This is useful if drivers would otherwise
need to do extensive cache maintenance (or explicitly maintaining the
cache isn't safe).

The API is protected using the new CONFIG_SYS_NONCACHED_MEMORY setting.
Boards can set this to the size to be used for the non-cached area. The
area will typically be right below the malloc() area, but architectures
should take care of aligning the beginning and end of the area to honor
any mapping restrictions. Architectures must also ensure that mappings
established for this area do not overlap with the malloc() area (which
should remain cached for improved performance).

While the API is currently only implemented for ARM v7, it should be
generic enough to allow other architectures to implement it as well.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>
      ed710457
  45. 18 12月, 2014 1 次提交
  47. 08 12月, 2014 1 次提交
  49. 06 12月, 2014 1 次提交
  51. 05 12月, 2014 1 次提交