mirror of
https://github.com/LuckfoxTECH/luckfox-pico.git
synced 2026-01-18 11:38:31 +01:00
8f34c2760d
project:cfg:BoardConfig_IPC: Added fastboot BoardConfig file and firmware post-scripts, distinguishing between the BoardConfigs for Luckfox Pico Pro and Luckfox Pico Max. project:app: Added fastboot_client and rk_smart_door for quick boot applications; updated rkipc app to adapt to the latest media library. media:samples: Added more usage examples. media:rockit: Fixed bugs; removed support for retrieving data frames from VPSS. media:isp: Updated rkaiq library and related tools to support connection to RKISP_Tuner. sysdrv:Makefile: Added support for compiling drv_ko on Luckfox Pico Ultra W using Ubuntu; added support for custom root filesystem. sysdrv:tools:board: Updated Buildroot optional mirror sources, updated some software versions, and stored device tree files and configuration files that undergo multiple modifications for U-Boot and kernel separately. sysdrv:source:mcu: Used RISC-V MCU SDK with RT-Thread system, mainly for initializing camera AE during quick boot. sysdrv:source:uboot: Added support for fastboot; added high baud rate DDR bin for serial firmware upgrades. sysdrv:source:kernel: Upgraded to version 5.10.160; increased NPU frequency for RV1106G3; added support for fastboot. Signed-off-by: luckfox-eng29 <eng29@luckfox.com>
KSelfTest arm64/signal/
=======================
Signals Tests
+++++++++++++
- Tests are built around a common main compilation unit: such shared main
enforces a standard sequence of operations needed to perform a single
signal-test (setup/trigger/run/result/cleanup)
- The above mentioned ops are configurable on a test-by-test basis: each test
is described (and configured) using the descriptor signals.h::struct tdescr
- Each signal testcase is compiled into its own executable: a separate
executable is used for each test since many tests complete successfully
by receiving some kind of fatal signal from the Kernel, so it's safer
to run each test unit in its own standalone process, so as to start each
test from a clean slate.
- New tests can be simply defined in testcases/ dir providing a proper struct
tdescr overriding all the defaults we wish to change (as of now providing a
custom run method is mandatory though)
- Signals' test-cases hereafter defined belong currently to two
principal families:
- 'mangle_' tests: a real signal (SIGUSR1) is raised and used as a trigger
and then the test case code modifies the signal frame from inside the
signal handler itself.
- 'fake_sigreturn_' tests: a brand new custom artificial sigframe structure
is placed on the stack and a sigreturn syscall is called to simulate a
real signal return. This kind of tests does not use a trigger usually and
they are just fired using some simple included assembly trampoline code.
- Most of these tests are successfully passing if the process gets killed by
some fatal signal: usually SIGSEGV or SIGBUS. Since while writing this
kind of tests it is extremely easy in fact to end-up injecting other
unrelated SEGV bugs in the testcases, it becomes extremely tricky to
be really sure that the tests are really addressing what they are meant
to address and they are not instead falling apart due to unplanned bugs
in the test code.
In order to alleviate the misery of the life of such test-developer, a few
helpers are provided:
- a couple of ASSERT_BAD/GOOD_CONTEXT() macros to easily parse a ucontext_t
and verify if it is indeed GOOD or BAD (depending on what we were
expecting), using the same logic/perspective as in the arm64 Kernel signals
routines.
- a sanity mechanism to be used in 'fake_sigreturn_'-alike tests: enabled by
default it takes care to verify that the test-execution had at least
successfully progressed up to the stage of triggering the fake sigreturn
call.
In both cases test results are expected in terms of:
- some fatal signal sent by the Kernel to the test process
or
- analyzing some final regs state