Android GKI Kernel in Android 14.0.0_2.2.0

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Android GKI Kernel in Android 14.0.0_2.2.0

4,251 Views
OliW
Contributor III

In i.MX release Android-14.0.0_2.2.0 symbol checking in kernel has been activated in i.MX kernel and user has to fiddle with symbol lists of GKI.

I noticed, that even if you use non GKI boot.img the system will include the system_dlkm partition because it is defined in device/nxp/imx8m/BoardConfigCommon.mk to include all modules stored under vendorr/nxp-opensource/imx-gki/system_dlkm_staging/flatten/lib/modules.

If you now build the system with some additional driver added to the i.MX kernel included in AOSP tree the built modules will go to vendor_dlkm as given in "BOARD_VENDOR_KERNEL_MODULES" variable. I think this mixture of GKI and vendor modules is intentional.

Now the following problems and questions:

- We have a vendor module which needs a symbol (e.g. ptp_find_pin) normally exported by ptp.ko which is now a GKI module. But the symbol is not exported by this module because no other module of the GKI build uses it and GKI kernel is build with "CONFIG_TRIM_UNUSED_KSYMS". With this option all unused symbols are removed from the export symbol list of the ptp.ko module. How is the proper solution for this? Just removing this particuklar module from the GKI list and use the one from the i.MX kernel build inside AOSP? But this might break loading other GKI modules depending on this module (e.g. ptp_kvm.ko which is als GKI). Then we have to move all the dependend modules also. This is hard to maintain.

- When you decide to use i.MX kernel included in AOSP and not use GKI should we disable GKI (or to say system_dlkm partition) at all that no components of GKI are used in our system?

- In Android 14.0.0_2.2.0 precompiled GKI seems to be the "android15-6.6-2024-08_r7" release which is based on Kernel 6.6.30. But the included i.MX kernel in AOSP source is 6.6.36. For example when loading the "hid_uclogic_test" GKI module, the error "hid_uclogic_test: disagrees about version of symbol hid_is_usb" pops up when using the i.MX kernel and not the GKI. Is this an error in the A14_2.2.0 distrubtion that GKI and i.MX kernel version do not fit together?

 

0 Kudos
Reply
9 Replies

3,881 Views
navya_dixit
Contributor V

Hello NXP,

Even we are experiencing the same issues with our modules, and our module is an audio module (sgtl5000.ko).

Irrespctive of with which module we are experiencing issue, I think the basic issue is with GKI build.

We are also waiting for your valuable input.

Attached is the error message just for reference.

 

0 Kudos
Reply

3,430 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi @navya_dixit :

 

Please refer to the workaround in the above post.  

 

Regards

Daniel

0 Kudos
Reply

4,159 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi @OliW :

 

Could you please let me know the detail steps about how to reproduce your issue on my side?

which ko showe error?   which ko calls ptp_fin_pin?   

 

Regards

Daniel

0 Kudos
Reply

4,149 Views
OliW
Contributor III

Hi @danielchen ,

we have a custom hardware and have to integrate some additional drivers as modules. Up to now we build these own modules inside the i.MX kernel which is build in the normal AOSP build process. We do no use a seperate GKI build setup (kleaf) to build our own kernel modules in the GKI environment.

We do also not use the GKI boot.img. We use the one with our own build i.MX kernel inside. But the GKI modules are used from system_dlkm because they are added as default for all i.MX 8 Mini devices.

E.G. we use an intel ethernet chip attached to the PCIe of the i.MX8 Mini. This ethernet chip needs the igc driver (CONFIG_IGC=m).

The igc.ko module is build together with the i.MX kernel and goes to vendor_dlkm but cannot be loaded because it needs the symbol ptp_find_pin which should come out of the ptp.ko module which is now grabbed from the prebuilt GKI modules which are available in system_dlkm. And in this prebuilt ptp.ko module the symbol is not eyported.

To reproduce you can add the CONFIG_IGC=m option to i.MX kernel build and try to load the igc.ko module. It will produce the error of the undefined symbol.

0 Kudos
Reply

3,859 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi @OliW :

 

For the "igc.ko",   we need to rebuild the GKI image.   The rebuild boot.img can insmod igc.ko.

The following is my steps to insmod igc.ko on evk_8mp Android 14.0.0_2.2.0 based on UG.

# repo init -u https://android.googlesource.com/kernel/manifest -b common-android15-6.6
# repo sync
# cd common
# git checkout -b android15-6.6-2024-08_r7 android15-6.6-2024-08_r7
# git apply <all device patches if needed>
# add "CONFIG_IGC=m" in arch/arm64/configs/imx8mp_gki.fragment
# add "drivers/net/ethernet/intel/igc/igc.ko" in _IMX_IN_TREE_MODULES of imx.bzl 
# cp /tmp/abi_gki_aarch64_imx android/abi_gki_aarch64_imx
# delete "devm_otg_ulpi_create" "pwm_apply_might_sleep" "TKT340553_SW_WORKAROUND" "ulpi_viewport_access_ops" in android/abi_gki_aarch64_imx
# tools/bazel run //common:kernel_aarch64_abi_update_symbol_list
# tools/bazel run //common:kernel_aarch64_abi_update_protected_exports
# tools/bazel run //common:kernel_aarch64_abi_update

 

Then you can get boot.img and system_dlkm.

 

Regards

Daniel

0 Kudos
Reply

3,828 Views
OliW
Contributor III

Hi @danielchen ,

so you use an own build GKI kernel (build inside kleaf environment) with all custom modules included at build time to solve this probem.

For me it comes more and more to the point how you (or NXP) plan to go on with the i.MX Android distribution regarding the kernel build.

What will be the prefered or better maintained kernel for an i.MX Android build for our custom hardware?

Can we go on using the in AOSP source included i.MX kernel or do we have to switch to the official Google common kernel because latest i.MX support is done there?

I think this actual mixture, that you distribute a prebuilt and signed GKI boot.img and modules and customers build it's own modules using the i.MX kernel included in AOSP is not a good solution. Not only because their kernel version differs in A14 2.2.0.

If GKI is the prefered way, it should be mentioned clearly in the User Guide that kernel and all modules now need to be build using the kleaf environment. Else customer always has to fight against unresolved or protected symbols. And it must be clear that this leads to an unsigned unofficial GKI build.

If i.MX kernel is still the prefered way than don't make precompiled GKI components as standard for all builds and define a clean makefile variable to disable all prebuilt GKI components at all and add proper documentation helping the customer to decide what kind of kernel build he should prefer.

Regards

Oliver

0 Kudos
Reply

3,429 Views
danielchen
NXP TechSupport
NXP TechSupport

The latest branch android15-6.6 included the symbol ptp_find_pin.

0 Kudos
Reply

3,432 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi @OliW 

Devices that launch with the Android14 platform release using kernel version v5.15 or higher are required to ship with the GKI kernel.  So the preferred way is to use GKI. we will update the User guider.

We can check whether the latest branch (android 15-6.6) included the symbol you require or not.  If included, download the latest google release.   then refer to "How to update GKI image" in the user guider.

If the symbol you require is not included, you need to export symbol based on the latest branch.

 

Regards

Daniel

 

 

0 Kudos
Reply

4,124 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi @OliW 

I reproduced this issue on my side, it is under analyzing now.   I will get it back to you once I have any results.

danielchen_0-1739437919292.png

 

Regards

Daniel

0 Kudos
Reply