cpufreq is broken, this should be fixed pretty soon..
HDMI-Audio: this is new and went mainline in v4.9.x-rc, fingers
crossed, it should work so please test. ( i finally have a lcd
monitor (with audio) that i can finally test with. . )
pru: nothing yet..
eqep: needs porting..
Kernel should hit the apt repo in a day or two, i'll reply to this
message when ready...
cd /opt/scripts/tools/
git pull
sudo ./update_kernel.sh --ti-channel --lts-4_9
status
v4.4.x-ti - still supported and on-going working
v4.1.x-ti - maintenance-only please upgrade to v4.4.x-ti
v3.14.x-ti - maintenance (really eol)
v3.8.13-bone - maintenance, probably never EOL... (i see another gcc6
patch coming on the horizon).
While the Black looks good, the Octavo on the Blue is not getting 1Ghz enabled:
[ 2.081446] cpufreq: cpufreq_online: CPU0: Running at unlisted
freq: 1000000 KHz
[ 2.081483] cpu cpu0: dev_pm_opp_set_rate: failed to find current
OPP for freq 1000000000 (-34)
[ 2.092525] cpufreq: cpufreq_online: CPU0: Unlisted initial
frequency changed to: 800000 KHz
debian@beaglebone:~$ cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
driver: cpufreq-dt
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 300 us.
hardware limits: 300 MHz - 800 MHz
available frequency steps: 300 MHz, 600 MHz, 720 MHz, 800 MHz
available cpufreq governors: powersave, conservative, userspace,
ondemand, performance, schedutil
current policy: frequency should be within 300 MHz and 800 MHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 300 MHz.
cpufreq stats: 300 MHz:93.27%, 600 MHz:1.09%, 720 MHz:0.00%, 800
MHz:5.64% (56)
debian@beaglebone:~$ sudo omapconf --cpuinfo
OMAPCONF (rev 1.72-nogit built Thu Apr 14 19:49:20 UTC 2016)
I've just added a forward port of the eqep driver.. One of the big
changes, the eqep clock should be enabled/setup via the device-tree,
instead of the driver..
If I was not otherwise busy, maybe. I'm still waiting for rpmsg /
remoteproc to exit the experimental stage. I do however have a project that
*could* use the PRU's in either configuration. A 1200 baud UART device that
*may* need to be bit banged, if I can't get uart4 sending 2-3 bytes per
stop / start bit sets. With that said I have no experience with the uarts
on that level, and reading the TRM it *seems* the FIFO's on the UARTs
should be up to 64 bytes each . . . still reading / learning.
I read through this thread and noted that the PRU isn’t working yet? I ended up compiling a 4.9.0-rc6 kernel, although not the ti variant,
and was able to get the PRU working with the old UIO driver. I was hoping at some point to switch to the new remoteproc driver, but
reading through this thread, it seems as its not ready? I know this thread is about a month old now, but is my understanding accurate?
Or have things progressed to a working state? If my understanding is accurate, how much more work does the remoteproc driver require?
I’ve even tested the old driver with my code and without any changes, it was performing like a champ. My only problem now is I haven’t been
able to get the USB gadget interface to work. Everything seems to go fine up until I attempt:
ls /sys/class/udc > UDC # enable my gadget
At this point, I get a crash around line 620 in f_hid.c in usb/gadget/function . At least the crash is in alloc_ep_req. It says, if I’m reading it right, that the in_ep is NULL, which I don’t think it is supposed to be or can’t be. So I’m not sure what I’m doing wrong that I’m getting a NULL endpoint, but I thought maybe I hadn’t configured the kernel quite right for USB. So now that TI has a more “official” 4.9 release, maybe things work there?
At any rate, I needed both the USB gadget interface and the PRU to work and eventually am hoping to migrate my code toward remoteproc so I don’t have the current issues (I needed various components that didn’t seem to be all in one place until 4.9).
I read through this thread and noted that the PRU isn't working yet? I
ended up compiling a 4.9.0-rc6 kernel, although not the ti variant,
and was able to get the PRU working with the old UIO driver. I was hoping
at some point to switch to the new remoteproc driver, but
reading through this thread, it seems as its not ready? I know this thread
is about a month old now, but is my understanding accurate?
Or have things progressed to a working state? If my understanding is
accurate, how much more work does the remoteproc driver require?
Correct only, uio_pruss as it's mostly upstream, and with a quick hack
we have a version that is compatible with 3.8.13 kernel's..
The remoteproc driver isn't upstream, TI will rebase it from v4.4.x-ti
and port it to v4.9.x-ti when they feel like it.
I've even tested the old driver with my code and without any changes, it was
performing like a champ. My only problem now is I haven't been
able to get the USB gadget interface to work. Everything seems to go fine
up until I attempt:
ls /sys/class/udc > UDC # enable my gadget
At this point, I get a crash around line 620 in f_hid.c in
usb/gadget/function . At least the crash is in alloc_ep_req. It says, if
I'm reading it right, that the in_ep is NULL, which I don't think it is
supposed to be or can't be. So I'm not sure what I'm doing wrong that I'm
getting a NULL endpoint, but I thought maybe I hadn't configured the kernel
quite right for USB. So now that TI has a more "official" 4.9 release,
maybe things work there?
Double check with v4.9.0, i've been also messing around with the usb
gadget configfs interface:
hopefully we drop the old g_multi version that we use on the bone..
At any rate, I needed both the USB gadget interface and the PRU to work and
eventually am hoping to migrate my code toward remoteproc so I don't have
the current issues (I needed various components that didn't seem to be all
in one place until 4.9).
I read through this thread and noted that the PRU isn’t working yet? I
ended up compiling a 4.9.0-rc6 kernel, although not the ti variant,
and was able to get the PRU working with the old UIO driver. I was hoping
at some point to switch to the new remoteproc driver, but
reading through this thread, it seems as its not ready? I know this thread
is about a month old now, but is my understanding accurate?
Or have things progressed to a working state? If my understanding is
accurate, how much more work does the remoteproc driver require?
Correct only, uio_pruss as it’s mostly upstream, and with a quick hack
we have a version that is compatible with 3.8.13 kernel’s…
I take it that’s why my uio_pruss works in 4.9… At least I haven’t had any problems… yet.
The remoteproc driver isn’t upstream, TI will rebase it from v4.4.x-ti
and port it to v4.9.x-ti when they feel like it.
I’ve even tested the old driver with my code and without any changes, it was
performing like a champ. My only problem now is I haven’t been
able to get the USB gadget interface to work. Everything seems to go fine
up until I attempt:
ls /sys/class/udc > UDC # enable my gadget
At this point, I get a crash around line 620 in f_hid.c in
usb/gadget/function . At least the crash is in alloc_ep_req. It says, if
I’m reading it right, that the in_ep is NULL, which I don’t think it is
supposed to be or can’t be. So I’m not sure what I’m doing wrong that I’m
getting a NULL endpoint, but I thought maybe I hadn’t configured the kernel
quite right for USB. So now that TI has a more “official” 4.9 release,
maybe things work there?
Double check with v4.9.0, i’ve been also messing around with the usb
gadget configfs interface:
hopefully we drop the old g_multi version that we use on the bone…
I am not sure what’s going on here, but I’ll check this out. Either I’m not doing something with configfs properly, or I’ve screwed up the kernel config.
I did note that when I look at my dmesg, I see musb-hdrc.1.auto showing up as a “host” driver and musb-hdrc.0.auto showing up under /sys/class/udc.
I didn’t know if the musb-hdrc.0.auto under /sys/class/udc means that its an “available” udc, or if it is the “device” udc, or if things are screwing up altogether.
Thanks for the script pointer.
> I read through this thread and noted that the PRU isn't working yet? I
> ended up compiling a 4.9.0-rc6 kernel, although not the ti variant,
> and was able to get the PRU working with the old UIO driver. I was
> hoping
> at some point to switch to the new remoteproc driver, but
> reading through this thread, it seems as its not ready? I know this
> thread
> is about a month old now, but is my understanding accurate?
> Or have things progressed to a working state? If my understanding is
> accurate, how much more work does the remoteproc driver require?
Correct only, uio_pruss as it's mostly upstream, and with a quick hack
we have a version that is compatible with 3.8.13 kernel's..
I take it that's why my uio_pruss works in 4.9... At least I haven't had any
problems... yet.
Yeah you shouldn't have any problems, the one nice thing about uio, it
let's you handle everything.
The remoteproc driver isn't upstream, TI will rebase it from v4.4.x-ti
and port it to v4.9.x-ti when they feel like it.
>
> I've even tested the old driver with my code and without any changes, it
> was
> performing like a champ. My only problem now is I haven't been
> able to get the USB gadget interface to work. Everything seems to go
> fine
> up until I attempt:
>
> ls /sys/class/udc > UDC # enable my gadget
>
> At this point, I get a crash around line 620 in f_hid.c in
> usb/gadget/function . At least the crash is in alloc_ep_req. It says,
> if
> I'm reading it right, that the in_ep is NULL, which I don't think it is
> supposed to be or can't be. So I'm not sure what I'm doing wrong that
> I'm
> getting a NULL endpoint, but I thought maybe I hadn't configured the
> kernel
> quite right for USB. So now that TI has a more "official" 4.9 release,
> maybe things work there?
Double check with v4.9.0, i've been also messing around with the usb
gadget configfs interface:
hopefully we drop the old g_multi version that we use on the bone..
I am not sure what's going on here, but I'll check this out. Either I'm not
doing something with configfs properly, or I've screwed up the kernel
config.
I did note that when I look at my dmesg, I see musb-hdrc.1.auto showing up
as a "host" driver and musb-hdrc.0.auto showing up under /sys/class/udc.
I didn't know if the musb-hdrc.0.auto under /sys/class/udc means that its an
"available" udc, or if it is the "device" udc, or if things are screwing up
altogether.
Thanks for the script pointer.
On the beagle xM, we just have one musb port, thus "musb-hdrc.0.auto"..
I checked the script you posted to me. That’s pretty much what I’m doing, except I’m trying to create a
HID function device with:
mkdir g1/function/hid.0
Which does “create” the device. I then have to provide some kind of HID report descriptor, which I do
based on one that has worked for me before, but somehow, when I perform the final step, I get a crash
when libcomposite tries to call the f_hid.c (the function file which I believe is contained in usb_f_hid driver).
Following the crash, it appears that it isn’t getting an endpoint back from usb_ep_autoconfig … and I don’t
know at this point, why that would be the case.
The other drivers, I believe, do seem to work, or at least I was able to originally (before I needed to use the
OTG port as a device port) connect to the beaglebone black (that’s the board I’m using, btw) over the regular
USB-IP interface. So when I wasn’t able to configure the HID interface properly, I became confused.
I had another look at this. I don’t think it is creating any interfaces for some reason. I am unsure why not.
If I check the configfs part of the filesystem, there doesn’t seem to be anywhere where the “interface” values
show up (things like bInterfaceProtocol or bInterfaceSubClass). I thought they were supposed to be part of the
configuration or something like that. Maybe I’m missing something.
Well, still no dice as far as usb_f_hid goes. I tried to change a few config items. I ended up, I think, with a better kernel build (less kruft),
but nothing working. I guess its either bisect the kernel and see what broke (que mission impossible theme), or dig into the kernel further
and see what is going wrong (que mission impossible theme reprise). I have not seen ANYWHERE, regular docs included, that anything
I’ve done should lead to this, but maybe something is misconfigured in the kernel, or its just “broke”. I SUPPOSE I could try the OTHER
types of hid interface (I compile out hiddev and the other hid interface just in case), or heaven forbid, g_hid.ko (que Kirk yelling “Kahn” from
Star Trek II, replacing it with “g_hid”).
Oh, this does remind me, I meant to ask, since I have NOT bisected the kernel before, any pointers on where to start
looking for good info on effective bisection? I figured I would mark the 3.13 kernel as working (i had things working there), unless you know or have
tried some kind of hid device in a later kernel and it worked.
I've just added a forward port of the eqep driver.. One of the big
changes, the eqep clock should be enabled/setup via the device-tree,
instead of the driver..
It would be awesome if someone who had it working in v4.4.x-bone/etc..
Could verify.
eqep was working for me in 4.4.x but I get a segmentation fault when I
read the sysfs position file:
# cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
It seems to happen at this call to readl() in eqep_get_position():
Line 401: position = readl(eqep->mmio_base + QPOSCNT);
from dmesg:
[ 1858.085381] DEBUG: tieqep.c: eqep_get_position: QPOSCNT=0
[ 1858.102133] DEBUG: tieqep.c: eqep_get_position: eqep->mmio_base=fa304180
[ 1858.108446] Unhandled fault: external abort on non-linefetch
(0x1028) at 0xfa304184
I got some good hints from Google+:
Michael Welling wrote:
This external abort fault is probably caused by the clock being dynamically
disabled by runtime suspend. pm_runtime_get_sync is missing somewhere.
Felipe Balbi wrote:
Looking at the diff, it works on 4.4 out of sheer luck. There's nothing guaranteeing
clock won't be gated. Enable pm runtime and call pm runtime get sync
I'm now reading about pm_runtime_get_sync() in
Documentation/power/runtime_pm.txt. I'll update if I make any
progress.
eqep was working for me in 4.4.x but I get a segmentation fault when I
read the sysfs position file:
# cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
[ 1858.108446] Unhandled fault: external abort on non-linefetch
(0x1028) at 0xfa304184
I'm now reading about pm_runtime_get_sync() in
Documentation/power/runtime_pm.txt. I'll update if I make any
progress.
I'm still investigating but I did notice that the original tieqep
driver had this code to enable the clock to the eQEP unit:
// Enable the clock to the eQEP unit
status = pwmss_submodule_state_change(pdev->dev.parent, PWMSS_EQEPCLK_EN);
// If we failed to enable the clocks, fail out
if (!(status & PWMSS_EQEPCLK_EN_ACK))
{
dev_err(&pdev->dev, "PWMSS config space clock enable failed\n");
ret = -EINVAL;
goto pwmss_clk_failure;
}
The function pwmss_submodule_state_change() appears to have been
removed by this commit:
commit cc37655e6bbf83ded1e4d1d7ffd977786a845a67
Author: Cooper Jr., Franklin <fcooper@ti.com>
pwm: pwm-ti*: Remove support for local clock gating
The PWMSS local clock gating registers have no real purpose on OMAP ARM
devices. These registers were left over registers from DSP IP where the
PRCM doesn't exist. There is a silicon bug where gating and ungating clocks
don't function properly. TRMs will be update to indicate that these
registers shouldn't be touched.
Therefore, all code that accesses the PWMSS_CLKCONFIG or PWMSS_CLKSTATUS
will be removed by this patch with zero loss of functionality by the ECAP
and EPWM drivers.
( i finally have a lcd