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

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.

Morgaine,  Sadly I have to agree with your view of Angstrom. I have spent days / weeks trying to get things working on Angstrom only to find that packages are out of date, built for 3.2 kernel, have bits missing or are just not there at all. I have tried building the missing bits to find yet more missing dependencies so eventually I have given up with it.

I am now running Debian, everything I want is there and reasonably up to date and, most importantly, it works.

No I have no tried to, but I will try it tonight and let you know....

I am good at letting out factory smoke...

True Brian, I've seen some dependency issues too, it seems that listed dependencies are not really complete.  I've had to copy files over from other distros occasionally to fill in the gaps, which is unsatisfactory because that just stores up problems for the future.

On top of this, several packages that I use regularly are not available in opkg list despite being provided in every other distro that I've used, so it's not really a supportive distro even without its maintenance problems.  It's really just a thrown together initial selection of  packages without any further improvement nor maintenance, and it's either untested for full functionality or else tested by someone with a very low quality bar.  Needless to say there is no official bug tracker, and it seems that there is no willingness to accept that problems even exist, let alone to get them fixed so that users can enjoy the distro and be immediately productive with it.

In fact, just reading the Angstrom website front page highlights that Angstrom is completely unsupported and that if you have any problems, they are yours.  It reads like an unprofessional tantrum by a 14-year old BOFH wannabe.  It stresses the importance of reading the FAQ but the FAQ button links to a nonexistent page, which is totally typical.  Given that so many other distros exist and have effective maintainers with an ethos of continual improvement, why bother with Angstrom?  I wouldn't advise it to anyone who wants to get work done.

True Brian, I've seen some dependency issues too, it seems that listed dependencies are not really complete.  I've had to copy files over from other distros occasionally to fill in the gaps, which is unsatisfactory because that just stores up problems for the future.

On top of this, several packages that I use regularly are not available in opkg list despite being provided in every other distro that I've used, so it's not really a supportive distro even without its maintenance problems.  It's really just a thrown together initial selection of  packages without any further improvement nor maintenance, and it's either untested for full functionality or else tested by someone with a very low quality bar.  Needless to say there is no official bug tracker, and it seems that there is no willingness to accept that problems even exist, let alone to get them fixed so that users can enjoy the distro and be immediately productive with it.

In fact, just reading the Angstrom website front page highlights that Angstrom is completely unsupported and that if you have any problems, they are yours.  It reads like an unprofessional tantrum by a 14-year old BOFH wannabe.  It stresses the importance of reading the FAQ but the FAQ button links to a nonexistent page, which is totally typical.  Given that so many other distros exist and have effective maintainers with an ethos of continual improvement, why bother with Angstrom?  I wouldn't advise it to anyone who wants to get work done.

Morgaine Dinova wrote:

 

On top of this, several packages that I use regularly are not available in opkg list despite being provided in every other distro that I've used,

I won't argue that angstrom has issues, but as you know from other discussions it's my belief that all distros have issues. That said, a distro having different goals and building on different design decisions shouldn't come as any surprise, the same could be said for arch vs debian vs fedora vs gentoo (and I see there's now a gentoo build for BBB which may please you) vs suse vs slackware, they all have different goals and provide different packages compiled in different ways.

One of my pet peeves is that in a lot of cases you have something like Raspbian trying to force a full desktop distro into an embedded device that really doesn't have the resources for it, so I quite like that angstrom leaves out a lot of non-essential stuff that I'd be tempted to lump into the 'bloat' category myself.

I also assume that your set of regularly used packages is different from mine and from Brians too, so not sure it's fair to compare that way. What doesn't work for you might be fine for me.

On the angstrom website, I know what you mean. You'll also notice that the angstrom version that appears on the BBB doesn't seem to be very closely related to the website, in fact I suspect you couldn't rebuild the BBB angstrom version yourself if you start at that site. I'm not actually sure you could rebuild it at all as I don't think enough of the pieces are available or well enough documented anywhere.

But you have to ask yourself if that's better or worse for other distros. We've seen the problems Mike Thomson had duplicating the debian build system in order to start on Raspbian, so I expect it's just a difference in how far off the bottom of the scale they all are.  Gentoo and LFS may be different in that regard, but then so are their goals.

I have no doubt that Angstrom's goals are different, and the BBB's version of Angstrom different yet again.  That's not the problem.

The problem is that whatever those goals are, they do not include the distro being maintained in working order by a maintainer.  Instead, it's unmaintained so that problems persist over long periods of time --- monitoring the IRC logs shows the same problems coming up again and again as beginners arrive and report their woes.  Quite often they're even ridiculed.  And no bug tracker means no bug tracking and no responsibility for quality.

Nor do those goals include the distro continually being expanded with more packages so that end users used to other distros have a good likelihood of finding their favorite packages ready to install so that getting work done is just minutes away.  Instead they have to port any missing applications themselves, because the maintainer's principle is "I do nothing, if you want something done then do it yourself."

Such "goals" are, to my mind, not the goals of a distro worth using.  I can fix pretty much any problem after decades in the *nix world.  But why should I have to?

Because of the lack of bug tracking and responsible maintenance, the same problems are being fixed by thousands of users in parallel as they discover them, and then fixed again for each new image that they download and write.  What a total waste of everyone's time.

Every identified problem deserves a proposed solution, so here are my recommendations to Jason Kridner.  Since Angstrom is not just a hobby distro but part of commercial products and the quality of the supplied operating system impacts on Beagleboard.org and TI, do the following:

• Appoint a second maintainer in addition to the existing one.
• Make the new maintainer's first responsibility to implement a bug tracker.
• Make the new maintainer's second responsibility to implement an automated continuous build system.
• Make the new maintainer's ongoing responsibility to raise the quality of the distro by 1) fixing bugs caught by the continuous build system, 2) fixing bugs in order of priority on the tracker, and 3) adding packages identified as missing and/or requested on the tracker.
• Proactively add items to the bug tracker based on problems reported on the mailing list and on IRC.

I guess it's obvious enough, but sometimes even obvious solutions need stating.

Morgaine Dinova wrote:

 

Such "goals" are, to my mind, not the goals of a distro worth using.

I don't disagree, but you can't deny that if those really are their goals then they're doing well at meeting them

I would disagree with your other post though. Having just one additional maintainer isn't enough, it needs a team of people who are interested and will actively contribute. If the current maintainer is blocking the process then it's probably time to remove the roadblock.  The project as a whole won't survive on the shoulders of just one or two people, a distro is too big for that.

Yes there needs to be a public bug tracker, a mailing list, up to date documentation, and the full build system needs to be in a public git tree somewhere so that if the existing maintainers disappear or become roadblocks then others can fork the whole thing without a ground-up rebuild.