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

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

My HDMI adapter has a wall wart (AC power supply), but I did have the same problem with the Pi.  I did the same thing you did  for the 16 USB stick that I had on the Pi (the processor sure is a power hog).

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.

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.

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

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.

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.

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.