Rockchip RK3588 and RK3566 Board Bring-Up: A Checklist from First Power-On to Production

Why a checklist, and why in this order

A custom board around an RK3588 or an RK3566 has far more ways to fail than the reference board it was derived from, and the failures hide behind one another: a marginal DDR rail looks like a kernel bug, a wrong Ethernet delay looks like a driver problem. The remedy is to prove the layers from the bottom up and never debug a layer until the one below it is solid. This is the order we use.

Step 0: before the first power-on

• Follow the reference design for power. These processors need several rails with a defined sequence, and the reference designs pair them with Rockchip power-management ICs. Deviating from the reference power tree is the most expensive way to be creative.
• Check boot straps and boot media pins against the reference: which of SD, eMMC and SPI flash the boot ROM tries first, and how the recovery mode is entered.
• Check the DDR layout against the reference rules for the memory type you use (LPDDR4, LPDDR4X or DDR4 depending on the chip and design): topology, length matching, reference planes and decoupling.
• Bring out the debug UART and the recovery USB port to test points or a header. If you can reach nothing else, you can still revive the board.
• Power it from a current-limited supply the first time, and watch each rail rise in the right order with an oscilloscope.

Step 1: the debug UART tells you the truth

Rockchip parts print from the boot ROM chain on a debug UART, by default at 1,500,000 baud, which many terminals do not offer in their menu; set it by hand. No output at all means a power, clock, reset or boot-media problem, not software. Read the first lines: they tell you whether the loader found the DDR and what it found.

Step 2: DDR is the first real test

The first-stage loader initialises DRAM using a vendor-supplied binary with training parameters for the memory type and speed. A board that stops during DDR training or boots and then crashes at random usually has a hardware margin problem: rail noise, a bad stub, or timing that the reference layout would not have had. Run a memory test for hours, with the processor busy and the board warm. Do not move on until it is clean, because every later symptom will otherwise look like something else.

Step 3: keep Maskrom as your safety net

Rockchip parts have a recovery mode in the boot ROM, Maskrom, reachable over USB when no valid boot image is found or when you force it by holding the boot pin. From it, host tools can load a loader and write storage over USB, so corrupted storage never means a dead board. Design the access in, document how a technician enters it, and use it in your production flashing too.

Step 4: the boot chain and the kernel

The chain is the boot ROM, then the first-stage loader with DDR initialisation, then U-Boot, then the kernel. Decide early between the vendor BSP, which gives you the full set of hardware accelerators on a vendor kernel, and mainline, whose support for these parts has grown a great deal but is not complete for every block. Products that depend on hardware video, the NPU or an ISP camera path generally start from the vendor BSP; products that need a long maintenance life and only the CPU, storage, network and display can often use mainline. Make the call before the first peripheral work, and keep the device tree and the build configuration in version control from day one.

Step 5: the peripherals, in the order that fails most often

1. Storage. eMMC speed mode and the matching signal integrity. A marginal eMMC works at low speed and fails at high.
2. Ethernet. Gigabit RGMII has clock-to-data delay that must be set once, either by the PHY or by the processor and never both. This is the single most common reason a link comes up but loses packets. Tune the delay values and run a throughput test with a packet-loss count.
3. USB. Host, device and OTG roles, and on the RK3588 the way USB 3 and other interfaces share physical lanes.
4. PCIe, SATA and other shared lanes. Some interfaces share the same high-speed lanes, so the choice made in the schematic fixes which combinations are possible. Verify the lane allocation against the datasheet before layout, not after.
5. Display. The panel's timing and power-up sequence, the interface (MIPI DSI, eDP, HDMI or LVDS depending on the board), the backlight and the touch controller. We cover the display side in more depth in our embedded HMI guide.
6. Audio, camera, wireless and sensors, each with its own clock, regulator and reset to declare in the device tree.

Step 6: thermal and power behaviour under load

These are performance processors, and they throttle when hot. Test with a worst-case load on the CPU, GPU and NPU at once, in the enclosure and at the upper ambient temperature, and see what the clocks do. A board that is fine on the bench in free air can fall to half speed in a sealed case. Set the thermal zones and the dynamic frequency scaling policy deliberately, and measure the power at the input, not only the processor temperature.

Step 7: NPU and acceleration

The NPU on these parts is substantial (about 6 TOPS on the RK3588 and a fraction of that on the RK3566), and getting a model to run on it means converting it with the vendor's toolkit and checking which operators are supported. Plan time for quantisation and accuracy checks on your own data. The NPU is not a free speedup for any model.

Step 8: before production

• A reproducible image build, with the exact bootloader, kernel and root filesystem recorded.
• A factory flashing procedure using the recovery mode, with a verification step and a log per unit.
• A first-boot self-test: memory, storage, network, display, sensors.
• An update mechanism with rollback, tested against power loss during the update.
• A temperature and burn-in run on a sample, with logs.

Our experience

We have designed the hardware for Rockchip platforms, including a multi-revision RK3128 mainboard with its display driver board, and bring up Rockchip application processors under Linux and Android. If you want a board designed, brought up and productised by one team, see our Linux BSP and driver service and our general bring-up guide.