So I stopped what I was doing and did some testing. It seems as though the
current iteration of capemgr has a problem loading more than two overlays
at boot, through the cmdline parameter. Both of the "custom" overlays have
been injected into the initramfs via the script update_initrd.sh.

Worklog and testing output:
http://pastebin.com/YkHnZ4f2

On Wed, Jan 18, 2017 at 1:57 PM, William Hermans <[email protected]> wrote:

> Yet more information I noticed, sorry for the multiple posts . . . But
> notice how the custom cape is attempted to load first, but the actual
> overlay id is dead last. It's almost as though capemgr is trying to load
> them simultaneously but the ADC overlay being smaller in size won out ?
>
> root@beaglebone:~# dmesg |grep bone_capemgr
> [    0.000000] Kernel command line: console=ttyO0,115200n8
> bone_capemgr.enable_partno=controller,BB-ADC,BB-W1-P8.26
> root=UUID=826386f9-a359-428a-a111-486cd84f92b5 ro rootfstype=ext4
> rootwait coherent_pool=1M quiet ipv6.disable=1
> [    4.252789] bone_capemgr bone_capemgr: Baseboard:
> 'A335BNLT,00C0,3214BBBK0403'
> [    4.252815] bone_capemgr bone_capemgr: 
> compatible-baseboard=ti,beaglebone-black
> - #slots=4
> [    4.305592] bone_capemgr bone_capemgr: slot #0: No cape found
> [    4.365587] bone_capemgr bone_capemgr: slot #1: No cape found
> [    4.425586] bone_capemgr bone_capemgr: slot #2: No cape found
> [    4.485586] bone_capemgr bone_capemgr: slot #3: No cape found
> [    4.491376] bone_capemgr bone_capemgr: enabled_partno PARTNO
> 'controller' VER 'N/A' PR '0'
> [    4.491388] bone_capemgr bone_capemgr: slot #4: override
> [    4.491401] bone_capemgr bone_capemgr: Using override eeprom data at
> slot 4
> [    4.491415] bone_capemgr bone_capemgr: slot #4: 'Override Board
> Name,00A0,Override Manuf,controller'
> [    4.491498] bone_capemgr bone_capemgr: enabled_partno PARTNO 'BB-ADC'
> VER 'N/A' PR '0'
> [    4.491509] bone_capemgr bone_capemgr: slot #5: override
> [    4.491520] bone_capemgr bone_capemgr: Using override eeprom data at
> slot 5
> [    4.491533] bone_capemgr bone_capemgr: slot #5: 'Override Board
> Name,00A0,Override Manuf,BB-ADC'
> [    4.491602] bone_capemgr bone_capemgr: enabled_partno PARTNO
> 'BB-W1-P8.26' VER 'N/A' PR '0'
> [    4.491613] bone_capemgr bone_capemgr: slot #6: override
> [    4.491624] bone_capemgr bone_capemgr: Using override eeprom data at
> slot 6
> [    4.491637] bone_capemgr bone_capemgr: slot #6: 'Override Board
> Name,00A0,Override Manuf,BB-W1-P8.26'
> [    4.492070] bone_capemgr bone_capemgr: initialized OK.
> [    4.503689] bone_capemgr bone_capemgr: slot #5: dtbo 'BB-ADC-00A0.dtbo'
> loaded; overlay id #0
> [    4.505152] bone_capemgr bone_capemgr: slot #6: dtbo
> 'BB-W1-P8.26-00A0.dtbo' loaded; overlay id #1
> [    4.540874] bone_capemgr bone_capemgr: slot #4: dtbo
> 'controller-00A0.dtbo' loaded; overlay id #2
>
>
> On Wed, Jan 18, 2017 at 1:49 PM, William Hermans <[email protected]>
> wrote:
>
>> Just for informational purposes here is that one pin in my custom overlay:
>>
>> . . .
>>> exclusive-use =
>>>         /* the pin header uses */
>>>         "P8.11",
>>> . . .
>>> /* P8_11 (ZCZ ball R12) */
>>>             P8_11_default_pin: pinmux_P8_11_default_pin {
>>>                 pinctrl-single,pins = <0x034  0x27>; };     /* Mode 7,
>>> Pull-Down, RxActive */
>>> . . .
>>> fragment@1 {
>>>         target = <&ocp>;
>>>         __overlay__ {
>>>
>>>             P8_11_pinmux {
>>>                 compatible = "bone-pinmux-helper";
>>>                 status = "okay";
>>>                 pinctrl-names = "default";
>>>                 pinctrl-0 = <&P8_11_default_pin>;
>>>             };
>>> . . .
>>>
>>> P8_11 {
>>>                     gpio-name = "P8_11";
>>>                     gpio = <&gpio1 13 0>;
>>>                     input;
>>>                     dir-changeable;
>>>                 };
>>> . . .
>>
>>
>> Then the P8.26 1-wire overlay is exactly the same as the one example
>> 1-wire overlay included with the stock image. But I changed the pin
>> configuration to match P8.26 instead of what was it ? P9.12 was it ? No
>> idea why I'm getting that boot message, and this is the first time I've
>> ever seen it.
>>
>> On Wed, Jan 18, 2017 at 1:39 PM, William Hermans <[email protected]>
>> wrote:
>>
>>> The error I noticed on my end was: *libfdt fdt_check_header():
>>> FDT_ERR_BADMAGIC* Which did not really make sense to me as the overlays
>>> seems to work just fine. I did not check everythign with my overlays, but I
>>> did check gpio45, and according to the direciton, and value files it's
>>> configured correctly. But I was getting some odd boot log error message
>>> about the capemgr back peddling a non existent pin conflict. From where it
>>> came, I have no idea.
>>>
>>> beaglebone login: [   19.548440] omap-sham 53100000.sham: initialization
>>>> failed.
>>>> [   19.880445] pinctrl-single 44e10800.pinmux: pin 44e10834.0 already
>>>> requested by ocp:P8_11_pinmux; cannot claim for onewire
>>>> [   19.921657] pinctrl-single 44e10800.pinmux: pin-13 (onewire) status
>>>> -22
>>>> [   20.000724] pinctrl-single 44e10800.pinmux: could not request pin 13
>>>> (44e10834.0) from group pinmux_P8_11_default_pin  on device pinctrl-single
>>>> [   20.093995] w1-gpio onewire: Error applying setting, reverse things
>>>> back
>>>>
>>>
>>> That's another error message I've been noticing lately. omap_sham
>>> initialization failing. But when I take a look at the output of lsmod . . .
>>> *root@beaglebone:~#* lsmod |grep omap
>>> omap_aes               13637  0
>>> omap_rng                4572  0
>>> omap_sham              21458  0
>>> rng_core                7390  1 omap_rng
>>>
>>> It seems to have loaded fine ? So I'm guessing omap_sham is related to
>>> SHA somehow, and thus probably important. Not sure why this error message
>>> though :/
>>>  I'm also assuming it's fine since it's already loaded, but . . .I'm not
>>> 100% positive.
>>>
>>> On Wed, Jan 18, 2017 at 1:29 PM, Robert Nelson <[email protected]>
>>> wrote:
>>>
>>>> On Wed, Jan 18, 2017 at 2:24 PM, William Hermans <[email protected]>
>>>> wrote:
>>>> > Not enough memory allocated ?
>>>>
>>>> Correct by default it was only 4k, defaulted to 0x60000
>>>>
>>>> seems to have fixed the big overlays...
>>>>
>>>> https://github.com/RobertCNelson/Bootloader-Builder/commit/6
>>>> f3929a577056d10a7994252aa521835bf3f3984
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Robert Nelson
>>>> https://rcn-ee.com/
>>>>
>>>> --
>>>> 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].
>>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>>> gid/beagleboard/CAOCHtYiu5hnmwr23woC5ST6X7HR2KJA8%2BfQkaA8U_
>>>> %3DpaGkO%2BBA%40mail.gmail.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>
>

-- 
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].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORri4-GbtRRq8JaNXKj_ugZ5B6UK6KS68v15e36TZJOUWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to