Have a question about the Next-Gen BeagleBone? Ask it here!

For anyone else with one of these, see

https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-black/G_QjWvBNXvc

you'll probably want to go to http://circuitco.com/support/index.php?title=Updating_The_Software and get the latest software image (2013.05.3 as of now) before trying to do anything with opkg

you'll probably want to go to http://circuitco.com/support/index.php?title=Updating_The_Software and get the latest software image (2013.05.3 as of now) before trying to do anything with opkg

Something must have been wrong with the build.  Looks like they pulled it.  I can see it in the change history so you're not a liar

Drew Fustini (admin) wrote: [my highlighting]

 

In the meantime, this discussion area ("Home > the knode > Development Platforms and Kits > element14 Development Kits > BeagleBone Black > Discussions") is the preferred location for BBB discussions.

There is no such navigation available in the knode, so saying that it's the preferred location can only be a statement of hope currently, not an actuality in the meantime.  Unless people are given a direct link to one of the BBB discussions or stumble across one among the random assortment of recent posts highlighted on the front page, they'll never find it.

Of course, we know it's not hard to find with a little perseverence (one of your RHS advertisements links to it), but new users can't divine which the "preferred location" actually is, and won't read your statement of hope until they've already found the spot.  Chicken and egg there.  Some will find nothing and just head elsewhere.

It's puzzling to see this choice being made, as it's likely to be bad for your user numbers and for the quality of support that new arrivals obtain from the site.  Fixing the knode's navigation faults will help, but only partially.  BBB support will still be inferior to that which Pi enjoys.  Is there a gain?  I don't see one.

As a stopgap, I recommend that you add to your front page (LHS column) a link called BeagleBone Black under "Featured Groups / Applications and Others", which already contains a mixture of real groups and community links.  That'll provide a direct link to your preferred location straight away and is easy + fast to do, in advance of fixing the knode's navigation which will require much more work from your devs.

It looks like there's been some site reorganization to improve the knode tree.  BeagleBone Black is now at

the knode > Single-Board Computers > BeagleBone Black

which seems a lot clearer than before.  I assume that this is the new "preferred location".

The transition probably doesn't break any thread bookmarks because messaging seems to be orthogonal to site navigation, but browser state is sensitive to it, so if you have a tab open on a thread in the old

the knode > Development Platforms and Kits > element14 Development Kits > BeagleBone Black > Discussions

then it will now have lost its parent if you try to go back, but good riddance to that.

Unfortunately there's still no downward navigation to reach "Discussions" within BeagleBone Black, so the only way of getting there is to click on an existing BBB thread and then go upwards to "Discussions" in its breadcrumbs.

While not as useful as having a BBB group would be, things are improving slightly I think.

Morgaine Dinova wrote:

 

Unfortunately there's still no downward navigation to reach "Discussions" within BeagleBone Black, so the only way of getting there is to click on an existing BBB thread and then go upwards to "Discussions" in its breadcrumbs.

I really don't get why 'Discussions' is so well hidden, and both BBB and SL have the other annoying problem of if you ever find them and click on a 'learn more' button or link you're re-directed off to a document under the knode > Development Platforms and Kits > Dev Kits Learning Center > Documents - so in a completely different area, no clue you're missing out on other information.

Unless you're paying close attention you probably miss that you've been teleported elsewhere too

Morgaine Dinova wrote:

 

Unfortunately there's still no downward navigation to

I think you're still right in the comment that there's just no useful navigation in the knode.. and all it would take is the addition of the tabs (All Content, Discussions, Documents, Blog, Videos) in an area specific manner at all levels, rather than them only appearing at certain points - for the knode they only seem to appear after you're already on the page they would have been useful in getting to in the first place!

selsinork wrote:

 

I really don't get why 'Discussions' is so well hidden

I do:  "webbies".

I'll say no more, or they won't buy me a nice glass of wine when I finally see them some day.

IDEA:

Element 14's "My Lists" in the "black bar" across the top of all pages has "Parts List" and "My Bookmarks" as its only two lists.  How about adding a third list, "My Communities"?  Since everything under knode > design > Single Board Computers appears to be a "Community" in the sense that it has an action titled "Follow this community", it would turn this new list into a sort of "group selector" without daring to use the forbidden word "group".  And it would make the black bar more useful too.

We can already select a community to visit through My Account > Communities, but that adds two levels of page load indirection and it still doesn't get you to the Discussions page for the desired community.  So, I suggest that this new "My Communities" list be populated with direct links to the Discussions pages of the communities you are following,

And all will be sweetness and light.  Or at least marginally better.

Morgaine.

I share your feelings with the two boards.  I pulled my Pi out and put the BeagleBone Black in it's place.  They both didn't like my monitor setup (An old retired Sony VGA with a HDMI to VGA adapter), but the rework of the config.txt did fixed this problem in the Pi.  I have about 30+ hours of searching into the BCubed, and still can't fix the problem. The docs say you can rework the UBoot uEnv.txt file and this will take care of the issue, but any change I make has no effect.  At one place I got a feeling I was suppose to recompile the UBoot image, but after reading about 10 pages in the manual, I couldn't find a clue on how to do that. 

My feelings on the two boards. Pi, like the Arduino, has a great backing on the software side, but the hardware side is really lacking.  I read at one of the sites if I wanted the manual on the MCU used in the Pi, I had to commit to an order of 1 million chips a year.  The hardware on the BCubed is great, and well documented.  The power is one of the big differences.  The Pi has to have 5 volt supply that will damage the board if it is off by .3 volts, where with the BCubed it 5 to 9 volts is good, because BCubed has some power management on the card.

I have tried all the flavors of linux except Fedora (because I couldn't uncompress it), and all of them have that same UBoot method that doesn't work.  Another really bizzare problem is if the monitor doesn't return EDID information then UBoot gives you one resolution to choose from; instead of the 11 the hardware supports.  That was the results on Debian, Ebuntu (Rarring or Precise), and Angstrom.

Mike, I had similar problems getting my BBB to work with a VGA monitor. I was using a HDMA to VGA adaptor sold by Farnell for use with the R-Pi and the problem was that it needed more current than the BBB supplies (more than the HDMI spec) so I rigged up a way of feeding the adaptor from a separate 5V PSU and now it works great.

Mike Connell wrote:

 

I have about 30+ hours of searching into the BCubed, and still can't fix the problem.

From what I've read, there are certainly some issues currently around setting video modes. This is partly due to everything still being very new, and partly due to using the newer DRM drivers that use KMS.  If you've ever spent time reading the general linux-kernel mailing list you'll have seen frequent reports of KMS issues.

There is work being done in this area, or so we're told, in order to allow forcing the 1920x1080 modes.  So I expect things will improve in this area given some time.

where with the BCubed it 5 to 9 volts

are you sure about that ?  If you have some pointer to where they say 9v is OK I'd love to see it. The SRM and the prominent 5v sticker on top of the barrel connector strongly suggest that the input is 5v only.

Another really bizzare problem is if the monitor doesn't return EDID information then UBoot gives you one resolution to choose from; instead of the 11 the hardware supports.

that's a KMS issue too, it'll base it's choices on what it gets from EDID and force a 'safe' mode if there's no EDID available. There do appear to be ways to override the EDID by supplying a kernel command line option with a filename of a user supplied EDID though. So there may be a way around that.

Powering the card

That is from the datasheets for the power management system. You could

safely use a 12 volt source with no problems.   There isn't a power

management system on the Pi.

Here is a quote from the new O'Riely book Getting Started with the

Beagle Bone....

2. The Power Connector. Your BeagleBone needs 5 volts and 500 mA of

direct current to operate. Most generic 5V DC power adapters with a

2.1mm barrel jack connector will power the board. It’s important to know

that even if a power connector will fit into this jack, it doesn’t

necessarily

mean that it’s providing 5 volts. Right nearby the jack is a small power a

protection chip in case you accidentally provide over five and up to 12

volts. It will protect your board and won’t let it power on if you connect

too much voltage. Still, it’s probably best to make sure you’re plugging

only 5V into the board.

I actually have mine running on a BK Precision .5 to 30 volt adjustable

power supply that can supply up to 30 amps if needed. I have it dialed

in for exactly 5.1 volts.  Even when I'm online the BBB only pulls about

187 miliamps.  The Pi was closer to 400 ma but the mcu on the Pi is

power hog.

The Screen Issue

I realize that EDID is important, but there should be a way to turn it

off for older monitors and let me select the monitor.  The uEnv.txt for

U-Boot does absolutely nothing.  I spent the afternoon trying to get

xrandr to change it but I needed to know the name of the video output. 

I tried every thing to coax the name out of the unit and none of the

names I came up with will work.  I think that the name of the output is

HDMI-A-1, but all the names I tried gave me the same message no output

by that name.

My Screen is an old Sony VGA and my wife used it as her Photshop screen

until we moved and now there is a dark spot in the right corner.  It is

OK as a test screen, but not a color match monitor anymore.  The monitor

will do about 1000x700, so I usually run it at 800x600.  The BBB runs it

at 1280X720 and about 100 pixels are off the screen to the left.  On the

Pi I could take care of this in the config.sys file (which is more

standard Linux than the U-boot approach), I turned the border on and

moved the picture to the left.  I did see that there are two uEnv.txt

files on the machine.  One is in the file system, and the other is the

devices under BeagleBone.  Neither of them seem to do anything.  I found

this when I changed there names to .BAK and then did a restart. There is

no difference in anything on the machine.

What I don't get is why it takes all of the screen resolution choices

away, and that is the same on Ubuntu (Rarring & Precise), Angstrom, and

Debian Wheezy.  On all of these different systems, if you go to System

Settings| Display the only resolution choice is 1280X720 16:9.

If you have any suggestions of where to read up on the any of this I

would appreciate it..

thanks

Powering the card

That is from the datasheets for the power management system. You could

safely use a 12 volt source with no problems.   There isn't a power

management system on the Pi.

Here is a quote from the new O'Riely book Getting Started with the

Beagle Bone....

2. The Power Connector. Your BeagleBone needs 5 volts and 500 mA of

direct current to operate. Most generic 5V DC power adapters with a

2.1mm barrel jack connector will power the board. It’s important to know

that even if a power connector will fit into this jack, it doesn’t

necessarily

mean that it’s providing 5 volts. Right nearby the jack is a small power a

protection chip in case you accidentally provide over five and up to 12

volts. It will protect your board and won’t let it power on if you connect

too much voltage. Still, it’s probably best to make sure you’re plugging

only 5V into the board.

I actually have mine running on a BK Precision .5 to 30 volt adjustable

power supply that can supply up to 30 amps if needed. I have it dialed

in for exactly 5.1 volts.  Even when I'm online the BBB only pulls about

187 miliamps.  The Pi was closer to 400 ma but the mcu on the Pi is

power hog.

The Screen Issue

I realize that EDID is important, but there should be a way to turn it

off for older monitors and let me select the monitor.  The uEnv.txt for

U-Boot does absolutely nothing.  I spent the afternoon trying to get

xrandr to change it but I needed to know the name of the video output. 

I tried every thing to coax the name out of the unit and none of the

names I came up with will work.  I think that the name of the output is

HDMI-A-1, but all the names I tried gave me the same message no output

by that name.

My Screen is an old Sony VGA and my wife used it as her Photshop screen

until we moved and now there is a dark spot in the right corner.  It is

OK as a test screen, but not a color match monitor anymore.  The monitor

will do about 1000x700, so I usually run it at 800x600.  The BBB runs it

at 1280X720 and about 100 pixels are off the screen to the left.  On the

Pi I could take care of this in the config.sys file (which is more

standard Linux than the U-boot approach), I turned the border on and

moved the picture to the left.  I did see that there are two uEnv.txt

files on the machine.  One is in the file system, and the other is the

devices under BeagleBone.  Neither of them seem to do anything.  I found

this when I changed there names to .BAK and then did a restart. There is

no difference in anything on the machine.

What I don't get is why it takes all of the screen resolution choices

away, and that is the same on Ubuntu (Rarring & Precise), Angstrom, and

Debian Wheezy.  On all of these different systems, if you go to System

Settings| Display the only resolution choice is 1280X720 16:9.

If you have any suggestions of where to read up on the any of this I

would appreciate it..

thanks

Mike Connell wrote:

 

Powering the card

That is from the datasheets for the power management system. You could

safely use a 12 volt source with no problems. 

Ok, I'll point out the datasheet for the TPS65217C, as used on the BBB, available from TI here http://www.ti.com/product/tps65217c which states on page 7 under RECOMMENDED OPERATING CONDITIONS

Do you still think 12v is ok ?

Under ABSOLUTE MAXIMUM RATINGS there is:

Stresses beyond those listed under Absolute Maximum Ratings may cause permanent damage to the device. These are stress ratings

only, and functional operation of the device at these or any other conditions beyond those indicated under Recommended Operating

Conditions is not implied. Exposure to absolute maximum rated conditions for extended periods may affect device reliability.

So given that the manufacturer says quite clearly in their datasheet that the effective maximum voltage is 5.8v, why do you think 12v is ok ?

Leaving the manufacturers spec aside for a moment, the BBB schematics show VDD_5V which is before the PMIC going to pins 5 & 6 of the P9 cape expansion header. Are you sure that every currently available cape is prepared to handle 12v on a connection that's clearly labelled 5v ?

Here is a quote from the new O'Riely book Getting Started with the

Beagle Bone....

Sorry, I'll take the chip manufacturers word over an author who doesn't appear to work for the manufacturer or bother checking his facts.

I realize that EDID is important, but there should be a way to turn it

off for older monitors and let me select the monitor.

I can't think of a monitor you'd want to use today that doesn't supply EDID.  DDC & EDID have been standard for 20 years now and HDMI requires it. It may simply be that your HDMI-to-VGA adapter isn't very good and isn't propagating the EDID correctly. You could look in

I spent the afternoon trying to get xrandr to change it

xrandr isn't going to let you change to a mode that the software believes doesn't exist.

On the

Pi I could take care of this in the config.sys file (which is more

standard Linux than the U-boot approach),

config.sys ?  you're thinking about DOS on a PC there    The config.txt that the RPi uses isn't anything like standard either. It's specific to the RPi.

uBoot on the other hand is very common on embedded linux systems, so it's worth taking the time to get to know it even if it's not always particularly user friendly.

What I don't get is why it takes all of the screen resolution choices

away,

I can understand why, although I agree it can be frustrating when it's not working properly.  Think of it this way, if it let you pick a screen mode that's not known to be safe and consequently that mode damaged your display you'd be justifiably angry (there have been reports of RPi damaging expensive TV's over in their forums). There's also the more unlikely possibility that by overdriving an old CRT outside it's limits you could overheat the flyback transformer, set it on fire and burn the house down. You'd be more than angry at that point I suspect. 

So, yes it's annoying, however there are very reasonable arguments for either:

• limiting things to EDID (or a known safe mode if no EDID)
• just letting the user be responsible for destroying their own equipment. 

In these days of lawsuits it's maybe somewhat more understandable that the developers have taken the safer route.

As a first suggestion for xrandr outputs, try 'default' without the quotes for the output. Otherwise, if you want to post some of the command lines you've had problems with there may be someone here who can offer some advice.

I can't suggest a good place to read up on this stuff, most of what I've picked up has been reading about other people struggling with KMS on the linux-kernel mailing list over the years - lkml really isn't something you want to be spending your time reading though, not if you value your sanity or have anything else to do

I'd suggest looking at https://github.com/torvalds/linux/blob/master/Documentation/EDID/HOWTO.txt but it appears that the kernel on my BBB is compiled without that option, so that won't help you.

Possibly look at the drm_kms_helper.edid_firmware section in https://github.com/torvalds/linux/blob/master/Documentation/kernel-parameters.txt and see if one of the built-in ones is useful - however I suspect that

# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set

in the kernel config means you can't use those either.  That leaves you with re-building the kernel to get access to the options, then finding a suitable set of fake edid settings for your monitor.

A tip for EDID is that you can look at the contents of /sys/devices/ocp.2/4830e000.fb/drm/card0/card0-HDMI-A-1/edid to see if there's anything useful in it, there are some programs out there to parse this data into human readable format, but the one I just tried (http://www.polypux.org/projects/read-edid/) makes all sorts of x86 assumptions and so isn't easily buildable on the BBB.

Mike Connell wrote:

 

Powering the card

That is from the datasheets for the power management system. You could

safely use a 12 volt source with no problems.

This is not correct, exceeding the recommended operating voltage will damage the board.

I actually have mine running on a BK Precision .5 to 30 volt adjustable

power supply that can supply up to 30 amps if needed. I have it dialed

in for exactly 5.1 volts.  Even when I'm online the BBB only pulls about

187 miliamps.  The Pi was closer to 400 ma but the mcu on the Pi is

power hog.

The biggest power hog on the Pi is the Ethernet controller not the SoC (is not an MCU).

Cheers

Jorge

selsinork wrote:

 

A tip for EDID is that you can look at the contents of /sys/devices/ocp.2/4830e000.fb/drm/card0/card0-HDMI-A-1/edid to see if there's anything useful in it, there are some programs out there to parse this data into human readable format, but the one I just tried (http://www.polypux.org/projects/read-edid/) makes all sorts of x86 assumptions and so isn't easily buildable on the BBB.

The standard Angstrom package parse-edid contains /usr/bin/parse-edid and this works for me:

$ parse-edid  <  /sys/devices/ocp.2/4830e000.fb/drm/card0/card0-HDMI-A-1/edid

 

parse-edid: parse-edid version 2.0.0
parse-edid: EDID checksum passed.

        # EDID version 1 revision 3
Section "Monitor"
        # Block type: 2:0 3:ff
        # Block type: 2:0 3:fc
        Identifier "DELL 2408WFP"
        VendorName "DEL"
        ModelName "DELL 2408WFP"
        # Block type: 2:0 3:ff
        # Block type: 2:0 3:fc
        # Block type: 2:0 3:fd
        HorizSync 30-83
        VertRefresh 56-76
        # Max dot clock (video bandwidth) 170 MHz
        # DPMS capabilities: Active off:yes  Suspend:yes  Standby:yes

        Mode    "1920x1200"     # vfreq 59.950Hz, hfreq 74.038kHz
                DotClock        154.000000
                HTimings        1920 1968 2000 2080
                VTimings        1200 1203 1209 1235
                Flags   "-HSync" "+VSync"
        EndMode
        # Block type: 2:0 3:ff
        # Block type: 2:0 3:fc
        # Block type: 2:0 3:fd
EndSection

As expected, the BBB runs its HDMI at its maximum of 1280X720 into the above more capable screen.

The DC Plug on the board goes into pin 10 of the TPS65217C IC (see schematic on page 38 in the Beagle Bone Black Manual).  Pin 10 is labeled AC.

Under ABSOLUTE MAXIMUM RATINGS there is:

As you can see the pin in question is pin 10 which is the AC pin, and from the datasheet you can see that the absolute maximum is 20 volts not 5.7.  The regulator system wouldn’t be much of a regulator system if it couldn’t handle 12 volts. 

I am not saying that I would connect a 12 volt supply to the input.  What I am saying is that you can on the BBB, but you can’t on the Pi, because the Pi doesn’t have any regulation on it at all.

Mike Connell wrote:

 

The DC Plug on the board goes into pin 10 of the TPS65217C IC (see schematic on page 38 in the Beagle Bone Black Manual).  Pin 10 is labeled AC.

 

Under ABSOLUTE MAXIMUM RATINGS there is:

	VALUE	UNIT
Supply voltage range (with respect to PGND)	BAT	-0.3 to 7	V
	USB, AC	-0.3 to 20	V

 

 

As you can see the pin in question is pin 10 which is the AC pin, and from the datasheet you can see that the absolute maximum is 20 volts not 5.7.  The regulator system wouldn’t be much of a regulator system if it couldn’t handle 12 volts.

 

I am not saying that I would connect a 12 volt supply to the input.  What I am saying is that you can on the BBB, but you can’t on the Pi, because the Pi doesn’t have any regulation on it at all.

Out of insatiable curiosity, I took a look at the TPS65217 data sheet.  According to my understanding, it can indeed tolerate 20V on AC or USB, but if they're more than 6.5V the internal NFETs switch off to protect SYS from excessive voltage.  Look for "over-voltage" in the data sheet.  From my read of the data sheet, the TPS65217 is not going to regulate 20V down to 5V in such a tiny package.  The NFETs serves the same purpose as RasPi's 5V zener diode plus fuse.

John Beetem wrote:

 

Out of insatiable curiosity, I took a look at the TPS65217 data sheet.  According to my understanding, it can indeed tolerate 20V on AC or USB, but if they're more than 6.5V the internal NFETs switch off to protect SYS from excessive voltage.

There's a big difference between tolerating 20V without destroying the regulator and working correctly at 20V input. The regulator surviving but the rest of the board being destroyed isn't a good outcome either.

Turning off the outputs above 6v to protect things may be a good thing, but on the BBB there's a bypass of the unprotected input onto P9. So it's impossible to know if an input above 5v is safe unless you know the details of the power system on all possible capes as well.

Mike seems either unwilling or incapable of reading past the absolute maximum ratings line in the datasheet, that's fine and I'll now leave him to it.  I do however feel that mis-information like this needs challenged and with references to the information provided by the manufacturer.

I'll leave it to others to read the information themselves and decide if the beaglebone blacks SRM and TI's data sheets or Mikes statements are the ones they should pay attention to.

Morgaine Dinova wrote:

 

The standard Angstrom package parse-edid contains /usr/bin/parse-edid and this works for me:

That doesn't seem to be on mine, but I'm still running one of the earliest angstrom images.  I've learned the hard way that opkg usage tends to break things so I don't tend to bother with it.

The one I linked to provides source to read-edid, get-edid (for DOS) and parse-edid, however try to build it and it's looking for things like libx86.h hence not easily buildable on an arm device. Possible if you have the patience to work through it though.

As expected, the BBB runs its HDMI at its maximum of 1280X720 into the above more capable screen.

What's interesting here is that I get 1280x1024 into a 1600x1200 screen. I'm going to grab the 2013.06.20 angstrom and see if there's any improvement.

Iain Paton wrote:

 

I'm going to grab the 2013.06.20 angstrom and see if there's any improvement.

So with the 2013.06.20 angstrom image I get 1920x1080p24 on an appropriate display, and 1920x1080p30 after adding capemgr.disable_partno=BB-BONELT-HDMI into the uEnv.txt on /dev/mmcblk0p1 as suggested in http://circuitco.com/support/index.php?title=BeagleBoneBlack_HDMI

I've had no luck getting 1920x1080p60 with no audio yet and the kernel in this latest angstrom still has the EDID firmware loading capability disabled.

There's a lot of extra debug information in the logs now to show you what modes were detected and why some were excluded.

It's worth noting that xrandr only shows the "supported" resolutions, not the full list. For the full list you need to go look in the kernel logs.

parse-edid similarly doesn't list all of the modes, and in my case one of the two modes it shows has been specifically excluded as invalid by the kernel driver!

Morgaine, I suspect you'll not be able to get 1920x1080 out of your monitor by default. Even if it is technically capable of it. Might work with a forced override, but as it seems that while a forced override will work for the console, Xorg helpfully ignores the override

Maximum absolute ratings are not "operating ratings," what they basically mean is that if for any event you happen to apply more than the absolute, there is a very high probability that you will have a fried integrated circuit. That parameter means that those inputs are protected up to 20V not that will operate up to 20V.

The maximum recommended operating voltage is 5.8V ... NOT 20V

Also, the TPS65217 includes input overvoltage detection, and the threshold values are 5.8V - 6.4V, if you exceed that threshold the PMIC will enter in FAULT mode and shutdown power until the voltage goes back to < 6.5V.

Following your reasoning the TPS65217 should also work with -0.3V ...

If you care to take a look at the Raspberry Pi schematics you will learn that it has three voltage regulators on the board, plus the internal ones in the SoC and Ethernet controller (not populated in Model A,) what it does not have (pitty) is a Power Management chip.

BTW, have you actually tried to power your BBB with 12V ?

Just to make it clear ...

YOU CAN NOT POWER THE BBB WITH 12V

Cheers

Jorge

selsinork wrote:

 

So with the 2013.06.20 angstrom image I get 1920x1080p24 on an appropriate display, and 1920x1080p30 after adding capemgr.disable_partno=BB-BONELT-HDMI into the uEnv.txt on /dev/mmcblk0p1 as suggested in http://circuitco.com/support/index.php?title=BeagleBoneBlack_HDMI

 

Morgaine, I suspect you'll not be able to get 1920x1080 out of your monitor by default.

I should have said that my BBB's parse-edid output was on the original image and kernel (3.8.6) but with that utility installed using opkg.  I'm clearly not going to see any improvements until get a new image (or at least kernel) installed, but I was postponing that until I take the step of moving to Debian.

I see no future in Angstrom, because "support" from its maintainer ranges from poor to non-existent.  He blames all problems on upstream and has no interest in making Angstrom work out of the box, which is why every problem that I experienced on my old BeagleBone white a year ago is still present in BBB.  That makes Angstrom worthless to me.  I don't have time to be doing the maintainer's job for him.  It contrasts markedly with the pride that Debian take in making their distro work cleanly.