This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC33XX-SOFTWARE: CC33XX

Part Number: CC33XX-SOFTWARE

Tool/software:

Hello,

I'm in the process of integrating the latest CC33XX-LINUX-MPU into our Yocto Scarthgap build but have encountered some issues.

The 1.0.0.4 release loads fine, and I can start the AP and STA modes fine and Bluetooth work via SDIO.

Both 1.0.0.6 and 1.0.0.8 releases crash at boot, despite using the same device tree and Kconfig settings.

Could you confirm whether the CC33XX driver is officially qualified for use with the Linux 6.6 LTS kernel and if it is regularly tested with this version? The release notes suggest that the driver is validated only for Kernel 6.1—is this still the case?

[ 6.654413] wlcore: cc33xx_probe :: Start
[ 6.654500] ------------[ cut here ]------------
[ 6.654504] WARNING: CPU: 0 PID: 301 at /net/mac80211/main.c:630 ieee80211_alloc_hw_nm+0xa4/0x600 [mac80211]
[ 6.654770] Modules linked in: cc33xx(+) mac80211 fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc cfg80211 crypto_engine authenc libdes btti_sdio btti crct10dif_ce polyval_ce polyval_generic cc33xx_sdio goodix_ts at24 >
[ 6.654840] CPU: 0 PID: 301 Comm: (udev-worker) Not tainted 6.6.23-lts-next-g239ba86eceba-dirty #1
[ 6.654847] Hardware name: Testo EBP001 (DT)
[ 6.654850] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 6.654856] pc : ieee80211_alloc_hw_nm+0xa4/0x600 [mac80211]
[ 6.655040] lr : wlcore_alloc_hw+0x38/0x488 [cc33xx]
[ 6.655104] sp : ffff800081bbb7e0
[ 6.655107] x29: ffff800081bbb7e0 x28: ffffaf9a5e4f201c x27: 0000000000000000
[ 6.655116] x26: ffff800081bbbbb0 x25: ffff5a664d8f6a28 x24: 0000000000000034
[ 6.655124] x23: ffffaf9a85f912c8 x22: 0000000000008000 x21: ffffaf9a5e4e3000
[ 6.655132] x20: ffff5a664c6e7400 x19: 0000000000000000 x18: 0000000000000000
[ 6.655140] x17: 0000000000000100 x16: ffffaf9a83521c30 x15: ffffaf9a834ce7e8
[ 6.655148] x14: ffffaf9a834ce8f0 x13: 7472617453203a3a x12: 2065626f72705f78
[ 6.655157] x11: fffffffffffe0000 x10: 0000000007b3db20 x9 : ffffaf9a5e4ca448
[ 6.655165] x8 : ffff800081bbb860 x7 : 705f787833336363 x6 : 0000000000000000
[ 6.655172] x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffffaf9a5e4c5c58
[ 6.655180] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000001e68
[ 6.655189] Call trace:
[ 6.655192] ieee80211_alloc_hw_nm+0xa4/0x600 [mac80211]
[ 6.655383] wlcore_alloc_hw+0x38/0x488 [cc33xx]
[ 6.655438] cc33xx_probe+0xac/0xf8 [cc33xx]
[ 6.655484] platform_probe+0x70/0xd8
[ 6.655495] really_probe+0x150/0x2c0
[ 6.655501] __driver_probe_device+0x80/0x140
[ 6.655507] driver_probe_device+0xe0/0x170
[ 6.655513] __driver_attach+0x98/0x1b0
[ 6.655518] bus_for_each_dev+0x84/0xf0
[ 6.655526] driver_attach+0x2c/0x40
[ 6.655531] bus_add_driver+0xf0/0x208
[ 6.655536] driver_register+0x64/0x138
[ 6.655541] __platform_driver_register+0x30/0x48
[ 6.655547] cc33xx_driver_init+0x2c/0xff8 [cc33xx]
[ 6.655593] do_one_initcall+0x60/0x2c0
[ 6.655601] do_init_module+0x60/0x210
[ 6.655607] load_module+0x1eb0/0x1fa0
[ 6.655613] init_module_from_file+0x90/0xe0
[ 6.655619] __arm64_sys_finit_module+0x1e4/0x2f8
[ 6.655624] invoke_syscall+0x50/0x120
[ 6.655633] el0_svc_common.constprop.0+0xc8/0xf0
[ 6.655640] do_el0_svc+0x24/0x38
[ 6.655647] el0_svc+0x40/0xe8
[ 6.655654] el0t_64_sync_handler+0x120/0x130
[ 6.655659] el0t_64_sync+0x190/0x198
[ 6.655665] ---[ end trace 0000000000000000 ]---
[ 6.655672] wlcore: ERROR could not alloc ieee80211_hw
[ 6.655675] wlcore: ERROR can't allocate hw
[ 6.655678] cc33xx_driver: probe of cc33xx.2.auto failed with error -12

  • Hi Mohamed,

    Could you confirm whether the CC33XX driver is officially qualified for use with the Linux 6.6 LTS kernel and if it is regularly tested with this version? The release notes suggest that the driver is validated only for Kernel 6.1—is this still the case?

    The CC33xx SDK as is only supports kernel 6.1. However, we do have a GitHub repository where customers can first apply the same patch that's within the CC33xx SDK, and then apply a "porting" patch. You can find this GitHub repository here: https://github.com/TexasInstruments-Sandbox/cc33xx-linux-mpu-ports/ 

    Just a few days I opened a PR for kernel 6.6: https://github.com/TexasInstruments-Sandbox/cc33xx-linux-mpu-ports/pull/7 So this will be reviewed and accepted soon. 

    If you would like to get started immediately, then you can apply the following change within the driver to get it working as I believe this is your issue:

    diff --git a/drivers/net/wireless/ti/cc33xx/main.c b/drivers/net/wireless/ti/cc33xx/main.c
    index 66fc129f5578..5a6b289f08f7 100644
    --- a/drivers/net/wireless/ti/cc33xx/main.c
    +++ b/drivers/net/wireless/ti/cc33xx/main.c
    @@ -5136,6 +5136,7 @@ static const struct ieee80211_ops cc33xx_ops = {
            .prepare_multicast = cc33xx_op_prepare_multicast,
            .configure_filter = cc33xx_op_configure_filter,
            .tx = cc33xx_op_tx,
    +       .wake_tx_queue = ieee80211_handle_wake_tx_queue,
            .set_key = cc33xx_op_set_key,
            .hw_scan = cc33xx_op_hw_scan,
            .cancel_hw_scan = cc33xx_op_cancel_hw_scan,
    @@ -5212,6 +5213,7 @@ static const struct ieee80211_ops cc33xx_ops = {
            .prepare_multicast = cc33xx_op_prepare_multicast,
            .configure_filter = cc33xx_op_configure_filter,
            .tx = cc33xx_op_tx,
    +       .wake_tx_queue = ieee80211_handle_wake_tx_queue,
            .set_key = cc33xx_op_set_key,
            .hw_scan = cc33xx_op_hw_scan,
            .cancel_hw_scan = cc33xx_op_cancel_hw_scan,
    

  • Hi Sabeeh,

    Thanks for your time. The issue was solved after applying the latest patch "0001-drivers-cc33xx-forward-port-cc33xx-1.0.0.8-SDK-drive.patch".