u-boot.git/common/cmd_bootm.c, branch v2015.01 Unnamed repository; edit this file 'description' to name the repository. x86: Support loading kernel setup from a FIT 2014-10-22T15:03:06+00:00 Simon Glass sjg@chromium.org 2014-10-20T03:11:24+00:00 90268b878bd830f2fc9b1e225d96009efe331cd1 Add a new setup@ section to the FIT which can be used to provide a setup binary for booting Linux on x86. This makes it possible to boot x86 from a FIT. Signed-off-by: Simon Glass <sjg@chromium.org> 
Add a new setup@ section to the FIT which can be used to provide a setup
binary for booting Linux on x86. This makes it possible to boot x86 from
a FIT.

Signed-off-by: Simon Glass <sjg@chromium.org>
cmd_bootm.c: Add 'booti' for ARM64 Linux kernel Images 2014-08-30T11:46:41+00:00 Tom Rini trini@ti.com 2014-08-14T10:42:36+00:00 d2b2ffe3107dc2b43352b391129bc84340be0b35 The default format for arm64 Linux kernels is the "Image" format, described in Documentation/arm64/booting.txt. This, along with an optional gzip compression on top is all that is generated by default. The Image format has a magic number within the header for verification, a text_offset where the Image must be run from, an image_size that includes the BSS and reserved fields. This does not support automatic detection of a gzip compressed image. Signed-off-by: Tom Rini <trini@ti.com> 
The default format for arm64 Linux kernels is the "Image" format,
described in Documentation/arm64/booting.txt.  This, along with an
optional gzip compression on top is all that is generated by default.
The Image format has a magic number within the header for verification,
a text_offset where the Image must be run from, an image_size that
includes the BSS and reserved fields.

This does not support automatic detection of a gzip compressed image.

Signed-off-by: Tom Rini <trini@ti.com>
bootm: Split out code from cmd_bootm.c 2014-06-19T15:18:58+00:00 Simon Glass sjg@chromium.org 2014-06-12T13:24:46+00:00 b639640371ed38c76602387af865b814967473ba This file has code in three different categories: - Command processing - OS-specific boot code - Locating images and setting up to boot Only the first category really belongs in a file called cmd_bootm.c. Leave the command processing code where it is. Split out the OS-specific boot code into bootm_os.c. Split out the other code into bootm.c Header files and extern declarations are tidied but otherwise no code changes are made, to make it easier to review. Signed-off-by: Simon Glass <sjg@chromium.org> 
This file has code in three different categories:
- Command processing
- OS-specific boot code
- Locating images and setting up to boot

Only the first category really belongs in a file called cmd_bootm.c.

Leave the command processing code where it is. Split out the OS-specific
boot code into bootm_os.c. Split out the other code into bootm.c

Header files and extern declarations are tidied but otherwise no code
changes are made, to make it easier to review.

Signed-off-by: Simon Glass <sjg@chromium.org>
Check run_command() return code properly 2014-06-11T20:25:47+00:00 Thomas Betker thomas.betker@freenet.de 2014-06-05T18:07:56+00:00 73671dad49bf2368959b7bf0e30ba931ea95565c run_command() returns 0 for success, 1 for failure. Fix places which assume that failure is indicated by a negative return code. Signed-off-by: Thomas Betker <thomas.betker@rohde-schwarz.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Tested-by: Stefan Roese <sr@denx.de> 
run_command() returns 0 for success, 1 for failure. Fix places which
assume that failure is indicated by a negative return code.

Signed-off-by: Thomas Betker <thomas.betker@rohde-schwarz.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>
bootm: make use of legacy image format configurable 2014-06-05T18:44:56+00:00 Heiko Schocher hs@denx.de 2014-05-28T09:33:33+00:00 21d29f7f9f4888a4858b58b368ae7cf8783a6ebf make the use of legacy image format configurable through the config define CONFIG_IMAGE_FORMAT_LEGACY. When relying on signed FIT images with required signature check the legacy image format should be disabled. Therefore introduce this new define and enable legacy image format if CONFIG_FIT_SIGNATURE is not set. If CONFIG_FIT_SIGNATURE is set disable per default the legacy image format. Signed-off-by: Heiko Schocher <hs@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Lars Steubesand <lars.steubesand@philips.com> Cc: Mike Pearce <mike@kaew.be> Cc: Wolfgang Denk <wd@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Michal Simek <monstr@monstr.eu> Acked-by: Simon Glass <sjg@chromium.org> 
make the use of legacy image format configurable through
the config define CONFIG_IMAGE_FORMAT_LEGACY.

When relying on signed FIT images with required signature check
the legacy image format should be disabled. Therefore introduce
this new define and enable legacy image format if CONFIG_FIT_SIGNATURE
is not set. If CONFIG_FIT_SIGNATURE is set disable per default
the legacy image format.

Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Lars Steubesand <lars.steubesand@philips.com>
Cc: Mike Pearce <mike@kaew.be>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Michal Simek <monstr@monstr.eu>
Acked-by: Simon Glass <sjg@chromium.org>
Remove unnecessary use of hush header file 2014-05-29T21:45:31+00:00 Simon Glass sjg@chromium.org 2014-04-11T02:01:23+00:00 ae4223f4444d7e673ff6b4a066c8584858629025 Some files include hush.h but don't actually use it. Remove this where possible. Signed-off-by: Simon Glass <sjg@chromium.org> 
Some files include hush.h but don't actually use it. Remove this where
possible.

Signed-off-by: Simon Glass <sjg@chromium.org>
Merge branch 'master' of git://git.denx.de/u-boot-usb 2014-05-22T16:56:15+00:00 Tom Rini trini@ti.com 2014-05-22T16:56:15+00:00 c9afa7cea84c9b7346fcd2710577bcc386631aba 






cmd_bootm.c: Only say XIP image when load is image_start
2014-05-12T19:20:05+00:00

Tom Rini
trini@ti.com

2014-05-01T14:01:08+00:00

717ccc1d7f77b4d1177c098749adc07205a22fa1

We say we have an XIP (in this case, image loaded at desired execution
address) when the image header has been offset in the load.  It's
possible that in some cases executing the header is non-fatal but that's
not true in many other cases.

Signed-off-by: Tom Rini <trini@ti.com>





We say we have an XIP (in this case, image loaded at desired execution
address) when the image header has been offset in the load.  It's
possible that in some cases executing the header is non-fatal but that's
not true in many other cases.

Signed-off-by: Tom Rini <trini@ti.com>







image: add support for Android's boot image format
2014-05-08T08:38:29+00:00

Sebastian Siewior
bigeasy@linutronix.de

2014-05-05T20:08:09+00:00

9ace3fc81427f6a4036718c2daff9d6f8ee7b69a

This patch adds support for the Android boot-image format. The header
file is from the Android project and got slightly alterted so the struct +
its defines are not generic but have something like a namespace. The
header file is from bootloader/legacy/include/boot/bootimg.h. The header
parsing has been written from scratch and I looked at
bootloader/legacy/usbloader/usbloader.c for some details.
The image contains the physical address (load address) of the kernel and
ramdisk. This address is considered only for the kernel image.
The "second image" defined in the image header is currently not
supported. I haven't found anything that is creating this.

v3 (Rob Herring):
This is based on http://patchwork.ozlabs.org/patch/126797/ with the
following changes:
- Rebased to current mainline
- Moved android image handling to separate functions in
  common/image-android.c
- s/u8/char/ in header to fix string function warnings
- Use SPDX identifiers for licenses
- Cleaned-up file source information:
  android_image.h is from file include/boot/bootimg.h in repository:
  https://android.googlesource.com/platform/bootable/bootloader/legacy
  The git commit hash is 4205b865141ff2e255fe1d3bd16de18e217ef06a
  usbloader.c would be from the same commit, but it does not appear
  to have been used for any actual code.
v4:
- s/andriod/android/
- Use a separate flag ep_found to track if the entry point has been set
rather than using a magic value.

Cc: Wolfgang Denk <wd@denx.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Tom Rini <trini@ti.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>





This patch adds support for the Android boot-image format. The header
file is from the Android project and got slightly alterted so the struct +
its defines are not generic but have something like a namespace. The
header file is from bootloader/legacy/include/boot/bootimg.h. The header
parsing has been written from scratch and I looked at
bootloader/legacy/usbloader/usbloader.c for some details.
The image contains the physical address (load address) of the kernel and
ramdisk. This address is considered only for the kernel image.
The "second image" defined in the image header is currently not
supported. I haven't found anything that is creating this.

v3 (Rob Herring):
This is based on http://patchwork.ozlabs.org/patch/126797/ with the
following changes:
- Rebased to current mainline
- Moved android image handling to separate functions in
  common/image-android.c
- s/u8/char/ in header to fix string function warnings
- Use SPDX identifiers for licenses
- Cleaned-up file source information:
  android_image.h is from file include/boot/bootimg.h in repository:
  https://android.googlesource.com/platform/bootable/bootloader/legacy
  The git commit hash is 4205b865141ff2e255fe1d3bd16de18e217ef06a
  usbloader.c would be from the same commit, but it does not appear
  to have been used for any actual code.
v4:
- s/andriod/android/
- Use a separate flag ep_found to track if the entry point has been set
rather than using a magic value.

Cc: Wolfgang Denk <wd@denx.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Tom Rini <trini@ti.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>







bootm: set max decompression size for LZO
2014-04-18T15:43:36+00:00

Kees Cook
keescook@chromium.org

2014-04-15T17:28:12+00:00

77cc8902e98f4b4a36688f454a07ad7bc82793a2

The LZO decompressor wasn't initializing the maximum output size, which
meant it would fail to decompress most of the time.

Reported-by: Matthias Weißer <weisserm@arcor.de>
Signed-off-by: Kees Cook <keescook@chromium.org>
Tested-by: Matthias Weißer <weisserm@arcor.de>
Acked-by: Simon Glass <sjg@chromium.org>





The LZO decompressor wasn't initializing the maximum output size, which
meant it would fail to decompress most of the time.

Reported-by: Matthias Weißer <weisserm@arcor.de>
Signed-off-by: Kees Cook <keescook@chromium.org>
Tested-by: Matthias Weißer <weisserm@arcor.de>
Acked-by: Simon Glass <sjg@chromium.org>