The U15 looks like a SO-8, so that's probably 50 mils.  It's huge by my standards so I'm not so worried about damaging anything.  I just hate that I have to open the thing up just to get started.  And the vendor did advertise I2C functionality on the block diagram, so one would have expected it would be available.

Of course all this is moot if the gigE doesn't work.  Then this whole thing was just a waste of time, and I'll be totally screwed looking for a PC/104+ style stack with a pair of LAN ports and all these other requirements we have for this project.  Argh.  Thought I had learnt my lesson about being an early adopter!

Well.  I just confused myself into thinking that I could use J7 (the RS-232 port) as an I2C port.  It shares some SPI functions but not I2C, as near as I can tell.  So that doesn't work. 

Another note.  On initial power up MPP[8] and MPP[9] may start up as I2C if the TWI serial ROM initialization is enabled.  So depending on what is going on with R30 and R33, U15's I2C functions may be turned on or off.  Looks like pulling that pin high puts it in that mode so that the pins are I2C at boot up, but you have to set the state of GE_TXD[2:0] to pick the boot device, which I guess is default to SPI flash for uBoot (which is good, because my I2C device is not what I want to boot from).  So maybe I can just solder wires onto pins 5 and 6 of U15 to pick up I2C functionality.  Again, it makes me look like a total tool but at least I can maybe push this project forward.

Also I2C/RS232 is shown on block diagram http://www.globalscaletechnologies.com/t-guruplugdetails.aspx#block for all three versions of Guruplug.  So I think I'm legitimately P/O'ed.  I think most people would take that drawing as an indicator that the functions were really available, i.e. via an onboard connector.

Here is a good reference for this material:  http://www.marvell.com/products/processors/embedded/kirkwood/HW_88F6281_OpenSource.pdf

Trying to track this down further - I don't have my Guruplugs in yet.  These are my notes as I attempt to use the schematics and pictures available to figure out what's going on.

There appear to be two separate boards, one is the main board and the other is a daughter-battery/cards/wireless board.  The two boards interface via a pair of Hirose-style pressfit surface mount connectors, J6 and J7 on the daughter board and J14 and J15 on the mainboard.  J14=J6 and J15=J7.

On the daughterboard, the wireless chip (AzureWave AW-GH381, I think, can't find a datasheet yet) appears to have I2C pins going in or coming out of it which are available at TP8 and TP13.  Also, J6 has pins 23 and 24, SCK_CTS0 and SDA_RTS0 which look promising.  It looks like these pins dead end here, though, I don't see anything connected to them on the schematic and the pins are not routed out.  Guess I can solder wires to the connector pins (yay, that's gonna look real professional).

On the mainboard, we seem to have U15, which is not stuffed.  This looks like a serial EEPROM (there is a board option for a serial rom initialization disable function as well).  The IO pins SCK_CTS0 and SDA_RTS0 (sounds familiar) are routed in the schematic to J14 and come from U1H (which is the Marvell chip).

Great.  I would have SWORN that the Guruplug pages advertised I2C functionality when I ordered this, but they do not now.  Wonder if I kept printed copies of that.  It is quite clear that the plug does not currently offer I2C as a real option, because they didn't bother to hook it up despite sufficient board real estate to insert a RS-232 connector.

If you need I2C like I do it looks like your choice is

• Solder directly to pins 23 and 24 of J6 and accept the unprofessional-looking result
• Remove the daughterboard, go without USB, wireless and cards, and plug your own board in
• Build a sandwich board to go in between (and good luck getting the connectors properly located)

Crap.  Thanks a ton, Globalscale, really helping me out here.

Pics, please.  If you don't mind throwing a scale (ruler) in those pics it would be awesome.  I am expecting to receive mine any day now.  Heat shouldn't be a big issue for me (it's going in the water, so we'll just sink it to the case) but if I can start planning on how to get the heat out sooner that will really help.  Thanks in advance!

Hi,
I have one of the older "Rev 6.0" boards - at least, that's what's on the silk on both the main and the JTAG/serial boards.  What is shipping now - if I order within the next month or so, will I get a "Rev 1.3" board with the additional connectors on the board?

I ask because I am interested in access to I2C pins (rather than having to bit bang it out on the "available" GPIO).

Thanks!

So it turns out that my awful hack may not have been so bad.  I installed debian-testing as you suggested and it worked - the same way.  Sample code built fine, but I do not get the desired result.  I think it is the API.

On the upside, I have now linked to a library which I actually believe is working right - so I can put the complaint to the hardware vendor and ask for support.  Unfortunately, it's up to them to help me because I don't think I can do anything about API performance at all.

Eugene - thanks for the words of advice.  I didn't think what I was doing was quite kosher but maybe it wasn't as bad as I thought it was - or maybe I just got lucky.   

Hi eugenesan, thanks for your reply.  Sorry if I wasn't perfectly clear.  My first post kind of sucked.  This one will be better and far more detailed.

Okay, negative on some of that.

1.  Yes, I used the automated sheevaplug-installer-1.0 to install Ubuntu 9.04
2.  Yes.  Here's exactly what I did:
2a. I started with the basic build and then apt-get install make/gcc/g++/that's probably it
2b. Then I tried to natively compile source code with vendor-provided binary API.  Link failed with error listed : ../../bin-pc/arm/libPvAPI.so: undefined reference to `__aeabi_atexit@CXXABI_ARM_1.3.3'
2c. I tried to cross-compile using my toolchain and the codesourcery toolchain.  Both results compile on x86 processor but do not run on the plug.  Resulting error is:  /usr/lib/libstdc++.so.6: version `CXXABI_ARM_1.3.3' not found (required by /root/Prosilica/bin-pc/arm/libPvAPI.so)

So at this point I realize it's not going to work, and I have been clued in to the fact that the problem is either the binary API provided by my vendor (who tells me that they used the CodeSourcery compiler which I have verified to compile working code for the plug), *or* it's the libstdc++ version.  Since I can't change the API on my own...

3.  Yes, I started to think that libstdc++ might be a fruitful thing to look at.
4.  Here's where I knew I was going down a bad path - but it was worth trying.  In fact, the compiled code *does* do some things right.  The API is able to read my MAC address.  I am able to provide outputs using printf.  But the API is not interacting with the network stack right.  I don't know how or why, but of course I assume it has to do with my gawdawful hack by installing some foreign libstdc++.
5.  Yep, exactly - no wonder.

So now I have provided the background you needed to understand my question.  I was going to try out the gentoo distribution since it's all built to be compiled.  But since gentoo is so foreign to me (perhaps easier to spell apt than emerge?) I will take your advice to try debian-unstable first.

To answer your question, I am only somewhat experienced with cross-compiled linuxes.  I usually prefer to work with bare metal, but my (GigE Vision camera) vendor requires linux.  So this is why I went with a distribution, because I can understand it.  I have had lots of trouble with openembedded and buildroot in the past, but perhaps there is more information up here now.

If you have other suggestions I will be happy to get them.  I'm sure I'll be back once debian-unstable is installed... thanks!

Okay, some more details in case anyone is following (the 37 views is a good sign but no replies is not).  This is the latest sheevaplug-installer-1.0 running ubuntu 9.04.  I tried replacing libstdc++ with the one from the cross-compiler I built, and my code compiles and links, which is good.  It is libstdc++.6.0.12 so a little bit newer.

But unfortunately the compiled code doesn't work right.  So I'm trying to figure out whether the problem is the binary API module I received from my vendor, or "something" wrong with my hacked libstdc++ (would be nice if I could compile one on the plug but I can't figure out how to get gcc to compile there).  Or maybe something else.

Anybody have any thoughts?  I will move to a different distribution if it's "easy" (read: less work than trying to compile gcc on the plug, which looks to be a ton of work, and also I would like to not brick the plug).  Thanks in advance...?

I'm running the latest Sheevaplug-install-1.0 and it works quite nicely.  I can compile and run things.  But I think I am looking for an updated libstdc++, the current version on the plug is, I think, libstdc++.6.0.10.  When I try to [natively compile on the plug using apt-getted gcc/make/etc and] link to an API provided by a vendor (specifically compiled using the codesourcery toolchain for the armv5tej) I get an error... undefined reference to `__aeabi_atexit@CXXABI_ARM_1.3.3'.

This is killing me and I'm about to dump the sheevaplug for a pc/104 stack.  I have put a lot of hours into this, even got crosstool-ng to compile a toolchain for me, but it just isn't doing it.  At the risk of providing too much information and putting this topic astray, I cannot remember the last error I got trying to cross-compile this, think it was looking for stubs32.h or something similar, which I cannot find.

I would really like to use this device if at all possible.  It's pretty sweet form-factor and capability- and power-wise, and the impressive development work provided by the community has a lot of appeal.  Anyone have any ideas on what I should do?  I tried compiling my own new gcc but that didn't work either.  Help, please?  (thanks in advance!)