[beagleboard] Can't re-establish PWM sysfs files after system crash.
Dear forum, I am running Debian 3.8.24-bone67 w/Xenomai. I have successfully used the sysfs for generating a PWM signal on the P8_13 pin for several days now by: 1. Adding the am33xx_pwm and bone_pwm_P8_13 overlay files. 2. Writing to the files in the /sys/devices/ocp.3/pwm_test_P8_13.*/ (period, duty, polarity and run). However, I had a system crash. Now, despite rebooting (+re-powering) I am not able to re-establish the situation. The overlay files seem to install. The pwm_test_P8_13.12/ directory appears, but the files for controlling the PWM is missing. I can remove and re-apply the overlays, but the files are still missing Something has obviously changed by the system crash. Please advice. Best regards Terje Froysa [ 91.601978] bone-capemgr bone_capemgr.9: part_number 'am33xx_pwm', version 'N/A' [ 91.610962] bone-capemgr bone_capemgr.9: slot #12: generic override [ 91.617590] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 12 [ 91.625705] bone-capemgr bone_capemgr.9: slot #12: 'Override Board Name,00A0,Override Manuf,am33xx_pwm' [ 91.635790] bone-capemgr bone_capemgr.9: slot #12: Requesting part number/version based 'am33xx_pwm-00A0.dtbo [ 91.646178] bone-capemgr bone_capemgr.9: slot #12: Requesting firmware 'am33xx_pwm-00A0.dtbo' for board-name 'Override Board Name', version '00A0' [ 91.661239] bone-capemgr bone_capemgr.9: slot #12: dtbo 'am33xx_pwm-00A0.dtbo' loaded; converting to live tree [ 91.672375] bone-capemgr bone_capemgr.9: slot #12: #8 overlays [ 91.683550] ehrpwm 48300200.ehrpwm: unable to select pin group [ 91.698871] ecap 48300100.ecap: unable to select pin group [ 91.714483] ehrpwm 48302200.ehrpwm: unable to select pin group [ 91.730620] ehrpwm 48304200.ehrpwm: unable to select pin group [ 91.746145] ecap 48304100.ecap: unable to select pin group [ 91.759347] bone-capemgr bone_capemgr.9: slot #12: Applied #8 overlays. [ 103.923016] bone-capemgr bone_capemgr.9: part_number 'bone_pwm_P8_13', version 'N/A' [ 103.931873] bone-capemgr bone_capemgr.9: slot #13: generic override [ 103.938516] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 13 [ 103.946631] bone-capemgr bone_capemgr.9: slot #13: 'Override Board Name,00A0,Override Manuf,bone_pwm_P8_13' [ 103.957008] bone-capemgr bone_capemgr.9: slot #13: Requesting part number/version based 'bone_pwm_P8_13-00A0.dtbo [ 103.967782] bone-capemgr bone_capemgr.9: slot #13: Requesting firmware 'bone_pwm_P8_13-00A0.dtbo' for board-name 'Override Board Name', version '00A0' [ 103.983070] bone-capemgr bone_capemgr.9: slot #13: dtbo 'bone_pwm_P8_13-00A0.dtbo' loaded; converting to live tree [ 103.994506] bone-capemgr bone_capemgr.9: slot #13: #2 overlays [ 104.005298] bone-capemgr bone_capemgr.9: slot #13: Applied #2 overlays. root@beaglebone:/home/debian# ls /sys/devices/ocp.3/pwm_test_P8_13.12/ modalias power subsystem uevent root@beaglebone:/sys/kernel/debug# cat pwm platform/48304100.ecap, 1 PWM device pwm-0 ((null) ): platform/48304200.ehrpwm, 2 PWM devices pwm-0 ((null) ): pwm-1 ((null) ): platform/48302200.ehrpwm, 2 PWM devices pwm-0 ((null) ): pwm-1 ((null) ): platform/48300100.ecap, 1 PWM device pwm-0 ((null) ): platform/48300200.ehrpwm, 2 PWM devices pwm-0 ((null) ): pwm-1 ((null) ): root@beaglebone:/sys/kernel/debug# -- 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.
[beagleboard] Where is i2c_smbus_xxxx_xxx() functions?
Dear forum, I have now verified my I2C devices using Python. I need to re-code them in C. I find i2c driver dokumented here: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/i2c/dev-interface The documentation complies with my 3.8.13-bone67 compiled and installed kernel source (KERNEL/drivers/i2c/i2c-core.c) Problem: No file in /usr/include/* contains the prototypes for the documented *i2c_smbus__()* functions. I can open/read/write to the /dev/i2c-x devices using standard read(), write() and ioctl(), but I find no higher level i2c functions. What is my problem? Please advice. Best regards Terje Froysa -- 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.
Re: [beagleboard] xeno_16550A driver install on Debian 3.8.13-bone67
Hello Charles, I have now carefully checked your suggestions. - I have checked that the UART dtbo are loaded at boot-time (by uEnv.txt) - I have built (and booted) the kernel with the xeno_16550A as loadable module. - I have checked the functionality of the /dev/ttyOx by running physical loop-back data traffic. The sudo cat /proc/tty/driver/OMAP-SERIAL reports the correct amount of traffic and the sent data is echoed correctly in another terminal window. - I have crawled the /proc/device-tree/ocp/serial* and cannot find any discrepancies. Everything seem correct. But the UARTs are now occupied by the omap_serial driver. According to Xenomai (http://xenomai.org/serial-16550a-driver/) the driver should be disabled by the setserial command. I can't get this command working. It reports the serial port but changing it results in error (regardless of the ttyO -number): debian@beaglebone:~$ setserial /dev/ttyO2 /dev/ttyO2, UART: undefined, Port: 0x, IRQ: 74 debian@beaglebone:/boot$ sudo setserial /dev/ttyO2 uart none Cannot set serial info: *Invalid argument* Consequently, I cannot load the xeno_16550A.ko module. I have browsed the net for the same problem, but have not found relevant subjects. There are no shared irq's in my problem (closest subject I found). Do you have any idea for a solution? Best regards Terje Froysa On Tuesday, November 11, 2014 3:59:51 PM UTC+1, Charles Steinkuehler wrote: On 11/11/2014 8:42 AM, Terje Froysa wrote: Dear forum, I have struggled for 4 days and I am out of ideas/suggestions on how to make this xeno_16550A driver work. 1. I have successfully installed the Xenomai 2.6.4 and the Debian 3.8.13. 2. Self-developed RTDM driver is working satisfactory. 3. But when irq numbers are defined for the kernel installed xeno_16550A driver the boot process crashes (attached log). Questions from Xenomai forum is: 1. The xeno_16550A driver uses byte access, have you checked the AM33xx TRM to check that this is valid? 2. Is the interface clock for the serial device you want to use enabled? From the TRM it seems that the 16550 compliant UART accommodates byte accesses. When installing and removing serial port drivers I can't see any associated clock enabling options in the menuconfig. I haven't tried getting the UARTs working with Xenomai, but have some general suggestions if you haven't tried them already, mostly focused on making sure the UART is actually enabled in the device-tree: * Do you have the UART enabled in the default device-tree being loaded by U-Boot? This should setup the clocks and other house-keeping required to make the UART actually work at the hardware level. * Can you build the Xenomai driver as a loadable module and try to load it after the system boots? If so, this will make it much easier to test variations on the running system. * Have you tried booting without the Xenomai serial module enabled and talking directly to the memory region used by the UART (via mmap() of /dev/mem or similar)? This could help you get your device tree properly setup so you know the UART is enabled before trying to boot the kernel with the serial driver enabled. * If it's a device-tree problem, you can boot with a working kernel and crawl through the live device-tree (via /proc/device-tree/ocp/serial*/) and make sure everything is as you expect. -- Charles Steinkuehler cha...@steinkuehler.net javascript: -- 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.
Re: [beagleboard] xeno_16550A driver install on Debian 3.8.13-bone67
Hello again, While having problems with the command: setserial /dev/ttyOx usart none I started to look at /lib/modprobe.d/aliases.conf I wonder if it is possible to set the xeno_16550A as an alias to the major number 248 (ttyOx): alias char-major-248-1 xeno_16540A alias char-major-248-2 xeno_16540A alias char-major-248-4 xeno_16540A Would this be a feasible solution for installing the xeno_16550A driver instead of the omap_usart driver? Best regards Terje -- debian@beaglebone:/lib/modprobe.d$ more aliases.conf # These are the standard aliases for devices and kernel drivers. # This file does not need to be modified. # # No new aliases should be added to this file, please file a bug against # the kernel for any aliases which are still not built-in. : # character devices ## alias char-major-10-1 psmouse : #alias char-major-240-* hsfserial #alias char-major-241-* hsfserial On Wednesday, November 12, 2014 1:21:06 PM UTC+1, Terje Froysa wrote: Hello Charles, I have now carefully checked your suggestions. - I have checked that the UART dtbo are loaded at boot-time (by uEnv.txt) - I have built (and booted) the kernel with the xeno_16550A as loadable module. - I have checked the functionality of the /dev/ttyOx by running physical loop-back data traffic. The sudo cat /proc/tty/driver/OMAP-SERIAL reports the correct amount of traffic and the sent data is echoed correctly in another terminal window. - I have crawled the /proc/device-tree/ocp/serial* and cannot find any discrepancies. Everything seem correct. But the UARTs are now occupied by the omap_serial driver. According to Xenomai (http://xenomai.org/serial-16550a-driver/) the driver should be disabled by the setserial command. I can't get this command working. It reports the serial port but changing it results in error (regardless of the ttyO -number): debian@beaglebone:~$ setserial /dev/ttyO2 /dev/ttyO2, UART: undefined, Port: 0x, IRQ: 74 debian@beaglebone:/boot$ sudo setserial /dev/ttyO2 uart none Cannot set serial info: *Invalid argument* Consequently, I cannot load the xeno_16550A.ko module. I have browsed the net for the same problem, but have not found relevant subjects. There are no shared irq's in my problem (closest subject I found). Do you have any idea for a solution? Best regards Terje Froysa On Tuesday, November 11, 2014 3:59:51 PM UTC+1, Charles Steinkuehler wrote: On 11/11/2014 8:42 AM, Terje Froysa wrote: Dear forum, I have struggled for 4 days and I am out of ideas/suggestions on how to make this xeno_16550A driver work. 1. I have successfully installed the Xenomai 2.6.4 and the Debian 3.8.13. 2. Self-developed RTDM driver is working satisfactory. 3. But when irq numbers are defined for the kernel installed xeno_16550A driver the boot process crashes (attached log). Questions from Xenomai forum is: 1. The xeno_16550A driver uses byte access, have you checked the AM33xx TRM to check that this is valid? 2. Is the interface clock for the serial device you want to use enabled? From the TRM it seems that the 16550 compliant UART accommodates byte accesses. When installing and removing serial port drivers I can't see any associated clock enabling options in the menuconfig. I haven't tried getting the UARTs working with Xenomai, but have some general suggestions if you haven't tried them already, mostly focused on making sure the UART is actually enabled in the device-tree: * Do you have the UART enabled in the default device-tree being loaded by U-Boot? This should setup the clocks and other house-keeping required to make the UART actually work at the hardware level. * Can you build the Xenomai driver as a loadable module and try to load it after the system boots? If so, this will make it much easier to test variations on the running system. * Have you tried booting without the Xenomai serial module enabled and talking directly to the memory region used by the UART (via mmap() of /dev/mem or similar)? This could help you get your device tree properly setup so you know the UART is enabled before trying to boot the kernel with the serial driver enabled. * If it's a device-tree problem, you can boot with a working kernel and crawl through the live device-tree (via /proc/device-tree/ocp/serial*/) and make sure everything is as you expect. -- Charles Steinkuehler cha...@steinkuehler.net -- 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
Re: [beagleboard] xeno_16550A driver install on Debian 3.8.13-bone67
Tried with an alias for the ttyO4: alias char-major-248-4 xeno_16550A But no reaction or error messages in dmesg, nor a change in driver link: lrwxrwxrwx 1 root root 0 Nov 12 13:41 /sys/dev/char/248:4/device/driver - ../../../bus/platform/drivers/omap_uart Do the aliases require the kernel module to be included in the kernel or am I barking up the wrong tree? Please advice anyone... Regards Terje On Wednesday, November 12, 2014 2:34:51 PM UTC+1, Terje Froysa wrote: Hello again, While having problems with the command: setserial /dev/ttyOx usart none I started to look at /lib/modprobe.d/aliases.conf I wonder if it is possible to set the xeno_16550A as an alias to the major number 248 (ttyOx): alias char-major-248-1 xeno_16550A alias char-major-248-2 xeno_16550A alias char-major-248-4 xeno_16550A Would this be a feasible solution for installing the xeno_16550A driver instead of the omap_usart driver? Best regards Terje -- debian@beaglebone:/lib/modprobe.d$ more aliases.conf # These are the standard aliases for devices and kernel drivers. # This file does not need to be modified. # # No new aliases should be added to this file, please file a bug against # the kernel for any aliases which are still not built-in. : # character devices ## alias char-major-10-1 psmouse : #alias char-major-240-* hsfserial #alias char-major-241-* hsfserial On Wednesday, November 12, 2014 1:21:06 PM UTC+1, Terje Froysa wrote: Hello Charles, I have now carefully checked your suggestions. - I have checked that the UART dtbo are loaded at boot-time (by uEnv.txt) - I have built (and booted) the kernel with the xeno_16550A as loadable module. - I have checked the functionality of the /dev/ttyOx by running physical loop-back data traffic. The sudo cat /proc/tty/driver/OMAP-SERIAL reports the correct amount of traffic and the sent data is echoed correctly in another terminal window. - I have crawled the /proc/device-tree/ocp/serial* and cannot find any discrepancies. Everything seem correct. But the UARTs are now occupied by the omap_serial driver. According to Xenomai (http://xenomai.org/serial-16550a-driver/) the driver should be disabled by the setserial command. I can't get this command working. It reports the serial port but changing it results in error (regardless of the ttyO -number): debian@beaglebone:~$ setserial /dev/ttyO2 /dev/ttyO2, UART: undefined, Port: 0x, IRQ: 74 debian@beaglebone:/boot$ sudo setserial /dev/ttyO2 uart none Cannot set serial info: *Invalid argument* Consequently, I cannot load the xeno_16550A.ko module. I have browsed the net for the same problem, but have not found relevant subjects. There are no shared irq's in my problem (closest subject I found). Do you have any idea for a solution? Best regards Terje Froysa On Tuesday, November 11, 2014 3:59:51 PM UTC+1, Charles Steinkuehler wrote: On 11/11/2014 8:42 AM, Terje Froysa wrote: Dear forum, I have struggled for 4 days and I am out of ideas/suggestions on how to make this xeno_16550A driver work. 1. I have successfully installed the Xenomai 2.6.4 and the Debian 3.8.13. 2. Self-developed RTDM driver is working satisfactory. 3. But when irq numbers are defined for the kernel installed xeno_16550A driver the boot process crashes (attached log). Questions from Xenomai forum is: 1. The xeno_16550A driver uses byte access, have you checked the AM33xx TRM to check that this is valid? 2. Is the interface clock for the serial device you want to use enabled? From the TRM it seems that the 16550 compliant UART accommodates byte accesses. When installing and removing serial port drivers I can't see any associated clock enabling options in the menuconfig. I haven't tried getting the UARTs working with Xenomai, but have some general suggestions if you haven't tried them already, mostly focused on making sure the UART is actually enabled in the device-tree: * Do you have the UART enabled in the default device-tree being loaded by U-Boot? This should setup the clocks and other house-keeping required to make the UART actually work at the hardware level. * Can you build the Xenomai driver as a loadable module and try to load it after the system boots? If so, this will make it much easier to test variations on the running system. * Have you tried booting without the Xenomai serial module enabled and talking directly to the memory region used by the UART (via mmap() of /dev/mem or similar)? This could help you get your device tree properly setup so you know the UART is enabled before trying to boot the kernel with the serial driver enabled. * If it's a device-tree
Re: [beagleboard] xeno_16550A driver install on Debian 3.8.13-bone67
Thanks Charles, I appreciate your ideas. I seem stuck between a rock and a hard place with very little substantial experiences to collect from the communities. I will try a couple of permutations more before I may revert to using the standard Linux drivers. I also got some comments from Xenomai (Gilles Chanteperdrix) below. Regards Terje Froysa At first sight, I would say that the omap_serial driver does not implement the necessary support (probably some ioctls), for what setserial is trying to do. I see several ways out: - implement the missing support in omap serial so that you can use the setserial none command; - try and use the 8250 driver instead of the omap_serial driver, since the omap serial devices are 8250 compatible, this driver supports the necessary ioctls for the setserial none command to work. At some point in time, I know using this serial driver for the kernel console worked, but I do not know if it was by chance (u-boot enables the clock, so the driver does not have to enable it), and if it still works; - do not enable any uart in the kernel configuration, neither omap_serial, nor 8250, and arrange for the clocks to be started before loading the xeno_16550a driver. On Wednesday, November 12, 2014 3:28:52 PM UTC+1, Charles Steinkuehler wrote: On 11/12/2014 6:21 AM, Terje Froysa wrote: Everything seem correct. But the UARTs are now occupied by the omap_serial driver. According to Xenomai (http://xenomai.org/serial-16550a-driver/) the driver should be disabled by the setserial command. I can't get this command working. It reports the serial port but changing it results in error (regardless of the ttyO -number): debian@beaglebone:~$ setserial /dev/ttyO2 /dev/ttyO2, UART: undefined, Port: 0x, IRQ: 74 debian@beaglebone:/boot$ sudo setserial /dev/ttyO2 uart none Cannot set serial info: *Invalid argument* Consequently, I cannot load the xeno_16550A.ko module. I have browsed the net for the same problem, but have not found relevant subjects. There are no shared irq's in my problem (closest subject I found). Do you have any idea for a solution? I _think_ the problem may be that if you don't enable the serial port in the device-tree than Xenomai encounters a bus error when accessing the address range (not entirely unexpected, since the UART's clock is probably turned off). But if you enable the UART in the device tree, Linux takes control of the port and Xenomai can't access it. Other than asking for advice on the Xenomai list, you might try booting with the Xenomai kernel and a device tree that _disables_ the UART you're trying to use. I would expect trying to load the xeno_16550A module to fail (as it does when you boot the kernel with the module enabled), but you should be able to manually setup the required low-level hardware configuration at which point you ought to be able to load the driver. Or in other words, I think you need to perform the hardware setup from the TI UART driver prior to loading the Xenomai serial driver. -- Charles Steinkuehler cha...@steinkuehler.net javascript: -- 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.
Re: [beagleboard] xeno_16550A driver install on Debian 3.8.13-bone67
Ok Charles, It doesn't seem very promising this comment from Gilles: I just had a quick look at the omap-serial.c driver and: - it does not do anything that I can see to enable its clocks - it does NOT use byte access but word access, that is, its registers are 16 bits wide. Unfortunately, as far as I can tell, the xeno_16550A driver only supports byte access. So, if you want it to work, you have to modify the driver to accept a regshift parameter applied to all offsets and use the corresponding readw if regshift is 2 or readl if regshift is 4. On Wednesday, November 12, 2014 3:52:19 PM UTC+1, Charles Steinkuehler wrote: Gilles' 3rd option is what I was referring to trying. The other two options seem workable as well. The best choice depends on what you're more comfortable working with. On 11/12/2014 8:41 AM, Terje Froysa wrote: Thanks Charles, I appreciate your ideas. I seem stuck between a rock and a hard place with very little substantial experiences to collect from the communities. I will try a couple of permutations more before I may revert to using the standard Linux drivers. I also got some comments from Xenomai (Gilles Chanteperdrix) below. Regards Terje Froysa At first sight, I would say that the omap_serial driver does not implement the necessary support (probably some ioctls), for what setserial is trying to do. I see several ways out: - implement the missing support in omap serial so that you can use the setserial none command; - try and use the 8250 driver instead of the omap_serial driver, since the omap serial devices are 8250 compatible, this driver supports the necessary ioctls for the setserial none command to work. At some point in time, I know using this serial driver for the kernel console worked, but I do not know if it was by chance (u-boot enables the clock, so the driver does not have to enable it), and if it still works; - do not enable any uart in the kernel configuration, neither omap_serial, nor 8250, and arrange for the clocks to be started before loading the xeno_16550a driver. On Wednesday, November 12, 2014 3:28:52 PM UTC+1, Charles Steinkuehler wrote: On 11/12/2014 6:21 AM, Terje Froysa wrote: Everything seem correct. But the UARTs are now occupied by the omap_serial driver. According to Xenomai (http://xenomai.org/serial-16550a-driver/) the driver should be disabled by the setserial command. I can't get this command working. It reports the serial port but changing it results in error (regardless of the ttyO -number): debian@beaglebone:~$ setserial /dev/ttyO2 /dev/ttyO2, UART: undefined, Port: 0x, IRQ: 74 debian@beaglebone:/boot$ sudo setserial /dev/ttyO2 uart none Cannot set serial info: *Invalid argument* Consequently, I cannot load the xeno_16550A.ko module. I have browsed the net for the same problem, but have not found relevant subjects. There are no shared irq's in my problem (closest subject I found). Do you have any idea for a solution? I _think_ the problem may be that if you don't enable the serial port in the device-tree than Xenomai encounters a bus error when accessing the address range (not entirely unexpected, since the UART's clock is probably turned off). But if you enable the UART in the device tree, Linux takes control of the port and Xenomai can't access it. Other than asking for advice on the Xenomai list, you might try booting with the Xenomai kernel and a device tree that _disables_ the UART you're trying to use. I would expect trying to load the xeno_16550A module to fail (as it does when you boot the kernel with the module enabled), but you should be able to manually setup the required low-level hardware configuration at which point you ought to be able to load the driver. Or in other words, I think you need to perform the hardware setup from the TI UART driver prior to loading the Xenomai serial driver. -- Charles Steinkuehler cha...@steinkuehler.net javascript: -- Charles Steinkuehler cha...@steinkuehler.net javascript: -- 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.
Re: [beagleboard] xeno_16550A driver install on Debian 3.8.13-bone67
Ok Robert, If I enable the 8250/16550 in the menuconfig this driver connects to /dev/ttySx. The ttyO[1,2,4] appears and vanishes with the BB-UARTx dtbo's The ttySx devices does not work anyhow (while not enabled via any dtbo) Is there any method of enabling the ttySx devices if a 8250 driver is preferred? Or, a method to associate the 8250 driver with the ttyOx devices? Regards Terje On Wednesday, November 12, 2014 3:46:39 PM UTC+1, RobertCNelson wrote: On Wed, Nov 12, 2014 at 8:41 AM, Terje Froysa terje@sintef.no javascript: wrote: Thanks Charles, I appreciate your ideas. I seem stuck between a rock and a hard place with very little substantial experiences to collect from the communities. I will try a couple of permutations more before I may revert to using the standard Linux drivers. I also got some comments from Xenomai (Gilles Chanteperdrix) below. Regards Terje Froysa At first sight, I would say that the omap_serial driver does not implement the necessary support (probably some ioctls), for what setserial is trying to do. I see several ways out: - implement the missing support in omap serial so that you can use the setserial none command; - try and use the 8250 driver instead of the omap_serial driver, since the omap serial devices are 8250 compatible, this driver supports the necessary ioctls for the setserial none command to work. At some point in time, I know using this serial driver for the kernel console worked, but I do not know if it was by chance (u-boot enables the clock, so the driver does not have to enable it), and if it still works; Ironically, the omap_serial branched from the 8250 driver around 3 years ago, currently linux-omap developers are working on merging back to using the 8250 based driver in a future kernel version (with a big pile of patches).. Regards, -- Robert Nelson http://www.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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] xeno_16550A driver install on Debian 3.8.13-bone67
Robert, just for my curiosity and pease of mind: If the 8250 have been no mainline for several years and there are no dtbo's to enable it. Why is the ttySx still there and the 8250 by default enabled in the -bone67 ? Regards Terje On Wednesday, November 12, 2014 5:07:59 PM UTC+1, RobertCNelson wrote: On Wed, Nov 12, 2014 at 9:56 AM, Terje Froysa terje@sintef.no javascript: wrote: Ok Robert, If I enable the 8250/16550 in the menuconfig this driver connects to /dev/ttySx. The ttyO[1,2,4] appears and vanishes with the BB-UARTx dtbo's The ttySx devices does not work anyhow (while not enabled via any dtbo) Is there any method of enabling the ttySx devices if a 8250 driver is preferred? Or, a method to associate the 8250 driver with the ttyOx devices? To utilize the 8250 driver, you will also need to change the *.dts file. Search: http://www.spinics.net/lists/linux-omap/ You'll find all the patches required to make it work on mainline, so you'll also have lots of fun backporting that those.. Regards, -- Robert Nelson http://www.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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] xeno_16550A driver install on Debian 3.8.13-bone67
Thanks Robert, for taking your time to enlight a newbie. The fog is slowly lifting Regards Terje On Wednesday, November 12, 2014 6:01:52 PM UTC+1, RobertCNelson wrote: On Wed, Nov 12, 2014 at 10:50 AM, Terje Froysa terje@sintef.no javascript: wrote: Robert, just for my curiosity and pease of mind: If the 8250 have been no mainline for several years and there are no dtbo's to enable it. Why is the ttySx still there and the 8250 by default enabled in the -bone67 ? The history goes like this.. Back in the board era, omap used the 8250 driver, then new non-generic features where added enabling omap features, thus making the omap-serial driver. Then came device tree's.. First the omap-serial driver got it's dts bindings and all omap devices used them. In the background, 8250 got some more generic enhancements and generic dts bindings... Fast forward the 8250 now has even shinny-er better features then the lagging omap-serial driver.. Thus it was decided to move back, in a release or two.. That ^ may be childlish, but it's the condensed version of pages and pages of discussions on linux-omap Regards, -- Robert Nelson http://www.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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] /etc/sysctl.conf
Hi, I am trying to decide where to enter boot-time kernel parameters. It seem to me that the /etc/sysctl.conf or /etc/sysclt.d is an appropriate place. But entering parameters here is not reflected in dmesg while entering the parameters as kernel command in uEnv.txt does. Question: Is the sysctl.conf in use and functional in Debian 3.8.13? Best regards Terje Froysa -- 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.
Re: [beagleboard] Disable CONFIG_SERIAL_OMAP
Not being able to disable the CONFIG_SERIAL_OMAP in the make menuconfig, I edited the .config file and re-compiled the kernel. Despite this, the CONFIG_SERIAL_OMAP is not disabled and has reappeared with: CONFIG_SERIAL_OMAP=y CONFIG_SERIAL_OMAP_CONSOLE=y What can I do to disable the SERIAL_OMAP? Please advice. Regards Terje -- 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.
[beagleboard] Re: make modules_install gets wrong path
Thanks Robert! This saved my day. I just had to remove the local version setting in the menuconfig and use the LOCALVERSION=-bone67 I guess this is a flaw in the making that will be corrected later. Best regards Terje Froysa -- 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.
Re: [beagleboard] Disable CONFIG_SERIAL_OMAP
Ok thanks, Problem is that the -*- marks can't be altered in the menuconfig character graphics. How do I turn off these settings? Do I have to edit the .config file? Regards Terje -- 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.
[beagleboard] Disabe CONFIG_SERIAL_OMAP ?
I need to disable CONFIG_SERIAL_OMAP in the debian 3.8.13-bone67 make menuconfig According to help this is synonymous with the menuconfig entries: -*- OMAP serial port support -*- Console on OMAP serial port I cant turn off these entries. Is it possible? According to Gilles Chanteperdrix at Xenomai, these entries must be disabled to use the xeno-16550A serial driver. Best regards Terje Froysa -- 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.
[beagleboard] Disable CONFIG_SERIAL_OMAP
I need to disable CONFIG_SERIAL_OMAP in the debian 3.8.13-bone67 make menuconfig. According to help this is synonymous with the menuconfig entries: -*- OMAP serial port support -*- Console on OMAP serial port I cant turn off these entries. Is it possible? According to Gilles Chanteperdrix at Xenomai, these entries must be disabled to use the xeno-16550A serial driver. Best regards Terje Froysa -- 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.
[beagleboard] make modules_install gets wrong path
Hi, I am trying to run a make modules_install but can't get control over the KERNELRELEASE. In make menuconfig I have set up the local version to -bone67, but somehow a '+' is always added to the kernel version. (also reflected in include/generated/utsrelease.h) Hence, I end up with a wrong path: DEPMOD 3.8.13-bone67+ WARNING: could not open /lib/modules/3.8.13-bone67+/modules.order: No such file or directory WARNING: could not open /lib/modules/3.8.13-bone67+/modules.builtin: No such file or directory Please advice. Best regards Terje Froysa -- 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.
[beagleboard] Re: Make modules modules_install problem.
Adding to my observations: By inspecting the bb-kernel/tools/local_install.sh I found that the 3.8.13+ probably stems from the file ./KERNEL/include/generated/utsrelease.h The script sets the KERNEL_UTS to 3.8.13+ by extracting the parameter from the utsrelease.h As the kernel version is distributed as 3.8.13-bone67, this seem to be a flaw in the kernel build/install system? -- 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.
[beagleboard] Make modules modules_install problem.
Dear forum, I am trying to compile and install a kernel module in my Debian 3.8.13-bone67 / Xenomai environment. The compile runs fine, but the modules modules_install causes a warning due to a wrong path (see below). The path is correct except for the 3.8.13+ which should have been 3.8.13-bone67 I am running a very simple makefile (maybe too simple?). Please advice. Best regards Terje Froysa *Makefile:* debian@beaglebone:~/gps_test$ cat Makefile obj-m := rtgps_1pps.o KSRC := /lib/modules/$(shell uname -r)/source EXTRA_CFLAGS := -I$(KSRC)/include/xenomai -I$(KSRC)/include/xenomai/posix -I$(KSRC)/arch/arm/mach-omap2 all: make -C $(KSRC) $(EXTRA_CFLAGS) M=`pwd` modules modules_install clean: make -C $(KSRC) M=`pwd` clean *Output:* debian@beaglebone:~/gps_test$ sudo make make -C /lib/modules/3.8.13-bone67/source -I/lib/modules/3.8.13-bone67/source/include/xenomai -I/lib/modules/3.8.13-bone67/source/include/xenomai/posix -I/lib/modules/3.8.13-bone67/source/arch/arm/mach-omap2 M=`pwd` modules modules_install make[1]: Entering directory `/home/debian/disk/bb-kernel/KERNEL' Building modules, stage 2. MODPOST 1 modules INSTALL /home/debian/gps_test/rtgps_1pps.ko DEPMOD *3.8.13+* WARNING: could not open /lib/modules/*3.8.13+*/modules.order: No such file or directory WARNING: could not open /lib/modules/3.8.13+/modules.builtin: No such file or directory make[1]: Leaving directory `/home/debian/disk/bb-kernel/KERNEL' -- 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.
[beagleboard] Debian 3.8.13-bone67 and Xenomai 2.5.4
Dear forum, I have installed a new kernel based on 3.8.13-bone67 and Xenomai 2.5.4 by means of the recipes found in: http://elinux.org/EBC_Xenomai http://elinux.org/EBC_Installing_Kernel_Source The new kernel runs and the latency tests reports as promised. However, when I try to compile a RTDM compliant driver I run into problems finding the Xenomai related include-files. Despite moving from cross-compiling to native-compiling, the usr/include/linux/ipipe.h etc. is still missing. I spot the missing files in: ./bb-kernel/KERNEL/arch/arm/include/asm But I can't identify any configuration that will produce a correct compiler environment. I have checked the Xenomai read-me files and cannot find any discrepancies. The Xenomai support refers to NIH (Not Invented Here) and leaves me in darkness. Are there anyone in this forum with a tip for me? Best regards Terje Froysa -- 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.
[beagleboard] Re: Debian 3.8.13-bone67 and Xenomai 2.5.4
Updated information/questions Two tip received outside this forum: Tip1: You have to install linux headers for your version (since it is not expected needed by normal users) sudo apt-get install linux-headers-linux version Tip2: Download Linux source files. Tip1 problem: I don't find package linux-headers-3.8.13-bone67 Tip2 problem: I already have compiled kernel and source from Xenomai patched 3.8.13-bone67 Will this download contain the Xenomai related files? (I read that Xenomai is included in kernel now, but what Xenomai files?) Best regards Terje Froysa -- 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.
[beagleboard] Re: Device tree overlays may load manually, but not at boot.
Thanks for good advice! I have taken care of the information for my further work. I will be away for 3 weeks now, so i can't attend this forum for a while if additional posts are made. Best regards Terje Froysa -- 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.
[beagleboard] Re: Device tree overlays may load manually, but not at boot.
Update: Originally there was a BB-SPIDEV1-00A0.dtbo in the /lib/firmware directory. This file loads when enabled in the uEnv.txt. The file is unique in the system (checked with find / ) Pin configuration of the pins if no .dtbo is loaded is 0x27. *Experiments:* 1. Changing the name of the original file (and in the uEnv.txt) - The loading fails under boot. 2. Compiling the BB-SPI1-SWP-01-00A0.dts into a file named BB-SPIDEV1-00A0.dtbo and copying it til /lib/firmware. This file swaps the D0 and D1 pins. - The load works, but the* pin configuration is identical with the original file loaded, i.e. D0/D1 are not swapped*...?? 3. Compiling same file into BB-SPIDEV1-SWP-00A0.dtbo, cp to /lib/firmware. Removing overlay file load in uEnv.txt and loading BB-SPIDEV1-SWP manually. - The manual load works and *pins configuration is changed, D0/D1 are swapped!* Can anyone please explain this enigma?? Is there at all any down-to-earth documentation on this subject except for all the hear-says? Best regards Terje Froysa On Thursday, August 14, 2014 6:02:32 PM UTC+2, Terje Froysa wrote: Dear Forum, I have now turned the web outside-in to find an answer to this question. I see a lot of subjects touching the subject, but the answers and suggestions are mostly in the hear-say category and points in different directions putting me off in an endless ghost-hunt. I have been testing various overlays, some loads without problems, other won't load but can be manually loaded after boot. I can even rename an overlay that loads and it stops loading even if the content is identical. I have changed the sequence of loading proving that the file system is ready at the time of loading. I have tested the suggested solutions from: http://elinux.org/BeagleBone_Black_Enable_SPIDEV The .dtbo files does not load at boot, but can be loaded manually later. And working when loaded! The boot log gives no clue of what the problem may be. - Is it the content of the .dtbo? - Is it the name of the .dtbo file? Please advice Best regards Terje Froysa *Running system:* debian@beaglebone:~$ uname -a Linux beaglebone 3.8.13-bone50 #1 SMP Tue May 13 13:24:52 UTC 2014 armv7l GNU/Linux *Boot log showing BB-SPI1-SWP-01 not loading:* debian@beaglebone:~$ dmesg |grep BB- [ 0.00] Kernel command line: console=tty0 console=ttyO0,115200n8 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN capemgr.enable_partno=BB-I2C1,BB-SPI1-SWP-01 root=UUID=5a42a22f-1771-4c44-93ef-8879c38b63d9 ro rootfstype=ext4 rootwait fixrtc quiet init=/lib/systemd/systemd [ 0.565888] bone-capemgr bone_capemgr.9: Skipping disabled cape with part# BB-BONELT-HDMI [ 0.565937] bone-capemgr bone_capemgr.9: Skipping disabled cape with part# BB-BONELT-HDMIN [ 0.714324] bone-capemgr bone_capemgr.9: slot #4: 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G' [ 0.714439] bone-capemgr bone_capemgr.9: slot #5: 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI' [ 0.714540] bone-capemgr bone_capemgr.9: slot #6: 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN' [ 0.714612] bone-capemgr bone_capemgr.9: enabled_partno part_number 'BB-I2C1', version 'N/A', prio '0' [ 0.714653] bone-capemgr bone_capemgr.9: slot #7: 'Override Board Name,00A0,Override Manuf,BB-I2C1' [ 0.714725] bone-capemgr bone_capemgr.9: enabled_partno part_number 'BB-SPI1-SWP-01', version 'N/A', prio '0' [ 0.714762] bone-capemgr bone_capemgr.9: slot #8: 'Override Board Name,00A0,Override Manuf,BB-SPI1-SWP-01' [ 0.714928] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape with part# BB-BONELT-HDMI [ 0.714943] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape with part# BB-BONELT-HDMIN [ 0.715135] bone-capemgr bone_capemgr.9: loader: before slot-4 BB-BONE-EMMC-2G:00A0 (prio 1) [ 0.715149] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1) [ 0.715228] bone-capemgr bone_capemgr.9: loader: before slot-7 BB-I2C1:00A0 (prio 0) [ 0.715240] bone-capemgr bone_capemgr.9: loader: check slot-7 BB-I2C1:00A0 (prio 0) [ 0.715732] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1) [ 0.718442] bone-capemgr bone_capemgr.9: loader: after slot-7 BB-I2C1:00A0 (prio 0) [ 0.718462] bone-capemgr bone_capemgr.9: slot #7: Requesting part number/version based 'BB-I2C1-00A0.dtbo [ 0.718477] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 'BB-I2C1-00A0.dtbo' for board-name 'Override Board Name', version '00A0' [ 0.718506] bone-capemgr bone_capemgr.9: slot #7: dtbo 'BB-I2C1-00A0.dtbo' loaded; converting to live tree [ 0.720710] bone-capemgr bone_capemgr.9: loader: before slot-8 BB-SPI1-SWP-01:00A0 (prio 0) [ 0.720724] bone-capemgr bone_capemgr.9: loader: check slot-8 BB-SPI1-SWP-01:00A0 (prio 0) [ 0.720740] bone-capemgr bone_capemgr.9: loader: after slot-8
Re: [beagleboard] Re: Device tree overlays may load manually, but not at boot.
Thanks for your reply. We intend to use this BBB professionally and need to change the pin configurations at boot. From your reply it seem to me that device overlays cannot be used as intended. We can remove and add predefined modules, but not change them... Is this really true? Does that mean that we cannot design a cape with our own ID and corresponding dtbo? If yes, what will you recommend for us to do to solve the problem? - If I generate a complete new am335x-boneblack.dtb, will that do? - Or do we have to re-compile the kernel? Best regards Terje Froysa -- 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.
Re: [beagleboard] Re: Device tree overlays may load manually, but not at boot.
Thanks again for your quick reply! With as intended I refer to the lecture given at: *http://elinux.org/BeagleBone_Black_Enable_SPIDEV* http://elinux.org/BeagleBone_Black_Enable_SPIDEV and many other lectures i have studied made me think that I (anyone) could throw out predefined pin configurations and ad-hoc substitute them with my own in the /lib/firmware directory. When I find the .dtbo working by placing them /lib/firmware and using echo device.dtbo $SLOTS, I (of course) get confused when the files are not accepted (and with no explanation) during boot. The confusion arises (like you say) when no other .dtbo file is accepted during boot but the built ins while no information is given but loading failed. Replacing an existing .dtbo and finding that the pins were configured as the origninal file suggests that the content of the /lib/firmware .dtbo's doesn't seem to count at all. I have used some 4-5 working days on this subject convinced that it all had to be my mistake since I couldn't find any consistent information about this. All documents and lectures on the web seemed to tell that loading custom ad-hoc .dtbo's by uEnv.txt was feasible. You are the first to tell me that the Linux cape configurations have to be furnished by anyone but ourselves. We are making a one-of-a-kind cape in a scientific research context. It really shouldn't be necessary to submit a short-sighted experiment although in professional context. We are doing changes steadily and plan to use BBB in many different activities (also in cooperation with the NTNU, Norwegian University of Technology). I don't think we will want to overthrow you with numerous patches for different projects. Well, I'm learning, but knowledge is sometime hard to obtain. In 1987, as a Unix system responsible, I learned the saying: Manuals...? Which manuals...? This is Unix my son, you gotta know! :-) I guess I have to do a script running after boot that loads the .dtbo and reconfigures the pins. Best regards Terje Froysa -- 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.
[beagleboard] Device tree overlays may load manually, but not at boot.
Dear Forum, I have now turned the web outside-in to find an answer to this question. I see a lot of subjects touching the subject, but the answers and suggestions are mostly in the hear-say category and points in different directions putting me off in an endless ghost-hunt. I have been testing various overlays, some loads without problems, other won't load but can be manually loaded after boot. I can even rename an overlay that loads and it stops loading even if the content is identical. I have changed the sequence of loading proving that the file system is ready at the time of loading. I have tested the suggested solutions from: http://elinux.org/BeagleBone_Black_Enable_SPIDEV The .dtbo files does not load at boot, but can be loaded manually later. And working when loaded! The boot log gives no clue of what the problem may be. - Is it the content of the .dtbo? - Is it the name of the .dtbo file? Please advice Best regards Terje Froysa *Running system:* debian@beaglebone:~$ uname -a Linux beaglebone 3.8.13-bone50 #1 SMP Tue May 13 13:24:52 UTC 2014 armv7l GNU/Linux *Boot log showing BB-SPI1-SWP-01 not loading:* debian@beaglebone:~$ dmesg |grep BB- [ 0.00] Kernel command line: console=tty0 console=ttyO0,115200n8 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN capemgr.enable_partno=BB-I2C1,BB-SPI1-SWP-01 root=UUID=5a42a22f-1771-4c44-93ef-8879c38b63d9 ro rootfstype=ext4 rootwait fixrtc quiet init=/lib/systemd/systemd [ 0.565888] bone-capemgr bone_capemgr.9: Skipping disabled cape with part# BB-BONELT-HDMI [ 0.565937] bone-capemgr bone_capemgr.9: Skipping disabled cape with part# BB-BONELT-HDMIN [ 0.714324] bone-capemgr bone_capemgr.9: slot #4: 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G' [ 0.714439] bone-capemgr bone_capemgr.9: slot #5: 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI' [ 0.714540] bone-capemgr bone_capemgr.9: slot #6: 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN' [ 0.714612] bone-capemgr bone_capemgr.9: enabled_partno part_number 'BB-I2C1', version 'N/A', prio '0' [ 0.714653] bone-capemgr bone_capemgr.9: slot #7: 'Override Board Name,00A0,Override Manuf,BB-I2C1' [ 0.714725] bone-capemgr bone_capemgr.9: enabled_partno part_number 'BB-SPI1-SWP-01', version 'N/A', prio '0' [ 0.714762] bone-capemgr bone_capemgr.9: slot #8: 'Override Board Name,00A0,Override Manuf,BB-SPI1-SWP-01' [ 0.714928] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape with part# BB-BONELT-HDMI [ 0.714943] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape with part# BB-BONELT-HDMIN [ 0.715135] bone-capemgr bone_capemgr.9: loader: before slot-4 BB-BONE-EMMC-2G:00A0 (prio 1) [ 0.715149] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1) [ 0.715228] bone-capemgr bone_capemgr.9: loader: before slot-7 BB-I2C1:00A0 (prio 0) [ 0.715240] bone-capemgr bone_capemgr.9: loader: check slot-7 BB-I2C1:00A0 (prio 0) [ 0.715732] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1) [ 0.718442] bone-capemgr bone_capemgr.9: loader: after slot-7 BB-I2C1:00A0 (prio 0) [ 0.718462] bone-capemgr bone_capemgr.9: slot #7: Requesting part number/version based 'BB-I2C1-00A0.dtbo [ 0.718477] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 'BB-I2C1-00A0.dtbo' for board-name 'Override Board Name', version '00A0' [ 0.718506] bone-capemgr bone_capemgr.9: slot #7: dtbo 'BB-I2C1-00A0.dtbo' loaded; converting to live tree [ 0.720710] bone-capemgr bone_capemgr.9: loader: before slot-8 BB-SPI1-SWP-01:00A0 (prio 0) [ 0.720724] bone-capemgr bone_capemgr.9: loader: check slot-8 BB-SPI1-SWP-01:00A0 (prio 0) [ 0.720740] bone-capemgr bone_capemgr.9: loader: after slot-8 BB-SPI1-SWP-01:00A0 (prio 0) [ 0.720754] bone-capemgr bone_capemgr.9: slot #8: Requesting part number/version based 'BB-SPI1-SWP-01-00A0.dtbo [ 0.720770] bone-capemgr bone_capemgr.9: slot #8: Requesting firmware 'BB-SPI1-SWP-01-00A0.dtbo' for board-name 'Override Board Name', version '00A0' [ 0.721636] bone-capemgr bone_capemgr.9: loader: done slot-7 BB-I2C1:00A0 (prio 0) [ 0.721672] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1) [ 1.075899] bone-capemgr bone_capemgr.9: failed to load firmware 'BB-SPI1-SWP-01-00A0.dtbo' [ 1.084703] bone-capemgr bone_capemgr.9: loader: failed to load slot-8 BB-SPI1-SWP-01:00A0 (prio 0) [ 1.094196] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1) [ 1.094214] bone-capemgr bone_capemgr.9: loader: after slot-4 BB-BONE-EMMC-2G:00A0 (prio 1) [ 1.122393] bone-capemgr bone_capemgr.9: loader: done slot-4 BB-BONE-EMMC-2G:00A0 (prio 1) *Verify overlay not loaded:* root@beaglebone:/home/debian# cat $SLOTS 0: 54:PF--- 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
