| Age | Commit message (Collapse) | Author |
|---|
|
Various misc enhancements to dfu_gadget_test.sh:
* After every write (download), perform a write to a different file
with different data. This ensures that the DFU buffer's content is
replaced, so that if the read (upload) succeeds, we know that the
correct data was actually read from the storage device, rather than
simply being left over in the DFU buffer. This requires two alt
setting names to be passed to the script, and a dummy data file to
be generated by dfu_gadget_test_init.sh.
* Fix the assumption that dfu_gadget_test.sh is run from the directory
that contains it, by cd'ing to that directory before invoking
./dfu_gadget_test_init.sh.
* Use $DIR$RCV_DIR consistently, rather than using plain $RCV_DIR in
some places.
* Add 959, 961 test file sizes, to be consistent with having one
more than and one less than all the other "round" sizes 64, 128, and
4096.
* Remove references to $BKP_DIR from dfu_gadget_test_init.sh, since it
isn't used.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
|
|
This commit adds test scripts for testing if any commit has introduced
regression to the DFU subsystem.
It uses md5 to test if sent and received file is correct.
The test detailed description is available at README file.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
|
|
Some devices (particularly bus devices) must track their children, knowing
when a new child is added so that it can be set up for communication on the
bus.
Add a child_pre_probe() method to provide this feature, and a corresponding
child_post_remove() method.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Some device types can have child devices and want to store information
about them. For example a USB flash stick attached to a USB host
controller would likely use this space. The controller can hold
information about the USB state of each of its children.
The data is stored attached to the child device in the 'parent_priv'
member. It can be auto-allocated by dm when the child is probed. To
do this, add a per_child_auto_alloc_size value to the parent driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Devices can have childen that can be addressed by a simple index, the
sequence number or a device tree offset. Add functions to access a child
in each of these ways.
The index is typically used as a fallback when the sequence number is not
available. For example we may use a serial UART with sequence number 0 as
the console, but if no UART has sequence number 0, then we can fall back
to just using the first UART (index 0).
The device tree offset function is useful for buses, where they want to
locate one of their children. The device tree can be scanned to find the
offset of each child, and that offset can then find the device.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
At present only root nodes in the device tree are scanned for devices.
But some devices can have children. For example a SPI bus may have
several children for each of its chip selects.
Add a function which scans subnodes and binds devices for each one. This
can be used for the root node scan also, so change it.
A device can call this function in its bind() or probe() methods to bind
its children.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Don't allow access to uclasses before they have been initialised.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Each device that was bound from a device tree has an node that caused it to
be bound. Add functions that find and return a device based on a device tree
offset.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Add this information to 'dm tree' and 'dm uclass' commands.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
In U-Boot it is pretty common to number devices from 0 and access them
on the command line using this numbering. While it may come to pass that
we will move away from this numbering, the possibility seems remote at
present.
Given that devices within a uclass will have an implied numbering, it
makes sense to build this into driver model as a core feature. The cost
is fairly small in terms of code and data space.
With each uclass having numbered devices we can ask for SPI port 0 or
serial port 1 and receive a single device.
Devices typically request a sequence number using aliases in the device
tree. These are resolved when the device is probed, to deal with conflicts.
Sequence numbers need not be sequential and holes are permitted.
At present there is no support for sequence numbers using static platform
data. It could easily be added to 'struct driver_info' if needed, but it
seems better to add features as we find a use for them, and the use of -1
to mean 'no sequence' makes the default value somewhat painful.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This command currently activates devices as it lists them. This is not
desirable since it changes the system state. Fix it and avoid printing
a newline if there are no devices in a uclass.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The device display for 'dm tree' and 'dm uclass' is mostly the same, so
move it into a common function.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Driver model currently only operates after relocation is complete. In this
state U-Boot typically has a small amount of memory available. In adding
support for driver model prior to relocation we must try to use as little
memory as possible.
In addition, on some machines the memory has not be inited and/or the CPU
is not running at full speed or the data cache is off. These can reduce
execution performance, so the less initialisation that is done before
relocation the better.
An immediately-obvious improvement is to only initialise drivers which are
actually going to be used before relocation. On many boards the only such
driver is a serial UART, so this provides a very large potential benefit.
Allow drivers to mark themselves as 'pre-reloc' which means that they will
be initialised prior to relocation. This can be done either with a driver
flag or with a 'dm,pre-reloc' device tree property.
To support this, the various dm scanning function now take a 'pre_reloc_only'
parameter which indicates that only drivers marked pre-reloc should be
bound.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The root device should be probed just like any other device. The effect of
this is to mark the device as activated, so that it can be removed (along
with its children) if required.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Marek Vasut <marex@denx.de>
|
|
Rather than reusing the 'reg' property, use an explicit property for the
expected ping value used in testing.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
Commit 95fac6ab4589 "sandbox: Use os functions to read host device tree"
removed the ability for get_device_and_partition() to handle the "host"
device type, and redirect accesses to it to the host filesystem. This
broke some unit tests that use this feature. So, revert that change. The
code added back by this patch is slightly different to pacify checkpatch.
However, we're then left with "host" being both:
- A pseudo device that accesses the hosts real filesystem.
- An emulated block device, which accesses "sectors" inside a file stored
on the host.
In order to resolve this discrepancy, rename the pseudo device from host
to hostfs, and adjust the unit-tests for this change.
The "help sb" output is modified to reflect this rename, and state where
the host and hostfs devices should be used.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Josh Wu <josh.wu@atmel.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
Make both dm enumeration commands support showing whether a driver is active
or not, and use a consistent indicator (an asterisk).
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Marek Vasut <marex@denx.de>
|
|
The values here are int, but the map_to_sysmem() call can return a long.
Add a cast to deal with this.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The GPIO tests require the sandbox GPIO driver, so cannot be run on other
platforms. Similarly for the 'dm test' command.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
It is best to avoid having any occurence of 'struct device' in driver
model, so rename to achieve this.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
vboot_test.sh uses Bashisms. Explicitly use #!/bin/bash so the script
doesn't fail if /bin/sh isn't Bash.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
run_command_list() is supposed to return a return code of 0 for success
and 1 for failure. Add a few simple tests that confirm this. These tests
work both with the built-in parser and hush.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
using UBI and DM together leads in compiler error, as
both define a "struct device", so rename "struct device"
in include/dm/device.h to "struct udevice", as we use
linux code (MTD/UBI/UBIFS some USB code,...) and cannot
change the linux "struct device"
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Marek Vasut <marex@denx.de>
|
|
add host tool "fit_check_sign" which verifies, if a fit image is
signed correct.
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
|
|
based on patch from andreas@oetken.name:
http://patchwork.ozlabs.org/patch/294318/
commit message:
I currently need support for rsa-sha256 signatures in u-boot and found out that
the code for signatures is not very generic. Thus adding of different
hash-algorithms for rsa-signatures is not easy to do without copy-pasting the
rsa-code. I attached a patch for how I think it could be better and included
support for rsa-sha256. This is a fast first shot.
aditionally work:
- removed checkpatch warnings
- removed compiler warnings
- rebased against current head
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: andreas@oetken.name
Cc: Simon Glass <sjg@chromium.org>
|
|
The unit-test for hush's "test -e" currently relies upon being run in
the U-Boot build directory, because it tests for the existence of a file
that exists in that directory.
Fix this by explicitly creating the file we use for the existence test,
and deleting it afterwards so that multiple successive unit-test
invocations succeed. This required adding an os.c function to erase
files.
Reported-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
|
|
The following shell command fails:
if test -z "$x"; then echo "zero"; else echo "non-zero"; fi
(assuming $x does not exist, it prints "non-zero" rather than "zero").
... since "$x" expands to nothing, and the argument is completely
dropped, causing too few to be passed to -z, causing cmd_test() to
error out early.
This is because when variable expansions are processed by make_string(),
the expanded results are concatenated back into a new string. However,
no quoting is applied when doing so, so any empty variables simply don't
generate any parameter when the combined string is parsed again.
Fix this by explicitly replacing quoting any argument that was originally
quoted when re-generating a string from the already-parsed argument list.
This also fixes loss of whitespace in commands such as:
setenv space " "
setenv var " 1${space}${space} 2 "
echo ">>${var}<<"
Reported-by: Russell King <linux@arm.linux.org.uk>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
|
|
Delete the temporary variables that are used to save unit-test results
from the environment after running the test. This prevents polluting
the environment, or growing it too much.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Add driver model support for GPIOs. Since existing GPIO drivers do not use
driver model, this feature must be enabled by CONFIG_DM_GPIO. After all
GPO drivers are converted over we can perhaps remove this config.
Tests are provided for the sandbox implementation, and are a sufficient
sanity check for basic operation.
The GPIO uclass understands the concept of named banks of GPIOs, with each
GPIO device providing a single bank. Within each bank the GPIOs are numbered
using an offset from 0 to n-1. For example a bank named 'b' with 20
offsets will provide GPIOs named b0 to b19.
Anonymous GPIO banks are also supported, and are just numbered without any
prefix.
Each time a GPIO driver is added to the uclass, the GPIOs are renumbered
accordinging, so there is always a global GPIO numbering order.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Pavel Herrmann <morpheus.ibis@gmail.com>
Signed-off-by: Viktor Křivák <viktor.krivak@gmail.com>
Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>
|
|
This command is not required for driver model operation, but can be useful
for testing. It provides simple dumps of internal data structures.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Pavel Herrmann <morpheus.ibis@gmail.com>
Signed-off-by: Viktor Křivák <viktor.krivak@gmail.com>
Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>
|
|
Add some tests of driver model functionality. Coverage includes:
- basic init
- binding of drivers to devices using platform_data
- automatic probing of devices when referenced
- availability of platform data to devices
- lifecycle from bind to probe to remove to unbind
- renumbering within a uclass when devices are probed/removed
- calling driver-defined operations
- deactivation of drivers when removed
- memory leak across creation and destruction of drivers/uclasses
- uclass init/destroy methods
- automatic probe/remove of children/parents when needed
This function is enabled for sandbox, using CONFIG_DM_TEST.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
I recently re-wrote cmd_test() to add new features. Add a bunch of unit-
tests to make sure I didn't break anything.
Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
|
|
"env default -f" doesn't work any more; replace it with
"env default -f -a". This avoids the following when running the ut
command:
do_ut_cmd: Testing commands
env - environment handling commands
Usage:
env default [-f] -a - [forcibly] reset default environment
...
Signed-off-by: Stephen Warren <swarren@nvidia.com>
|
|
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: Masahiro Yamada <yamada.m@jp.panasonic.com>
|
|
Signed-off-by: Wolfgang Denk <wd@denx.de>
[trini: Drop changes for PEP 4 following python tools]
Signed-off-by: Tom Rini <trini@ti.com>
|
|
This adds the "test_compression" command when building the sandbox. This
tests the existing compression and decompression routines for simple
sanity and for buffer overflow conditions.
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-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>
|
|
Add a description of how to implement verified boot using signed FIT images,
and a simple test which verifies operation on sandbox.
The test signs a FIT image and verifies it, then signs a FIT configuration
and verifies it. Then it corrupts the signature to check that this is
detected.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
It is difficult to automatically test tracing on most architectures, but
with sandbox it is easy enough to do a simple sanity check.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
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>
|
|
Since run_command() and run_command_list() are important and a little
confusing, add some basic tests to check that the behaviour is correct.
Note: I am not sure that this should be committed, nor where it should go
in the source tree. Comments welcome.
To run the unit tests use the ut_cmd command available in sandbox:
make sandbox_config
make
./u-boot -c ut_cmd
(To test both hush and built-in parsers, you need to manually change
CONFIG_SYS_HUSH_PARSER in include/configs/sandbox.h and build/run again)
Signed-off-by: Simon Glass <sjg@chromium.org>
|
