Migrating from Hisilicon to Rockchip: Workload Assessment and Implementation Path
Where Does the Migration Effort Actually Sit?
Migrating a Hisilicon design to Rockchip (RK3588/RK3576 as representative targets) is not "swap the BSP and run." Effort stacks across four layers — hardware, BSP, algorithms, and applications — with very different workloads and reuse rates at each. Estimate them separately before committing to a schedule.
How Much Can Each Layer Reuse?
| Layer | Key work | Reuse | Main risk |
|---|---|---|---|
| Hardware | Pinout remapping, power tree re-planning, MIPI/USB/Ethernet redesign, sensor module adaptation | Low — mostly redesign | First-spin debug cycle; tighter DDR length and impedance rules |
| BSP | uboot/kernel adaptation, GPIO/I2C peripheral driver rebuild, flashing and production test tooling | Low — rebuilt item by item | Many small drivers quietly stretch schedules |
| Algorithms | Model conversion to RKNN, quantization validation, pre/post-processing rewrite, full ISP re-tuning | Medium — depends on coupling | Quantization accuracy loss; image-quality acceptance |
| Applications | Business logic, GB28181/ONVIF stacks, cloud integration, configuration | High — mostly retained | Coupled architectures raise rework cost |
Two hardware spins are nearly unavoidable: the first spin answers "does it run," the second "can it be manufactured." Power sequencing, DDR length matching, and thermal issues mostly surface on the first spin, so plan for two.
How Do You Estimate BSP and Driver Rewrite Volume?
Start uboot and kernel work from a SoM vendor's maintained baseline rather than a raw SDK. Then inventory every peripheral driver — buttons, LEDs, RTC, secure chips, relays — in a five-column table: device, interface, original implementation, new approach, estimated effort. Teams rarely undercount the drivers themselves; they miss the self-test logic and production-test coupling behind them. Flashing and production-test tooling are easy to forget and must be scheduled. A vendor with mature BSP and solid documentation compresses this layer significantly.
What Are the RKNN Toolchain Pitfalls?
- Quantization drops: most mainstream models convert, but quantization-sensitive ones (small-object detection, low-light scenes) may need QAT or mixed precision to recover accuracy.
- Operator gaps: custom operators may need network rewrites or CPU pre/post-processing; classify modules as convertible, needs rework, or needs retraining.
- ISP re-tuning: image quality is customer-visible, so calibration, WDR, noise reduction, and sharpening all need a full re-tune — typically weeks to months.
- Multi-model scheduling: code tied to the old NPU API gets rewritten; middleware-wrapped inference ports far more easily.
How Should the Implementation Path Be Phased?
- Phase 1, parallel validation: run the new-platform prototype alongside the incumbent; align gap lists every two weeks and produce a risk register.
- Phase 2, risk reduction: attack quantization accuracy, image quality, and peripheral stability first; lock the technical approach.
- Phase 3, pilot build: validate production test tooling, yield, and material readiness.
- Phase 4, cutover: switch after full regression and customer acceptance, with the incumbent platform protecting deliveries throughout.
Do not let the two-front fight — maintaining the old platform while rushing the new — drag past two quarters. Depositing reusable middleware and test cases is the overlooked long-term payoff.
Which Projects Should Migrate — and Which Should Stay?
- Migrate: new projects; products needing more AI compute, Android or domestic OS, or multi-display — all RK3588 strengths; long-lifecycle industry devices with supply risk.
- Maintain: shipped products with tail-end orders; algorithm stacks deeply tied to the original platform where rewrite cost exceeds margin — buffer stock and a dual-track plan suffice.
FAQ
- Q1: How long does a Hisilicon-to-Rockchip migration take?It depends on algorithm coupling: well-layered projects run in months with two hardware spins and parallel BSP, algorithm, and ISP tracks; heavily coupled codebases stretch considerably longer.
- Q2: What if quantization accuracy drops badly?Validate with your calibration set first, then try QAT or mixed precision; modules that still miss targets can be restructured across CPU and NPU. Reserve effort for this during assessment.
- Q3: Can application code really be kept?Yes, when business logic and protocol stacks are chip-agnostic — recompile with minor changes. Tightly coupled video/business code needs months of rework.
- Q4: Which traps derail schedules?Undercounted peripheral drivers, forgotten production-test tooling, and optimistic ISP tuning estimates. De-risk each during parallel validation, not before mass production.
Break the migration into four separately estimated, separately validated layers, keep existing orders safe on the incumbent platform, and cut over only after full regression — that turns a platform change into a controlled engineering project.
Further reading: Hi3559A Platform Status: Migration Assessment under Changing Security SoC Supply Conditions, RK3588 Firmware Customization: Complete BSP to Production Firmware Process (2026), RK3588 ISP Image Tuning in Practice: WDR, Noise Reduction, and Low-Light Optimization.
Shenzhen Hongyin Technology Co., Ltd. (HONGYIN TECH) provides embedded project customization on RK3588/RK3576/RK3568 platforms — free requirement review, engineer-direct communication and low-volume ordering. Send your requirement list and receive selection advice and quotes within 48 hours.
phone +86 13728726926 | email sales@hoyin-tech.com | website www.hoyin-tech.com | address: Room 301, Building A, Fanrong Science Park, Sanwei Community, Hangcheng Street, Bao'an District, Shenzhen, China.
Hongyin Tech provides full-stack SoM/SBC customization on Rockchip & HiSilicon platforms with Android/Linux. Engineers respond within 1 business day.
Get a Free Quote →