[ARM: OMAP2+: Warn about deprecated legacy booting mode]

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4b91f7f3c8b20e073b7bfc098625b37f99789508

[Linux 3.18-rc4 Announcement]

https://lwn.net/Articles/619669/

I have done some checking and I don't believe anyone here is currently working on device tree support at this time. If there is some task with which you need help, I would suggest you setup a services contract. Our engineers would be glad to assist you in any way needed.

http://www.logicpd.com/se...oftware-engineering/

A services contract is not needed, at this time. The greater Linux community has moved down a different, maybe better, hardware description path. Non-DeviceTree ARM OMAP boards have now officially been flagged for deprecation. The Linux kernel community documentation should lead us down a reasonable path. The OMAP3 BeagleBoard and AM3517-EVM already work with DeviceTree on stock Linux kernels. Thanks for doing the internal inquiry with your development team.

[References]
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/arm/omap/omap.txt
- http://devicetree.org/Device_Tree_Usage
- http://omappedia.org/wiki/Device_Tree
-

Logic PD sent a Torpedo kit to one of the Open Source developers. He has added device tree support for our board into the mainline kernel as of 4.2. It's in Kernel 4.2 RC1.

From here, you can see the Torpedo has been added.
http://www.phoronix.com/s...inux-4.2-ARM-Support

His code changes have not gone through any Logic PD quality checks but I know the developer was interacting with a software developer from Logic PD to help him along.

When I have some time, I'll do some preliminary checks.

adam

Great News! Keep us updated on the progress. It could be a game changer many companies integrating your SOM(s).

Device Tree:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts?id=refs/tags/v4.2-rc1

Notes:
- [U-Boot] Will need to be updated to a current version for proper Device-Tree loading support (ATAGS / ID Chip)
- [kernel] ATAGS / ID Chip / SOM Product ID infrastructure will need refactoring (Separate Device Driver to provide SysFS information?)
- [kernel] Add all the proper power supply settings as annotated regulator nodes
- [WiFi] wl1283 drivers will need refactoring (Remove the need to know about Product ID)
- [WiFi] Regulatory DB will need refactoring (Should match current kernel loading practices from user space)
- There are some examples of other board(s) that are similar (i.e. SBC-T3730, CM-T3730, TMDSEVM3730)

If you can generically handle the Product ID infrastructure, this board will probably remain well supported for a long time. The chances of being deprecated would be lowered. Which is where the product was previously queued by kernel developers.

This bootloader and kernel effort would be a HUGE win for your product(s). It may even provide better pathways to adoption and design inclusion.

I thought I'd give you another update on the device tree status.

Linux 4.2-RC8 was pushed yesterday and there is a DTS and DSTI file in cluded.

I have some proposed changes I am making to the DTS file that is part of Linux 4.2, but I am guessing it won't be accepted for a bit, however I will eventually post the patches on our support site.

Display 15 (Display 28 support coming soon)
Frame buffer Support
DSS
OpenFB (df_andi, df_knuckles, etc. all seems to work like they do for our stock BSP)
Backlight (on/off with PWM dimming support to come)

Audio (although not really tested as it seems to be suck in mute)
Mcbsp interface (I think I need to add pin-out info yet, but I am not sure. I haven’t tested it)
Twl4030-audio
Sound Card (as identified by aplay –l as “omap3logic”)

Kim
Shared Transport
Bluetooth (however the BTS file I have is too old, so it doesn’t fully work, so I'm investigating that)

I haven't yet looked at the board examples you gave me, but I will do that to see how we can integrate the Product ID info to get the proper max system speed and Mac Address for the Wireless chip. I am still learning the device tree system, but I've been told that U-boot can modify and pass the device tree to the kernel, so once learn how to do that, I was hoping we might have a method of passing the MAC address to the driver and specifying which NVS file is appropriate.

adam

I found instructions for running calibration and setting the mac address here for a different board. I was going to adapt it to work with the T+W board as a work around for now. I have to match up the pin-outs to from the armadeus board to their corresponding T+W pins.

http://www.armadeus.com/w...?title=Wl12xx_driver


adam

The armadeus instructions look reasonable and they use the standard linux firmware path for TI Connectivity. Updating firmware should be much improved with the newer kernel infrastructure. I would be willing to test the patches when you are ready.

For anyone who is following this thread, initial Device Tree support was added in Kernel 4.2. This provided a basic starting ground. Subsequent updates have been pushed which should be included with Kernel 4.5. None of it has been tested via Logic PD's SQA, but it has been tested in the open source community, but like anything it's in a constant state of change.

As of right now, we have the following:

WiFi (using open source power levels, not using FCC approved Power levels)
Bluetooth (via pdata-quirks and not fully through device tree) (using open source power levels, not using FCC approved Power levels)
LCD Type 15 (older LCD which requires small source patch)
GPIO Based Backlight (instead of PWM) (PWM will eventually be added)
TSC2004 Touch Screen
SD Card
USB OTG via PMIC (not a lot of testing done)
Audio (via PMIC) (the default is muted, but it can be unmuted to work)

To Do:
LCD Backlight PWM
LCD Type 28
Detection of 1GHz processors (1GHZ is available by manually updating DTS file)
ISP1763A USB Controller (this requires a lot of rework to make support Device Tree)
Gas Gauge on Dev-Kit
OMAP3-ISP (Video camera)

Updated RootFS to handle updated kernel features

What Probably Won't work:
GPS (there is no open source driver)

The pending changes are in the upcoming 4.5 Kernel, but they can be found:

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/

Hi Adam,

I'm having troubles with booting WiFi on Linux 4.2.6 that I build using Buildroot and your configs and devicetree.
I load modules
#modprobe wlcore_sdio
#modprobe wl12xx
wlcore: loaded

#lsmod
Module Size Used by Not tainted
arc4 1675 2
wl12xx 47036 0
wlcore 149876 1 wl12xx
mac80211 294776 2 wl12xx,wlcore
cfg80211 177722 2 wlcore,mac80211
wlcore_sdio 5704 0
ipv6 269994 12 [permanent]

But when I try to bring up interface
#ifconfig wlan0 up

Following errors are shown.
[ 1094.851776] wlcore: ERROR nvs size is not as expected 2: 912 != 1113
[ 1095.234863] wlcore: ERROR NVS file is needed during boot
[ 1095.628234] wlcore: ERROR NVS file is needed during boot
[ 1095.636932] wlcore: ERROR firmware boot failed despite 3 retries
ifconfig: SIOCSIFFLAGS: No such device

It seems that wlcore tries to load wl127x-nvs.bin instead of wl128x-nvs.bin, as it says in this post here
http://lists.infradead.or...2015-May/340371.html

Both (wl128x-nvs.bin and wl127x-nvs.bin) are located in /lib/firmware/ti-connectivity/.
wl128x-nvs.bin is 912bytes and wl127x-nvs.bin is 1.1Kbytes.

How do you enabled and tested WiFi in these newer kernels?

I'm using -30 and -31 Torpedo versions, but as I understand same chip WL1283 is used also on the newest -32 version.

Regards,
Dragan

I have gotten the mainstream driver to work with the open source NVS file, but I have seen the behavour you describe. It appears to be a bug in the open source code. I've considering asking the people in the community if we could add a device tree entry to allow people to specify the nvs file in the device tree. This would give people the ability to use custom NVS file names.

If you want to use the open source tree, you should be able to delete the wl127x-nvs.bin file and rename the 128x-nvs.bin file to wl127x-nvs.bin and it should work using the open source power levels. I don't know if they meet FCC levels, so any devices made with this would not fall under our FCC cert.

You could try taking the LogicPD NVS files from our stock BSP and renaming them as well, butI haven't tried that. If they work, you'll get proper FCC power levels without the calibration factor. The downside is that the -30 and -31 torpedo have different power levels, and the mainstream kernel doesn't support detecting the different versions, so you'd need to make sure which ever devices you have are using the correct NVS file and I don't know what the impact is of not using the correct calibration information.

If you wanted to do a services contract, we could get someone here to modify the driver to pull in the data from the EEPROM so you can use the calibration factors, but I would have to have someone in sales contact you. All of the mainstream development is being outside of Logic PD, but I am contributing to it as a hobby outside of work. We don't publish the INI file for the Torpedo, so it's not really possible (that I know) to calibrate the NVS file to your SOM.

U-boot in our BSP has a bunch of code to extract the data from the EEPROM, and format the data into a structure that the product ID driver in our BSP can read out. None of that has been pushed to the mainstream.

adam

I checked the driver source and it appears as if this bug is intentional.

/drivers/net/wireless/ti/wlcore/wlcore_i.h has the following comment:

/*
* wl127x and wl128x are using the same NVS file name. However, the
* ini parameters between them are different. The driver validates
* the correct NVS size in wl1271_boot_upload_nvs().
*/

So it looks like the rename is intentional for some reason.

adam

Hi Adam,

I tried with renaming open source wl128x-nvs.bin to wl128x-nvs.bin, but it doesn't work. I copied nvs from LogicPD BSP and with it I successfully load WiFi firmware, but I can't do iw wlan0 scan. I will try with using calibrator TI tool to generate NVS files.

Regards,
Dragan

You'll have to add the wlan0 to the network interfaces in the /etc directory.

cat /etc/network/interfaces

# The loopback interface
auto lo
iface lo inet loopback

iface eth0 inet dhcp
iface wlan0 inet dhcp

Then use 'ifup wlan0' to bring up the interface once the driver has loaded. Once the interface is up, your iw commands should become available.

adam

Where you able to make any progress on that? Buildroot is just a barebones rootfs, so it requires a fair amount of setup, but I like it because it's easy to add and remove packages in the menu.

adam

Hi Adam,

Sorry for the late response, it was holidays here.
No still not enabled WiFi.
I success to load firmware. First replaced wl127x-nvs.bin with wl128x-nvs.bin, then
#modprobe wlcore_sdio
#modprobe wl12xx
wlcore: loaded

/etc/network/interfaces file is
# The loopback interface
auto lo
iface lo inet loopback

iface wlan0 inet dhcp

With command
#ifup wlan0

wlcore: firmware booted (Rev 7.3.10.0.133)
IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
udhcpc (v1.23.2) started
Sending discover...
Sending discover...
Sending discover...
No lease, failing

#ifconfig

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

wlan0 Link encap:Ethernet HWaddr DE:AD:BE:EF:00:00
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Command
#iw wlan0 scan does not return anything, or it happens to break like this

[ 768.482086] wlcore: Scan completed due to error.
[ 768.486816] ------------[ cut here ]------------
[ 768.491638] WARNING: CPU: 0 PID: 6 at drivers/net/wireless/ti/wlcore/main.c:802 wl1271_op_cancel_hw_scan+0x15c/0x160 [wlcore]()
[ 768.503234] Modules linked in: arc4 wl12xx wlcore mac80211 cfg80211 wlcore_sdio ipv6
[ 768.511230] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 4.2.6 #1
[ 768.517364] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[ 768.523773] Workqueue: phy0 wl1271_scan_complete_work [wlcore]
[ 768.529724] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[ 768.537597] [] (show_stack) from [] (dump_stack+0x8c/0x9c)
[ 768.544982] [] (dump_stack) from [] (warn_slowpath_common+0x84/0xb4)
[ 768.553222] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24)
[ 768.562133] [] (warn_slowpath_null) from [] (wl1271_op_cancel_hw_scan+0x15c/0x160 [wlcore])
[ 768.572418] [] (wl1271_op_cancel_hw_scan [wlcore]) from [] (wl1271_scan_complete_work+0x100/0x104 [wlcore])
[ 768.584075] [] (wl1271_scan_complete_work [wlcore]) from [] (process_one_work+0x134/0x344)
[ 768.594207] [] (process_one_work) from [] (worker_thread+0x4c/0x4bc)
[ 768.602416] [] (worker_thread) from [] (kthread+0xdc/0xf4)
[ 768.609710] [] (kthread) from [] (ret_from_fork+0x14/0x2c)
[ 768.617034] ---[ end trace 114f5a6353a5e812 ]---
[ 768.628234] wlcore: Hardware recovery in progress. FW ver: Rev 7.3.10.0.133
[ 768.636871] wlcore: pc: 0x0, hint_sts: 0x00000020 count: 1
[ 768.644348] wlcore: down
[ 768.648803] ieee80211 phy0: Hardware restart was requested
[ 769.109954] wlcore: firmware booted (Rev 7.3.10.0.133)

I read that this can happen, if interrupt (wlan irq line) from chip is not proccesed. In /proc/interrupts I can see

264: 89 49056000.gpio 24 Level wl12xx

which, as I understand, means that that irq line produce interrupts.

I spent some time to make buildroot build out-of-tree, with external buildroot toolchain, so there is no need to build toolchain everytime when make clean is done.

Regards

I also tried bringing AP, by enabling hostapd.
After loading modules, run:
#ifconfig wlan0 up 192.168.1.1 netmask 255.255.255.0
[ 99.307220] wlcore: firmware booted (Rev 7.3.10.0.133)
[ 99.356414] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

Made /etc/hostapd.conf
interface=wlan0
ssid=buildrootAP
hw_mode=g
channel=6
auth_algs=1

Run
#hostapd -B /etc/hostapd.conf
Configuration file: /etc/hostapd.conf
[ 211.697021] wlcore: down
Using interface wlan0 with hwaddr de:ad:be:ef:00:00 and ssid "buildrootAP"
[ 211.738464] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
wlan0: interface state UNINITIALIZED->ENABLED
wlan0: AP-ENABLED

It says that AP is enabled, but can't see it with scanning on my PC.

Regards

I know at one point I had it working and I did a throughput test and I found the throughput was comparable to the results we were seeing in the Logic PD stock BSP.
I am going to have to look into that a little more. I have been doing the device tree stuff at home as a hobby, and it's not officially endorsed by Logic PD. If you need something quickly, I would suggest getting a services contract where someone can custom build you a BSP (or tune the Logic PD BSP to your newer kernel).

If you don't mind waiting, I will get back to it as I have time.

For your information, Kernel 4.5-RC1 should be release soon. As part of that, I believe there are a few more items in the device tree for better board support. I pushed a few more of the last week that are pending, and I hope they make it into the tree by 4.5's release.

adam