| c166c47b | 19-May-2017 |
Simon Glass <sjg@chromium.org> |
dm: test: Add support for running tests with livetree
It is useful to run the driver model tests with both livetree and flat
tree in case something is different between the two. Add this feature to
dm: test: Add support for running tests with livetree
It is useful to run the driver model tests with both livetree and flat
tree in case something is different between the two. Add this feature to
the test runner.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| f86db10c | 19-May-2017 |
Simon Glass <sjg@chromium.org> |
dm: test: Move test running code into a separate function
We want to run the same test on flat and live trees. In preparation for
this, create a new function which handles running a test.
Signed-of
dm: test: Move test running code into a separate function
We want to run the same test on flat and live trees. In preparation for
this, create a new function which handles running a test.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| e48eeb9e | 24-Apr-2017 |
Simon Glass <sjg@chromium.org> |
dm: blk: Improve block device claiming
The intention with block devices is that the device number (devnum field
in its descriptor) matches the alias of its parent device. For example,
with:
aliase
dm: blk: Improve block device claiming
The intention with block devices is that the device number (devnum field
in its descriptor) matches the alias of its parent device. For example,
with:
aliases {
mmc0 = "/sdhci@700b0600";
mmc1 = "/sdhci@700b0400";
}
we expect that the block devices for mmc0 and mmc1 would have device
numbers of 0 and 1 respectively.
Unfortunately this does not currently always happen. If there is another
MMC device earlier in the driver model data structures its block device
will be created first. It will therefore get device number 0 and mmc0
will therefore miss out. In this case the MMC device will have sequence
number 0 but its block device will not.
To avoid this, allow a device to request a device number and bump any
existing device number that is using it. This all happens during the
binding phase so it is safe to change these numbers around. This allows
device numbers to match the aliases in all circumstances.
Add a test to verify the behaviour.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 24f927c5 | 27-Mar-2017 |
Stefan Roese <sr@denx.de> |
dm: test: Add test for device removal
Add a test for the correct device removal. Currently two different ways
for device removal are supported:
- Normal device removal via the device_remove() API
-
dm: test: Add test for device removal
Add a test for the correct device removal. Currently two different ways
for device removal are supported:
- Normal device removal via the device_remove() API
- Removal via selective device driver flags (DM_FLAG_ACTIVE_DMA)
This new test "remove_active_dma" adds tests cases for those both ways
of removal. This is done by adding a new test driver, which has this
flag set.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
show more ...
|
| 0e4e38ae | 18-Nov-2016 |
Alexander Graf <agraf@suse.de> |
travis: Add efi_loader grub2 test
We have all the building blocks now to run arbitrary efi applications
in travis. The most important one out there is grub2, so let's add
a simple test to verify tha
travis: Add efi_loader grub2 test
We have all the building blocks now to run arbitrary efi applications
in travis. The most important one out there is grub2, so let's add
a simple test to verify that grub2 still comes up.
Signed-off-by: Alexander Graf <agraf@suse.de>
show more ...
|
| 95b62b2e | 17-Nov-2016 |
Alexander Graf <agraf@suse.de> |
efi_loader: Allow to compile helloworld.efi w/o bundling it
Today we can compile a self-contained hello world efi test binary that
allows us to quickly verify whether the EFI loader framwork works.
efi_loader: Allow to compile helloworld.efi w/o bundling it
Today we can compile a self-contained hello world efi test binary that
allows us to quickly verify whether the EFI loader framwork works.
We can use that binary outside of the self-contained test case though,
by providing it to a to-be-tested system via tftp.
This patch separates compilation of the helloworld.efi file from
including it in the u-boot binary for "bootefi hello". It also modifies
the efi_loader test case to enable travis to pick up the compiled file.
Because we're now no longer bloating the resulting u-boot binary, we
can enable compilation always, giving us good travis test coverage.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
show more ...
|
| 4ca4b265 | 17-Nov-2016 |
Alexander Graf <agraf@suse.de> |
tests: Add efi_loader hello world test
Now that we have working network tests and a hello world efi application
built inside our tree, we can automatically test that efi binary running
inside of U-B
tests: Add efi_loader hello world test
Now that we have working network tests and a hello world efi application
built inside our tree, we can automatically test that efi binary running
inside of U-Boot.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
show more ...
|
| b1849152 | 06-Nov-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
fs-test.sh: Update expected results
After the latest changes, ext4 no longer has any fails.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Acked-by: Stephen Warren <swarren@wwwdotorg.or
fs-test.sh: Update expected results
After the latest changes, ext4 no longer has any fails.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
show more ...
|