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]
<mailto:[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]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
Gerald
[email protected] <mailto:[email protected]>
http://beagleboard.org/
http://circuitco.com/support/
