I'm trying to build the 3.14.17-ti-r19 from:
git@github.com:RobertCNelson/ti-linux-kernel-dev.git
...but I keep getting errors about the patches not applying. I
currently get the following trying to build from tag 3.14.17-ti-r19 or
from the head of the ti-linux-3.14.y branch:
dir: beaglebone/pinmux
Applying: am335x-bone-common: split out am33xx_pinmux
error: patch failed: arch/arm/boot/dts/am335x-bone-common.dtsi:65
error: arch/arm/boot/dts/am335x-bone-common.dtsi: patch does not apply
Patch failed at 0001 am335x-bone-common: split out am33xx_pinmux
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
charles@cubox:~/ti-linux-kernel-dev$
If I switch to other tags (earlier versions, like ti-r18), I get
different patches that fail.
It looks like maybe the build_kernel.sh script is pulling in an untagged
version of the TI kernel:
Starting patch.sh
pulling: ti-linux-3.14.y
From https://github.com/RobertCNelson/ti-linux-kernel
* branch ti-linux-3.14.y -> FETCH_HEAD
...and something is newer than expected which breaks the patch script.
What's the "right' way to build a -ti-19 kernel as a baseline so I can
start playing with updating the pinmux helper and universal device tree?
For your sanity you have to use the tags, from this tree:
https://github.com/beagleboard/linux/tree/3.14.17-ti-r19
Since our base is always a moving target ( ti's 3.14 bsp ) branch,
it's going to be painful working from my git tree directly.
btw: i'm almost done converting everything from custom &pin nodes to
your Px_yy_z_pin values:
+&uart4 {
+ pinctrl-names = "default";
-+ pinctrl-0 = <&uart4_pins>;
++ pinctrl-0 = <
++ &P9_11_uart_pin
++ &P9_13_uart_pin
++ >;
I tried that, using the configuration from:
arch/arm/configs/bb.org_defconfig
...but the kernel version was 3.14.17+ (I was expecting 3.14.17-ti-r19)
and when I did "make deb_pkg", I got armel instead of armhf packages.
...that's why I fell back to ti-linux-kernel-dev.
I'm apparently missing some sort of secret sauce (a.k.a. "clues"). :-/
"deb_pkg" still hasn't learned to autodetect "armhf", so we do some
deb voodoo around that.. 
otherwise, the ti-r19 comes from LOCALVERSION
So:
make ARCH=arm KBUILD_DEBARCH=armhf LOCALVERSION=-ti-r19
CROSS_COMPILE=${CC} KDEB_PKGVERSION=1wheezy deb-pkg
will generate:
linux-image-3.14.17-ti-r19_1wheezy_armhf.deb
Regards,
btw, when you build/test this on a local machine, it helps to randomly
increment "LOCALVERSION" nothing worse then doing a bunch of changes,
but it won't install the new *.deb as it has the same version as the
old..
LOCALVERSION=-ti-r19.x (x -> nothing -> big number)
Regards,
Many thanks!
I figured the missing LOCALVERSION was just something I didn't have vs.
the official build scripts, but when I got armel packages instead of
armhf I figured something was very wrong so I headed down a different path.
Hey Charles,
Ran into a problem last night with the pinmux, what's the proper way
to grab a pin. For the lcd4, i need P9_27_gpio_pd_pin
diff --git a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
index 2df34ce..6f3dceb 100644
--- a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
@@ -15,7 +15,7 @@
status = "okay";
compatible = "ti,tilcdc,panel";
pinctrl-names = "default";
- pinctrl-0 = <&bbcape_lcd_pins &bbcape_lcd4_disen_pins>;
+ pinctrl-0 = <&bbcape_lcd_pins &P9_27_gpio_pd_pin>;
panel-info {
ac-bias = <255>;
ac-bias-intrpt = <0>;
but, P9_27_pinmux still grabs it:
[ 3.197699] pinctrl-single 44e10800.pinmux: pin 44e109a4.0 already
requested by P9_27_pinmux.32; cannot claim for panel.48
[ 3.209481] pinctrl-single 44e10800.pinmux: pin-105 (panel.48) status -22
[ 3.216666] pinctrl-single 44e10800.pinmux: could not request pin
105 (44e109a4.0) from group pinmux_P9_27_gpio_pd_pin on device
pinctrl-single
ps, i disabled my git mirror script, so:
https://github.com/RobertCNelson/ti-linux-kernel-dev
is safe today, i'm going to try and only update my ti mirror when i
already have my patchset rebased.
Regards,
NM, found a work around..
When we "know" what cape is installed, thus we are already building a
*.dtb for it, just disable the pinmux, as it's already tied to the
cape.
diff --git a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
index 2df34ce..138a619 100644
--- a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
@@ -6,6 +6,12 @@
* published by the Free Software Foundation.
*/
+&ocp {
+ P9_27_pinmux {
+ status = "disabled";
+ };
+};
Yes, that's what you need to do for now, and this is why no "cape" pins
can be controlled at run-time without using a device-tree overlay (or
changeset).
What I'm working on is adding a setting to the pinmux helper, so rather
than trying to have the LCD cape "own" the pinmux setting, it would just
let the pinmux helper know it should start in a specific mode.
...but it looks like you might be assigning LEDs to the GPIO. This
causes the GPIO pin to be "owned" by the gpio-leds driver, making it
impossible to use the pin as a GPIO for any other purpose. I haven't
worked out a solution for this, other than to not use the kernel
gpio-leds driver (driving the LED from userspace) or just give up the
option to reconfigure the I/O and let the kernel LED driver "own" it.
I've been trying out
http://builds.beagleboard.org/builders/runtests/builds/39 that seems
to have several of these changes implemented...
NM, found a work around..
When we "know" what cape is installed, thus we are already building a
*.dtb for it, just disable the pinmux, as it's already tied to the
cape.
diff --git a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
index 2df34ce..138a619 100644
--- a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
@@ -6,6 +6,12 @@
* published by the Free Software Foundation.
*/
+&ocp {
+ P9_27_pinmux {
+ status = "disabled";
+ };
+};
+
&lcdc {
status = "okay";
};
Yes, that's what you need to do for now, and this is why no "cape" pins
can be controlled at run-time without using a device-tree overlay (or
changeset).
What I'm working on is adding a setting to the pinmux helper, so rather
than trying to have the LCD cape "own" the pinmux setting, it would just
let the pinmux helper know it should start in a specific mode.
In general, I prefer leaving the pinmux helper in control, but I think
*some* of the lines might be *ok* to put under control of the LCD, no?
...but it looks like you might be assigning LEDs to the GPIO. This
causes the GPIO pin to be "owned" by the gpio-leds driver, making it
impossible to use the pin as a GPIO for any other purpose. I haven't
worked out a solution for this, other than to not use the kernel
gpio-leds driver (driving the LED from userspace) or just give up the
option to reconfigure the I/O and let the kernel LED driver "own" it.
For normalcy, do we agree then to put everything possible into a
pinmux helper and simply impact the boot-up state of the helper?
I see one conflict here that needs to be resolved:
[ 12.785659] pinctrl-single 44e10800.pinmux: pin 44e109ac.0 already
requested by P9_25_pinmux.30; cannot claim for 48038000.mcasp
[ 12.798203] pinctrl-single 44e10800.pinmux: pin-107
(48038000.mcasp) status -22
[ 12.806053] pinctrl-single 44e10800.pinmux: could not request pin
107 (44e109ac.0) from group mcasp0_pins on device pinctrl-single
[ 12.818665] davinci-mcasp 48038000.mcasp: Error applying setting,
reverse things back
Any idea why there isn't a status entry on the cape-universal node?
root@beaglebone:~# ls /sys/devices/ocp.3/cape-universal.41/
modalias power subsystem uevent
Full boot log: [ 0.000000] Booting Linux on physical CPU 0x0[ 0.000000] Initializing cg - Pastebin.com
BTW, this build seems to have resolved the funny P9_14 issue being
associated with the uSD card.
As Robert showed, the pinmux helper can easily be disabled for
particular pins, allowing them to be directly "owned" by the driver (and
making them difficult or impossible to change w/o DT overlays or
changesets).
If you want to leave pinmux in control, one needs faith in the end users
and some "enlightenment" of the config-pin utility is in order to help
keep folks from shooting themselves in the foot. Any pins not needing
to be modified by user-space (ie: signals that don't go to the P8/P9
headers) can probably remain under control of the appropriate driver w/o
issue.
I've got a modified version of the pinmux-helper, device-tree, and
config-pin that allow modifying the i2c2 lines after boot. Give me a
bit to get everything organized and pushed to github (three patch-sets
to push...ugh!) and I'll post an RFC.