On Mon, Dec 16, 2013 at 8:53 AM,  <[email protected]> wrote:
> Dear all,
>
> May I ask for your advice regarding a device tree overlay problem occuring
> at boot time (Ubuntu on BBB). My MAX-GPIO-set-00A0.dtbo file works just nice
> when I use it manually by typing the command
>
>> echo MAX-GPIO-set > slots
>
>
> (in /sys/devices/bone_capemgr.*). I conclude from this that the dtbo file
> itself is correct.
>
> Now, when I modify uEnv.txt to load the dtbo file at boot:
>
>> optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
>> capemgr.enable_partno=BB-UART5,MAX-GPIO-set
>
>
> the MAX-GPIO-set file is not applied (however, the BB_UART5 file is applied
> correctly). dmesg | grep "MAX" gives the following output:
>
>> [    0.000000] Kernel command line: console=ttyO0,115200n8
>> capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
>> capemgr.enable_partno=BB-UART5,MAX-GPIO-set root=/dev/mmcblk0p2 ro
>> rootfstype=ext4 rootwait fixrtc ip=
>> [    1.958351] bone-capemgr bone_capemgr.8: enabled_partno part_number
>> 'MAX-GPIO-set', version 'N/A', prio '0'
>> [    1.983096] bone-capemgr bone_capemgr.8: slot #8: 'Override Board
>> Name,00A0,Override Manuf,MAX-GPIO-set'
>> [    2.052857] bone-capemgr bone_capemgr.8: loader: before slot-8
>> MAX-GPIO-set:00A0 (prio 0)
>> [    2.061427] bone-capemgr bone_capemgr.8: loader: check slot-8
>> MAX-GPIO-set:00A0 (prio 0)
>> [    2.107066] bone-capemgr bone_capemgr.8: loader: after slot-8
>> MAX-GPIO-set:00A0 (prio 0)
>> [    2.175944] bone-capemgr bone_capemgr.8: slot #8: Requesting part
>> number/version based 'MAX-GPIO-set-00A0.dtbo
>> [    2.197751] bone-capemgr bone_capemgr.8: slot #8: Requesting firmware
>> 'MAX-GPIO-set-00A0.dtbo' for board-name 'Override Board Name', version
>> '00A0'
>> [    3.396200] bone-capemgr bone_capemgr.8: failed to load firmware
>> 'MAX-GPIO-set-00A0.dtbo'
>> [    3.404896] bone-capemgr bone_capemgr.8: loader: failed to load slot-8
>> MAX-GPIO-set:00A0 (prio 0)
>
>
> Any ideas would be highly appreciated. Thanks in advance!

I've recently run into the same issue for the BEAGLEBOY .dts:
https://github.com/bear24rw/gamingcape/blob/master/software/BEAGLEBOY-00A0.dts

The load triggering code is at:
https://github.com/beagleboard/linux/blob/3.8/drivers/misc/cape/beaglebone/capemgr.c
There is a call to request_firmware() at:
https://github.com/beagleboard/linux/blob/3.8/drivers/misc/cape/beaglebone/capemgr.c#L1370
This seems to be a generic internal kernel interface:
https://github.com/beagleboard/linux/blob/0250b2002e6eb3a2f7a4eef526dd107bfda3f590/Documentation/firmware_class/README

It is going to take me more than a few seconds to figure out how the
devicetree overlay mechanism is providing a firmware-loading driver. I
expect there to be something accepting the fw_entry info in the DT
overlay code, but I'm not seeing it in:
https://github.com/beagleboard/linux/tree/3.8/drivers/of

Any experts want to send me in the right direction or do I need to
break out the debug tools?


>
> Max
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to