| b979d3d4 | 04-Jul-2016 |
Simon Glass <sjg@chromium.org> |
dm: Add a test for of-platdata
Add a simple test which checks that the of-platdata system is working
correctly. The sequence is as follows:
- SPL starts up and probes all the UCLASS_MISC drivers
-
dm: Add a test for of-platdata
Add a simple test which checks that the of-platdata system is working
correctly. The sequence is as follows:
- SPL starts up and probes all the UCLASS_MISC drivers
- There are 3 of these in sandbox.dts
- Therefore there should be 3 U_BOOT_DEVICE() declarations in dt-platdata.c
- These should produce 3 sandbox_spl_test devices
- Each device prints out its platform data when probed
- This test checks for this output and compares it against expectations
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| a811779b | 04-Jul-2016 |
Simon Glass <sjg@chromium.org> |
test/py: Start sandbox SPL when enabled
When sandbox SPL is enabled we want to start that rather than U-Boot proper,
since some tests may rely on running it first.
Signed-off-by: Simon Glass <sjg@c
test/py: Start sandbox SPL when enabled
When sandbox SPL is enabled we want to start that rather than U-Boot proper,
since some tests may rely on running it first.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| c7f636f5 | 04-Jul-2016 |
Simon Glass <sjg@chromium.org> |
test/py: Note which console produced unexpected output
At present the SPL and U-Boot consoles both present the same error message
when the expected console output does not appear. Add "SPL" to the S
test/py: Note which console produced unexpected output
At present the SPL and U-Boot consoles both present the same error message
when the expected console output does not appear. Add "SPL" to the SPL error
message to resolve this ambiguity.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 73a9054d | 03-Jul-2016 |
Simon Glass <sjg@chromium.org> |
test/py: Add a helper to run a list of U-Boot commands
Some tests want to execute a sequence of commands. Add a helper for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Teddy Ree
test/py: Add a helper to run a list of U-Boot commands
Some tests want to execute a sequence of commands. Add a helper for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Teddy Reed <teddy.reed@gmail.com>
show more ...
|
| 9e17b034 | 03-Jul-2016 |
Simon Glass <sjg@chromium.org> |
test/py: Provide a way to check that a command fails
Sometimes we want to run a command and check that it fails. Add a function
to handle this. It can check the return code and also make sure that t
test/py: Provide a way to check that a command fails
Sometimes we want to run a command and check that it fails. Add a function
to handle this. It can check the return code and also make sure that the
output contains a given error message.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 8b304a37 | 03-Jul-2016 |
Simon Glass <sjg@chromium.org> |
test/py: Add an option to execute a string containing a command
It is sometimes inconvenient to convert a string into a list for execution
with run_and_log(). Provide a helper function to do this.
test/py: Add an option to execute a string containing a command
It is sometimes inconvenient to convert a string into a list for execution
with run_and_log(). Provide a helper function to do this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Teddy Reed <teddy.reed@gmail.com>
show more ...
|
| f3d3e95c | 03-Jul-2016 |
Simon Glass <sjg@chromium.org> |
test/py: Return output from run_and_log()
It is useful to be able to obtain the output from a command. Return it from
this function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Teddy
test/py: Return output from run_and_log()
It is useful to be able to obtain the output from a command. Return it from
this function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Teddy Reed <teddy.reed@gmail.com>
show more ...
|
| 86845bf3 | 03-Jul-2016 |
Simon Glass <sjg@chromium.org> |
test/py: Provide output from exceptions with RunAndLog()
Tests may want to look at the output from running a command, even if it
fails (e.g. with a non-zero return code). Provide a means to obtain t
test/py: Provide output from exceptions with RunAndLog()
Tests may want to look at the output from running a command, even if it
fails (e.g. with a non-zero return code). Provide a means to obtain this.
Another approach would be to return a class object containing both the
output and the exception, but I'm not sure if that would result in a lot
of refactoring.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Teddy Reed <teddy.reed@gmail.com>
show more ...
|
| 3b8d9d97 | 03-Jul-2016 |
Simon Glass <sjg@chromium.org> |
test/py: Allow RunAndLog() to return the output
Tests may want to look at the output from running a command. Return it so
that this is possible.
Signed-off-by: Simon Glass <sjg@chromium.org>
Review
test/py: Allow RunAndLog() to return the output
Tests may want to look at the output from running a command. Return it so
that this is possible.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Teddy Reed <teddy.reed@gmail.com>
show more ...
|
| 0671960b | 03-Jul-2016 |
Simon Glass <sjg@chromium.org> |
test/py: Allow tests to control the sandbox device-tree file
Normally tests will run with the test.dtb file designed for this purpose.
However, the verified boot tests need to run with their own dev
test/py: Allow tests to control the sandbox device-tree file
Normally tests will run with the test.dtb file designed for this purpose.
However, the verified boot tests need to run with their own device-tree
file, containing a public key.
Make the device-tree file a config option so that it can be adjusted by
tests. The default is to keep the current behaviour.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Teddy Reed <teddy.reed@gmail.com>
show more ...
|
| 07f4eadc | 03-Jul-2016 |
Simon Glass <sjg@chromium.org> |
test: Add a simple script to run tests on sandbox
A common check before sending patches is to run all available tests on
sandbox. But everytime I do this I have to look up the README. This presents
test: Add a simple script to run tests on sandbox
A common check before sending patches is to run all available tests on
sandbox. But everytime I do this I have to look up the README. This presents
quite a barrier to actually doing this.
Add a shell script to help. To run the tests, type:
test/run
in the U-Boot directory, which should be easy to remember.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Teddy Reed <teddy.reed@gmail.com>
show more ...
|
| d56dd0b1 | 06-Jul-2016 |
Daniel Schwierzeck <daniel.schwierzeck@gmail.com> |
test/py: support 'memstart =' in u_boot_utils.find_ram_base()
Some archs like MIPS or PPC have a different 'bdinfo' output
than ARM regarding the memory configuration. Also support
'memstart = 0x*'
test/py: support 'memstart =' in u_boot_utils.find_ram_base()
Some archs like MIPS or PPC have a different 'bdinfo' output
than ARM regarding the memory configuration. Also support
'memstart = 0x*' in u_boot_utils.find_ram_base() to make
all tests requiring the RAM base working on those archs.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
show more ...
|
| 085e64dd | 06-Jul-2016 |
Stephen Warren <swarren@nvidia.com> |
test/py: strip VT100 codes from match buffer
Prior to this patch, any VT100 codes emitted by U-Boot are considered part
of a command's output, which often causes tests to fail. For example,
test_env
test/py: strip VT100 codes from match buffer
Prior to this patch, any VT100 codes emitted by U-Boot are considered part
of a command's output, which often causes tests to fail. For example,
test_env_echo_exists executes printenv, and then considers any text on a
line before an = sign as a valid U-Boot environment variable name. This
includes any VT100 codes emitted. When the test later attempts to use that
variable, the name would be invalid since it includes the VT100 codes.
Solve this by stripping VT100 codes from the match buffer, so they are
never seen by higher level test code.
The codes are still logged unmodified, so that users can expect U-Boot's
exact output without interference. This does clutter the log file a bit.
However, it allows users to see exactly what U-Boot emitted rather than a
modified version, which hopefully is better for debugging. It's also much
simpler to implement, since logging happens as soon as text is received,
and so stripping the VT100 codes from the log would require handling
reception and stripping of partial VT100 codes.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
show more ...
|