Slow boot sequence caused by Cape Manager and Device Tree Overlaying

Background Information:
I am using a standard Beaglebone Black with the latest version of Angstrom (2013.09.04) loaded.
I developed software to that uses eqep2 on the Beaglebone Black and it works well, I get the correct results from the quadrature counter.

Problem Description:
A problem is that the related Device Tree Overlay in conjunction with the Cape Manager cause my BBB boot-up time to extend beyond 60 seconds, and it
seems to be related to the cape manager trying to load cape firmware as the snippet from the boot-up sequence, shown below, suggests.
However, in essence I do not have an actual cape, I merely assign the eqep2 pins to P8.39, 40, 41 and 42 using a Device Tree Overlay and then access the eqep2 registers
using mmap in my software, and as mentioned earlier it works as expected.

[ 0.480195] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status -22
[ 0.487510] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single
[ 60.501312] bone-capemgr bone_capemgr.9: failed to load firmware ‘bone_eqep2-00A0.dtbo’
systemd-fsck[90]: Angstrom: clean, 49347/112672 files, 304984/449820 blocks
[ 68.329939] libphy: PHY 4a101000.mdio:01 not found
[ 68.335035] net eth0: phy 4a101000.mdio:01 not found on slave 1


.-. o o

-----.-----.-----.| | .----…-----.-----.
__ | —’| ‘–.| .-’| | |

— || --’| | | ’ | | | |
‘—’---’–’--’–. |-----’’----’’–’ ‘-----’-’-’-’
-’ |

The Angstrom Distribution beaglebone ttyO0

Is there a way to prevent the Cape Manager to actually load cape firmware?
Is there a different way to speed up the boot time?



Is there a way to prevent the Cape Manager to actually load cape firmware?

If you don't have an actual cape, you must be telling capemgr to load
the overlay for you. If you don't want capemgr to load the overlay,
don't tell it to do so.

Is there a different way to speed up the boot time?

One way is to avoid the capemgr and merge your device tree changes into
the root device tree file loaded by u-boot.

There are also many other ways to improve boot time which are unrelated
to device tree overlays. Google a bit and you'll find lots of info.

Thank you for the feedback Charles.
I am new to the Device Tree concept and would appreciate it a lot if you can please give me more guidance. Below is the contents of the device tree file I used.
Basically the idea was to define the pins for the pin-mux and then enable the pin-mux settings by using the overlay scheme.
Without using the overlay scheme, how would I enable the pin-mux settings,in this device tree file for example?


/ {
compatible = “ti,beaglebone”, “ti,beaglebone-black”;

/* identification */
part-number = “bone_eqep2”;
version = “00A0”;

fragment@0 {
target = <&am33xx_pinmux>;
overlay {
pinctrl_eqep2: pinctrl_eqep2_pins {
pinctrl-single,pins = <
0x0B8 0x23 /* P8_39 = GPIO2_12 = EQEP2_index, MODE3 /
0x0BC 0x23 /
P8_40 = GPIO2_13 = EQEP2_strobe, MODE3 /
0x0B0 0x33 /
P8_41 = GPIO2_10 = EQEP2A_in, MODE3 /
0x0B4 0x33 /
P8_42 = GPIO2_11 = EQEP2B_in, MODE3 */


fragment@1 {
target = <&epwmss2>;
overlay {
status = “okay”;

fragment@2 {
target = <&ocp>;
overlay {
test_helper: helper {
compatible = “bone-pinmux-helper”;
pinctrl-names = “default”;
pinctrl-0 = <&pinctrl_eqep2>;
status = “okay”;

Best Regards

Sorry for the delay, I'm traveling. Review RCN's "simple cape manager"
for the newer kernels, he's doing exactly what you want (mixing some
device tree stanzas that would typically be overlays directly into the
boot time device tree). That and a review of the device tree source in
the kernel tree (which makes extensive use of include) and a review of
the flattened device tree (convert the *.dtb to the *.dts source with
dtc for review) should get you started.