This patch add support for gpimage format as a preparatory
patch for porting u-boot for keystone2 devices and is
based on omapimage format. It re-uses gph header to store the
size and loadaddr as done in omapimage.c
Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Acked-by: Tom Rini <trini@ti.com>
Otherwise, when booting VxWorks kernel, the incorrect message will
be seen:
ARM Unknown OS Kernel Image (uncompressed)
Signed-off-by: Miao Yan <miao.yan@windriver.com>
Relocation code based on a patch by Scott Wood, which is:
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: David Feng <fenghua@phytium.com.cn>
Becuase fdt_check_header function takes (const void *)
type argument, the argument should be passed to it
without being casted to (char *).
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Fix various misspellings of things like "environment", "kernel",
"default" and "volatile", and throw in a couple grammar fixes.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Add mkimage support for generating and verifying MXS bootstream.
The implementation here is mostly a glue code between MXSSB v0.4
and mkimage, but the long-term goal is to rectify this and merge
MXSSB with mkimage more tightly. Once this code is properly in
U-Boot, MXSSB shall be deprecated in favor of mkimage-mxsimage
support.
Note that the mxsimage generator needs libcrypto from OpenSSL, I
therefore enabled the libcrypto/libssl unconditionally.
MXSSB: http://git.denx.de/?p=mxssb.git;a=summary
The code is based on research presented at:
http://www.rockbox.org/wiki/SbFileFormat
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Otavio Salvador <otavio@ossystems.com.br>
A FIT image with a ramdisk that sets the entry or load points to 0x0
must be treated as meaning "leave in place" and NOT "relocate to 0x0".
This regression was introduced in a51ec63.
Signed-off-by: Stefano Babic <sbabic@denx.de>
If a specific configuraion is selected by the bootm command, e.g. with
'bootm 84000000#recoveryconf' we must honour this for not just the kernel,
but also the ramdisk and FDT.
In the conversion to using a common fit_image_load() function for loading
images from FITs (commits a51ec63 and 53f375f) this feature was lost.
Reinstate it by passing the selected configuration back from
fit_image_load() to boot_get_kernel(), then use this configuration
(which is stored in images->fit_uname_cfg) in both boot_get_ramdisk()
and boot_get_fdt().
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the arguments to bootm are processed in a somewhat confusing
way. Sub-functions must know how many arguments their calling functions
have processed, and the OS boot function must also have this information.
Also it isn't obvious that 'bootm' and 'bootm start' provide arguments in
the same way.
Adjust the code so that arguments are removed from the list before calling
a sub-function. This means that all functions can know that argv[0] is the
first argument of which they need to take notice.
Signed-off-by: Simon Glass <sjg@chromium.org>
This seems to be a common function for several architectures, so create
a common function rather than duplicating the code in each arch.
Also make an attempt to avoid introducing #ifdefs in the new code, partly
by removing useless #ifdefs around function declarations in the image.h
header.
Signed-off-by: Simon Glass <sjg@chromium.org>
The image file is still very large, and some of the code is only used when
libfdt is in use. Move this code into a new file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Much of the image code uses addresses as ulongs and pointers interchangeably,
casting between the two forms as needed.
This doesn't work with sandbox, which has a U-Boot RAM buffer which is
separate from the host machine's memory.
Adjust the cost so that translating from a U-Boot address to a pointer uses
map_sysmem(). This allows bootm to work correctly on sandbox.
Note that there are no exhaustive tests for this code on sandbox, so it is
possible that some dark corners remain.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de> (v1)
This is the main entry point to the FIT image verification code. We will
be using it to handle image verification with signatures, so rename the
function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
The FIT code is about half the size of the >3000-line image.c. Split this
code into its own file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
One we split out the FIT code from image.c we will need this function.
Export it in the header.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Rather than repeat the line
#if defined(CONFIG_TIMESTAMP) || defined(CONFIG_CMD_DATE) || \
defined(USE_HOSTCC)
everywhere, put this in a header file and #define IMAGE_ENABLE_TIMESTAMP
to either 1 or 0. Then we can use a plain if() in most code and avoid
the #ifdefs.
The compiler's dead code elimination ensures that the result is the same.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Marek Vasut <marex@denx.de>
and, if including libfdt.h which includes libfdt_env.h in
the correct order, don't include fdt.h before libfdt.h.
this is needed to get the fdt type definitions set from
the project environment before fdt.h uses them.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Cc: Jerry Van Baren <gvb.uboot@gmail.com>
Move the getenv_yesno() to env_common.c and change most checks for
'y' or 'n' to use this helper.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
When booting a fit image with multiple configurations, the user either has to
specify which configuration to use explicitly, or there has to be a default
defined which is chosen automatically. This change adds an option to change
that behavior so that a configuration can be selected explicitly, or the
configuration which has the device tree that claims to be compatible with the
earliest item in U-Boot's device tree.
In other words, if U-Boot claimed to be compatible with A, B, and then C, and
the configurations claimed to be compatible with A, D and B, D and D, E, the
first configuration, A, D, would be chosen. Both the first and second
configurations match, but the first one matches a more specific entry in
U-Boot's device tree. The order in the kernel's device tree is ignored.
Signed-off-by: Gabe Black <gabeblack@google.com>
Commit-Ready: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
command.c:44:38: error: bad constant expression
dlmalloc.c:1468:2: warning: Using plain integer as NULL pointer
dlmalloc.c:1468:5: warning: Using plain integer as NULL pointer
dlmalloc.c:2176:12: warning: Using plain integer as NULL pointer
dlmalloc.c:2179:31: warning: Using plain integer as NULL pointer
dlmalloc.c:2382:14: warning: Using plain integer as NULL pointer
dlmalloc.c:2436:14: warning: Using plain integer as NULL pointer
dlmalloc.c:2582:31: warning: Using plain integer as NULL pointer
dlmalloc.c:2585:17: warning: Using plain integer as NULL pointer
dlmalloc.c:2646:14: warning: Using plain integer as NULL pointer
dlmalloc.c:2659:19: warning: Using plain integer as NULL pointer
dlmalloc.c:2692:19: warning: Using plain integer as NULL pointer
dlmalloc.c:2707:19: warning: Using plain integer as NULL pointer
dlmalloc.c:2708:14: warning: Using plain integer as NULL pointer
dlmalloc.c:2786:31: warning: Using plain integer as NULL pointer
dlmalloc.c:2801:12: warning: Using plain integer as NULL pointer
dlmalloc.c:2801:22: warning: Using plain integer as NULL pointer
dlmalloc.c:2926:27: warning: Using plain integer as NULL pointer
dlmalloc.c:2928:14: warning: Using plain integer as NULL pointer
dlmalloc.c:2929:12: warning: Using plain integer as NULL pointer
dlmalloc.c:3075:14: warning: Using plain integer as NULL pointer
hush.c:292:14: warning: symbol 'last_return_code' was not declared. Should it be static?
hush.c:293:5: warning: symbol 'nesting_level' was not declared. Should it be static?
hush.c:2175:20: warning: Using plain integer as NULL pointer
hush.c:2175:34: warning: Using plain integer as NULL pointer
hush.c:2210:41: warning: Using plain integer as NULL pointer
hush.c:2216:45: warning: Using plain integer as NULL pointer
hush.c:2249:25: warning: Using plain integer as NULL pointer
hush.c:2332:13: warning: symbol 'new_pipe' was not declared. Should it be static?
hush.c:2390:5: warning: symbol 'reserved_word' was not declared. Should it be static?
hush.c:2927:5: warning: symbol 'parse_stream' was not declared. Should it be static?
hush.c:3127:6: warning: symbol 'mapset' was not declared. Should it be static?
hush.c:3133:6: warning: symbol 'update_ifs_map' was not declared. Should it be static?
hush.c:3161:5: warning: symbol 'parse_stream_outer' was not declared. Should it be static?
hush.c:3295:34: warning: Using plain integer as NULL pointer
hush.c:3631:5: warning: symbol 'do_showvar' was not declared. Should it be static
image.c:1282:29: warning: Using plain integer as NULL pointer
image.c:1315:41: warning: Using plain integer as NULL pointer
image.c:1330:25: warning: Using plain integer as NULL pointer
image.c:1706:25: warning: Using plain integer as NULL pointer
main.c:510:10: warning: symbol 'hist_num' was not declared. Should it be static?
main.c:512:5: warning: symbol 'hist_list' was not declared. Should it be static?
main.c:513:6: warning: symbol 'hist_lines' was not declared. Should it be static?
usb_storage.c:195:6: warning: symbol 'usb_show_progress' was not declared. Should it be static?
usb_storage.c:440:48: warning: Using plain integer as NULL pointer
usb_storage.c:503:5: warning: symbol 'usb_stor_BBB_comdat' was not declared. Should it be static?
usb_storage.c:551:5: warning: symbol 'usb_stor_CB_comdat' was not declared. Should it be static?
usb_storage.c:629:55: warning: Using plain integer as NULL pointer
usb_storage.c:620:5: warning: symbol 'usb_stor_CBI_get_status' was not declared. Should it be static?
usb_storage.c:675:43: warning: Using plain integer as NULL pointer
usb_storage.c:668:5: warning: symbol 'usb_stor_BBB_clear_endpt_stall' was not declared. Should it be static?
usb_storage.c:679:5: warning: symbol 'usb_stor_BBB_transport' was not declared. Should it be static?
usb_storage.c:801:5: warning: symbol 'usb_stor_CB_transport' was not declared. Sh
xyzModem.c:104:1: warning: symbol 'CYGACC_COMM_IF_GETC_TIMEOUT' was not declared. Should it be static?
xyzModem.c:122:1: warning: symbol 'CYGACC_COMM_IF_PUTC' was not declared. Should it be static?
xyzModem.c:169:1: warning: symbol 'parse_num' was not declared. Should it be stat
note: hush.c's nesting_level deleted because not used.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Allow the itb file to declare to u-boot that its hash should not be
checked automatically on bootm or iminfo. This allows an image to
either be checked automatically or to include a script which may
check it otherwise (such as after part of the itb has been relocated
to RAM by the script).
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Before this patch, error codes returned from fdtlib were ignored and
continued access would cause a crash. Now just check if the image is
truncated and error if so.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
This patch adds support to include Load, Entry address and OS tag
of ramdisk on to FIT image through mkimage tool.
Signed-off-by: Jagannadha Sutradharudu Teki <402jagan@gmail.com>
Provides a tool to build boot Image for PBL(Pre boot loader) which is
used on Freescale CoreNet SoCs, PBL can be used to load some instructions
and/or data for pre-initialization. The default output image is u-boot.pbl,
for more details please refer to doc/README.pblimage.
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
image.c: In function ‘boot_get_ramdisk’:
image.c:800:8: warning: unused variable ‘end’ [-Wunused-variable]
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
This patch allows loading RAW ramdisk via bootz command. The raw ramdisk is
loaded only in case it's size is specified:
bootz <kernel addr> <ramdisk addr>:<ramdisk size> <fdt addr>
For example:
bootz 0x42000000 0x43000000:0x12345 0x44000000
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Tom Warren <TWarren@nvidia.com>
Cc: albert.u.boot@aribaud.net
Cc: afleming@gmail.com
Cc: Simon Glass <sjg@chromium.org>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Nicolas Pitre <nico@fluxnic.net>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Detlev Zundel <dzu@denx.de>
These calls should not be made directly any more, since bootstage
will call the show_boot_...() functions as needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Rather than the caller negating our progress numbers to indicate an
error has occurred, which seems hacky, add a function to indicate this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Mike Frysinger <vapier@gentoo.org>
boot_get_fdt() expects a uImage-wrapped FDT to be loaded to a staging
location, and then memmove()s it to the load address specified in the
header. This change enhances boot_get_fdt() to detect when the image has
already been loaded to the correct address, and skip this memmove(). The
detection algorithm was written to match the equivalent for the kernel;
see bootm_load_os()'s IH_COMP_NONE case.
v2: New patch
Signed-off-by: Stephen Warren <swarren@nvidia.com>
The commit message of a28afca (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: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Simon Glass <sjg@chromium.org>
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: Kumar Gala <galak@kernel.crashing.org>
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: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Stefan Roese <sr@denx.de>
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: Stefano Babic <sbabic@denx.de>
CC: Wolfgang Denk <wd@denx.de>
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: Stephen Warren <swarren@nvidia.com>
Tested-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
