The backports are installed like a package and are not kernel patches even though they create kernel modules. Our stock BSP still retains the original kernel modules as on option, but the default drivers are disabled.

Using the stock 2.4-4 BSP, you can re-create the series of packages you'll need.


./ltib -p backports -m prep

Creates the subfolder with the backports drivers.

./ltib -p crda -m prep

Creates the subfolder with the CRDA tool for changing regulatory domains

./ltib -p regulatorydb -m prep
Creates the regulatory database that CRDA uses which contains the FCC and IC information for the WiFi channels.

Does that help?

adam

Hi Adam,

> Does that help?

Partially.

I was looking for a simple ordered list of the patches, provided by BSP 2.4-4, to generate the supported Linux kernel. I did not know if the 'backports' are required or not. Apparently they are. It is different from 2.4-3 in this regard. One should be able to take this ordered list and the patches from your tar and create the correct supported kernel. It should be a relatively quick list to generate and not some huge work item. I can handle the patching and proper build, if I know the order and requirements.

I just want to apply the Open Source content, in the 'LPD-IP-package-pool' correctly, in the right order. 

I Hope that this better explains my request.

Derald,

When comparing the 2.4-3 and the 2.4-4 \config\platform\omap_logic\pkg_map file difference I see the following packages changed to support the -32 WIFI and the backports.

backports-4.0.1-1
crda-3.13
regulatorydb-2015.07.09
ti-utils-01
ti-utils-fw-01
lpd-ti-firmware-00

The config\platform\omap_logic\packages.lkc shows the dependency for the various different packages. Since the backports requires the kernel source I would recommend the following order:

kernel-3.0.101-01-dm37x-r38324.patch > backports-4.0.1-1.patch

With the 2.4-3 release there was a base and many additional kernel patches in numerical order following the base patch. In the 2.4-4 release all these patches were combined into a single patch (kernel-3.0.101-01-dm37x-r38324.patch).

Let me know if you need any additional information.

Thanks,
Brad

Hi Brad,

Thanks for the reply. Are the 'backports' required for the '-32' SOM to function properly?

Derald

Derald,

The DM37x T+W -32 SOMs does not require the use of the updated backports.  However, the default configuration setting in the DM37Linux 2.4-4 BSP is PKG_LINUX_BACKPORTS [=y].

The updated backports provides the following:
1. Dual role where WiFi AP + Station can be used simultaneously

2. Both 2.4GHz and 5GHz bands are available when used as an Access Point.

The updated Wireless backports now allows an access point to use 5.0 and 5.8GHz bands.
Channels 36, 40, 48 are available in the 5GHz band and 149, 153, 157, 161 and 165 are available 
in the 5.8GHz band. 
3. Setting the regulatory domains using the CRDA.  

Here are example commands for setting the regulatory domains. 

Select regulatory domain for United States
    DM-37x# iw reg set US
Select regulatory domain for Canada
    DM-37x# iw reg set CA

Regards,

Brad

 

Hi Brad,

Thanks again. This completes the information that we needed on this topic. We use a custom embedded Linux development and deployment environment. This type of information will ALWAYS be needed in our use case, especially with the very old Linux 3.0.y kernel and the WiFi/FCC regulatory dependencies.

 

Best regards,

Derald

 

The backported wireless driver is not finding the firmware files. I have applied the backports-4.0.1-1, from the BSP 2.4-4, to Linux 3.0.101. I built the backported wl12xx/wlcore into the kernel and get the following:

~ # ifup wlan0
[  257.040283] wlcore: ERROR NVS file is needed during boot
[  257.453094] wlcore: ERROR NVS file is needed during boot
[  257.859252] wlcore: ERROR NVS file is needed during boot
[  257.865722] wlcore: ERROR firmware boot failed despite 3 retries
ip: RTNETLINK answers: File exists
[  258.445190] wlcore: ERROR NVS file is needed during boot
[  258.843688] wlcore: ERROR NVS file is needed during boot
[  259.242004] wlcore: ERROR NVS file is needed during boot
[  259.248443] wlcore: ERROR firmware boot failed despite 3 retries
ip: SIOCSIFFLAGS: No such device
ip: RTNETLINK answers: Network is down

~ # ls -l /lib/firmware/ti-connectivity/
total 2204
-rw-r--r--    1 1000     1000        273252 Dec 21  2015 wl1271-fw-2.bin
-rw-r--r--    1 1000     1000        272784 Dec 21  2015 wl1271-fw-ap.bin
-rw-r--r--    1 1000     1000           912 Dec 21  2015 wl1271-nvs.bin
-rw-r-----    1 1000     1000        359140 Jan  8  2016 wl128x-fw-5-mr.bin
-rw-r-----    1 1000     1000        360452 Jan  8  2016 wl128x-fw-5-plt.bin
-rw-r-----    1 1000     1000        378988 Jan  8  2016 wl128x-fw-5-sr.bin
-rw-r--r--    1 1000     1000        265196 Dec 21  2015 wl128x-fw-ap.bin
-rw-r--r--    1 1000     1000        272748 Dec 21  2015 wl128x-fw.bin
-rw-r--r--    1 1000     1000          1113 Oct 22  2014 wl128x-nvs-tw30.bin
-rw-r--r--    1 1000     1000          1113 Oct 22  2014 wl128x-nvs-tw31.bin
-rw-r--r--    1 1000     1000          1113 May 13  2015 wl128x-nvs-tw32.bin
-rw-r--r--    1 1000     1000          1113 Dec 21  2015 wl128x-nvs.bin

 Has anyone seen something similar to this, with WiFi and BSP 2.4-4? The results are the same when built as modules also. There must be something that I have missed. Linux config and dmesg are attached.

linux-config.txt    3.0.101-dmesg.txt

When ltib builds the kernel, it extracts the backports and applies some patches to it. Are you applying the patches? There are 6 in total.

If you build the backports as their own package, the backports have a significant number of extra configs.

If you have our ltib environment, I would suggest building them separately without installing them, and comparing the contents of Kconfig as well as the .config files. I am not aware of anyone trying to merge the backports into the kernel, but I do understand the desire to do that as well.

#prep the backports (with patches)

./litb -p backports -m prep

# build the backports (and generate config file)
./ltib -p backports -m scbuild


Now you should have a patched set of driver files and there is a .config file that you'll need for making sure all the right flags are set.

I did a quick comparison and noticed a bunch were missing. I'll ask the developer who did the backport patches to see if he has ever compiled the backports into the kernel instead of a separate package. I haven't seen him in the last couple days, so it may take a bit for him to respond.

Let me know if that helps.

adam

Hi Adam,

I used the patches and firmware directly from BSP 2.4-4. I applied and verified them by hand. We want to use the FCC confirmed firmware as we do with BSP 2.4-3 currently. The backports is based at 4.0.1-1 plus LogicPD's wlcore patches. Compilation and printk verification show the the board file is detecting the right information.

Other than this WiFi issue, other things appear to load as before. We build our kernel with everything builtin, with the exception of the smsc911x ethernet driver. I will continue trying different configurations.

Thanks for the follow-up.

Derald

Now it appears to be working. (Without backports)

1. Removed backported wlcore from Linux configuration

2. Re-enabled LogicPD patched version of wl12xx from the standard tree

I will stop now while I am winning. More testing will be done next week. Linux config and dmesg is attached. Have a Great weekend.

3.0.101-dmesg-working.txt  linux-3.0.101-working-config.txt

If you want to use our older drivers, we have a defconfig setup to disable backports and enable the old ones built into the kernel instead.

use this defconfig when setting up ltib: config/platform/omap_logic/defconfig.wifi-original

If it's working,and you're ok with the older drivers then you can leave it alone.

There are a variety of reasons why you might want to use the backports though:

1. 5GHz Access Point (previously client only)
2. European Compliance
3. Multirole Capability

adam

It is working now with the 'backports' integrated in the Linux 3.0.101 kernel tree. The firmware load mechanism can not find its way to the actual firmware data when the backported 'wlcore' is compiled directly into the kernel. I re-enabled the 'backports-4.0.1' and compiled 'wlcore' and friends as modules from the source tree. I did have to change our '/etc/network/interfaces' in order to load the modules properly. The network interface 'wlan0' comes up and I can use 'hostapd' to start the AP. 

My next step is to get the LogicPD CRDA bin files to load properly from user space.

Files:

wifi-modules.txt

interfaces.txt

ifconfig-integration.txt

3.0.101-dmesg-integration.txt

linux-3.0.101-integration-config.txt