Hy, I´m having a very similar problem. I am using the current version of ubuntu for BBB (Ubuntu 14.04 LTS (GNU/Linux 3.8.13-bone47 armv7l)) and tried to a device tree overlay with this guide for the exact same cape: http://the8thlayerof.net/2013/10/28/canbus-beagle-bone-black-as-a-canbus-data-logger-part-2/
However the dmesg output says the loading fails: [ 2.011897] bone-capemgr bone_capemgr.9: loader: before slot-3 TT3201-001:05 (prio 0) [ 2.020116] bone-capemgr bone_capemgr.9: loader: check slot-3 TT3201-001:05 (prio 0) [ 2.042227] bone-capemgr bone_capemgr.9: loader: after slot-3 TT3201-001:05 (prio 0) [ 2.062825] bone-capemgr bone_capemgr.9: slot #3: Requesting part number/version based 'TT3201-001-05.dtbo [ 2.093253] bone-capemgr bone_capemgr.9: slot #3: Requesting firmware 'TT3201-001-05.dtbo' for board-name 'TT3201 CAN Bus Cape', version '05' [ 2.901230] bone-capemgr bone_capemgr.9: failed to load firmware 'TT3201-001-05.dtbo' [ 2.909494] bone-capemgr bone_capemgr.9: loader: failed to load slot-3 TT3201-001:05 (prio 0) and I get a permission denied when i want to add it manually with: ubuntu@arm:/sys/devices/bone_capemgr.9$ sudo echo TT3201:001 >slots -bash: slots: Permission denied There are plenty of people having this problem but i could not find a good solution yet as it should not happen in newer releases anymore. I appreciate any help??? Am Freitag, 15. November 2013 11:50:05 UTC+1 schrieb Jesper We: > > OK, I have read this > thread<https://groups.google.com/forum/#!msg/beagleboard/Iem_mHknIUM/buwAqagYukwJ>twice > now, and I still fail to see any real solution in between the > discussion of various patches. > > There is a lot of discussion in that thread about custom kernels, but my > BB Black has the latest Angstrom eMMC flasher version with everything as > default. > > I have made a Cape PCB with an RTC and 4 serial ports for UART1,2,4,5. The > Cape has an EEPROM at i2c address 0x54 (Slot #0) with the proper part > number and revision. > I have disabled the loading of all HDMI overlay features in uEnv.txt. > > On exactly the same board I can swap out my Cape for the Circuitco RS232 > cape which I have a couple of. It has the .dto files already in > /lib/firmware in the distro. > That DTO loads fine during boot, with the same priority (0) as my cape. > So it's not an issue of the eMMC not being ready. > > However, the Circuitco Rs232 Capes are loaded earlier in the boot process > than the point at which my cape fails. Since my DTO is just a merge of the > original RS232 UARTs DTOs from the distro, I cannot understand why... > > So my questions are: > - Why is the failure to load my cape coming much later in the boot process > than the Circuitco cape's success? > - Is there any way to know why the boot time loading fails, when the cape > loads fine manually? > > See below fore some transcripts. The source for my DTO is enclosed. > > /jesper > > > root@beaglebone:~# ls -l /lib/firmware/CP* > -rw-r--r-- 1 root root 1969 Nov 14 19:15 /lib/firmware/CP-CLOUDSAFE- > 00A0.dtbo > -rwxr-xr-x 1 root root 2117 Nov 14 19:13 /lib/firmware/CP-CLOUDSAFE- > 00A0.dts > > Loading the DTO manually works fine: > > root@beaglebone:/lib/firmware# echo CP-CLOUDSAFE > >/sys/devices/bone_capemgr.8/slots > root@beaglebone:/lib/firmware# dmesg > .... > [ 200.937688] bone-capemgr bone_capemgr.8: part_number > 'CP-CLOUDSAFE',version > 'N/A' > [ 200.937766] bone-capemgr bone_capemgr.8: slot #7: generic override > [ 200.937786] bone-capemgr bone_capemgr.8: bone: Using override eeprom > data at slot 7 > [ 200.937803] bone-capemgr bone_capemgr.8: slot #7: 'Override Board > Name,00A0,Override Manuf,CP-CLOUDSAFE' > [ 200.937896] bone-capemgr bone_capemgr.8: slot #7: Requesting part > number/version based 'CP-CLOUDSAFE-00A0.dtbo > [ 200.937915] bone-capemgr bone_capemgr.8: slot #7: Requesting firmware > 'CP-CLOUDSAFE-00A0.dtbo' for board-name 'Override Board Name', version > '00A0' > [ 200.947556] bone-capemgr bone_capemgr.8: slot #7: dtbo > 'CP-CLOUDSAFE-00A0.dtbo' loaded; converting to live tree > [ 200.947984] bone-capemgr bone_capemgr.8: slot #7: #5 overlays > [ 200.954890] 48022000.serial: ttyO1 at MMIO 0x48022000 (irq = 89) is a > OMAP UART1 > [ 200.958878] 48024000.serial: ttyO2 at MMIO 0x48024000 (irq = 90) is a > OMAP UART2 > [ 200.964739] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 61) is a > OMAP UART4 > [ 200.970604] 481aa000.serial: ttyO5 at MMIO 0x481aa000 (irq = 62) is a > OMAP UART5 > [ 200.974945] bone-capemgr bone_capemgr.8: slot #7: Applied #5 overlays. > .... > root@beaglebone:~# cat /sys/devices/bone_capemgr.8/slots > 1: 55:PF--- > 2: 56:PF--- > 3: 57:PF--- > 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G > 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI > 6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN > 7: ff:P-O-L Override Board Name,00A0,Override Manuf,CP-CLOUDSAFE > > > But when rebooting the board it will not load: > > > Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: Baseboard: > 'A335BNLT,0A5C,2713BBBK1211' > Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: compatible > -baseboard=ti,beaglebone-black > Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: > Skippingdisabled cape > with part# BB-BONELT-HDMI > Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: > Skippingdisabled cape > with part# BB-BONELT-HDMIN > Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: slot #0: > 'Cloudsafe IO Cape,00A0,Cashpro AB,CP-CLOUDSAFE' > Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8: slot #1: > No cape found > Jan 01 00:01:02 beaglebone kernel: bone-capemgr bone_capemgr.8:<span > style="color: #000;" c > ... -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
