BBB Cape Issues

BBB issues for Cape Developers:

  1. eMMC/HDMI take over ¾ the usable pins (non power/ground/analogue) on P8/P9

  2. The “button” is not useable when you have a cape installed.

  3. eMMC interferes with booting of capes

  4. Capes boot at the same time as the eMMC is being used (even if you cause the

software to NOT use the eMMC) , causing hangs unless capes are re-designed.

  1. The software to help fix these issues can’t solve the collisions with capes

(during boot).

  1. Hardware mods are required to prevent eMMC from even trying to be used.

  2. Cape Developers have 2 options: Give up, or spend 2X the amount for a BBW.

Cheap Solution:

Remove the eMMC and HDMI (and support components) and create a “Grey”…

a) NO redesign required(sysboot resistor change only).

b) NO software required to be modified.

c) Continues the low cost approach to letting the community develop capes.

d) Reduced dependency on higher priced BB White

(which is a negative for cape developers)

e) Only “mods” required are changes to BOM and PnP loading manifest

(possible solder mask change required for tooling)

f) uSD slot is still provided already on BBB so no penalty there.
(Yes, a uSD would need to be provided in place of the eMMC)

I support this - having a BeagleBone with more I/O capability at boot-up at the expense of reduced on-board resources in the form of no eMMC and HDMI is a win for me. I don’t need these features and it would free up the I/O pins and ease the design of capes which cannot tolerate the default configuration due to the high-speed data present on the pins at boot-up.

Harsh.

Have you actually _tried_ getting a cape running with the BBB, or are
you just whining? I'm running one of the nastier capes to get working
on a Black (the BeBoPr, which conflicts with pretty much every
reserved pin in the new 'Black design).

Specifically what cape(s) have you designed that you are having
problems with, and are your issues really with the new Black or with
coming up to speed on 3.8 and Device Tree (which would affect
operation on a BBW as well)?

IMHO, the new Black hardware rocks, and I think they did a great job
adding features, reducing the cost, and maintaining the backwards
compatibility they could. The _software_ however, is still very much
a work in progress, which relates mostly to the switch to a 3.8 kernel
and device tree. IMHO this was also the right call (it will just be
harder to switch the longer you wait), but it does cause some pain out
here in the field.

If you're having specific issues on the 'Black hardware, describe them
and perhaps the community can come up with an answer that will solve
or work around your problem. Pretty much everything you mentioned as
"issues" can be solved with a software or minimal hardware work-around.

No.

Gerald

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Harsh.

Have you actually _tried_ getting a cape running with the BBB, or are
you just whining? I'm running one of the nastier capes to get working
on a Black (the BeBoPr, which conflicts with pretty much every
reserved pin in the new 'Black design).

Specifically what cape(s) have you designed that you are having
problems with, and are your issues really with the new Black or with
coming up to speed on 3.8 and Device Tree (which would affect
operation on a BBW as well)?

IMHO, the new Black hardware rocks, and I think they did a great job
adding features, reducing the cost, and maintaining the backwards
compatibility they could. The _software_ however, is still very much
a work in progress, which relates mostly to the switch to a 3.8 kernel
and device tree. IMHO this was also the right call (it will just be
harder to switch the longer you wait), but it does cause some pain out
here in the field.

Agreed. My first impressions were not favorable, but that was due to my laziness in accepting the default pinmux settings.:-[
IMHO the 3.8 kernel and device tree is a pretty steep learning curve, but a much better alternative to the proliferation of SOC/board
specialization files in the kernel.

So make a custom uboot image and move a boot resistor or two, or drive
the boot option pins from your cape conditioned by reset. It's not
that hard, and doesn't require a new BeagleBone hardware version.

- --
Charles Steinkuehler
charles@steinkuehler.net

I have a design using the BBB and think that the emmc is a good idea
even though it takes pins away from gpio
the HDMI can be disabled easy enough at boot by not loading the virtual cape
and since the HDMI are all inputs its a no brainer to use the pins for
something else

Its rather easy to figure out which pins and mux settings you can use
with TI pinmux utility
so as not to interfere with any already used pins on the BBB
translating that to the DT is a bit tricky but all in a days work

It seems that you do not have a good understanding or hardware
manufacturing. more different boards
will mean an increase in price of the BBB over all and i do NOT want to
see this Diamond in the rough cost
more than it has to.

New HW? In roughly 2 more months we will have 136,000 BBB shipped. I can’t handle any one off boards. We have our hands full.

If anyone wants to go and create a one, or two, or three, off boards, all the information is there to build it. No need to ask permission, just go off an do it.

Gerald

And the best part is you don't have to keep porting custom vendor
changes to the ever moving Linux Kernel. Once your arch is accepted
into mainline, you have some drivers and a device tree file to
maintain, and most of the drivers are typically mainlined as well
(being things like generic ARM core uarts, gpio, etc).

IMHO it's a vast improvement over using the board files (and trying to
get those pushed into mainline), but the transition is definitely a
bit bumpy. Tell me again exactly _why_ drivers for a BeagleBone cape
really belong in the mainline Linux kernel source?!? :slight_smile:

- --
Charles Steinkuehler
charles@steinkuehler.net

Gerald: I wasn't meaning there should be a new "official" hardware
release. I was trying to point out that it is a fairly minor change
to the existing BeagleBone to work around any or all of the issues
that were raised, and it can even be done without modifying the
existing BBB at all (by a bit of clever cape design and driving the
boot lines at reset).

Leave the BeagleBone Black just like it is, and sell another 400,000
or so of them! :slight_smile: The hardware is awesome, and the rough edges will
get polished off the software soon enough.

I was just making a general comment.

Now, back to being on vacation…

Gerald

Charles,

Where is the “Harshness”?

I just stated facts.

I’ve been working with the BCC and a new cape that are having issues with this (trying to work with the PRU pins)

Gerald,

Did i say “Beagleboard.org and specifically Gerald” ought to do this?

Group:

I put this out here for a discussion.

Not to be attacked for my “lack of understnading”

Even developers are reluctant to modify fleas on boards so they can use Capes

Also just look at the sheer amount of time its taken to get the existing capes to work on the new boards. (and the effort to do this…)

Tom

No attack taken at all. Just making a statement for all the other folks that may be reading this thread. Just stating my position. And I did say anyone can make a board in any fashion they chose. No restrictions at all.

It should be noted that unless you build a LOT of boards, it will be a lot more expensive. More like the original BeagleBone. No HDMI. No eMMC.

Gerald

Hey - nifty idea. Looks like one could hack a test of this - just hang a 10K resistor between P8-43 and P8-1 to change the boot order and take the eMMC completely out of the picture. Will give it a shot.

Careful there...you probably don't want to go resetting your
BeagleBone when you twiddle an I/O pin. You'll probably want at least
a diode or transistor or something for isolation.

- --
Charles Steinkuehler
charles@steinkuehler.net

Changing boot order is easy. There is a memory expansion cape that does this. Resistors, buffer, and the SYS_RST line. Works great!

Gerald