Skip to content

U
U-Boot.Mirror

OS / U-Boot.Mirror

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

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

切换分支/标签
  1. 21 8月, 2013 1 次提交
    • Y
      powerpc: mpc85xx: Support booting from SD Card with SPL · bb0dc108
      由 Ying Zhang 提交于 
      The code from the internal on-chip ROM. It loads the final uboot image
into DDR, then jump to it to begin execution.

The SPL's size is sizeable, the maximum size must not exceed the size of L2
SRAM. It initializes the DDR through SPD code, and copys final uboot image
to DDR. So there are two stage uboot images:
	* spl_boot, 96KB size. The env variables are copied to L2 SRAM, so that
	ddr spd code can get the interleaving mode setting in env. It loads
	final uboot image from offset 96KB.
	* final uboot image, size is variable depends on the functions enabled.
Signed-off-by: NYing Zhang <b40530@freescale.com>
Acked-by: NYork Sun <yorksun@freescale.com>
      bb0dc108
  3. 17 8月, 2013 1 次提交
    • S
      RFC: bootm: Add silent_linux environment variable · 8d51aacd
      由 Simon Glass 提交于 
      At present the console for linux is silent if the U-Boot console is silent,
unless CONFIG_SILENT_U_BOOT_ONLY is set. I wonder if a better way would be
to have an environment variable to control this? Then we can control the
verbosity from scripts, and set the variable to 'no' for those boards that
want Linux to boot with console output.
Signed-off-by: NSimon Glass <sjg@chromium.org>
      8d51aacd
  5. 10 8月, 2013 2 次提交
  7. 27 7月, 2013 1 次提交
  9. 24 7月, 2013 1 次提交
    • W
      Licenses: introduce SPDX Unique Lincense Identifiers · eca3aeb3
      由 Wolfgang Denk 提交于 
      Like many other projects, U-Boot has a tradition of including big
blocks of License headers in all files.  This not only blows up the
source code with mostly redundant information, but also makes it very
difficult to generate License Clearing Reports.  An additional problem
is that even the same lincenses are referred to by a number of
slightly varying text blocks (full, abbreviated, different
indentation, line wrapping and/or white space, with obsolete address
information, ...) which makes automatic processing a nightmare.

To make this easier, such license headers in the source files will be
replaced with a single line reference to Unique Lincense Identifiers
as defined by the Linux Foundation's SPDX project [1].  For example,
in a source file the full "GPL v2.0 or later" header text will be
replaced by a single line:

        SPDX-License-Identifier:        GPL-2.0+

We use the SPDX Unique Lincense Identifiers here; these are available
at [2].

Note: From the legal point of view, this patch is supposed to be only
a change to the textual representation of the license information,
but in no way any change to the actual license terms. With this patch
applied, all files will still be licensed under the same terms they
were before.

Note 2: The apparent difference between the old "COPYING" and the new
"Licenses/gpl-2.0.txt" only results from switching to the upstream
version of the license which is differently formatted; there are not
any actual changes to the content.

Note 3: There are some recurring questions about linense issues, such
as:
    - Is a "All Rights Reserved" clause a problem in GPL code?
    - Are files without any license header a problem?
    - Do we need license headers at all?

The following excerpt from an e-mail by Daniel B. Ravicher should help
with these:

| Message-ID: <4ADF8CAA.5030808@softwarefreedom.org>
| Date: Wed, 21 Oct 2009 18:35:22 -0400
| From: "Daniel B. Ravicher" <ravicher@softwarefreedom.org>
| To: Wolfgang Denk <wd@denx.de>
| Subject: Re: GPL and license cleanup questions
|
| Mr. Denk,
|
| Wolfgang Denk wrote:
| > - There are a number of files which do not include any specific
| > license information at all. Is it correct to assume that these files
| > are automatically covered by the "GPL v2 or later" clause as
| > specified by the COPYING file in the top level directory of the
| > U-Boot source tree?
|
| That is a very fact specific analysis and could be different across the
| various files.  However, if the contributor could reasonably be expected
| to have known that the project was licensed GPLv2 or later at the time
| she made her contribution, then a reasonably implication is that she
| consented to her contributions being distributed under those terms.
|
| > - Do such files need any clean up, for example should we add GPL
| > headers to them, or is this not needed?
|
| If the project as a whole is licensed under clear terms, you need not
| identify those same terms in each file, although there is no harm in
| doing so.
|
| > - There are other files, which include both a GPL license header
| > _plus_ some copyright note with an "All Rights Reserved" clause. It
| > has been my understanding that this is a conflict, and me must ask
| > the copyright holders to remove such "All Rights Reserved" clauses.
| > But then, some people claim that "All Rights Reserved" is a no-op
| > nowadays. License checking tools (like OSLC) seem to indicate this is
| > a problem, but then we see quite a lot of "All rights reserved" in
| > BSD-licensed files in gcc and glibc. So what is the correct way to
| > deal with such files?
|
| It is not a conflict to grant a license and also reserve all rights, as
| implicit in that language is that you are reserving all "other" rights
| not granted in the license.  Thus, a file with "Licensed under GPL, All
| Rights Reserved" would mean that it is licensed under the GPL, but no
| other rights are given to copy, modify or redistribute it.
|
| Warm regards,
| --Dan
|
| Daniel B. Ravicher, Legal Director
| Software Freedom Law Center (SFLC) and Moglen Ravicher LLC
| 1995 Broadway, 17th Fl., New York, NY 10023
| (212) 461-1902 direct  (212) 580-0800 main  (212) 580-0898 fax
| ravicher@softwarefreedom.org   www.softwarefreedom.org

[1] http://spdx.org/
[2] http://spdx.org/licenses/Signed-off-by: NWolfgang Denk <wd@denx.de>
      eca3aeb3
  11. 23 7月, 2013 6 次提交
  13. 17 7月, 2013 2 次提交
  15. 02 7月, 2013 1 次提交
  17. 01 7月, 2013 1 次提交
    • H
      dfu: make data buffer size configurable · e7e75c70
      由 Heiko Schocher 提交于 
      Dfu transfer uses a buffer before writing data to the
raw storage device. Make the size (in bytes) of this buffer
configurable through environment variable "dfu_bufsiz".
Defaut value is configurable through CONFIG_SYS_DFU_DATA_BUF_SIZE
Signed-off-by: NHeiko Schocher <hs@denx.de>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
Cc: Tom Rini <trini@ti.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Acked-by: NTom Rini <trini@ti.com>
      e7e75c70
  19. 26 6月, 2013 4 次提交
  21. 24 6月, 2013 1 次提交
  23. 21 6月, 2013 5 次提交
  25. 14 6月, 2013 2 次提交
  27. 13 6月, 2013 1 次提交
  29. 08 6月, 2013 3 次提交
    • G
      pci: introduce CONFIG_PCI_INDIRECT_BRIDGE option · 842033e6
      由 Gabor Juhos 提交于 
      The pci_indirect.c file is always compiled when
CONFIG_PCI is defined although the indirect PCI
bridge support is not needed by every board.

Introduce a new CONFIG_PCI_INDIRECT_BRIDGE
config option and only compile indirect PCI
bridge support if this options is enabled.

Also add the new option into the configuration
files of the boards which needs that.

Compile tested for powerpc, x86, arm and nds32.
MAKEALL results:

powerpc:
  --------------------- SUMMARY ----------------------------
  Boards compiled: 641
  Boards with warnings but no errors: 2 ( ELPPC MPC8323ERDB )
  ----------------------------------------------------------
  Note: the warnings for ELPPC and MPC8323ERDB are present even
  without the actual patch.

x86:
  --------------------- SUMMARY ----------------------------
  Boards compiled: 1
  ----------------------------------------------------------

arm:
  --------------------- SUMMARY ----------------------------
  Boards compiled: 311
  ----------------------------------------------------------

nds32:
  --------------------- SUMMARY ----------------------------
  Boards compiled: 3
  ----------------------------------------------------------

Cc: Tom Rini <trini@ti.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com>
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
      842033e6
    • P
      spl_mmc: add Falcon mode support for raw variant · 2b75b0ad
      由 Peter Korsgaard 提交于 
      If Falcon mode support is enabled (and the system isn't directed into
booting u-boot), it will instead try to load kernel from sector
CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR and
CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS of kernel argument parameters
starting from sector CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR.
Signed-off-by: NPeter Korsgaard <peter.korsgaard@barco.com>
      2b75b0ad
    • P
      spl_mmc: add Falcon mode support for FAT variant · 7ad2cc79
      由 Peter Korsgaard 提交于 
      If Falcon mode support is enabled (and the system isn't directed into
booting u-boot), it will instead try to load kernel from
CONFIG_SPL_FAT_LOAD_KERNEL_NAME file and kernel argument parameters from
CONFIG_SPL_FAT_LOAD_ARGS_NAME, both from the same partition as u-boot.
Signed-off-by: NPeter Korsgaard <peter.korsgaard@barco.com>
      7ad2cc79
  31. 03 6月, 2013 2 次提交
  33. 16 5月, 2013 1 次提交
  35. 15 5月, 2013 2 次提交
  37. 13 5月, 2013 1 次提交
  39. 10 5月, 2013 1 次提交
    • L
      ARM: OMAP5: Fix warm reset with USB cable connected · 0b1b60c7
      由 Lokesh Vutla 提交于 
      Warm reset on OMAP5 freezes when USB cable is connected.
Fix requires PRM_RSTTIME.RSTTIME1 to be programmed
with the time for which reset should be held low for the
voltages and the oscillator to reach stable state.

There are 3 parameters to be considered for calculating
the time, which are mostly board and PMIC dependent.
-1- Time taken by the Oscillator to shut + restart
-2- PMIC OTP times
-3- Voltage rail ramp times, which inturn depends on the
PMIC slew rate and value of the voltage ramp needed.

In order to keep the code in u-boot simple, have a way
for boards to specify a pre computed time directly using
the 'CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC'
option. If boards fail to specify the time, use a default
as specified by 'CONFIG_DEFAULT_OMAP_RESET_TIME_MAX_USEC' instead.
Using the default value translates into some ~22ms and should work in
all cases.
However in order to avoid this large delay hiding other bugs,
its recommended that all boards look at their respective data
sheets and specify a pre computed and optimal value using
'CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC'

In order to help future board additions to compute this
config option value, add a README at doc/README.omap-reset-time
which explains how to compute the value. Also update the toplevel
README with the additional option and pointers to
doc/README.omap-reset-time.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
[rnayak@ti.com: Updated changelog and added the README]
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      0b1b60c7
  41. 02 5月, 2013 1 次提交
    • W
      Add SLRE - Super Light Regular Expression library · a5ecbe62
      由 Wolfgang Denk 提交于 
      Downloaded from http://slre.sourceforge.net/
and adapted for U-Boot environment.

Used to implement regex operations on environment variables.
Code size is ~ 3.5 KiB on PPC.

To enable this code, define the  CONFIG_REGEX  option in your board
config file.

Note:  There are more recent versions of the SLRE library available at
http://slre.googlecode.com ; unfortunately, the new code has a heavily
reorked API which makes it less usable for our purposes:
- the return code is strings, which are more difficult to process
- we don't get any information any more which sub-string of the data
  was matched by the given regex
- it is much more cumbersome to work with arbitrary expressions, where
  for example the number of substrings for capturing are not known at
  compile time
Also, there does not seem to be any real changes or improvements of
the functionality.

Because of this, we deliberately stick with the older code.

Note 2: the test code (built when SLRE_TEST is defined) was modified
to allow for more extensive testing; now we can test the regexp
matching on all lines on a text file (instead of the whole data in the
file as a single block).
Signed-off-by: NWolfgang Denk <wd@denx.de>
      a5ecbe62