This commit aims to add an application to gather debug information about the host and target systems. It can also perform some diagnostic checks on the host and target systems.
This will facilitate the process of users seeking assistance for solving some problem.
Current capabilities:
- Get host OS version;
- Get host python modules;
- Get host system packages;
- Get host PATH;
- Get host compilation flags for the target;
- Get target NuttX configuration;
- Get target OS version, hostname, build and architecture;
- Capable of adding custom, vendor specific, information. Currently gathering only Espressif related info:
- Get the bootloader version of detected image files;
- Get the version of different toolchains used by Espressif chips;
- Get Esptool version.
Due to the current Nuttx not supporting death test, we removed death test from the original test cases of Android
Signed-off-by: hujun5 <hujun5@xiaomi.com>
If the same signal is quickly repeated multiple times, the signal may be ignored.
In SMP since we cannot control thread scheduling to ensure timely signal processing,
it is best to use semaphores to wait for signal processing to complete, which can also shorten the ostest time
Signed-off-by: hujun5 <hujun5@xiaomi.com>
ostest contains some logic that depends on internal implementation of signal sets and ostest must be updated to match those changes.
There is no particular impact from this PR. This PR is the result of impact from nuttx 8885.
Tested with nuttx 8885
The test consists of two parts:
- A tester that tries to trigger wrong states of work queue
- A verifier that checks whether the wqueue is still working properly
The tester is trying to queue and cancel work several times with
priority lower/same/higher than the work queue.
Most wrong cases are likely to happen with high priority like:
- If `cancel` never decreases semcount, the count may keep growing
and finally overflow
- If `cancel` is decreasing semcount too much, the `work_thread` may
be waken up less times than expected
The lower/same priority testers are just added for covering other
unexpected situations.
The verifier is trying to queue some works and check they are called as
expected:
- Frist queue a 'sleep' worker, to let a work queue thread be in busy
status and not waiting on sem, while other work queue thread(s) (if
any) still waiting for sem. If sem is in wrong state, it may cause
wrong behavior in either thread waiting/not waiting on the sem.
- Then queue a few count works, if the work queue(s) are still working
properly, these works should finally be all called once.
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
VELAPLATFO-4612
There are three test.
1. Write a long default string into the serial port.
2. Read the default string given by the last test from the serial port.
3. Manually execute the `test_content_ gen.py` script and write the text into the serial device to test the burst capability or run this script and specify device path to automatically test.
Signed-off-by: xinbingnan <xinbingnan@xiaomi.com>
The BMI160 6-axis acceleration sensor is used as the peripheral of the I2C test. The main purpose of the test is to open the peripheral and read the data of the sensor. If it is read successfully, the test is successful.
Add compiled constraints to make it work only when the bmi160 driver is turned on.
Signed-off-by: xinbingnan <xinbingnan@xiaomi.com>
