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

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.

At one of the sites, that you guys sent me, I saw a conversation about

the two varieties of Debian, one was the Desktop version, and the other

I don't remember the name of.  They were saying that the Desktop version

is much larger and takes longer to load, and has no advantage.  Is the

mystery version the one you are using?

There are a few pre-built images around but I built my own using the Rober Nelson build instructions the rootfs he provides has apache2 and sshd installed and running,  no X windows so just console but then once it's up and running you can configure whatever else you need.

I boot and run from a 16Gbyte class 10 uSD card not the eMMC. I also have a 1TByte USB HD which I use for development and backup.

.

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.

Brian Welsby wrote:

 

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

All distros have that problem though. Once you reach a certain point, and that might be just 100 or so packages, it starts to become a real challenge to keep up to date with everything and to handle the interdependant forward and backward breaking changes. 

Generally out of date only matters if there's a security fix or new feature you require that's missing in the old version.

Something being built for an older kernel generally isn't an issue and can often be a good thing. 3.2 really isn't old enough to be a big issue here.  However, if you think having things built for the current kernel is good, then I encourage you to rebuild glibc against the 3.10 kernel (use the --enable-kernel=3.1.0 configure option). When you find a bug in 3.10 that causes you to have to revert to 3.9.x until the bug gets fixed you'll have all sorts of fun when you reboot.

Bits missing is a bigger issue, most often when something's been built without some necessary feature.  Building something from source because there's no package available is usually ok. Building something where a package exists just to enable a feature comes with a much more interesting set of problems.

Brian Welsby wrote:

 

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

All distros have that problem though. Once you reach a certain point, and that might be just 100 or so packages, it starts to become a real challenge to keep up to date with everything and to handle the interdependant forward and backward breaking changes. 

Generally out of date only matters if there's a security fix or new feature you require that's missing in the old version.

Something being built for an older kernel generally isn't an issue and can often be a good thing. 3.2 really isn't old enough to be a big issue here.  However, if you think having things built for the current kernel is good, then I encourage you to rebuild glibc against the 3.10 kernel (use the --enable-kernel=3.1.0 configure option). When you find a bug in 3.10 that causes you to have to revert to 3.9.x until the bug gets fixed you'll have all sorts of fun when you reboot.

Bits missing is a bigger issue, most often when something's been built without some necessary feature.  Building something from source because there's no package available is usually ok. Building something where a package exists just to enable a feature comes with a much more interesting set of problems.

I don't disagree with what you are saying, all I want is the basic kernel and the tools to build what I need.

As an example, I was trying to get Qt working...  On the BBB just install the Qt tools and you get Error required kernel 3.2.0 so check the BBB forums and the response there is that as opengl-es isn't yet available for kernel 3.18 you can't have it  so install with --force-depends and most of it will work. Ok so far so good but missing some functionality..  so I thought what about using Qtcreator on desktop and cross compile / develop Qt on desktop as per excellent tutorials on Derek Malloys site (written for BBW) you can download the toolchain etc etc but when you go to the Angstom site to get the toolchain you see the ones with qte were produced in 2011 and are Qt v4.6.1.

I thought I would see about bringing this up to v4.8.x but first of all try to build the tool chain as is.   I installed all the Angstrom build system, rebuilt the kernel etc all worked so then tried the bitbake recipe to build the qte toolchain. it started the process, got so far then error saying it couldn't find the compiler???  turns out it was looking for a different cross compiler to the one the system had built / installed so that then means getting into all the recipes understanding all the bitbake system etc etc..... just too much. It looks like I was using parts of the system that was created in 2011 with the current build system that has been put together for the 3.18 kernel development so even though the recipes are there they are no longer compatible.

On Debian I just install the Qt4 sdk and "everything" is there including qtcreator, and the demos and examples I installed xorg and fluxbox as the window manager and I had an application up and running within minutes. I downloaded the Qt serial port addon and it compiled installed and tested working. 

I have also installed on my BBB the software for my 3D printer I am building and yet again it just works.

If I want to use Java, Python, Perl, PHP, Ada, Fortran, or whatever I am confident that with Debian I can, with Angstrom I expect many issues.

In effect, you're saying that the distro is unmaintained and so its problems are revealed continually by users as they try to get work done, instead of being caught and revealed by an automated continuous build system.

That's a substantially shorter statement of the problem.

Morgaine Dinova wrote:

 

In effect, you're saying that the distro is unmaintained and so its problems are revealed continually as users try to work with it instead of being revealed by an automated continuous build system.

 

That's a substantially shorter statement of the problem.

Yes

Brian Welsby wrote:

 

Yes

I've added it to my list of recommendations as the new maintainer's "second responsibility".

Unfortunately the probability of Jason looking here is rather small, and this being a catch-all thread, all this will soon submerge without trace.  Even if seen, the likelihood of these concerns being shared is unknown and probably low, and the likelihood of change even lower.

Brian Welsby wrote:

 

On the BBB just install the Qt tools and you get Error required kernel 3.2.0 so check the BBB forums

From what I can tell that error is from opkg.. Leaving aside the opengl-es part for a moment, you're looking at crap dependencies in the packaging here.  I'll say nothing more than that IMHO any distro that does dependencies in the packages is fundamentally broken as they all consistently make a mess of them.

The opengl-es part is always going to be problematic as you're off into GPU territory. We know the shiny new DRM/KMS driver for the BBB has issues, so it follows that things relying on it will too.  I really wish all of the embedded systems would just give up on the -es front and just use the normal OpenGL. My reason is fairly simple, using the normal one means you have far more help available from others in the community who wouldn't otherwise care about the -es side.

From my side, the whole angstrom build system with cross compilers and such like is a waste of time. I'd much prefer to be getting an app compiled than trying to debug why the toolchain can't find it's compiler. As such I strongly support the debian ideal of building everything natively.

If I want to use Java, Python, Perl, PHP, Ada, Fortran, or whatever I am confident that with Debian I can, with Angstrom I expect many issues.

In a lot of ways I'd argue that I don't want a lot of those on an embedded system at all.  I've come to expect issues with angstrom no matter what I try to do

Unfortunately angstrom remains useful as it'll be the place kernel fixes get developed and tested first.

Morgaine Dinova wrote:

 

That's a substantially shorter statement of the problem.

Can't we just go with "angstrom is $%!te" ?

selsinork wrote:

 

Can't we just go with "angstrom is $%!te" ?

That certainly hits the sweet spot for being concise.   But Jason's a good guy and deserves a bit more to work with.

I agree with your earlier point that just two maintainers probably would not be enough given the workload, but it would at least be a start.  What's most missing currently though is the will to maintain the distro and to work directly towards raising its quality.  In fact, I think it's fair to say that the aim is to avoid any distro maintenance whatsoever, as a matter of policy, so it's no surprise that its present quality is quite poor.

Morgaine Dinova wrote:

most missing currently though is the will to maintain the distro

and I do believe that trying to maintain a full distro on your own is likely to destroy any will that existed, quite quickly too.

I'm confused though, all the other bits like bonescript that seem to be done by Jason himself don't appear to have any particular reliance on angstrom. I can't think of a reason you couldn't layer them on top of debian, gentoo, or something else that would relieve the pressure of having to maintain a full distro yourself.

Which leaves it as a conscious choice to persist with angstrom and it's problems. I have difficulty understanding a choice like that.

selsinork wrote:

 

I'm confused though, all the other bits like bonescript that seem to be done by Jason himself don't appear to have any particular reliance on angstrom. I can't think of a reason you couldn't layer them on top of debian, gentoo, or something else that would relieve the pressure of having to maintain a full distro yourself.

 

Which leaves it as a conscious choice to persist with angstrom and its problems. I have difficulty understanding a choice like that.

According to my recollection, Ångström was the first OS to run on BeagleBoard and at the time beagleboard.org had minimal involvement with software and was happy to get help from anywhere.  I used Ångström quite a bit as a generic GNU/Linux OS, and it worked fine for my modest OS needs.  My understanding is that Ångström runs well with less memory than larger distros like Debian, which was important with only 128KB 128MB of DRAM on the original BeagleBoard.  Debian runs fine on a 256KB 256MB RasPi so Beagle might as well switch over.  IMO the key question is which OS is best supported on each platform, and that depends on the individual interests of OS maintainers.

Edit: oops

John Beetem wrote:

 

My understanding is that Ångström runs well with less memory than larger distros like Debian,

absolutely agree, angstrom seems to have cut out a lot of the bloat of the bigger distros, but that does come at a price.

which was important with only 128KB of DRAM on the original BeagleBoard. 

KB ?  Can I borrow your time-warp machine John ? 

IMO the key question is which OS is best supported on each platform, and that depends on the individual interests of OS maintainers.

Well yes, but given that for generic linux the real differences are all in the kernel... much easier to build a kernel that you can sit debian on top of than trying to re-invent debian