You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
hi3516cv200 (V2 generation) is the only platform where binary blobs call kernel APIs directly — all other platforms (V3/V3.5/V4) go through OSAL, which can be recompiled for any kernel version.
Currently CV200 is locked to kernel 4.9.37. Bumping beyond ~4.19 will break blob modules because removed kernel APIs (ioremap_nocache, do_gettimeofday, init_timer, set_fs, etc.) are called directly from the 18 blob .o files in kernel/obj/hi3516cv200/.
PR #45 landed the foundation — all open_ modules load and stream on real hi3518ev200 hardware. This issue tracks the next step: kernel version independence.
Proposed approach
Create a CV200 OSAL shim module (open_osal.ko) that exports old kernel API names, forwarding to current kernel implementations. This mirrors how V3/V4 OSAL works but targeted at the specific APIs the V2 blobs import.
The CV200 shim only needs to cover kernel APIs that the blobs actually call and that changed between 4.9 and the target kernel. It does NOT need the full OSAL abstraction layer.
Step 3: Incremental kernel testing
Target
Expected effort
4.19 LTS
Likely works with zero or minimal shims
5.4 LTS
access_ok, do_gettimeofday shims
5.10 LTS
Above + set_fs/get_fs (hardest)
5.15 LTS
Above + ioremap_nocache
6.1+ LTS
Above + proc_ops, strlcpy, sysctl changes
Known hard problems
set_fs()/get_fs() removal (5.10+): Blobs use these for kernel↔user copies. Restoring addr_limit in thread_info requires a kernel patch, not just a module shim. The V4 OSAL solved this by wrapping all user access behind osal_copy_from_user().
Struct layout changes: If blobs embed struct file_operations, struct timer_list, or struct proc_dir_entry by value, field offset changes will cause silent corruption. Each blob needs verification via objdump -d to check struct access patterns.
Problem
hi3516cv200 (V2 generation) is the only platform where binary blobs call kernel APIs directly — all other platforms (V3/V3.5/V4) go through OSAL, which can be recompiled for any kernel version.
Currently CV200 is locked to kernel 4.9.37. Bumping beyond ~4.19 will break blob modules because removed kernel APIs (
ioremap_nocache,do_gettimeofday,init_timer,set_fs, etc.) are called directly from the 18 blob.ofiles inkernel/obj/hi3516cv200/.PR #45 landed the foundation — all open_ modules load and stream on real hi3518ev200 hardware. This issue tracks the next step: kernel version independence.
Proposed approach
Create a CV200 OSAL shim module (
open_osal.ko) that exports old kernel API names, forwarding to current kernel implementations. This mirrors how V3/V4 OSAL works but targeted at the specific APIs the V2 blobs import.Step 1: Catalog blob dependencies
Categorize undefined symbols into:
__aeabi_*— stable)Step 2: Build shim module
Reuse patterns from existing OSAL implementations:
kernel/osal/hi3516cv500/— V3.5 OSAL (closest reference)kernel/osal/linux/kernel/— V4 shared OSALThe CV200 shim only needs to cover kernel APIs that the blobs actually call and that changed between 4.9 and the target kernel. It does NOT need the full OSAL abstraction layer.
Step 3: Incremental kernel testing
access_ok,do_gettimeofdayshimsset_fs/get_fs(hardest)ioremap_nocacheproc_ops,strlcpy, sysctl changesKnown hard problems
set_fs()/get_fs()removal (5.10+): Blobs use these for kernel↔user copies. Restoringaddr_limitinthread_inforequires a kernel patch, not just a module shim. The V4 OSAL solved this by wrapping all user access behindosal_copy_from_user().Struct layout changes: If blobs embed
struct file_operations,struct timer_list, orstruct proc_dir_entryby value, field offset changes will cause silent corruption. Each blob needs verification viaobjdump -dto check struct access patterns.References
kernel/compat/kernel_compat.h— existing compat shims for source modules (3.0–7.0)kernel/osal/hi3516cv500/— V3.5 OSAL reference implementation