Does hikey support insmod under init.rc?

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

@doitright Thanks for the detailed explanation! Appreciate your insights as usual.

@yinjun2014 For future references, please enclose code/logs/outputs in your post with 3 backticks. Otherwise it’s impossible to read. See for references.

vendor_hikey_dir := :device/linaro/hikey/vendor/lib/modules

You have an extra colon “:” in front of device/linaro/hikey/vendor/lib/modules?



diff --git a/rootdir/init.rc b/rootdir/init.rc

What/where is rootdir? Please try it on /vendor/etc/init/init.hikey960.rc if BOARD_VENDOR_KERNEL_MODULES doesn’t work.

Hi vchong,
I found the modprobe was denied by selinux when boot. do you have any sample to show how to fix these error on hikey board?

Forked subcontext for 'u:r:vendor_init:s0' with pid 1581
e[32m[    8.274413] e[33minite[0m: Forked subcontext for 'u:r:vendor_init:s0' with pid 1582
e[32m[    8.281532] e[33minite[0m: Parsing file /init.rc...
e[32m[    8.318859] e[33maudite[0m: type=1400 audit(14.243:5): avc:  denied  { entrypoint } for  pid=1584 comm="init" path="/vendor/bin/toybox_vendor" dev="sdd11" ino=117 scontext=u:r:modprobe:s0 tcontext=u:object_r:vendor_toolbox_exec:s0 tclass=file permissive=0
e[32m[    8.384273] e[33mueventde[0m: ueventd started!
e[32m[    8.390572] e[33mselinuxe[0m: SELinux: Loaded file_contexts\x0a
e[32m[    8.397350] e[33mueventde[0m: Parsing file /ueventd.rc...
e[32m[    8.403290] e[33mueventde[0m: Parsing file /vendor/ueventd.rc...

avc: denied { entrypoint } for pid=1584 comm=“init” path="/vendor/bin/toybox_vendor" dev=“sdd11” ino=117 scontext=u:r:modprobe:s0 tcontext=u:object_r:vendor_toolbox_exec:s0 tclass=file permissive=0

If your objective is just to allow that, then you’ll need to add an allow rule something like this;

allow modprobe vendor_toolbox_exec:file { entrypoint };

Look in your “avc: denied” line and you can see where all the parts of that come from.
Also note that once it gets past that denial, there will probably be some additional surprises waiting for you. My suggestion would be to set your selinux permissive first, then collect all of the errors printed by selinux, write up a policy, and try that.

Also be aware that very often when you are trying to fight the platform in this way, you will come up against “neverallow” rules. If this happens, you have two choices; either continue down the path of hacking the selinux policy (by modifying the system policy in system/sepolicy/) or try to accomplish your objective in a better way, like building your driver into the kernel instead of loading it as a module, or following any of the other solutions that you’ve been guided towards in this thread.

in fact I already add a modprobe.te under device/linaro/hikey/sepolicy:

allow modprobe { vendor_file }:system module_load;
allow modprobe vendor_toolbox_exec:file { entrypoint };

in fact I also follow below links to add some policy under /system/sepolicy:!/!/!/ 

after add above all modifications, I tried to compile but get follow error message:

/bin/bash -c "(rm -f out/target/product/hikey960/obj/ETC/sepolicy_neverallows_intermediates/sepolicy_neverallows ) && (ASAN_OPTIONS=detect_leaks=0 out/host/linux-x86/bin/checkpolicy -M -c 30 -o out/target/product/hikey960/obj/ETC/sepolicy_neverallows_intermediates/sepolicy_neverallows out/target/product/hikey960/obj/ETC/sepolicy_neverallows_intermediates/policy.conf )"

libsepol.report_failure: neverallow on line 1090 of system/sepolicy/public/domain.te (or line 12528 of policy.conf) violated by allow modprobe vendor_toolbox_exec:file { read getattr map execute entrypoint open };

libsepol.report_failure: neverallow on line 1061 of system/sepolicy/public/domain.te (or line 12450 of policy.conf) violated by allow modprobe vendor_toolbox_exec:file { execute };

libsepol.check_assertions: 2 neverallow failures occurred

This means currently Hikey have .limitation of the modprobe in neverallow part in dowmain.te:
I past the part the line 1090 and Line 1061 part of the domain.te:

  # Do not allow system components access to /vendor files except for the
  # ones whitelisted here.
  neverallow {
    # TODO(b/37168747): clean up fwk access to /vendor
    -init # starts vendor executables
    -kernel # loads /vendor/firmware
    -ueventd # reads /vendor/ueventd.rc
  } {
  }:file *;

does this mean the Hikey board forbidden this modprobe operation for some special reason ?
Or how to fix this conflict error?

I think I know what your problem is.

You’re trying to run your modprobe from the ROOT init.rc, which is starting from the ‘init’ context. You need to end up with the vendor_modprobe context, but you can’t get there from init. You need to start by going into the vendor_init context, which is easily done just by moving your modprobe line OUT of the root init.rc and into a VENDOR init.

Thank you. I will feedback you whenever I have update.

I searched the whole codebase and try to find the suitable vendor_init , but no found, it even have no vendor folder under the project root. But while I searched another Qualcomm platform , when I search by find . -name *.rc| grep vendor , it will listed so many init scripts like below:


So I still suspect why Hikey have no vendor folder and may have any trick inside.

also I use audit2allow to generate the policy automatically as below:

adb pull /sys/fs/selinux/policy 
cyin@kesh-hs-lws01:/work/hikey-xx-0507/external/selinux/prebuilts/bin$ cat avc.log | audit2allow -p policy

#============= modprobe ==============
allow modprobe vendor_toolbox_exec:file entrypoint;

I checked above line already added in my /device/linaro/sepolicy/modprobe.te. So this should have other issue.

Stop screwing around with selinux policy. Re-read my previous response and follow my instructions.

Thanks, I know you mean I need put the modprobe xxx.ko related on some vendor scripts, but in fact I could not find the vendor scripts on the Hikey platform, because Hikey platform even have no vendor folder under the project root /. But Qualcomm platform have vendor related init scripts.
So that’s why have not follow the instructions.
Sorry for confuse you.

@yinjun2014 Please see again previous reply (number 14) above. You might have missed it.

Again, for future references, please enclose code/logs/outputs in your post with 3 backticks. Otherwise it’s hard to read your logs. See for references.

Also as mentioned above, vendor init is device/linaro/hikey/init.common.rc in your source tree, or /vendor/etc/init/init.hikey960.rc. Try putting your modprobe there, but it should have already been loaded automatically by just using BOARD_VENDOR_KERNEL_MODULES, without having to change init rc files. One of our engineers did it.

In fact currently I already put the modprobe in the device/linaro/hikey/init.common.rc.

xx/device/linaro/hikey$ git diff  init.common.rc
diff --git a/init.common.rc b/init.common.rc
old mode 100644
new mode 100755
index 6d66ca7..465d150
--- a/init.common.rc
+++ b/init.common.rc
@@ -25,7 +25,8 @@ on init
     mkdir /dev/socket/pdx/system/vr/sensors 0775 system system

     start watchdogd
+    exec u:r:modprobe:s0 -- /vendor/bin/modprobe -a -d \
+        /vendor/lib/modules snd-soc-xxx- ...
 on fs

/device$ grep "BOARD_VENDOR_KERNEL_MODULES" -r .

also on the device folder, I searched the macro BOARD_VENDOR_KERNEL_MODULES, only google related folder used this macro, not found under hikey folder.
Below is all the output

./google/crosshatch/ += \
./google/crosshatch/ += \
./google/crosshatch/ += \
./google/crosshatch/ += \
./google/crosshatch/ += \
./google/crosshatch/ += \
./google/crosshatch/ += \
./google/crosshatch/ += \
./google/taimen/ += \
./google/taimen/ += \
./google/taimen/ += \
./google/taimen/ += \
./google/taimen/ += \
./google/taimen/ += \
./google/taimen/ += \
./google/taimen/ += \
./google/muskie/ += \
./google/muskie/ += \
./google/muskie/ += \
./google/muskie/ += \
./google/muskie/ += \
./google/muskie/ += \
./google/muskie/ += \
./google/muskie/ += \

do you mean your engineer use modprobe success on the hikey platform? which android version ? 8.0 or 10.0?