Technical guide
When a command-line session is available through the RK3588 serial port, check the kernel, init and application services separately. This shows progress through startup; graphics, peripherals and continuous operation still require separate checks. Record each layer's inputs, logs and decision to locate the first failure.
Define the scope of the Stage-0 record
The OpenHarmony 6.1 Stage-0 adaptation record for RK3588, in Chinese uses a specified board, the Build22 build label and an SD boot medium. Stage-0 means minimum validation without a graphical interface. Build22 is the build label used by that record; connect it to the source revision, build configuration and image hash when investigating a problem.
Read startup progress separately from the functions checked in that phase. When adding graphics, applications or peripherals, retain the same version records and extend the relevant acceptance cases.
Layer responsibilities and diagnosis inputs
Swipe the table horizontally to view all columns.
| Layer | Responsibility | Records to check first |
|---|---|---|
| Boot loading and hardware description | Load the image and supply boot parameters and hardware description | Boot medium, image hash, boot parameters and DTB version |
| Kernel | Initialize processors, drivers and basic resources | Serial logs, driver errors and root filesystem mounting |
| init | Organize user-space processes and dependencies according to startup configuration | Configuration path, process sequence, exits and restarts |
| Application services | Provide graphics, device functions and business interfaces | Service logs, dependency state, interface responses and scenario cases |
DTB is a binary device-tree description that supplies hardware information to the kernel. Match it to the board and image revision instead of comparing filenames alone. Keep init as the subsystem's technical name and check configuration against the OpenHarmony version in use. The startup subsystem source helps locate mechanisms and configuration; project conclusions require records from the relevant version.
Find the earliest failure using one consistent version
Use the same board revision, image and boot medium for every reproduction of the problem. Review logs in time order. Record driver initialization failures, filesystem path errors, unavailable dependencies and process exits separately. If a service exits, check its dependencies before changing service settings or error handling.
Attach the following fields to each reproduction. This is a record definition for integration work, with no preset test results.
Swipe the table horizontally to view all columns.
| Record field | Information to retain | Purpose |
|---|---|---|
| Version identity | Board revision, source revision, build label and image hash | Confirm consistent inputs across reproductions |
| Boot conditions | Medium, power arrangement, connections and boot parameters | Explain environmental differences |
| First failure | Log time, module, error code and surrounding context | Separate the initial problem from later failures |
| Reproduction steps | Power or restart sequence, actions and occurrence frequency | Allow another engineer to repeat the check |
| Phase decision | Layers checked, supporting evidence and remaining functions | Separate one boot from continuous operation testing |
Inputs for an adaptation assessment
Prepare the board and revision, current system, available source, boot medium, complete serial logs and target functions. Agree the layers covered by the phase before defining graphics, peripheral, application and stability tests. See the embedded Linux BSP and device application adaptation service, in Chinese for related inputs and deliverables.
Online
Phone
WeChat
Top