Re: [beagleboard] Boot Freezes with a single P8-P9 connection; reproduced on two boards
See inline below. Gerald On Wed, Apr 29, 2015 at 7:19 PM, Kenneth Martin mar...@granitesemi.com wrote: Gerald, I've looked into it, and I don't think I could do a good job as I can't understand TI's documentation. The boot process is described in Section 26.1 starting at pg 4898 (of SPRUH73K) and summarized in table 26-7 which takes 5 pages; one of the difficulties I have is I don't know what all the acronyms are: for example, one of the boot options is SPI0; [GC} Booting for SPI.Serial Peripheral Interface. Basically booting from an SPI FLASH device. Not used on the BBB. I think this is an EEPROM with an SPI interface, but I don't think the BBB has such a device? [GC} It does not. The two modes support on the BBB are listed on the schematic page with the pull up and pull down resistors that set the boot mode. If this is the case, why do we have it as one of the first boot devices? [GC} Because that is the mode that support what we needed. Just because it is an option does not mean it has to be there. It is ignored because it is not there. We had to work with the options the chip designer gave us. We can't change the way the processor works. The boot ROM looks for it, it isn't there, and thenm moves on to the next option in the list. Do we need to consider booting from an EEPROM with an SPI interface? [GC} No need to. eMMC and SD booting works fine. I believe the BBB has two SPI interfaces with the first one being used for the HDMI interface, and the second going to the header, so my guess is we can not boot from an EEPROM with an SPI interface. [GC} Actually, it is SPI flash, not EEPROM. There is a way to boot form SPI, but you will need to add it to an expansion board. There are other options such as booting from a UART, or booting from an Ethernet interface, or booting from the USB interface (not sure which one), which also seem like very difficult choices to implement if we wanted to use them; are these boot options we want to consider for the BBB? [GC} Depends on your application. UART and USB boot require special SW from TI to support downloading over those interfaces. The eMMC and the SD slots are the best options. Also, I'm guessing MMC0 in the tables refers to the eMMC, whereas MMC1 stands for booting the micro SD card, but these are only guesses; do you know if these guesses are correct. [GC] MMC is the same as SD from a booting perspective. eMMC means embedded. We use one MMC por fo the SD connector and the other for the embedded MMC device. The TI reference manual in Chapt. 26 is difficult to understand, and it may not be possible to understand it without help from TI which is not available for the BBB. [GC] Actually, it is not really that complicated. You need to decide the best option for your product and then figure out if it cn be done and how to do it. Given my failure to be able to understand Chapter 26, I could not do a reasonable job of documenting the use of the SYSBOOT pins; I'm guessing this aspect of the AM335X SOCs is perhaps convoluted and maybe not well done, or at least not well explained in TI's documentation. [GC] Again, focus on where you need to boot form. Then make sure you don't inadvertently change th eboot option by loading any of the boot pins. So where do you want to boot form in your application. On 15-04-24 04:08 PM, Gerald Coley wrote: Feel free to provide any wording that makes this understandable to all and I will consider adding it in. Gerald On Fri, Apr 24, 2015 at 2:49 PM, Bit Pusher ken.w.mar...@gmail.com wrote: The discussion are about the affect of holding the boot pin down, not how the various SYS_BOOT signals affects the boot sequence. The DNI's on the schematics were not in the previous SRM's; I unfortunately, did not notice this change, and even if I had noticed it, I would not have known the DNI's indicate the resistors were not included without this being explained somewhere in the text. I believe also that Fig. 39 on Page 68 may not have been included in earlier SRM's (version C came out after most our design was done). Irrespective, I can only guess at what Fig. 39 means, as there is no written explanation. My guess would be: SYS_BOOT6-13 have no effect and are do not cares. SYS_BOOT14-15 change some clock frequency, but which clock is unknown. SYS_BOOT5 enables some clock, and SYS_BOOT04 should be either 11100 or 11000. The former, which is when the boot button is not pushed, boots MMC1 and then MMC0, whereas the latter boots SPI0 and then MMC0. I thought MMC1 was the microSD card? Is this not correct? Also, for the latter case, where SPI0 is booted first, I do not know what SPI0 is? Could you help here? If the SRM included a couple of paragraphs here describing in words what is going on, it would make designing Capes much easier. Just stating in the text what DNI designated would really have helped. On Friday, April 24, 2015 at 2:26:39 PM
Re: [beagleboard] Boot Freezes with a single P8-P9 connection; reproduced on two boards
Gerald, I've looked into it, and I don't think I could do a good job as I can't understand TI's documentation. The boot process is described in Section 26.1 starting at pg 4898 (of SPRUH73K) and summarized in table 26-7 which takes 5 pages; one of the difficulties I have is I don't know what all the acronyms are: for example, one of the boot options is SPI0; I think this is an EEPROM with an SPI interface, but I don't think the BBB has such a device? If this is the case, why do we have it as one of the first boot devices? Do we need to consider booting from an EEPROM with an SPI interface? I believe the BBB has two SPI interfaces with the first one being used for the HDMI interface, and the second going to the header, so my guess is we can not boot from an EEPROM with an SPI interface. There are other options such as booting from a UART, or booting from an Ethernet interface, or booting from the USB interface (not sure which one), which also seem like very difficult choices to implement if we wanted to use them; are these boot options we want to consider for the BBB? Also, I'm guessing MMC0 in the tables refers to the eMMC, whereas MMC1 stands for booting the micro SD card, but these are only guesses; do you know if these guesses are correct. The TI reference manual in Chapt. 26 is difficult to understand, and it may not be possible to understand it without help from TI which is not available for the BBB. Given my failure to be able to understand Chapter 26, I could not do a reasonable job of documenting the use of the SYSBOOT pins; I'm guessing this aspect of the AM335X SOCs is perhaps convoluted and maybe not well done, or at least not well explained in TI's documentation. On 15-04-24 04:08 PM, Gerald Coley wrote: Feel free to provide any wording that makes this understandable to all and I will consider adding it in. Gerald On Fri, Apr 24, 2015 at 2:49 PM, Bit Pusher ken.w.mar...@gmail.com mailto:ken.w.mar...@gmail.com wrote: The discussion are about the affect of holding the boot pin down, not how the various SYS_BOOT signals affects the boot sequence. The DNI's on the schematics were not in the previous SRM's; I unfortunately, did not notice this change, and even if I had noticed it, I would not have known the DNI's indicate the resistors were not included without this being explained somewhere in the text. I believe also that Fig. 39 on Page 68 may not have been included in earlier SRM's (version C came out after most our design was done). Irrespective, I can only guess at what Fig. 39 means, as there is no written explanation. My guess would be: SYS_BOOT6-13 have no effect and are do not cares. SYS_BOOT14-15 change some clock frequency, but which clock is unknown. SYS_BOOT5 enables some clock, and SYS_BOOT04 should be either 11100 or 11000. The former, which is when the boot button is not pushed, boots MMC1 and then MMC0, whereas the latter boots SPI0 and then MMC0. I thought MMC1 was the microSD card? Is this not correct? Also, for the latter case, where SPI0 is booted first, I do not know what SPI0 is? Could you help here? If the SRM included a couple of paragraphs here describing in words what is going on, it would make designing Capes much easier. Just stating in the text what DNI designated would really have helped. On Friday, April 24, 2015 at 2:26:39 PM UTC-4, Graham wrote: BeagleBone Black SRM Version C.1 Section 6.7 Boot Configuration Design, Page 67. See Page 68, Figure 38. Yes, DNI means Do Not Insert. Or some time the term NP , meaning No Pop or do not populate is used. Section 6.8 Default Boot Options, Page 68. It is covered again on page 106, Section 8.3 Pin Usage Considerations. --- Graham == On Fri, Apr 24, 2015 at 1:04 PM, Bit Pusher ken.w@gmail.com wrote: I totally understand their are many compromises in designs; I just wish there was documentation; in this case, I find it sadly inadequate. Finally, the input is another GPIO header pin that has a reset defaultof input with a pull down which I believe is about 23K (it took me 2 hours to find documentation on reset defaults - one statement in a very large TRM table describing registers stating to look at data sheets, about 1 hour to find and understand in data sheet where the mux reset defaults are given) . If the pull-up and pull-down resistors on the board had been chose to be something like 4.7K this error would not have happened, and I don't believe this would have any impact on power except maybe 0.7mA additional current just during the time the boot button is pushed at power up, which is insignificant.
Re: [beagleboard] Boot Freezes with a single P8-P9 connection; reproduced on two boards
BeagleBone Black SRM Version C.1 Section 6.7 Boot Configuration Design, Page 67. See Page 68, Figure 38. Yes, DNI means Do Not Insert. Or some time the term NP , meaning No Pop or do not populate is used. Section 6.8 Default Boot Options, Page 68. It is covered again on page 106, Section 8.3 Pin Usage Considerations. --- Graham == On Fri, Apr 24, 2015 at 1:04 PM, Bit Pusher ken.w.mar...@gmail.com wrote: I totally understand their are many compromises in designs; I just wish there was documentation; in this case, I find it sadly inadequate. Finally, the input is another GPIO header pin that has a reset defaultof input with a pull down which I believe is about 23K (it took me 2 hours to find documentation on reset defaults - one statement in a very large TRM table describing registers stating to look at data sheets, about 1 hour to find and understand in data sheet where the mux reset defaults are given) . If the pull-up and pull-down resistors on the board had been chose to be something like 4.7K this error would not have happened, and I don't believe this would have any impact on power except maybe 0.7mA additional current just during the time the boot button is pushed at power up, which is insignificant. On Thursday, April 23, 2015 at 11:28:53 PM UTC-4, Graham wrote: Kenneth: There are fifteen lines, and a field of 100 K Ohm resistors that tell the Sitara how to boot. There are locations for a pull up and a pull down on each of the boot instruction lines. Only one of those resistors is populated for each line. Read the SRM. Any load that would cause a logic state established by a 100K resistor, pull up or pull down, to change logic state, will modify, and likely kill the boot process. If your input was a CMOS gate, it would probably have worked. If your input was one of those Panasonic driver transistors with the built-in resistors to ground, you are changing the boot instructions by attaching it. --- Graham == On Thursday, April 23, 2015 at 9:23:08 PM UTC-5, Kenneth Martin wrote: 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@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
Re: [beagleboard] Boot Freezes with a single P8-P9 connection; reproduced on two boards
Feel free to provide any wording that makes this understandable to all and I will consider adding it in. Gerald On Fri, Apr 24, 2015 at 2:49 PM, Bit Pusher ken.w.mar...@gmail.com wrote: The discussion are about the affect of holding the boot pin down, not how the various SYS_BOOT signals affects the boot sequence. The DNI's on the schematics were not in the previous SRM's; I unfortunately, did not notice this change, and even if I had noticed it, I would not have known the DNI's indicate the resistors were not included without this being explained somewhere in the text. I believe also that Fig. 39 on Page 68 may not have been included in earlier SRM's (version C came out after most our design was done). Irrespective, I can only guess at what Fig. 39 means, as there is no written explanation. My guess would be: SYS_BOOT6-13 have no effect and are do not cares. SYS_BOOT14-15 change some clock frequency, but which clock is unknown. SYS_BOOT5 enables some clock, and SYS_BOOT04 should be either 11100 or 11000. The former, which is when the boot button is not pushed, boots MMC1 and then MMC0, whereas the latter boots SPI0 and then MMC0. I thought MMC1 was the microSD card? Is this not correct? Also, for the latter case, where SPI0 is booted first, I do not know what SPI0 is? Could you help here? If the SRM included a couple of paragraphs here describing in words what is going on, it would make designing Capes much easier. Just stating in the text what DNI designated would really have helped. On Friday, April 24, 2015 at 2:26:39 PM UTC-4, Graham wrote: BeagleBone Black SRM Version C.1 Section 6.7 Boot Configuration Design, Page 67. See Page 68, Figure 38. Yes, DNI means Do Not Insert. Or some time the term NP , meaning No Pop or do not populate is used. Section 6.8 Default Boot Options, Page 68. It is covered again on page 106, Section 8.3 Pin Usage Considerations. --- Graham == On Fri, Apr 24, 2015 at 1:04 PM, Bit Pusher ken.w@gmail.com wrote: I totally understand their are many compromises in designs; I just wish there was documentation; in this case, I find it sadly inadequate. Finally, the input is another GPIO header pin that has a reset defaultof input with a pull down which I believe is about 23K (it took me 2 hours to find documentation on reset defaults - one statement in a very large TRM table describing registers stating to look at data sheets, about 1 hour to find and understand in data sheet where the mux reset defaults are given) . If the pull-up and pull-down resistors on the board had been chose to be something like 4.7K this error would not have happened, and I don't believe this would have any impact on power except maybe 0.7mA additional current just during the time the boot button is pushed at power up, which is insignificant. On Thursday, April 23, 2015 at 11:28:53 PM UTC-4, Graham wrote: Kenneth: There are fifteen lines, and a field of 100 K Ohm resistors that tell the Sitara how to boot. There are locations for a pull up and a pull down on each of the boot instruction lines. Only one of those resistors is populated for each line. Read the SRM. Any load that would cause a logic state established by a 100K resistor, pull up or pull down, to change logic state, will modify, and likely kill the boot process. If your input was a CMOS gate, it would probably have worked. If your input was one of those Panasonic driver transistors with the built-in resistors to ground, you are changing the boot instructions by attaching it. --- Graham == On Thursday, April 23, 2015 at 9:23:08 PM UTC-5, Kenneth Martin wrote: 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
[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.
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.
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
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
