Hello,
Now linux 3.10 is released and runs without problems on beagleboard-xm (well, usb absence problems can be solved by playing with .config). But what about 1ghz - is it still not possible? What piece of a puzzle is still missing?
With best regards,
S.Nizamov
v3.10? not going to happen... However in v3.11-rc, we now have the
ti-abb-regulator bindings... So give it a shot and let us know..
So just add them to:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-beagle-xm.dts
Regards,
Haha so finally I don’t have to keep hacking the frequency settings to allow 1 GHz? Now it can be done safely?
v3.10? not going to happen… However in v3.11-rc, we now have the
ti-abb-regulator bindings… So give it a shot and let us know…So just add them to:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-beagle-xm.dts
I do not feel myself competent enough 
At least I would not try to do that without being able to see (even better - modify) the actual settings. Are there any exposed controls somewhere in /sys /proc or anything similar?
With best regards,
S.Nizamov
Definitely going to have to try this when I get back to my BBxM. @Nizamov, what settings did you tweak in .config to get the USB to work again? Also, does the 3.11-rc kernel have that erratum patch that fixed the PLL clock in it?
However, wouldn’t the CPU still only be operating at 800 MHz? I’ve been reading through the documentation, and the device tree for the CPU still only lists 800 MHz as the top frequency. I’ve been reading through the DM37xx manual and can’t find any mention of the proper operating voltages to frequencies.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap36xx.dtsi
It appears to have been located inside the non-comprehensive manual for the DM3730, instead of the full manual. Go figure. But for OPP1G, the voltage is listed to be 1.38V (http://www.ti.com/lit/ds/symlink/dm3730.pdf, page 144), meaning that we would have to overlay omap36xx.dtsi and add this to the operating points line
/* KHz uV */
1000000 1380000
This would also have to be referenced when adding the ABB entry into omap3-beagle-xm.dts. As per note 2 on table 4-20 (page 144) says that ABB must be set to forward body bias mode, so when adding the abb driver to omap3-beagle-xm from https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt, use the abb_x example by the way, as omap3 only supports abb-v1, and I’d rename it to abb. In the abb_info property you’d have to add
/* uV ABB efuse rbb_m fbb_m vset_m */
1380000 1 0 0 0 0
checking the register numbers, turns out they match the ones for the DM3730 cpu in the Beagleboard-xM. Interesting. But I’m not going to have access to a Beagleboard-xM until Tuesday, so if anyone wants to try this out and share the results that’d be great!
Look for solution here:
https://github.com/RobertCNelson/stable-kernel/commit/7d75e5eda0498477227b052b5a6515da99368917
which PLL do you mean? Starting from 3.8 the kernel states 21.6 mhz for camera clock in dmesg, but the actual frequency is 27 mhz. Although I can not check it directly any more, it seems to be still the case in 3.10.
Best regards,
S.Nizamov
That would be DPPL5. Something was wrong in prior kernel that required a patch called “sprz319-erratum.” The timer was unstable or something. Also, I pulled the defconfig for the 3.11-rc1 kernel (Which is the one I am experimenting with), and when I boot I get this message
musb_bus_suspend 2457: trying to suspend as b_idle while active
I am using the device tree based boot method.
However, it just keeps repeating this message over and over again, and then the board locks up. I removed all of the MUSB kernel modules, since USB On The Go never really worked that well on the xM. However, I still don’t get the USB ports on the board or the ethernet. A little confusing considering the ethernet and usb hub are on the EHCI port.
I do get these in the boot log and I think VUSB3v1 powers the USB hub on the BBxM. When I try to force vusb3v1 to on with its sysfs entry, even as root, I just get “Permission Denied,” I think its a read only property.
[ 3.413085] VUSB3V1: disabling
[ 3.419311] VPLL2: disabling
[ 3.423553] VDAC: disabling
To get the ehci to work, i had to get these off linux-omap:
https://github.com/RobertCNelson/armv7-multiplatform/blob/v3.11.x/patch.sh#L220
and finally this little gem..
https://github.com/RobertCNelson/armv7-multiplatform/commit/938bada0449abc2bdc4b99386ac1a53c8026fbf2
(for some reason it jsut doesn't work as built-in)
This fixed usb for me in both board file/dts mode..
Regards,
All of the patches after line 220 there?
However, it just keeps repeating this message over and over again, and then
the board locks up. I removed all of the MUSB kernel modules, since USB On
The Go never really worked that well on the xM. However, I still don’t get
the USB ports on the board or the ethernet. A little confusing considering
the ethernet and usb hub are on the EHCI port.To get the ehci to work, i had to get these off linux-omap:
https://github.com/RobertCNelson/armv7-multiplatform/blob/v3.11.x/patch.sh#L220
and finally this little gem…
https://github.com/RobertCNelson/armv7-multiplatform/commit/938bada0449abc2bdc4b99386ac1a53c8026fbf2
(for some reason it jsut doesn’t work as built-in)This fixed usb for me in both board file/dts mode…
What about this patch, accepted just a few days ago - isn’t is the solution for this problem ?
commit 5b3e69eafcfc490dcdd0368f680170b24686abe5
Author: Roger Quadros <rogerq@ti.com>
USB: ehci-omap: Tweak PHY initialization sequence
commit 4e5c9e6fa2d232a0686d5fe45cd1508484048936 upstream.
For PHY mode, the PHYs must be brought out of reset
before the EHCI controller is started.
This patch fixes the issue where USB devices are not found
on Beagleboard/Beagle-xm if USB has been started previously
by the bootloader. (e.g. by "usb start" command in u-boot)
Tested on Beagleboard, Beagleboard-xm and Pandaboard.
Issue present on 3.10 onwards.
Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Best regards,
S.Nizamov
Yes that was the solution. I was trying to fold it into stable-kernel until I realized that was completely pointless, so I’m just going to submit a patchset for armv7-multiplatform for 1 GHz on the beagleboard xm. There are a few things that need to be added/amended to do so
Okay everybody, I’ve put together a fork of RobertCNelson’s armv7-multiplatform that adds the necessary driver and modifications to allow the Beagleboard xM to run safely at 1 GHz using TI’s new adaptive body bias driver in the 3.11-rc2 linux kernel. I’ll put together a blog post tomorrow, err later, I’ve been up for 30 hours getting this working. USB works, however the sprz319 erratum has to be ported to 3.11, meaning usb on the xM is unstable and most likely will cutout within 15 minutes. Enjoy! https://github.com/Teknoman117/beagleboardxm-kernel
Sweet, thanks for working on this Nathaniel!
I just pulled the merge, I'm going to test it a few older xM's i have here too..
So for device trees in v3.11-rcX (ignoring the expansion boards, i
want to use the 3.8/bone capemgr/dtbos for that) we still need video
working and a easy to enable sprz319 workaround to be feature
identical with the old beagle board file..
Regards,
Honest, for how long we've come... This just seems really cool. 
debian@arm:~$ 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: generic_cpu0
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 - 1000 MHz
available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz
available cpufreq governors: conservative, ondemand, userspace,
powersave, performance
current policy: frequency should be within 300 MHz and 1000 MHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 300 MHz.
cpufreq stats: 300 MHz:43.52%, 600 MHz:2.20%, 800 MHz:0.00%, 1000
MHz:54.28% (3)
Regards,
Well, that was one of the ehci problems, but i had that in my v3.11.x
based tree already... But thanks for the hint.. As it'll fix the
v3.10.x tree.
Regards,
For anyone who is curious, i detailed what I did here: http://teknoman117.wordpress.com/2013/07/24/beagleboard-xm-1-ghz-operation-safely-and-reliably/
Okay so I ported the sprz319 erratum patch to kernel 3.11-rc2. Robert, the patch in stable kernel for sprz319 kept failing to apply. So I made the modification presented by it by hand and heres the new patch - https://github.com/Teknoman117/beagleboardxm-kernel/blob/v3.11.x/patches/omap_sprz319_erratum_v2.1/0001-hack-omap-clockk-dpll5-apply-sprz319e-2.1-erratum-kernel-3.11-rc2.patch
Submitted a merge request.
Sweet, this is merged. Good to hear that hack/patch is still working.
On my one xM that showed the pll issue, i just couldn't get it to
reliably fail enough to prove the patch worked.
I'm pretty sure in it's current form it's omap34xx safe. So I'll give
it some testing tomorrow enable by default as I still have to fix
video on the C4.. (Only had my xM's at work today, and my old Bx just
had too many other issues..)
Regards,