v4.9.x-ti now open for testing...

Franklin_S_Cooper_Jr · January 30, 2017, 4:56pm

So one thing I noticed is that the eqep node isn't adding any clocks
compared to EHRPWM and ECAP. So I would be curious if adding the
following entries to the eqep node may solve. I don't really remember
how we came up with this

clocks = <&l4_root_clk_div>;
clock-names = "fck";

From what I remember for ECAP and PWM that the PWMSS clock gate wouldn't
allow a clock to be ungated once you tell it to gate it. However, the
patch you mentioned shouldn't change anything because by default (on
reset) PWMSS ungates the PWM, ECAP and EQEP clocks.

You mind sharing a boot log showing this failure? Also can you share the
patch your using now for the eqep driver along with dts changes?

drew-fustini-bborg · January 30, 2017, 7:02pm

Thanks for the assistance, Franklin. Here is the patch that is applied:
https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-4.9.y/patches/drivers/ti/eqep

The boot log is in this gist and also attached:
https://gist.github.com/pdp7/0df175876304e30e8971c2aadb7493c7/

Thanks!
Drew

beaglebone-4.9.6-ti-r17-boot-log-for-eqep.txt (21.8 KB)

0001-tieqep-forward-port-of-Nathaniel-Lewis-eQEP-driver.patch (25.3 KB)

unhandled_fault_abort.txt (3.79 KB)

tieqep.c (21.4 KB)

am33xx.dtsi (24.9 KB)

drew-fustini-bborg · January 30, 2017, 9:40pm

I just found that I can avoid the abort by setting runtime power
control to "on" instead of "auto" through sysfs.

# uname -r
4.9.6-ti-r17
# config-pin p8.11 qep
# config-pin p8.12 qep

# echo on > /sys/devices/platform/ocp/48300000.epwmss/48300180.eqep/power/control
# echo on > /sys/devices/platform/ocp/48302000.epwmss/48302180.eqep/power/control
# echo on > /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/power/control

# cat /sys/devices/platform/ocp/48300000.epwmss/48300180.eqep/power/runtime_status
active
# cat /sys/devices/platform/ocp/48302000.epwmss/48302180.eqep/power/runtime_status
active
# cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/power/runtime_status
active

# cat /sys/devices/platform/ocp/48300000.epwmss/48300180.eqep/position
0
# cat /sys/devices/platform/ocp/48302000.epwmss/48302180.eqep/position
0
# cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
-1

I'm guessing this is probably not a real solution, but it seems
promising to finally avoid that unhandled fault ("external abort on
non-linefetch") upon reading position.

-Drew

RobertCNelson · January 31, 2017, 2:40am

Nice find Drew!

Once you enable the power control, it's it acting the same as v4.4.x was?

Regards,

drew-fustini-bborg · January 31, 2017, 11:47am

Yes, it does read position ok.

# uname -r
4.9.6-ti-r17

  # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/power/control
  auto
  # echo on > /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/power/control
  # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/power/control
  on
  # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/power/runtime_status
  active

# config-pin p8.11 qep
# config-pin p8.12 qep

  # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
  -2
  <turn the rotary encoder>
  # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
  46

thanks,
drew

William_Hermans · February 1, 2017, 3:28am

> Once you enable the power control, it's it acting the same as v4.4.x was?

Yes, it does read position ok.

  # uname -r
  4.9.6-ti-r17

  # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/
power/control
  auto
  # echo on > /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/
power/control
  # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/
power/control
  on
  # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/
power/runtime_status
  active

  # config-pin p8.11 qep
  # config-pin p8.12 qep

  # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
  -2
  <turn the rotary encoder>
  # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
  46

thanks,
drew

Drew, do you have a complete gist on how you set this all up ? Mark Yoder
was interested in the wqep module a while back, but I do not thnk he was
able to figure it out completely. Also, from a personal project / somethign
to tpy with. I'm very interested in the eqep module as well. Or hmm maybe
ecap is more of what I'm interested in ?

DrewFustini · February 1, 2017, 4:08am

Here is a gist that I've been keeping notes in:
https://gist.github.com/pdp7/0df175876304e30e8971c2aadb7493c7

Here is repeating the steps on 4.1, 4.4 and 4.9:
https://gist.github.com/pdp7/1db356e758e9ff0c1e570e6ee362c673

For 4.9, I am forcing the eQEP peripheral that I'm using to never
suspend by changing its power/control file in sysfs to "on" instead of
"auto". I still need to figure out the real solution so that the
tieqep handles suspend and resume properly.

-drew

William_Hermans · February 1, 2017, 4:14am

Thanks Drew.

DrewFustini · February 2, 2017, 10:16am

I've created this patch which seems to have done the trick without
messing with sysfs. It adds pm_runtime_get_sync() before read or
write to eQEP memory mapped registers:
patches/drivers/ti/eqep/0002-Avoid-unhandled-fault-when-reading-eQEP-registers.patch

Here is the gist of the patch (also attached):
https://gist.github.com/pdp7/5fddaab028630dd06ace8e5012cf6798

Here's the results (no need to mess with files in sysfs anymore):

root@beaglebone:~# uname -r
4.9.6-ti-r18
root@beaglebone:~# config-pin p8.11 qep && config-pin p8.12 qep
root@beaglebone:~# cat
/sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
0
<turn the rotary encoder>
root@beaglebone:~# cat
/sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
66

thanks,
drew

0002-Avoid-unhandled-fault-when-reading-eQEP-registers.patch (3.27 KB)

DrewFustini · February 2, 2017, 12:16pm

Robert - I’ve raised a pull request with the patch on the ti-linux-4.9.y branch of your ti-linux-kernel-dev repo:
https://github.com/RobertCNelson/ti-linux-kernel-dev/pull/10

thanks,
drew

Baozhu_Zuo · December 9, 2016, 4:17am

What’s the kernel 4.9 plan? will we switch to kernel 4.9 ?

在 2016年11月3日星期四 UTC+8上午12:24:27，robert nelson写道：

Baozhu_Zuo · December 9, 2016, 10:56pm

What's the new features on v4.9 ？

RobertCNelson · December 9, 2016, 10:58pm

For wl18xx, i get 1,600 kb/s vs 55 kb/s network speed's when ssh'ed
into the AP (using SoftAp0) and connect to a network AP with wlan0..

(aka your default bbgw image get's a nice boost. )

Regards,

Baozhu_Zuo · December 9, 2016, 11:16pm

Great, Thank you for your job.
Last question, a BB developer , how to choose v4.1 v4.4 v4.9

RobertCNelson · December 9, 2016, 11:22pm

v4.1.x : no longer maintained by Greg Kroah-Hartman, Sasha Levin has
taken over maintenance.
v4.4.x : maintained by Greg Kroah-Hartman for at-least another year
v4.9.x : the next lts, maintained by Greg Kroah-Hartman, will replace v4.4.x

Regards,

tmlind · December 9, 2016, 11:36pm

* Robert Nelson <robertcnelson@gmail.com> [161209 14:59]:

RobertCNelson · December 10, 2016, 2:06am

Hi Tony,

Actually for wl18xx, we are just using 99% mainline, i did have to
revert your v4.9.x-rcX wl12/wl18xx firmware changes to get things
running. (shakes fist at evil nvs files..)

https://github.com/RobertCNelson/linux-dev/blob/master/patch.sh#L347-L353

https://github.com/RobertCNelson/linux-dev/tree/master/patches/reverts

https://github.com/RobertCNelson/linux-stable-rcn-ee/commits/4.9-rc8-bone3

Full patchlist:

https://github.com/RobertCNelson/linux-stable-rcn-ee/compare/v4.9-rc8...4.9-rc8-bone3

PS, i really really owe you a BeagleBone Green Wireless & BeagleBone
Black Wireless device-tree files for v4.10.0-rc1. I was hoping to get
them around v4.9.0-rc1 but we had a breakthru on the Green, that
finally fixed wifi on first (cold) bootup.. (undocumented feature of
the wl18xx when one pin is pulled the wrong direction on startup)..

@Jason, do we have any Green/Black/Blue wl18xx's heading Tony's way???

Regards,

RobertCNelson · December 10, 2016, 2:28am

firmware: wl18xx-conf.bin

https://github.com/rcn-ee/repos/tree/master/bb-wl18xx-firmware/suite/jessie/debian

It was generated by wlconf, this version:

https://github.com/rcn-ee/repos/tree/master/ti-wlconf

so git: d39cb9d35247ad6c06542fbac1d40a7c5bcb9856

http://git.ti.com/cgit/cgit.cgi/wilink8-wlan/18xx-ti-utils.git/log/

R8.6SP1

http://git.ti.com/cgit/cgit.cgi/wilink8-wlan/18xx-ti-utils.git/commit/?id=d39cb9d35247ad6c06542fbac1d40a7c5bcb9856

on the bbgw via:

sudo wlconf -o /lib/firmware/ti-connectivity/wl18xx-conf.bin -I
WL1835MOD_INI_C2PC.ini

this was the version Seeed sent in FCC stuff, i think the original
WL1835MOD_INI_C2PC.ini came from CircuitCo for the original wl18xx
cape...

Regards,

WL1835MOD_INI_C2PC.ini (10.4 KB)

jkridner · December 10, 2016, 3:43am

Robert Nelson <robertcnelson@gmail.com> [161209 14:59]:

What’s the new features on v4.9 ？

For wl18xx, i get 1,600 kb/s vs 55 kb/s network speed’s when ssh’ed
into the AP (using SoftAp0) and connect to a network AP with wlan0…

(aka your default bbgw image get’s a nice boost. )

As I’ve seen tons of issues with the mainline kernel and wl12xx/wl18xx…
What’s the driver + firmware combination you’re using?

Hi Tony,

Actually for wl18xx, we are just using 99% mainline, i did have to
revert your v4.9.x-rcX wl12/wl18xx firmware changes to get things
running. (shakes fist at evil nvs files…)

https://github.com/RobertCNelson/linux-dev/blob/master/patch.sh#L347-L353

https://github.com/RobertCNelson/linux-dev/tree/master/patches/reverts

https://github.com/RobertCNelson/linux-stable-rcn-ee/commits/4.9-rc8-bone3

Full patchlist:

https://github.com/RobertCNelson/linux-stable-rcn-ee/compare/v4.9-rc8…4.9-rc8-bone3

PS, i really really owe you a BeagleBone Green Wireless & BeagleBone
Black Wireless device-tree files for v4.10.0-rc1. I was hoping to get
them around v4.9.0-rc1 but we had a breakthru on the Green, that
finally fixed wifi on first (cold) bootup… (undocumented feature of
the wl18xx when one pin is pulled the wrong direction on startup)…

@Jason, do we have any Green/Black/Blue wl18xx’s heading Tony’s way???

I’ve got a Blue to send his way as soon as we have a good enough image that I can run the test program out-of-the-box. Should be in the mail by Monday, I’d expect.

I can order him a Green Wireless and Black Wireless.

tmlind · December 10, 2016, 6:37pm

* Robert Nelson <robertcnelson@gmail.com> [161209 18:07]:

> * Robert Nelson <robertcnelson@gmail.com> [161209 14:59]:
>> > What's the new features on v4.9 ？
>>
>> For wl18xx, i get 1,600 kb/s vs 55 kb/s network speed's when ssh'ed
>> into the AP (using SoftAp0) and connect to a network AP with wlan0..
>>
>> (aka your default bbgw image get's a nice boost. )
>
> As I've seen tons of issues with the mainline kernel and wl12xx/wl18xx..
> What's the driver + firmware combination you're using?

Hi Tony,

Actually for wl18xx, we are just using 99% mainline, i did have to
revert your v4.9.x-rcX wl12/wl18xx firmware changes to get things
running. (shakes fist at evil nvs files..)

Hmm care to explain what broke?

Do you have fix f38b7c254753 ("wlcore: sdio: drop kfree for memory
allocated with devm_kzalloc") applied? Without that there can be random
oopses on rmmod.

FYI, those patches just change things around so the right nvs file is
found for the WLAN. The fact that I had to symlink to different files
when booting the same NFSroot on different SoCs was totally driving me
crazy.

If something accidentally broke there then let's just fix it up in the
mainline kernel.

linux-dev/patch.sh at master · RobertCNelson/linux-dev · GitHub

https://github.com/RobertCNelson/linux-dev/tree/master/patches/reverts

Commits · RobertCNelson/linux-stable-rcn-ee · GitHub

Full patchlist:

Comparing v4.9-rc8...4.9-rc8-bone3 · RobertCNelson/linux-stable-rcn-ee · GitHub

Hard to say what the missing piece for wl18xx is in the mainline kernel,
you probably know best at this point I seriously don't know of any
wl18xx board in the mainline that would work reliably, so let's start
with BB Green to get the missing %1 of the code merged and verify it
works. With recent fixes, wl12xx seems to work OK on the boards I've
tested with.

PS, i really really owe you a BeagleBone Green Wireless & BeagleBone
Black Wireless device-tree files for v4.10.0-rc1. I was hoping to get
them around v4.9.0-rc1 but we had a breakthru on the Green, that
finally fixed wifi on first (cold) bootup.. (undocumented feature of
the wl18xx when one pin is pulled the wrong direction on startup)..

Yes please, at least BB Green has integrated WLAN, so that should always
be configured in the dts file.

Regards,

Tony