| 82744c20 | 04-Oct-2018 |
Mario Six <mario.six@gdsys.cc> |
test: regmap: Increase size of syscon0 memory
The upcoming changes to the regmap interface will contain a proper check
for plausibility when reading/writing from/to a register map. To still
have the
test: regmap: Increase size of syscon0 memory
The upcoming changes to the regmap interface will contain a proper check
for plausibility when reading/writing from/to a register map. To still
have the current tests pass, increase the size of the memory region for
the syscon0 device, since one of the tests reads and writes beyond this
range.
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Mario Six <mario.six@gdsys.cc>
show more ...
|
| ac3f26cc | 26-Sep-2018 |
Joe Hershberger <joe.hershberger@ni.com> |
net: Don't overwrite waiting packets with asynchronous replies
Peter originally sent a fix, but it breaks a number of other things.
This addresses the original reported issue in a different way.
Th
net: Don't overwrite waiting packets with asynchronous replies
Peter originally sent a fix, but it breaks a number of other things.
This addresses the original reported issue in a different way.
That report was:
> U-Boot has 1 common buffer to send Ethernet frames, pointed to by
> net_tx_packet. When sending to an IP address without knowing the MAC
> address, U-Boot makes an ARP request (using the arp_tx_packet buffer)
> to find out the MAC address of the IP addressr. When a matching ARP
> reply is received, U-Boot continues sending the frame stored in the
> net_tx_packet buffer.
>
> However, in the mean time, if U-Boot needs to send out any network
> packets (e.g. replying ping packets or ARP requests for its own IP
> address etc.), it will use the net_tx_packet buffer to prepare the
> new packet. Thus this buffer is no longer the original packet meant
> to be transmitted after the ARP reply. The original packet will be
> lost.
This instead uses the ARP tx buffer to send async replies in the case
where we are actively waiting for an ARP reply.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Reported-by: Tran Tien Dat <peter.trantiendat@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
show more ...
|
| 72ff0042 | 26-Sep-2018 |
Joe Hershberger <joe.hershberger@ni.com> |
test: eth: Add a test for the target being pinged
The target will respond to pings while doing other network handling.
Make sure that the response happens and is correct.
This currently corrupts th
test: eth: Add a test for the target being pinged
The target will respond to pings while doing other network handling.
Make sure that the response happens and is correct.
This currently corrupts the ongoing operation of the device if it
happens to be awaiting an ARP reply of its own to whatever serverip it
is attempting to communicate with. In the test, add an expectation that
the user operation (ping, in this case) will fail. A later patch will
address this problem.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
show more ...
|
| 751fed42 | 01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
sysreset: Add a way to find the last reset
We have a method to return the last reset as a string for humans, but not
a method that allows it to be used programmatically. Add a new method that
return
sysreset: Add a way to find the last reset
We have a method to return the last reset as a string for humans, but not
a method that allows it to be used programmatically. Add a new method that
returns the last reset as an enum.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| a4f737a9 | 01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
panel: Expand the backlight support
At present the panel can be turned on but not off, and the brightness
cannot be controlled at run-time. Add a new API function to both the panel
and backlight ucl
panel: Expand the backlight support
At present the panel can be turned on but not off, and the brightness
cannot be controlled at run-time. Add a new API function to both the panel
and backlight uclasses to handle this. Enhance the PWM backlight driver
to deal with custom levels properly and allow the backlight to be turned
on and off.
Update the test to cover thes new features.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| cdd140af | 01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
log: Add helpers for common log levels
At present to output a log message you need something like:
log(UCLASS_SPI, LOCL_INFO, "message1");
log(UCLASS_SPI, LOCL_INFO, "message2");
but many fi
log: Add helpers for common log levels
At present to output a log message you need something like:
log(UCLASS_SPI, LOCL_INFO, "message1");
log(UCLASS_SPI, LOCL_INFO, "message2");
but many files use the same category throughout. Also it is helpful to
shorten the length of log names, providing helpers for common logging
levels. Add some macros so that it is possible to do:
(top of file, before #includes)
#define LOG_CATEGORY UCLASS_SPI
(later in the file)
log_info("message1");
log_debug("message2");
log_err("message3");
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 11ae93ee | 01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
binman: Run tests concurrently
At present the tests run one after the other using a single CPU. This is
not very efficient. Bring in the concurrencytest module and run the tests
concurrently, using
binman: Run tests concurrently
At present the tests run one after the other using a single CPU. This is
not very efficient. Bring in the concurrencytest module and run the tests
concurrently, using one process for each CPU by default. A -P option
allows this to be overridden, which is necessary for code-coverage to
function correctly.
This requires fixing a few tests which are currently not fully
independent.
At some point we might consider doing this across all pytests in U-Boot.
There is a pytest version that supports specifying the number of processes
to use, but it did not work for me.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 3bc11e81 | 01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
test: Tidy up comments and variable name
The 'result' variable counts the number of failures in running the tests.
Rename it to 'failures' to make this more obvious. Also tidy up a few
comments.
Si
test: Tidy up comments and variable name
The 'result' variable counts the number of failures in running the tests.
Rename it to 'failures' to make this more obvious. Also tidy up a few
comments.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| c9adb355 | 01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
test: Print the name of each test before running it
At present the tests are run without any indication of what is running.
For the tests which start with a build this is pretty obvious, but for
too
test: Print the name of each test before running it
At present the tests are run without any indication of what is running.
For the tests which start with a build this is pretty obvious, but for
tools it is not.
Add a name for each test we run, and print it before starting the test.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 87b05ee3 | 01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
test/py: Fix unicode handling for log filtering
At present the unicode filtering seems to get confused at times with
this error:
UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in positi
test/py: Fix unicode handling for log filtering
At present the unicode filtering seems to get confused at times with
this error:
UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position
32: ordinal not in range(128)
It seems to be due to self._nonprint being interpreted as UTF-8. Fix it
by using ordinals instead of characters, changing the string to set.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Michal Simek <michal.simek@xilinx.com>
show more ...
|
| 9f8037ea | 01-Oct-2018 |
Simon Glass <sjg@chromium.org> |
sandbox: Unprotect DATA regions in bus tests
On my Ubuntu 18.04.1 machine two driver-model bus tests have started
failing recently. The problem appears to be that the DATA region of the
executable i
sandbox: Unprotect DATA regions in bus tests
On my Ubuntu 18.04.1 machine two driver-model bus tests have started
failing recently. The problem appears to be that the DATA region of the
executable is protected. This does not seem correct, but perhaps there
is a reason.
To work around it, unprotect the regions in these tests before accessing
them.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|