--------------------------------------------
On Wed, 1/18/17, William Hermans <[email protected]> wrote:

 Subject: Re: [beagleboard] Re: Cape Manager for U-Boot
 To: [email protected]
 Date: Wednesday, January 18, 2017, 11:27 PM
 
 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/RobertCNels
 on/Bootloader-Builder/commit/6
 f3929a577056d10a7994252aa52183 5bf3f3984
 
 
 
 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 beagleboard+unsubscribe@google
 groups.com.
 
 To view this discussion on the web visit https://groups.google.com/d/ms
 gid/beagleboard/CAOCHtYiu5hnmw
 r23woC5ST6X7HR2KJA8%2BfQkaA8U_
 %3DpaGkO%2BBA%40mail.gmail.com .
 
 For
 more options, visit https://groups.google.com/d/op
 tout.
 
 
 
 
 
 
 
 
 
 
 
 
 -- 
 
 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.
 ermania fascista spre concesii  l-a determinat pe regele Caro  al II sa

-- 
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/1521027588.266521.1484800365877%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to