wifi/bt/gps modules not listed in MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS

[koenkooi]

I'm assuming they are enabled in the kernel build. The EULA has been accepted:

root@dragonboard-410c:~# opkg list_installed | grep dragon
firmware-qcom-dragonboard410c - 1.1.0-r0.0

And:

root@dragonboard-410c:~# opkg list_installed | grep kernel
kernel - 4.2-r0.1
kernel-4.2.0+yocto - 4.2-r0.1
kernel-image-4.2.0+yocto - 4.2-r0.1
kernel-module-configfs - 4.2-r0.1
kernel-module-g-ether - 4.2-r0.1
kernel-module-g-mass-storage - 4.2-r0.1
kernel-module-g-serial - 4.2-r0.1
kernel-module-libcomposite - 4.2-r0.1
kernel-module-u-ether - 4.2-r0.1
kernel-module-usb-f-mass-storage - 4.2-r0.1
kernel-module-usb-f-rndis - 4.2-r0.1
root@dragonboard-410c:~# 

[koenkooi]

Same issue for display and GPU modules

[lumag]

I'd say that depends on the list of modules that are considered essential. I think it might be a good idea to use packagegroups and then to make packagegroups be selected via this variable. This way we can push decisions to that packagegroup (think about kgsl&sde vs msm.ko, vidc vs iris / venus, etc).

[koenkooi]

After install all modules and launching weston, this is what I have running on rb3gen2:

root@qcs6490-rb3gen2-core-kit:~# cat /proc/modules | awk '{print " | " $1 " | " $4 " | " }'

Module	Dependencies
bluetooth	-
ecdh_generic	bluetooth,
ecc	ecdh_generic,
snd_soc_hdmi_codec	-
rpmsg_ctrl	-
fastrpc	-
qrtr_smd	-
rpmsg_char	rpmsg_ctrl,
venus_dec	-
venus_enc	-
videobuf2_dma_contig	venus_dec,venus_enc,
videobuf2_memops	videobuf2_dma_contig,
phy_qcom_edp	-
qcom_pd_mapper	-
nb7vpq904m	-
lontium_lt9611uxc	-
pmic_glink_altmode	-
ucsi_glink	-
qcom_battmgr	-
aux_hpd_bridge	pmic_glink_altmode,
typec_ucsi	ucsi_glink,
venus_core	venus_dec,venus_enc,
msm	-
v4l2_mem2mem	venus_dec,venus_enc,venus_core,
videobuf2_v4l2	venus_dec,venus_enc,v4l2_mem2mem,
ocmem	msm,
drm_exec	msm,
videodev	venus_dec,venus_enc,venus_core,v4l2_mem2mem,videobuf2_v4l2,
qcom_spmi_adc5	-
gpu_sched	msm,
videobuf2_common	venus_dec,venus_enc,videobuf2_dma_contig,videobuf2_memops,venus_core,v4l2_mem2mem,videobuf2_v4l2,
qcom_q6v5_pas	-
qcom_spmi_temp_alarm	-
qcom_vadc_common	qcom_spmi_adc5,
qcom_pil_info	qcom_q6v5_pas,
nvmem_qcom_spmi_sdam	-
qcom_pon	-
rtc_pm8xxx	-
drm_dp_aux_bus	msm,
drm_display_helper	msm,
qcom_stats	-
qcom_q6v5	qcom_q6v5_pas,
camcc_sc7280	-
mc	v4l2_mem2mem,videobuf2_v4l2,videodev,videobuf2_common,
videocc_sc7280	-
crct10dif_ce	-
drm_client_lib	msm,
coresight_stm	-
qcom_sysmon	qcom_q6v5_pas,qcom_q6v5,
phy_qcom_qmp_combo	-
dispcc_sc7280	-
i2c_qcom_geni	-
phy_qcom_snps_femto_v2	-
stm_core	coresight_stm,
llcc_qcom	msm,
coresight_tmc	-
coresight_replicator	-
coresight_funnel	-
aux_bridge	nb7vpq904m,phy_qcom_qmp_combo,
pinctrl_sc7280_lpass_lpi	-
qcom_common	qcom_q6v5_pas,
typec	nb7vpq904m,pmic_glink_altmode,ucsi_glink,typec_ucsi,phy_qcom_qmp_combo,
ath11k_ahb	-
qcom_glink_smem	qcom_common,
gpi	[permanent],
qrtr	qrtr_smd,
icc_bwmon	-
coresight	coresight_stm,coresight_tmc,coresight_replicator,coresight_funnel,
lpassaudiocc_sc7280	-
gpucc_sc7280	-
pinctrl_lpass_lpi	pinctrl_sc7280_lpass_lpi,
mdt_loader	venus_core,msm,qcom_q6v5_pas,
ath11k	ath11k_ahb,
qcrypto	-
authenc	qcrypto,
pmic_glink	pmic_glink_altmode,ucsi_glink,qcom_battmgr,
libdes	qcrypto,
mac80211	ath11k,
pdr_interface	pmic_glink,
libarc4	mac80211,
qcom_pdr_msg	qcom_pd_mapper,pdr_interface,
qcom_rng	-
icc_osm_l3	-
socinfo	-
qmi_helpers	qcom_pd_mapper,qcom_sysmon,ath11k,pdr_interface,qcom_pdr_msg,
nvmem_reboot_mode	-
display_connector	-
drm_kms_helper	msm,drm_display_helper,drm_client_lib,aux_bridge,display_connector,
cfg80211	ath11k,mac80211,
rfkill	bluetooth,cfg80211,
fuse	-
drm	lontium_lt9611uxc,aux_hpd_bridge,msm,drm_exec,gpu_sched,drm_display_helper,drm_client_lib,aux_bridge,display_connector,drm_kms_helper,
backlight	drm_display_helper,drm,
nfnetlink	-
ipv6	[permanent],

[koenkooi]

I'd say that depends on the list of modules that are considered essential. I think it might be a good idea to use packagegroups and then to make packagegroups be selected via this variable. This way we can push decisions to that packagegroup (think about kgsl&sde vs msm.ko, vidc vs iris / venus, etc).

In oe-core we already have MACHINE_ESSENTIAL_RDEPENDS, MACHINE_ESSENTIAL_RRECOMMENDS and MACHINE_EXTRA_RECOMMENDS to denote the degree of importance. Adding packagegroups in a BSP is a degree of abstraction too much, but is not mutually exclusive with what I'm proposing:

My current idea is to have something like this in each machine:

QCOM_VIDEO_MODULES = "venus-core"
QCOM_DRM_MODULES = "msm"
QCOM_MISC_HW = "pci-bridge-driver"

And in the shared .inc something like this:

MACHINE_ESSENTIAL_RDEPENDS = "${QCOM_MISC_HW}"
MACHINE_ESSENTIAL_RRECOMMENDS = "${QCOM_DRM_MODULES }"
MACHINE_EXTRA_RECOMMENDS = "${QCOM_VIDEO_MODULES}"

That would make anything (re)using bits from core-image- work a lot better out of the box.

[lumag]

With this approach we are encoding BSP details directly into machine config. How would you select between kgsl and msm drivers for the GPU? Or between venus and vidc(?) drivers for video encoders? Having that in packagegroups haves the same problem, but in a more traditional way: how to select dependent packages basing on 10 external conditions. And then those packagegroups can be added to MACHINE_ESSENTIAL/EXTRA_RDEPENDS/RRECOMMENDS.

[ricardosalveti]

At least for rb3gen2 the missing modules can all be listed via MACHINE_EXTRA_RECOMMENDS (following same behavior from other BSPs), as what is essential to boot is already part of the kernel.

Using package groups for modules is really not that common (in BSP layers), but can be done if we decide to facilitate not including certain modules as part of the build. Personally I would prefer us having the upstream modules in a common qcom MACHINE_EXTRA_RECOMMENDS definition and have a custom package-group / recipe for the downstream components, with the required denylist changes and so on, otherwise we might have to maintain a large set of possible options and combinations.

This would make the basic BSP experience from upstream be mostly functional and complete as the default behavior.

[ricardosalveti]

Quite often people just install kernel-modules directly (which is the default in most BSP layers), so having the downstream logic separated, with the required configuration to disable the upstream modules and so on, would probably work better.

[lumag]

The split between upstream/downstream modules sounds perfect to me.