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:

 

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 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.

did you try 'nomodeset' to stop KMS being stupid ?

Don't know if it helps or not, but there seems to be a way to override the KMS settings. kernel-parameters.txt has the following:

drm_kms_helper.edid_firmware=[<connector>:]<file>

                        Broken monitors, graphic adapters and KVMs may

                        send no or incorrect EDID data sets. This parameter

                        allows to specify an EDID data set in the

                        /lib/firmware directory that is used instead.

                        Generic built-in EDID data sets are used, if one of

                        edid/1024x768.bin, edid/1280x1024.bin,

                        edid/1680x1050.bin, or edid/1920x1080.bin is given

                        and no file with the same name exists. Details and

                        instructions how to build your own EDID data are

                        available in Documentation/EDID/HOWTO.txt. An EDID

                        data set will only be used for a particular connector,

                        if its name and a colon are prepended to the EDID

                        name.

So possibly you can write an EDID that does what you need ?

No way for me to try it - don't have a microHDMI cable yet !

Oh, and the first few lines of that EDID/HOWTO.txt file really says quite a lot about KMS

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..

selsinork wrote:

 

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.

The old Google Groups wasn't bad.  The new Google Groups is awful IMO which prevents me (and I'm sure many others) from casual use.  This means that if you do post a problem, the people who might be able to help you don't visit very often and your query goes unanswered.

One thing I like about element14 is that you can quickly view presence of new comments in many groups (though not 'blog comments, alas) so in a few seconds I can see if there's something that might be of interest.

In all cases, you do need a good wiki to back up the forum, and community members who have enough interest to keep the wiki up to date.  Are they updating the Beagle wiki with BBoneBlack lore?

selsinork wrote:

 

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.

The old Google Groups wasn't bad.  The new Google Groups is awful IMO which prevents me (and I'm sure many others) from casual use.  This means that if you do post a problem, the people who might be able to help you don't visit very often and your query goes unanswered.

One thing I like about element14 is that you can quickly view presence of new comments in many groups (though not 'blog comments, alas) so in a few seconds I can see if there's something that might be of interest.

In all cases, you do need a good wiki to back up the forum, and community members who have enough interest to keep the wiki up to date.  Are they updating the Beagle wiki with BBoneBlack lore?

I prefer to view the beagleboard forum directly in google groups versus embedded on bealgeboard.org: https://groups.google.com/forum/?fromgroups#!categories/beagleboard

The CircuitCo wiki has an extensive article for BeagleBone Black (BBB):

http://circuitco.com/support/index.php?title=BeagleBoneBlack

Other important BBB articles:

Updating the software: http://circuitco.com/support/index.php?title=Updating_The_Software

Accessories (including cape testing): http://circuitco.com/support/index.php?title=BeagleBone_Black_Accessories

John Beetem wrote:

 

In all cases, you do need a good wiki to back up the forum, and community members who have enough interest to keep the wiki up to date.  Are they updating the Beagle wiki with BBoneBlack lore?

CircuitCo is updating their BeagleBoneBlack wiki pages periodically, and I started adding BBB info to the eLinux BeagleBone wiki page which I maintain, although since I currently lack a BBB myself I can't base it on first-hand experience.

Wikis are wikis though ... those of you who actually have BBBs already, you can help out if you want to.