Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • early-display
  • variant-emmc-nvme-boot
  • 2023-01-25
  • v3
  • variant-emmc-nvme-boot
  • 2020-06-01
7 results
Search by author
  • Any Author
  • Jack Humbert Jack Humbert jackhumbert
1 author
  1. Feb 27, 2012
    • Shawn Guo's avatar
      common/image.c: align usage of fdt_high with initrd_high · fa34f6b2
      Shawn Guo authored 
      
The commit message of a28afca5 (Add uboot "fdt_high" enviroment variable)
states that fdt_high behaves similarly to the existing initrd_high.
But fdt_high actually has an outstanding difference from initrd_high.
The former specifies the start address, while the later specifies the
end address.

As fdt_high and initrd_high will likely be used together, it'd be nice
to have them behave same.  The patch changes the behavior of fdt_high
to have it aligned with initrd_high.

The document of fdt_high in README is updated with an example to
demonstrate the usage of this environment variable.

Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
Acked-by: default avatarSimon Glass <sjg@chromium.org>
      fa34f6b2
  3. Jan 13, 2012
  5. Dec 12, 2011
    • Kumar Gala's avatar
      powerpc/bootm: Flush ramdisk and device tree image when booting on MP · 3b200110
      Kumar Gala authored 
      
We already flush the kernel image after we've loaded it to ensure
visiblity to the other cores.  We need to do the same thing for the
ramdisk and device tree images.  In AMP boot scenarios we might not be
HW cache coherent with the secondary core that we are loading and
setting the ramdisk and device tree up for.  Thus we need to ensure
we've flushed the regions of memory utilized by ramdisk and device tree
so the loadding and any modifications (from decompression or fdt updates)
are made visible to the secondary cores.

Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      3b200110
  7. Dec 01, 2011
    • Stephen Warren's avatar
      image: Implement IH_TYPE_KERNEL_NOLOAD · b9b50e89
      Stephen Warren authored 
      
The legacy uImage format includes an absolute load and entry-point
address. When bootm operates on a kernel uImage in memory that isn't
loaded at the address in the image's load address, U-Boot will copy
the image to its address in the header.

Some kernel images can actually be loaded and used at any arbitrary
address. An example is an ARM Linux kernel zImage file. To represent
this capability, IH_TYPE_KERNEL_NOLOAD is implemented, which operates
just like IH_TYPE_KERNEL, except that the load address header is
ignored, and U-Boot does not copy the image to its load address, but
rather uses it in-place.

This is useful when sharing a single (uImage-wrapped) zImage across
multiple boards with different memory layouts; in this case, a specific
load address need not be picked when creating the uImage, but instead
is selected by the board-specific U-Boot environment used to load and
boot that image.

v2: Rename from IH_TYPE_KERNEL_ANYLOAD to IH_TYPE_KERNEL_NOLOAD.

Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
Signed-off-by: default avatarStefan Roese <sr@denx.de>
      b9b50e89
  9. Oct 23, 2011
    • Stefano Babic's avatar
      mkimage: adding support for Davinci AIS image · 4962e38e
      Stefano Babic authored 
      
Some Davinci processors supports the Application
Image Script (AIS) boot process. The patch adds the generation
of the AIS image inside the mkimage tool to make possible
to generate a bootable U-boot without external tools
(TI Davinci AIS Generator).

Signed-off-by: default avatarStefano Babic <sbabic@denx.de>
CC: Wolfgang Denk <wd@denx.de>
      4962e38e
  11. Oct 21, 2011
    • Stephen Warren's avatar
      checkpatch whitespace cleanups · 712fbcf3
      Stephen Warren authored 
      
This avoids the following checkpatch warning in later patches:

ERROR: "(foo*)" should be "(foo *)"
ERROR: space required before the open brace '{'
ERROR: space prohibited before that close parenthesis ')'
ERROR: spaces required around that '||' (ctx:WxV)
WARNING: space prohibited between function name and open parenthesis '('
WARNING: line over 80 characters

This fixes all the white-space warnings/errors in my subsequent patch,
and within this current patch. A number of other checkpatch warnings
and errors are still present in this patch itself, but are beyond simple
whitespace fixes, so are not solved by this patch.

v2: New patch

Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
Tested-by: default avatarSimon Glass <sjg@chromium.org>
Tested-by: default avatarSimon Glass <sjg@chromium.org>
      712fbcf3
    • Macpaul Lin's avatar
      nds32: common bdinfo, bootm, image support · 64d61461
      Macpaul Lin authored 
      
Add support of NDS32 to common commands bdinfo, bootm, and image format.

Signed-off-by: default avatarMacpaul Lin <macpaul@andestech.com>
      64d61461
  13. Oct 17, 2011
  15. Oct 09, 2011
  17. Sep 07, 2011
  19. Aug 03, 2011
  21. Jul 28, 2011
  23. Jul 19, 2011
  25. Jul 16, 2011
  27. Apr 26, 2011
  29. Nov 28, 2010
  31. Oct 29, 2010
  33. Oct 20, 2010
  35. Oct 18, 2010
    • John Rigby's avatar
      boot: change some arch ifdefs to feature ifdefs · fca43cc8
      John Rigby authored 
      
The routines boot_ramdisk_high, boot_get_cmdline and boot_get_kbd
are currently enabled by various combinations of CONFIG_M68K,
CONFIG_POWERPC and CONFIG_SPARC.

Use CONFIG_SYS_BOOT_<FEATURE> defines instead.

CONFIG_SYS_BOOT_RAMDISK_HIGH
CONFIG_SYS_BOOT_GET_CMDLINE
CONFIG_SYS_BOOT_GET_KBD

Define these as appropriate in arch/include/asm/config.h files.

Signed-off-by: default avatarJohn Rigby <john.rigby@linaro.org>
Acked-by: default avatarWolfgang Denk <wd@denx.de>
      fca43cc8
    • John Rigby's avatar
      common/image.c remove extra calls to be32_to_cpu in boot_get_fdt · d1263fce
      John Rigby authored 
      
fdt_totalsize returns size in cpu endian so don't call be32_to_cpu
on the result.  This was harmless on big endian platforms but not
on little endian ARMs.

Signed-off-by: default avatarJohn Rigby <john.rigby@linaro.org>
      d1263fce
    • John Rigby's avatar
      common/image.c fix length calculation in boot_relocate_fdt · 758b3997
      John Rigby authored 
      
boot_relocate_fdt is called on platforms with CONFIG_SYS_BOOTMAPSZ
defined to relocate the device tree blob to be inside the
boot map area between bootmap_base and bootmap_base+CONFIG_SYS_BOOTMAPSZ.

For the case where the blob needs to be relocated, space is
allocated inside the bootmap by calling lmb_alloc_base with
size passed in plus some padding:

    of_len = *of_size + CONFIG_SYS_FDT_PAD;

For the case where the blob is already inside the bounds of the boot map
area, lmb_reserve is called to reserve the the space where the blob is
already residing.  The calculation for this case is currently:

    of_len = (CONFIG_SYS_BOOTMAPSZ + bootmap_base) - (ulong)fdt_blob;

This is wrong because it reserves all the space in the boot map area
from the blob to the end ignoring completely the actual size. The
worst case is where the blob is at the beginning and the entire boot map
area get reserved. Fix this by changing the length calculation to this:

    of_len = *of_size + CONFIG_SYS_FDT_PAD;

This bug has likely never manifested itself because bootm has never
been called with the fdt blob already in the bootmap area.  In my
testing on an OMAP3 beagle board I initially worked around the bug
by simply moving the initial location of the fdt blob.  I have tested
with the new calculation with the fdt blob both inside and outside
the boot map area.

Signed-off-by: default avatarJohn Rigby <john.rigby@linaro.org>
      758b3997
  37. Sep 28, 2010
  39. Aug 08, 2010
    • Stephan Linz's avatar
      fdt relocate: have more attention to use a bootmap or not · 958e1206
      Stephan Linz authored 
      
Platforms with flat device tree support can use a bootmap to relocate
the fdt_blob. This is not a must. That's why the relocation function
boot_relocate_fdt() should be use only if CONFIG_OF_LIBFDT was defined
together with CONFIG_SYS_BOOTMAPSZ (see common/cmd_bootm.c).

On MicroBlaze platforms there is no need to use a bootmap to relocate
a fdt blob. So we need a more precise focus on the compilation and usage
of boot_relocate_fdt().

In general it is valid to exclude the function boot_relocate_fdt() if
the bootmap size CONFIG_SYS_BOOTMAPSZ is not defined.

Signed-off-by: default avatarStephan Linz <linz@li-pro.net>
      958e1206
  41. Aug 07, 2010
  43. Jul 04, 2010
    • Wolfgang Denk's avatar
      Make sure that argv[] argument pointers are not modified. · 54841ab5
      Wolfgang Denk authored 
      
The hush shell dynamically allocates (and re-allocates) memory for the
argument strings in the "char *argv[]" argument vector passed to
commands.  Any code that modifies these pointers will cause serious
corruption of the malloc data structures and crash U-Boot, so make
sure the compiler can check that no such modifications are being done
by changing the code into "char * const argv[]".

This modification is the result of debugging a strange crash caused
after adding a new command, which used the following argument
processing code which has been working perfectly fine in all Unix
systems since version 6 - but not so in U-Boot:

int main (int argc, char **argv)
{
	while (--argc > 0 && **++argv == '-') {
/* ====> */	while (*++*argv) {
			switch (**argv) {
			case 'd':
				debug++;
				break;
			...
			default:
				usage ();
			}
		}
	}
	...
}

The line marked "====>" will corrupt the malloc data structures and
usually cause U-Boot to crash when the next command gets executed by
the shell.  With the modification, the compiler will prevent this with
an
	error: increment of read-only location '*argv'

N.B.: The code above can be trivially rewritten like this:

	while (--argc > 0 && **++argv == '-') {
		char *arg = *argv;
		while (*++arg) {
			switch (*arg) {
			...

Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
Acked-by: default avatarMike Frysinger <vapier@gentoo.org>
      54841ab5
  45. May 28, 2010
  47. May 05, 2010
  49. Jan 25, 2010
  51. Dec 08, 2009
  53. Dec 05, 2009
    • Peter Korsgaard's avatar
      add lzop decompression support · 20dde48b
      Peter Korsgaard authored 
      
Add lzop decompression support to the existing lzo bitstream handling
(think gzip versus zlib), and support it for uImage decompression if
CONFIG_LZO is enabled.

Lzop doesn't compress as good as gzip (~10% worse), but decompression
is very fast (~0.7s faster here on a slow ppc). The lzop decompression
code is based on Albin Tonnerre's recent ARM Linux lzo support patch.

Cc: albin.tonnerre@free-electrons.com
Signed-off-by: default avatarPeter Korsgaard <jacmet@sunsite.dk>
      20dde48b
  55. Oct 03, 2009
  57. Sep 10, 2009