Tool/software: Linux
A problem well described is a problem well understood.
Lack of information demands unnecessary communication thereby delaying actual debug of the problem and costs time for both sides.
Here's a simple guideline for better describing issues and reducing delays in resolution.
It's just a template and all steps may not be required or applicable for every issue.
I hope below six step guideline or parts of it, as necessary, will help save everyone's time and efforts.
1. Post title
-
<Platform:driver name: one line statement> [ex: AM572x: eMMC: command timeout error during write to card]
2. HW description
-
SoC [AM5728, AM3352, DRA7XX etc] & PG - Rev 1.0, 2.0 etc
-
TI EVM or a custom board, IF TI EVM which Rev (A< B, G etc) or variant (IDK, uEVM etc)
-
Relevant device info - PMIC, DDR, CAM, DISPLAY, ETH card, PCIE card, et
3. SW description
-
SDK version, Kernel and U-boot version
-
Custom bootloader vs SDK bootloader
-
Application, middle ware, frameworks used
-
additional patches/changes done on top of an SDK
4. Problem Scenario
-
Describe the usecase and components involved
-
Events leading to the issue
-
Time taken to issue reproduction and Frequency of reproduction
-
If it's on a custom board, has it been tried on a TI HW?
5. Relevant logs
-
Usually - full boot log leading upto the issu
-
At least complete issue signature when it's not feasible to share entire boot log
-
Check for debug options - ex: setting "loglevel=7", "earlyprintk" in bootargs, enabling driver specific debug "CONFIG_PM_DEBUG" or "CONFIG_MMC_DEBUG", etc.
6. Attach relevant collaterals
-
share device tree source (dts/dtsi) files if modified or using a custom board
-
system block diagram for system level problems involving more than just kernel drivers
-
A standlone application/test case to reproduce issue when required
Regards,
RK