| Age | Commit message (Collapse) | Author |
|---|
|
Nothing too fancy. A simple test that attmpts to load two loadables and
verify that they are properly unpacked in the u-boot sandbox.
Signed-off-by: Karl Apsite <Karl.Apsite@dornerworks.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The dumpimage is able to extract components contained in a FIT image:
$ ./dumpimage -T flat_dt -i CONTAINER.ITB -p INDEX FILE
The CONTAINER.ITB is a regular FIT container file. The INDEX is the poisition
of the sub-image to be retrieved, and FILE is the file (path+name) to save the
extracted sub-image.
For example, given the following kernel.its to build a kernel.itb:
/dts-v1/;
/ {
...
images {
kernel@1 {
description = "Kernel 2.6.32-34";
data = /incbin/("/boot/vmlinuz-2.6.32-34-generic");
type = "kernel";
arch = "ppc";
os = "linux";
compression = "gzip";
load = <00000000>;
entry = <00000000>;
hash@1 {
algo = "md5";
};
};
...
};
...
};
The dumpimage can extract the 'kernel@1' node through the following command:
$ ./dumpimage -T flat_dt -i kernel.itb -p 0 kernel
Extracted:
Image 0 (kernel@1)
Description: Kernel 2.6.32-34
Created: Wed Oct 22 15:50:26 2014
Type: Kernel Image
Compression: gzip compressed
Data Size: 4040128 Bytes = 3945.44 kB = 3.85 MB
Architecture: PowerPC
OS: Linux
Load Address: 0x00000000
Entry Point: 0x00000000
Hash algo: md5
Hash value: 22352ad39bdc03e2e50f9cc28c1c3652
Which results in the file 'kernel' being exactly the same as '/boot/vmlinuz-2.6.32-34-generic'.
Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
|
|
Some image types, like "KeyStone GP", do not have magic numbers to
distinguish them from other image types. Thus, the automatic image
type discovery does not work correctly.
This patch also fix some integer type mismatches.
Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
|
|
Sometimes it is useful to see the output from U-Boot, so add an option to
make this easier.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Prior to commit d455d87 there was an inconsistency between the position of
the 'address' parameter in 'sb load' and 'sb save'. This was corrected but
it broke some tests. Fix the tests and also the help for 'sb save'.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The host filesystem name has changed, so update the tests. The tests now
run again correctly:
$ make O=b/sandbox sandbox_defconfig all
...
$ test/image/test-fit.py -u b/sandbox/u-boot
FIT Tests
=========
Kernel load
Kernel + FDT load
Kernel + FDT + Ramdisk load
Tests passed
Caveat: this is only a sanity check - test coverage is poor
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Add a test for dumpimage.
Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Signed-off-by: Wolfgang Denk <wd@denx.de>
[trini: Fixup common/cmd_io.c]
Signed-off-by: Tom Rini <trini@ti.com>
|
|
When this test fails it is useful to see the output from U-Boot. Add
printing of this information on failure.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The image code is fairly complex with various different options. It would
be useful to have comprehensive tests for this.
As a start, create a script which tries out loading a kernel/ramdisk/fdt
from a FIT and checks that the images appear in the right place in memory.
This uses sandbox which now supports bootm and related features.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
