Does hikey support insmod under init.rc?


I compile some ko files and try to load the ko via init.rc automatically, but the previous line already execute but the insmod sees skipped.

diff --git a/rootdir/init.rc b/rootdir/init.rc
index 636daea..a1a819f 100644
--- a/rootdir/init.rc
+++ b/rootdir/init.rc
@@ -397,6 +397,10 @@ on late-fs
     # HALs required before storage encryption can get unlocked (FBE/FDE)
     class_start early_hal
@@ -570,8 +574,11 @@ on post-fs-data
     mkdir /data/cache 0770 system cache
     mkdir /data/cache/recovery 0770 system cache
     mkdir /data/cache/backup_stage 0700 system system
-    mkdir /data/cache/backup 0700 system system
**+    mkdir /data/cache/backup 0700 root root**  //this part already execute by check the property. 
+    insmod /system/lib/modules/snd-soc-xxx-xx.ko  //not execute at below all
+    insmod /system/lib/modules/snd-soc-xxx-xx.ko
+    insmod /system/lib/modules/xxxxx-odsp-xx.ko
+    insmod /system/lib/modulesxxxxx-xx.ko

does hikey board have any limitation of the KO feature? I have not found any insmod example in the project.


Don’t think the vendor init process has permission to write to /system. Can you not build the modules as built-in instead of loadable?


Of course we could build the modules as built-in, but we also hope support the ko as loadable as needed.
As I know Qualcomm OpenQ board could load ko as init.rc but why hikey board could not do the same thing? any special setting on Hikey board?


What the aosp version on both boards?


Hikey use the Android 10.0, kernel 4.9 while OpenQ using Android 8.0 and kernel 4.9


Actually can you first try placing your .ko files under /vendor/lib/modules and see if it works from there?


I asked an engineer from our aosp team and the proper way to do it is to copy the module to somewhere in device/linaro/hikey and use BOARD_VENDOR_KERNEL_MODULES. See [1][2] for references. The module will be included in vendor.img and should be loaded automatically on boot. If not, see [3].



Thanks for help. I will try to access these google website later(we blocked as you know).
So the Hikey platform should support the load the ko in boot phase , just need keep the method correct ,right ?


You’re welcome. Right. Project Treble compliance is mandatory from Android 9 onwards, which is most probably why the method used on the OpenQ board isn’t allowed anymore. If you use Android 8 on hikey, the method might still work, and if you use Android 10 on OpenQ, you’ll probably see it fail the way it’s failing on hikey now.

Anyway, [1] is just

	device/ti/beagle_x15-kernel/$(TARGET_KERNEL_USE)/pvrsrvkm.ko` in ``.

[3] is mainly

on early-init
    exec u:r:modprobe:s0 -- /vendor/bin/modprobe -a -d \
        /vendor/lib/modules module_a module_b module_c ...


Correction: Actually Project Treble is mandatory from Android 8 onwards, so then maybe check the Android 8 source for the OpenQ board to see if it’s fully compliant.


Actually, it has to do with whether or not a device launched with Android 8 or higher. And I suppose in this context, it really means whether the first of google’s compliance tests it passed officially involved that version or higher.

In other words, if a device had ever passed a compliance test for android 7 and was declared for commercial launch, then it would be free to remain treble-free indefinitely.

Now on the other hand, these boards are different. There is no google compliance testing involved. That means that you’re free to do what you want with them.

Likely, the only thing needed in order to make this work, is to unset the variable “PRODUCT_FULL_TREBLE_OVERRIDE” in
*** HOWEVER, there really doesn’t seem to be any reason to resort to that for this objective.

Why not build the drivers into the kernel instead of building them as modules? Its generally preferred (on Android) not to use modules.


I tried to modify the b/hikey960/ on the hikey platform as below:

+++ b/hikey960/
@@ -45,3 +45,10 @@ BOARD_VENDORIMAGE_PARTITION_SIZE := 822083584     # 784MB
+vendor_hikey_dir := :device/linaro/hikey/vendor/lib/modules
+         $(vendor_hikey_dir)/snd-soc-xxx-1.ko \
+         $(vendor_hikey_dir)/snd-soc-xxx-2.ko \
+         $(vendor_hikey_dir)/iaxxx-xxx-3.ko \
+         $(vendor_hikey_dir)/iaxxx-xxx-1.ko

inf fact firstly I already move my 4 ko files at the device/linaro/hikey/vendor/lib/modules folder. but after compile again, I found these 4 ko files have not been installed into the out/target/product/hikey960/vendor/lib/modules.
That means the macro BOARD_RECOVERY_KERNEL_MODULES does not support on the hikey board.
I still suspect whether hikey board support the module load mechanism on this platform.


and then I just modify the a makefile and install my ko to /vendor/lib/modules directly.

hikey960:/vendor/lib/modules # ls
xxx.ko        snd-soc-xxx.ko
iaxxx-oxxx2.ko snd-xxx3.ko

from shell command, we could find the ko already installed on the folder.
while I also update the init.rc as below to load the ko automatically:

diff --git a/rootdir/init.rc b/rootdir/init.rc
index 636daea..8037a6f 100644
--- a/rootdir/init.rc
+++ b/rootdir/init.rc
@@ -41,7 +41,8 @@ on early-init
     mkdir /dev/memcg/system 0550 system system

     start ueventd
+    exec u:r:modprobe:s0 -- /vendor/bin/modprobe -a -d \
+        /vendor/lib/modules  xxx.ko xxx2.ko xxx3.ko xxx4.ko
 on init
     sysclktz 0

but these scripts also have not execute success by check by lsmod command on shell:

Z:\hikey-xxxx-0507>adb shell
hikey960:/ # lsmod
Module                  Size  Used by