[beagleboard] How to compile code on Linux Host with -lprussdrv
Hello there, I am following Derek Molloy's book on pru programming and I have run into a problem. I have my user space c++ application build on a remote x86 linux pc. I am using cross compiler there to deploy executables to the BeagleBone Black. So far it was working great but it does not with pru. Is there a way to download the pru package to the host machine and be abble to use -lprussdrv linker flag? I tried compiling the package on BeagleBone Black and then to copy the: „libprussdrv.a” „libprussdrvd.a” „libprussdrvd.so” „libprussdrv.so” to the /usr/lib/ and cross compiller lib/ folders on my host machine. The code then compilled with the linker flag but i had seg fault on the BeagleBone Black when trying to run the part of code where i open the asm .bin file. The problem is also that I am not able to compile the example code on the BeagleBone Black. I have placed the include and lib files in the /usr/lib/ and /usr/include/ dirs of BeagleBone Black. This is the example code: https://pastebin.com/nSsgU7Mk When trying to compile using (on bb) gcc test.c - test -lprussdrv i get: https://pastebin.com/nE3dAQ7b I am wondering either the pru header file has acces to the .c file? Or is it handled by the library? Should I place the prussdrv.c file somewhere for the header to see it? I would really aprichiate all help. -- 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: BeagleBoard-X15 - seriously? :)
One note of caution: If its like previous BB releases the early boards will probably contain processor Engineering samples. These are usually buggy early silicon. Actually the community is a great outlet for TI to dump its engineering stock and still charge for it. -- 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] Boot Freezes with a single P8-P9 connection; reproduced on two boards
I have found a reproducible boot freeze (on two boards); could someone else possibly check; it's very easy to try. No connections besides power plug and one (or two) wires from header P8 to P9 Scenario 1: connect P8-43 to P9-30, plug in power, only power light comes on and BBB does not boot up Scenario 2: connect P8-44 to P9-28, plug in power, only power light comes on and BBB does not boot up Scenario 3: connect both P8-43 to P9-30 and P8-44 to P9-28, plug in power, power light and all 4 LEDs come on steady and BBB does not boot up. Discussion: 1) doing these tests numerous times on 2 BBB's did not hurt either one of the boards I have, but this behavior is so strange that it might be risky; please don't be upset with me if it hurts your board. 2) uname -a gives Linux beaglebone 3.8.13-bone70 #1 SMP Fri Jan 23 02:14:42 UTC 2015 armv7l GNU/Linux. My OS version is Debian wheezy 7.8 3) without wires connected, after booting and doing a sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins shows ... pin 42 (44e108a8) 002f (this is P8-43 in mode 7 which should be gpio2_8) pin 43 (44e108ac) 002f (this is P8-44 in mode 7 which should be gpio2_9) ... pin 102 (44e10998) 0027 (this is P9-30 in mode 7 which should be gpio3_17) pin 103 (44e1099c) 0027 (this is P9-28 in mode 7 which should be gpio3_16) Therefore at boot, pins P8-43 and P8-44, without applying device trees, are both configured as inputs with pull-downs; pins P9-30 and P9-28, without applying device trees, are both configured as inputs with pull_up/pull_down's disabled. 4) making the connections after boot does not have any discernible effects 5) It seems to me that having two gpio's connected together with both configured as inputs and one having a pull-down should not cause the BBB to freeze at boot. 6) It is also interesting that having two connections as in 5) causes different behavior; that is the boot process goes further to light all four LED's and then freezes. Could someone check to see if they are getting similar behavior; I can't imagine that I am doing something real stupid with only a single wire connection; but I have previously done many rather stupid things so you never know (without verification). Would someone in the expert category have some suggestions how to get around this problem; if we can't find a work around, months and months of work will be thrown away. For example, if we configured the device tree that is loaded at boot up, would it take precedence before the default pin mux that causes the freeze (if this happens to be the problem, currently we have no insight into what is causing this behavior). Has anyone else seen similar problems (we may also have something funny with connections to P8-45 and P8-46 but have not tracked this down yet to simple scenarios. I'm open to suggestions as we are currently stuck. Thanks. -- 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: PRUSS under Debian beta
We have been using the PRUSS's extensively on bone70; with mostly success, but every so often, memory gets corrupted, and we have to reboot. This behavior is aperiodic and we have not been able to track it down yet (the PRUSS's can write anywhere in memory - they could be a significant security risk - for example changing some bytes loaded at PRUSS startup could be used to take over the BBB). That is until today (see my recent post), where some input connections to the header that we want to use as PRUSS inputs is causing the BBB to freeze at boot. Generally, however, the PRUSS's seem to work as expected (make sure you assemble with -V2) On Friday, June 27, 2014 at 4:03:32 PM UTC-4, Sherman Boyd wrote: Hello. I'm trying to get PRUSS working with the new Debian beta image. I've got things working on Angstrom, but not on Debian. I'm using kernel 3.8.13-bone50, is anybody else using PRUSS on this 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.
Re: [beagleboard] Boot Freezes with a single P8-P9 connection; reproduced on two boards
you are messing with the boot pins. its been stated here 100s of times you cannot do anything to these pins before board boots. check the BBB schematic and the using the bbb board guide., On 4/23/2015 9:09 AM, Bit Pusher wrote: I have found a reproducible boot freeze (on two boards); could someone else possibly check; it's very easy to try. No connections besides power plug and one (or two) wires from header P8 to P9 Scenario 1: connect P8-43 to P9-30, plug in power, only power light comes on and BBB does not boot up Scenario 2: connect P8-44 to P9-28, plug in power, only power light comes on and BBB does not boot up Scenario 3: connect both P8-43 to P9-30 and P8-44 to P9-28, plug in power, power light and all 4 LEDs come on steady and BBB does not boot up. Discussion: 1) doing these tests numerous times on 2 BBB's did not hurt either one of the boards I have, but this behavior is so strange that it might be risky; please don't be upset with me if it hurts your board. 2) uname -a gives Linux beaglebone 3.8.13-bone70 #1 SMP Fri Jan 23 02:14:42 UTC 2015 armv7l GNU/Linux. My OS version is Debian wheezy 7.8 3) without wires connected, after booting and doing a sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins shows ... pin 42 (44e108a8) 002f (this is P8-43 in mode 7 which should be gpio2_8) pin 43 (44e108ac) 002f (this is P8-44 in mode 7 which should be gpio2_9) ... pin 102 (44e10998) 0027 (this is P9-30 in mode 7 which should be gpio3_17) pin 103 (44e1099c) 0027 (this is P9-28 in mode 7 which should be gpio3_16) Therefore at boot, pins P8-43 and P8-44, without applying device trees, are both configured as inputs with pull-downs; pins P9-30 and P9-28, without applying device trees, are both configured as inputs with pull_up/pull_down's disabled. 4) making the connections after boot does not have any discernible effects 5) It seems to me that having two gpio's connected together with both configured as inputs and one having a pull-down should not cause the BBB to freeze at boot. 6) It is also interesting that having two connections as in 5) causes different behavior; that is the boot process goes further to light all four LED's and then freezes. Could someone check to see if they are getting similar behavior; I can't imagine that I am doing something real stupid with only a single wire connection; but I have previously done many rather stupid things so you never know (without verification). Would someone in the expert category have some suggestions how to get around this problem; if we can't find a work around, months and months of work will be thrown away. For example, if we configured the device tree that is loaded at boot up, would it take precedence before the default pin mux that causes the freeze (if this happens to be the problem, currently we have no insight into what is causing this behavior). Has anyone else seen similar problems (we may also have something funny with connections to P8-45 and P8-46 but have not tracked this down yet to simple scenarios. I'm open to suggestions as we are currently stuck. Thanks. -- 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 mailto:beagleboard+unsubscr...@googlegroups.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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] A way to compile PRU user apps on host PC
Hello there, I was wondering either it is possible to compile user applications for BeagleBone Black, that require lprussdrv linker flag? So far I have copied the libs: libprussdrv.a 1 libprussdrv.so libprussdrvd.a libprussdrvd.so that were created on BeagleBone Black, to the cross gcc lib directory on my host pc. Then I am able to compile and link the code with -lprussdrv flag, but when trying to execute it I am getting segmentation fault (when running remotelly) or this output when running from BeagleBone Black: AM33XX File ./test.bin open passed The program then hangs and I have to kill it. I would really appreciate all help in this matter! -- 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: BeagleBoard-X15 - seriously? :)
They are what are called X versions. As was the case on the BBB, these are the same devices as the production release versions.The same devices will be used on the TI EVM. All issues are listed in the process errata. Any issues that may be fixed have HW workarounds already in the design. Gerald On Thu, Apr 23, 2015 at 9:52 AM, da...@s-i-solutions.com wrote: One note of caution: If its like previous BB releases the early boards will probably contain processor Engineering samples. These are usually buggy early silicon. Actually the community is a great outlet for TI to dump its engineering stock and still charge for it. -- 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. -- Gerald ger...@beagleboard.org http://beagleboard.org/ http://circuitco.com/support/ -- 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] Accessing peripherals from the PRU
It's my understanding that you can access peripherals from the PRU. I can do this by reading/writing the appropriate addresses in the L4_PER memory map, correct? -- 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: BeagleBoard-X15 - seriously? :)
I never meant to imply they don't work, it really depends on your definition of work. ...bottom line read the errata ..especially be wary of the words no workarounds. -- 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: BeagleBoard-X15 - seriously? :)
Non of that has had much if any effect on any of our projects. Which my buddy ( the EE in our projects ) read the errata prior to release. He expressed some concerns early on, but in the end they have had no effect on our projects. On Thu, Apr 23, 2015 at 1:06 PM, da...@s-i-solutions.com wrote: I never meant to imply they don't work, it really depends on your definition of work. ...bottom line read the errata ..especially be wary of the words no workarounds. -- 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. -- 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: BeagleBoard-X15 - seriously? :)
The only real thing that bothers me that I can think of offhand. Is having an on-die RTC that effectively can not be used. However, there *are* both hardware, and software work arounds. Depending on how early you need the clock to be accurate. Not even sure if that is listed as an errata item, but . . . On Thu, Apr 23, 2015 at 2:07 PM, Robert Nelson robertcnel...@gmail.com wrote: On Thu, Apr 23, 2015 at 3:06 PM, da...@s-i-solutions.com wrote: I never meant to imply they don't work, it really depends on your definition of work. ...bottom line read the errata ..especially be wary of the words no workarounds. You realize, the errata list is pretty small right now.. But i guarantee, it'll get longer when 100k users buy the board and start doing random things.. 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+unsubscr...@googlegroups.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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: BeagleBoard-X15 - seriously? :)
On Thu, Apr 23, 2015 at 3:06 PM, da...@s-i-solutions.com wrote: I never meant to imply they don't work, it really depends on your definition of work. ...bottom line read the errata ..especially be wary of the words no workarounds. You realize, the errata list is pretty small right now.. But i guarantee, it'll get longer when 100k users buy the board and start doing random things.. 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: BeagleBoard-X15 - seriously? :)
Don't get me started on that. Tried that for years and never could get it through. So, we are doing a custom BBB design for a customer, and it is there. Gerald On Thu, Apr 23, 2015 at 4:30 PM, William Hermans yyrk...@gmail.com wrote: Well in our case ntpdate + ntp.pool.org works fine. Most of the time. But I've also thought about many external work arounds, which really renders my gripe moot. An msp430g2553 for instance doesn't cost much more than an RTC, and can serve multiple purposes . . . On Thu, Apr 23, 2015 at 2:18 PM, Robert Nelson robertcnel...@gmail.com wrote: On Thu, Apr 23, 2015 at 4:14 PM, William Hermans yyrk...@gmail.com wrote: The only real thing that bothers me that I can think of offhand. Is having an on-die RTC that effectively can not be used. However, there *are* both hardware, and software work arounds. Depending on how early you need the clock to be accurate. Not even sure if that is listed as an errata item, but . . . The x15 has an external rtc with a battery spot. ;) 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+unsubscr...@googlegroups.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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Gerald ger...@beagleboard.org http://beagleboard.org/ http://circuitco.com/support/ -- 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] Boot Freezes with a single P8-P9 connection; reproduced on two boards
On Thu, 23 Apr 2015 20:02:03 -0400, you wrote: inputs are not inputs are not inputs as far as loading goes. if I connect an instrument with a 50 ohm impedance to a TTL/CMOS gate, then it's going to see low at that gate input, even though they are all inputs. Different logic series gates look like different things at the inputs. Those inputs affect the other inputs. The GPIO current out is not the issue, it's what the GPIO input sees when the circuit is booted that determines what happens. Harvey If they cause the BBB to not boot, by hooking an input to them, I would argue they should never have been brought out to the header, and that examples of how to handle this sensitivity while still making use of the header pins should be more readily available. The documentation on this sensitivity appears to be a single poorly written paragraph in the SRM which only states they should not be driven (actually 3 lines only in section 7.12.1 following Fig 58; to be specific: /If you plan to use any of these signals, then on power up, these pins should not be driven. //If you do, it can affect the boot mode of the processor and could keep the processor from //booting or working correctly/. I can't see this addressed anywhere else in the documentation). It should state that not even inputs can not be connected to these header pins. There is no documentation that I can see on why they were even brought out to the header. Issues like this make other alternatives to using the BBB's look more attractive (such as the new PI). At a minimum, this will cost us another 4 lost weeks and $2K for new populated boards for another iteration on our cape. Very frustrating, and I would argue both poor design and poor documentation. Looking at the schematic, it appears the existing load on each pin is 2 100K resistors? If this is correct, I would not call this well loaded when a typical gpio output current is 4-6mA. On 15-04-23 02:08 PM, Gerald Coley wrote: ANY load can affect how they are read. These pins are already well loaded as it is. If you want to use them, use a buffer to isolate them until after the processor is running. Gerald On Thu, Apr 23, 2015 at 12:20 PM, Bit Pusher ken.w.mar...@gmail.com mailto:ken.w.mar...@gmail.com wrote: This is not clear as they are connected to other inputs which I would normally think means they are not being driven. Is there a definition you can give a link to defining what driven is? Also, can you supply a link of how to control and what are the mux defaults before boot? Thank you. On Thursday, April 23, 2015 at 12:29:26 PM UTC-4, Wulf Man wrote: you are messing with the boot pins. its been stated here 100s of times you cannot do anything to these pins before board boots. check the BBB schematic and the using the bbb board guide., On 4/23/2015 9:09 AM, Bit Pusher wrote: I have found a reproducible boot freeze (on two boards); could someone else possibly check; it's very easy to try. No connections besides power plug and one (or two) wires from header P8 to P9 Scenario 1: connect P8-43 to P9-30, plug in power, only power light comes on and BBB does not boot up Scenario 2: connect P8-44 to P9-28, plug in power, only power light comes on and BBB does not boot up Scenario 3: connect both P8-43 to P9-30 and P8-44 to P9-28, plug in power, power light and all 4 LEDs come on steady and BBB does not boot up. Discussion: 1) doing these tests numerous times on 2 BBB's did not hurt either one of the boards I have, but this behavior is so strange that it might be risky; please don't be upset with me if it hurts your board. 2) uname -a gives Linux beaglebone 3.8.13-bone70 #1 SMP Fri Jan 23 02:14:42 UTC 2015 armv7l GNU/Linux. My OS version is Debian wheezy 7.8 3) without wires connected, after booting and doing a sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins shows ... pin 42 (44e108a8) 002f (this is P8-43 in mode 7 which should be gpio2_8) pin 43 (44e108ac) 002f (this is P8-44 in mode 7 which should be gpio2_9) ... pin 102 (44e10998) 0027 (this is P9-30 in mode 7 which should be gpio3_17) pin 103 (44e1099c) 0027 (this is P9-28 in mode 7 which should be gpio3_16) Therefore at boot, pins P8-43 and P8-44, without applying device trees, are both configured as inputs with pull-downs; pins P9-30 and P9-28, without applying device trees, are both configured as inputs with pull_up/pull_down's disabled. 4) making the connections after boot does not have any discernible effects 5) It seems to me that having two gpio's connected together
[beagleboard] Re: About the address range
David Goodenough david.goodenough@... writes: searching on the net I think I may have found what you are using. It is not an AM2320, but rather an AM2321. This DOES have an I2C interface unlike the AM2320. According to sellers who offer AM2320 (e.g. on AliExoress), it supports both, I2C and Aosong's proprietary single wire protocol. This claim is also backed by this datasheet: http://akizukidenshi.com/download/ds/aosong/AM2320.pdf . The only difference between AM2320 and AM2321 seems to be the orientantion of the pins (bottom side vs. back side). But unfortunately the datasheet gives no information about changing the I2C device address, which I would also be interested in, so that I can put multiple sensors onto a single I2C bus. -- 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] Boot Freezes with a single P8-P9 connection; reproduced on two boards
If they cause the BBB to not boot, by hooking an input to them, I would argue they should never have been brought out to the header, and that examples of how to handle this sensitivity while still making use of the header pins should be more readily available. The documentation on this sensitivity appears to be a single poorly written paragraph in the SRM which only states they should not be driven (actually 3 lines only in section 7.12.1 following Fig 58; to be specific: /If you plan to use any of these signals, then on power up, these pins should not be driven. //If you do, it can affect the boot mode of the processor and could keep the processor from //booting or working correctly/. I can't see this addressed anywhere else in the documentation). It should state that not even inputs can not be connected to these header pins. There is no documentation that I can see on why they were even brought out to the header. Issues like this make other alternatives to using the BBB's look more attractive (such as the new PI). At a minimum, this will cost us another 4 lost weeks and $2K for new populated boards for another iteration on our cape. Very frustrating, and I would argue both poor design and poor documentation. Looking at the schematic, it appears the existing load on each pin is 2 100K resistors? If this is correct, I would not call this well loaded when a typical gpio output current is 4-6mA. On 15-04-23 02:08 PM, Gerald Coley wrote: ANY load can affect how they are read. These pins are already well loaded as it is. If you want to use them, use a buffer to isolate them until after the processor is running. Gerald On Thu, Apr 23, 2015 at 12:20 PM, Bit Pusher ken.w.mar...@gmail.com mailto:ken.w.mar...@gmail.com wrote: This is not clear as they are connected to other inputs which I would normally think means they are not being driven. Is there a definition you can give a link to defining what driven is? Also, can you supply a link of how to control and what are the mux defaults before boot? Thank you. On Thursday, April 23, 2015 at 12:29:26 PM UTC-4, Wulf Man wrote: you are messing with the boot pins. its been stated here 100s of times you cannot do anything to these pins before board boots. check the BBB schematic and the using the bbb board guide., On 4/23/2015 9:09 AM, Bit Pusher wrote: I have found a reproducible boot freeze (on two boards); could someone else possibly check; it's very easy to try. No connections besides power plug and one (or two) wires from header P8 to P9 Scenario 1: connect P8-43 to P9-30, plug in power, only power light comes on and BBB does not boot up Scenario 2: connect P8-44 to P9-28, plug in power, only power light comes on and BBB does not boot up Scenario 3: connect both P8-43 to P9-30 and P8-44 to P9-28, plug in power, power light and all 4 LEDs come on steady and BBB does not boot up. Discussion: 1) doing these tests numerous times on 2 BBB's did not hurt either one of the boards I have, but this behavior is so strange that it might be risky; please don't be upset with me if it hurts your board. 2) uname -a gives Linux beaglebone 3.8.13-bone70 #1 SMP Fri Jan 23 02:14:42 UTC 2015 armv7l GNU/Linux. My OS version is Debian wheezy 7.8 3) without wires connected, after booting and doing a sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins shows ... pin 42 (44e108a8) 002f (this is P8-43 in mode 7 which should be gpio2_8) pin 43 (44e108ac) 002f (this is P8-44 in mode 7 which should be gpio2_9) ... pin 102 (44e10998) 0027 (this is P9-30 in mode 7 which should be gpio3_17) pin 103 (44e1099c) 0027 (this is P9-28 in mode 7 which should be gpio3_16) Therefore at boot, pins P8-43 and P8-44, without applying device trees, are both configured as inputs with pull-downs; pins P9-30 and P9-28, without applying device trees, are both configured as inputs with pull_up/pull_down's disabled. 4) making the connections after boot does not have any discernible effects 5) It seems to me that having two gpio's connected together with both configured as inputs and one having a pull-down should not cause the BBB to freeze at boot. 6) It is also interesting that having two connections as in 5) causes different behavior; that is the boot process goes further to light all four LED's and then freezes. Could someone check to see if they are getting similar behavior; I can't imagine that I am doing something real stupid with only a single wire connection; but I have previously done many rather stupid things so you never
