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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>>> 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) 0000002f (this is P8-43 in mode 7 which should be >>>>>>> gpio2_8) >>>>>>> pin 43 (44e108ac) 0000002f (this is P8-44 in mode 7 which should be >>>>>>> gpio2_9) >>>>>>> ... >>>>>>> pin 102 (44e10998) 00000027 (this is P9-30 in mode 7 which should be >>>>>>> gpio3_17) >>>>>>> pin 103 (44e1099c) 00000027 (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 [email protected]. >>>>>>> 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 [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Gerald >>>>> >>>>> [email protected] >>>>> http://beagleboard.org/ >>>>> http://circuitco.com/support/ >>>>> -- >>>>> For more options, visit http://beagleboard.org/discuss >>>>> --- >>>>> You received this message because you are subscribed to a topic in the >>>>> Google Groups "BeagleBoard" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/d/topic/beagleboard/kMTzEq_A_AY/unsubscribe. >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> [email protected]. >>>>> 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 a topic in the >>> Google Groups "BeagleBoard" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/beagleboard/kMTzEq_A_AY/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> 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 [email protected]. > > For more options, visit https://groups.google.com/d/optout. > -- Gerald [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
