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

a post in the google group suggests it's available here http://dominion.thruhere.net/koen/angstrom/beaglebone/?C=M;O=D from the person who builds the images, as a couple of others have posted that it's vanished off the official page. There's a newer image up on that site too.

Teething troubles can only be expected at this stage especially as more people get their hands on them.  Still it would be nice if they'd added a "pulled because of...." message so that people who've installed it already know what to expect.

I'm not a fan of forums at the best of times, but that google groups thing they're using is awful, and the general mixture of beagleboard, beaglebone and beaglebone-black stuff leaves you never quite sure if what you're reading even applies to your board.

selsinork wrote:

 

that google groups thing they're using is awful, and the general mixture of beagleboard, beaglebone and beaglebone-black stuff leaves you never quite sure if what you're reading even applies to your board.

Totally agree with both of those points.

It would be easy enough for us to make a dedicated BeagleBone (or even more specific BBB) group here to categorize information more clearly, but I suspect that the upstream info isn't ever going to get any clearer because the BeagleBoard old timers have grown up with their pre-AM3358 gear and probably don't see any issue.

The present single thread isn't helping either --- all this info is going to get submerged and lost very quickly.  The problem is particularly acute for beginners, who are faced with a long thread to navigate and no way to title their own posts to highlight their question.  Nobody is benefiting from this.

We really ought to be capitalizing on Element 14's effective group system for BB[B].  It has worked out very well for Raspberry Pi, and is likely to prove equally useful for managing info and discussions about BBB better than is being done at present.

Morgaine.

I'm not a fan of forums at the best of times, but that google groups thing they're using is awful, and the general mixture of beagleboard, beaglebone and beaglebone-black stuff leaves you never quite sure if what you're reading even applies to your board.

I agree - I've been trying to find a fix for a problem I'm having with using HDMI and I keep coming across stuff that doen't apply to the BBB despite putting "BBB" or "BeagleBone Black" into the search terms

I can't find a way to compensate for overscan or to set the resulution manually (unlike the Pi which is actually very good in that regard).

I posted a question there yesterday.

https://groups.google.com/forum/#!searchin/beagleboard/bbb$20uEnv.txt/beagleboard/xobKNktj6WI/mZsxCRJMwasJ

I haven't had any response as yet but I have a horrible feeling after reading the reply by Robert Nelson in this other thread about HDMI problems that there may be no solution:

https://groups.google.com/forum/#!searchin/beagleboard/bbb$20uEnv.txt/beagleboard/fPBgF7j_WX4/XrI0TUrVsPUJ

I was going to update to the image mentioned above (2013.05.3) that has now been pulled as it apparently defaulted to 1280x720 - maybe I'll try the newer one or maybe I'll wait a while and see what happens next.

It also strikes me as slightly strange that they didn't fix the "no audio output over HDMI" before doing a production release.

I'm not convinced at the moment that the BBB would be a very good "out of the box" experience for a novice when compared with the Pi in present form.

Morgaine Dinova wrote:

 

The present single thread isn't helping either --- all this info is going to get submerged and lost very quickly.  The problem is particularly acute for beginners, who are faced with a long thread to navigate and no way to title their own posts to highlight their question.  Nobody is benefiting from this.

Yeah, unfortunately while we only have a BBB discussion area that's buried in the bowels of the knode and therefore hard to find it's difficult to do a lot about it. The title of this thread probably doesn't help either.

Until the Admins decide to create a top level BBB group I think we're stuck.

dhid wrote:

 

I agree - I've been trying to find a fix for a problem I'm having with using HDMI and I keep coming across stuff that doen't apply to the BBB despite putting "BBB" or "BeagleBone Black" into the search terms

I keep finding things where you think you've got a BBB specific page but the link from there takes you to a generic BeagleBoard (not even original beaglebone) page. To the point that I was given a BeagleBoard xM SRM at one stage.

Unseen barriers like this will put off a lot of beginners.

I haven't had any response as yet but I have a horrible feeling after reading the reply by Robert Nelson in this other thread about HDMI problems that there may be no solution:

hmm.. I see him mention KMS  

It also strikes me as slightly strange that they didn't fix the "no audio output over HDMI" before doing a production release.

I'm sure these things will get fixed in time, but as there's already a DVI with audio cape I agree it's surprising it doesn't work yet

I'm not convinced at the moment that the BBB would be a very good "out of the box" experience for a novice when compared with the Pi in present form.

The Pi has had over a year to get it's act together, it had its share of issues in the first few weeks after availability as well. If the tether to your main PC works, and it didn't for me for unknown reasons, I expect the BBB will be a much better starting point. The web based interface, IDE, bonescript stuff etc certainly looks very slick and much better for a beginner than a command prompt and not knowing you need to type startx...

dhid wrote:

 

I agree - I've been trying to find a fix for a problem I'm having with using HDMI and I keep coming across stuff that doen't apply to the BBB despite putting "BBB" or "BeagleBone Black" into the search terms

I keep finding things where you think you've got a BBB specific page but the link from there takes you to a generic BeagleBoard (not even original beaglebone) page. To the point that I was given a BeagleBoard xM SRM at one stage.

Unseen barriers like this will put off a lot of beginners.

I haven't had any response as yet but I have a horrible feeling after reading the reply by Robert Nelson in this other thread about HDMI problems that there may be no solution:

hmm.. I see him mention KMS  

It also strikes me as slightly strange that they didn't fix the "no audio output over HDMI" before doing a production release.

I'm sure these things will get fixed in time, but as there's already a DVI with audio cape I agree it's surprising it doesn't work yet

I'm not convinced at the moment that the BBB would be a very good "out of the box" experience for a novice when compared with the Pi in present form.

The Pi has had over a year to get it's act together, it had its share of issues in the first few weeks after availability as well. If the tether to your main PC works, and it didn't for me for unknown reasons, I expect the BBB will be a much better starting point. The web based interface, IDE, bonescript stuff etc certainly looks very slick and much better for a beginner than a command prompt and not knowing you need to type startx...

To the point that I was given a BeagleBoard xM SRM at one stage.

Yes I think I must have clicked on the same link as it wasn't until I started to read it that I realised it was for the wrong board!

hmm.. I see him mention KMS  

I'm not a Linux expert at all but does this mean that you have to have a suitable EDID file to force a particular mode?

The Pi has had over a year to get it's act together, it had its share of issues in the first few weeks after availability as well. If the tether to your main PC works, and it didn't for me for unknown reasons, I expect the BBB will be a much better starting point. The web based interface, IDE, bonescript stuff etc certainly looks very slick and much better for a beginner than a command prompt and not knowing you need to type startx...

Yes that's true and we won't mention the USB problems! I spent may "happy" hours hunting for different keyboards and mice in the early days of Pi, including a late night trip to Asda to buy a keyboard which worked, despite having various ones lying around, none of which did work. Then of course the little design "hiccup" over the power rails........

Regards tethering - I couldn't get SSH working using the included browser client so I ended up using putty, but I agree the concept is good if they can fine tune it so it works ok on most browser and operating system combinations.

EDIT:

Sorry selsinork I hadn't seen your other reply before posting this.

Thanks I'll have a look at the kernel-parameters.txt

dhid wrote:

 

I'm not a Linux expert at all but does this mean that you have to have a suitable EDID file to force a particular mode?

The EDID is supposed to be supplied by the display, essentially there's an I2C connection between the display and the device. Called DDC - http://en.wikipedia.org/wiki/Display_Data_Channel

This has been around since the 15pin vga days at least. It allows the display to essentially have a small eeprom containing descriptions of the various modes that it supports. The connected device can read these and set itself up accordingly. In some cases the I2C connection can also be used for software control of the display brightness, contrast etc.

However, historically the display mode in windows, linux etc has been set manually in the driver. So all sorts of displays either don't provide the data at all, don't provide correct data or whatever.  The downside to KMS appears to be that it expects everything to play by the rules and unconditionally believes whatever rubbish it reads out of the EDID - leading to problems when something is not right, and that could be as simple as the necessary connections are missing from the cable.

So at some point they've provided the option to force KMS to use an EDID provided by the user instead of believing the display. That gives you a way out, but is rather different from the older kernel command line options that google will turn up.

I've not looked in detail, but I suspect it doesn't give you the same level of control as you can get from config.txt on the Pi. For example, as EDID was originally for computer displays I don't know if it'll have a way to specify overscan settings to solve your problem.

Some details on EDID data format here http://en.wikipedia.org/wiki/Extended_display_identification_data I don't see anything specific for overscan though there may be ways to use horizontal blanking ot border settings to deal with it.

selsinork wrote:

 

dhid wrote:

 

I'm not a Linux expert at all but does this mean that you have to have a suitable EDID file to force a particular mode?

The EDID is supposed to be supplied by the display, essentially there's an I2C connection between the display and the device. Called DDC - http://en.wikipedia.org/wiki/Display_Data_Channel

This has been around since the 15pin vga days at least. It allows the display to essentially have a small eeprom containing descriptions of the various modes that it supports. The connected device can read these and set itself up accordingly. In some cases the I2C connection can also be used for software control of the display brightness, contrast etc.

 

However, historically the display mode in windows, linux etc has been set manually in the driver. So all sorts of displays either don't provide the data at all, don't provide correct data or whatever.  The downside to KMS appears to be that it expects everything to play by the rules and unconditionally believes whatever rubbish it reads out of the EDID - leading to problems when something is not right, and that could be as simple as the necessary connections are missing from the cable.

 

So at some point they've provided the option to force KMS to use an EDID provided by the user instead of believing the display. That gives you a way out, but is rather different from the older kernel command line options that google will turn up.

I've not looked in detail, but I suspect it doesn't give you the same level of control as you can get from config.txt on the Pi. For example, as EDID was originally for computer displays I don't know if it'll have a way to specify overscan settings to solve your problem.

Some details on EDID data format here http://en.wikipedia.org/wiki/Extended_display_identification_data I don't see anything specific for overscan though there may be ways to use horizontal blanking ot border settings to deal with it.

Thanks selsinork I've never really looked at the EDID stuff much before as I've mostly used Windows and what Unix I used in the past was on terminals with no graphics.

Well I've half solved my problem!

I noticed that RT1 (Polyswitch type fuse for HDMI) was rather hot when I had the HDMI to VGA Adaptor plugged in! Remembering that the HDMI to VGA converters draw a fair bit of current and as the Polyswitch is only 100mA hold current I hooked it out and connected the HDMI 5V to VDD via meter on 300 mA current range and discovered it draws between 140 and 200 mA and worked when connected like this!

So that explains why I got a display briefly when I connected the HDMI converter having already booted connected to the TV but got nothing when booting with it connected directly - there was a couple of seconds before the Polyswitch started to go to high resistance and drop the voltage below that required for the HDMI converter to function correctly.

I've now put a link in between VDD and the HDMI 5V and the HDMI to VGA converter works OK and with no overscan, unlike the TV. I just need to try to sort out the overscan problem when connected to the TV.

I'll start having a play with creating an EDID file and trying different resolutions and refresh rates and see what happens.

Thanks for your interest and help - much appreciated!

dhid wrote:

 

I just need to try to sort out the overscan problem when connected to the TV.

 

I don't own a TV, so probably not a lot of help here, but I know that some displays have an option to turn off overscan. My Samsung 400UX-2 has a 'Size' option with 'screen fit', Zoom1, Zoom2, 4:3, 16:9 options. Setting it to Screen fit defeats overscan and gives you a native resolution display. Not that I can understand why you'd ever want overscan on a display like this..

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.