Today, I received my much anticipated DVI cape from BoardZoo, aka
CircuitCo. It's a sweet looking board, and after straightening some
pins that got bent during shipping, I slotted that thing into my
BeagleBone.
The device I recived looks nothing like the one on the <a href="http:// boardzoo.com/product_info.php?products_id=86">BoardZoo</a>. It also
does'tlook like the one found <a href="http://www.flickr.com/photos/
koenkooi/6303545872/">here</a>. I posted some pictures of my cape
which has full headers, and audio jacks. It's pretty cool, because it
was more than I expected. A couple curious details I noticed is that
the big cap visible on earlier boards is now gone in my board, and
there is a really thin wire going from a header pin to a resistor(?).
I had been running the Ubuntu distribution from <a href"http:// elinux.org/BeagleBoardUbuntu">Robert C. Nelson</a> and things were
running well. it seems, however, that the EEPROM spec is not supported
in that kernel based on some dmesg output (it just didn't show up).
So I popped in my Angstrom card, and made sure I was running the
latest <a href="http://groups.google.com/group/beagleboard/
browse_thread/thread/10d7fe6209cea0/71746fd7371bc98a?
hl=en&lnk=gst&q=beaglebone+dvi+cape#71746fd7371bc98a">updated SD card
image</a>. , which as I've read is supposed to have some recognition
of the DVI cape. I got nothing. I was able to ssh in to the bone, and
<a href="http://pastebin.com/6bEK4X98">dmesg</a> told me that it was
having problems talking to the EEPROM.
On a whim, and lacking much other documentation, I perused the
BoardZoo <a href="https://github.com/CircuitCo/BeagleBone-DVI-D/blob/
master/BeagleBone-DVI-D-000-schematic.pdf?raw=true">schematic</a>
(pdf). Then I looked at my board again. There's DIP switches there!
But they are hidden under some sort of amber tinted tape. That
signals, "Don't touch me!", but I want to... It also appears that the
DIP switches are connected to the EEPROM... Do I dare take off the
tape?
If it isn't a DIP switch issue, does it mean that the EEPROM is
corrupt? Can the BeagleBone reflash the <a href="http:// groups.google.com/group/beagleboard/browse_thread/thread/
d2bf035e4ca5661f/354ceb2db8892415?hl=en&lnk=gst&q=beaglebone+dvi
+cape#354ceb2db8892415">EEPROM</a> of a cape in situ, and also, how
would one go about that? Is that even desirable?
I doubt very much that the EEPROM is even programmed. I wa snot aware these things were even shipping yet. Plus you will need an updated SW image to support it, something that has not been released yet.
The DVID has no audio on it. That is why the picture is different. We don’t have audio working yet. There wil be a different SKU later with audio that will cost more than just the DVI-D version.
The tape on the dipswitch is to seal the switch when the board is washed. That is the way the switches come from the place that makes the switch.
Today, I received my much anticipated DVI cape from BoardZoo, aka
CircuitCo. It's a sweet looking board, and after straightening some
pins that got bent during shipping, I slotted that thing into my
BeagleBone.
The device I recived looks nothing like the one on the <a href="http://
boardzoo.com/product_info.php?products_id=86">BoardZoo</a>. It also
does'tlook like the one found <a href="Explore | Flickr
koenkooi/6303545872/">here</a>. I posted some pictures of my cape
which has full headers, and audio jacks. It's pretty cool, because it
was more than I expected. A couple curious details I noticed is that
the big cap visible on earlier boards is now gone in my board, and
there is a really thin wire going from a header pin to a resistor(?).
I had been running the Ubuntu distribution from <a href"http://
elinux.org/BeagleBoardUbuntu">Robert C. Nelson</a> and things were
running well. it seems, however, that the EEPROM spec is not supported
in that kernel based on some dmesg output (it just didn't show up).
Yeah, my previously posted images don't support that yet, but my dvi
cape just arrived via fedex a few moments ago, so hopefully change
that pretty quickly..
[ 1.485318] BeagleBone Cape EEPROM: wrong header 0xffffffff,
expected 0xee3355aa
[ 1.493066] Could not detect BeagleBone cape properly
[ 1.576951] BeagleBone cape EEPROM: could not read eeprom at address 0x55
[ 1.666950] BeagleBone cape EEPROM: could not read eeprom at address 0x56
[ 1.756951] BeagleBone cape EEPROM: could not read eeprom at address 0x57
[ 1.764041] BeagleBone cape: exporting ADC pins to sysfs
Blake, are you getting the same with Koen's uImage?
[ 1.867355] BeagleBone cape: initializing DVI cape
[ 1.959355] BeagleBone cape EEPROM: could not read eeprom at address 0x55
[ 2.049524] BeagleBone cape EEPROM: could not read eeprom at address 0x56
[ 2.139354] BeagleBone cape EEPROM: could not read eeprom at address 0x57
[ 2.146494] BeagleBone cape: exporting ADC pins to sysfs
(it also helped to lift pin 7 on the 24c eeprom to disable the write
protect.. )
The board you have received is a pre-released version of the
BeagleBone DVI-D cape. We are sorry if that was not made clear. Only a
few units of the Audio version were released for development purposes.
The DVI cape as shown on Boardzoo.com does not have audio jacks. We
are in production on this non-audio version but software is still in
process. We are going to post the updated SRM on BeagleBoardToys
support wiki with proper details.
The BeagleBone DVI-D Cape you have received is a pre-released version.
We are sorry that this was not made clear. Only a few units of this
version have been released for development. The software that supports
the EEPROM programming is still in process. The photos on Boardzoo.com
do not have audio jacks. This is due to the audio software is not
ready. We are updating Boardzoo.com, BeagleBoardToys support wiki, and
the System Reference Manual for proper details.
Unfortunately in my noobishness I'm a little uncertain what to do with
the uImage. I tried simply replacing the existing uImage on the SD
card with the one Keon supplied, but I couldn't get it to boot. If you
could point me to a forum thread on the matter, I'd appreciate it.
Also, Robert, how do you "lift pin 7 on the 24c eeprom"? Do you flip
one of the DIP switches? Or is it accomplished with code (the chip
datasheet gave be that idea)?
Best regards,
Blake
Robert, BTW, I did eventually get that USB WiFi "sorta working". Still
some issues I'm working out, but those seem to be mostly with key
sharing.
You have to physically cut the pin on the EEPROM off, removing it completely. You can do that with an Xacto knife or a good pocket knife. Oh, and you will most likely need a good magnifying glass.
Dude, it's cool. I feel privileged to have some "pre-release" gear.
Keep doing that - interate & (pre)release. Repeat. I'll keep banging
on it till I get it to work, and I'll post my results.
>> [ 1.576951] BeagleBone cape EEPROM: could not read eeprom at address 0x55
>> [ 1.666950] BeagleBone cape EEPROM: could not read eeprom at address 0x56
>> [ 1.756951] BeagleBone cape EEPROM: could not read eeprom at address 0x57
>> [ 1.764041] BeagleBone cape: exporting ADC pins to sysfs
[ 1.867355] BeagleBone cape: initializing DVI cape
[ 1.959355] BeagleBone cape EEPROM: could not read eeprom at address 0x55
[ 2.049524] BeagleBone cape EEPROM: could not read eeprom at address 0x56
[ 2.139354] BeagleBone cape EEPROM: could not read eeprom at address 0x57
[ 2.146494] BeagleBone cape: exporting ADC pins to sysfs
(it also helped to lift pin 7 on the 24c eeprom to disable the write
protect.. )
Regards,
--
Robert Nelsonhttp://www.rcn-ee.com/
Robert, Koen, thank you for your help with this.
Unfortunately in my noobishness I'm a little uncertain what to do with
the uImage. I tried simply replacing the existing uImage on the SD
card with the one Keon supplied, but I couldn't get it to boot. If you
could point me to a forum thread on the matter, I'd appreciate it.
Not a problem, if you can pastebin your serial log we can take a look
what's going on bootup.. In my case i just took koen's uImage file
and just overwrote the existing uImage in my boot partition.. If your
running angstrom, i believe that's setup to boot from the rootfs
partition..
Also, Robert, how do you "lift pin 7 on the 24c eeprom"? Do you flip
one of the DIP switches? Or is it accomplished with code (the chip
datasheet gave be that idea)?
steady hands, good microscope/magnifying glass, a very small tweezer
and a soldering iron to remove the lead..
Best regards,
Blake
Robert, BTW, I did eventually get that USB WiFi "sorta working". Still
some issues I'm working out, but those seem to be mostly with key
sharing.
Awesome, you'll like the v3.2 beaglebone kernel, the usb is much
better then v3.1's..
Well I'm pretty certain I got Koen's kernel running. I'm not sure what
I did different this time, but it booted, And I can ssh into it.
root@beaglebone:~# uname -a
Linux beaglebone 3.2.0+ #42 Wed Feb 1 14:00:16 CET 2012 armv7l GNU/
Linux
I'll give de-soldering a shot. That sounds a tad more sane than
cutting the pin. Until I build I build up the courage to do that
(probably tomorrow; too much wine tonight for "steady"), I'll play
with the improved USB device support.
I'm losing characters in the USB serial connection, when using either
minicom or screen. Does anyone have some idea how to fix that, besides
change the hardware/software control flow which doesn't help? I've not
yet connected an external 5vdc, but I don't think that would matter.
Is anyone else building their own kernel outside of the
Angstrom/OpenEmbedded environment? I've my own mini-distribution with
its own simple scripted build process; using the TI PSP my kernel
isn't detecting an RTC... maybe it's just the kernel config. For some
reason I am using CONFIG_RTC_DRV_TWL4030 rather than
CONFIG_RTC_DRV_OMAP; I don't remember what led me to that, but I the
kernel didn't seem to detect an RTC when configured with
CONFIG_RTC_DRV_OMAP.
The pin does not need to be lived like the chip is taking a leak.
Just lift it barely enough so that it is not touching the pad. The
best way to do this is to use desoldering braid which you should be
able to get at radio shack. Get the stuff with flux in it if they
have it.
This can take some skill and as others have said, a really good
magnifier helps, preferably the kind you wear on your head.
Not a problem, if you can pastebin your serial log we can take a look
what's going on bootup.. In my case i just took koen's uImage file
and just overwrote the existing uImage in my boot partition.. If your
running angstrom, i believe that's setup to boot from the rootfs
partition..
We desperately wanted to do that so the package manager would take care of the kernel/module match, but sadly u-boot is being stupid again:
Loading uImage from vfat: 0.23s
Loading uImage from ext2/3/4: 4.62s
To get our 10s boot target we switched back to kernel-in-vfat
do it like Lilo in the past, tell u-boot a list of sectors to read
the kernel from....
