The Computer Corner Take II (#26) by Bill Kibler

To see more Computer Corner articles look here: CCII page or check out the Home Page .

Intel D2700MUD with Problems

The Next System Came With Problems

In article #25, I discussed how I went from ASUS Eeepc to the Intel D2500CCE board for monitoring and collecting data. They were both Atom chip sets, but the Eeepc only has USB ports for handling I/O. The D2500CCE has four true serial ports and the board is supported or available for at least three years. All those features make it a good choice for sub $100 motherboards without fans. Which had me willing to try another Intel board when looking for a low power option for interfacing to some ham gear. I am looking to have an AC powered system, unlike my solar powered data collector, that runs not 24/7 but near to it. The choice I made was the D2700MUD, which has HyperThreading and comes up as four CPU cores. But the fun doesn't stop there.

I need to start by saying that I did do some checking on the specs, but I didn't think to check for linux problems, since it was an Atom core. That turned out to be a mistake, as the board will run linux, just not graphical linux. Let me explain in more detail. As is pretty common these days, chip sets contain pretty much the whole system and if not in one then sometimes in two or three main chips. The Intel D series of Atom boards, has the CPU and Graphic engine in one chip, with the I/O in the second chip. In the case of the D2xxx series, one of the chip sets is referred to as "Cedartrails" line and contains either the GMA600 or GMA650 graphic chip. There in lies the problem, as there appears to be a problem with the implementation.

Starting from the top, I ordered the board from mini-box.com for $83, and it arrived within three days. I stuck it into an old case with a ATX 500W power supply - way over kill, but it had the correct SATA connectors and the screw holes matched the case. I grabbed an old SATA 80GB drive with linux already installed and hooked up the proper screen and keyboard. It booted just fine without any special operation, except for the mouse. It only has one PS-2 connector, so I had to use the USB keyboard mouse adapter and for some reason it had problems with the mouse. I tried putting the keyboard or mouse in the PS-2 connector and it seemed that it liked the mouse when it was in the PS-2 connector and the keyboard when attached to the USB adaper. I run a four port KVM switch and this system is but one of 4 that I control using a single mouse keyboard combination. I have had problems before with the three button mouse and thus was not surprised by this problem.

Next I checked out the system and found the screen setting options to be 800x600 and 640x480 and none others. Typically I run much higher and figured I just needed to change the driver. Well needless to say this is where all the problems begin and there seems to be no answer for now. What appears to me to have happened - and this is just guessing on my part based on the emails and comments I have seen going back over a year - there must be a problem in the actual chip layout. It seems when the drivers for the Cedartrail chip first came out, they supported both 32 and 64 bit systems. The Intel site had drivers for windows 7, both 32 and 64 bit. However it looks like not long after release, the systems started crashing and Intel had to pull the 64bit drivers. At the same time the linux drivers were also pulled and any support for linux was stopped. At present, early 2013, Intel is still saying no linux and not windows 64 bit support. I saw plenty of email comments that even the 32bit windows drivers don't always work.

The links and comments suggest that there are some work arounds and some users have been able to get higher graphic settings to work. I swapped disks and loaded a Debian 7 version and am getting 1024x768 using the VESA driver. I have tested it using VLC (don't), MPLAYER (somewhat OK), and movieplayer which worked resonably well for playing videos. All of those at 1024x768 which for most tasks actuall isn't that bad. I tried the LinuxMint13 with the early Intel and private code that worked sort of, until VLC was tried and caused it to lock up. I tried Meego and that was just an awlful operating system and the graphic seems less than good, although some have been able to use the kernel with some success. Supposedly the 3.7 kernel works better, but my attempt to use Arch failed, so I can't say if that is true or not.

I saw several people who, like myself, intended to use the system in a somewhat headerless way, and thus the board speed and cores was the main concern. If your application doesn't really need the high resolutions or the supposed 3D graphics, then the cost and features is pretty good. There is suppose to be some AMD E300 chipsets with similar low power consumption and greater speed or better performance, but I didn't see any for under $100. But then my sub-$100 system doesn't do good graphics and AMD just might. I clearly have doubts that Intel will fix or correct this problem, so if you need better graphics, you will need to use the one PCI slot for a grahic adapter of your choice, which at best will not be great speed wise, since PCI access is less than high end. For high end graphics, the choice is simply other board.

NOTE: as of mid 2013 - the Intel site says the D2700 "status" is "end of life" as they put it. Check here for other boards in the series "http://ark.intel.com/products/series/49428". For me that is an admission of the boards problems and thus they have removed it from stock. Having said that, I went the site where I got the board and theys still show it and in fact have a "new" label on the product. So personally I have no idea if it is safe to buy any of these boards, especially if you need great graphics, as it is just clear what is going on. Just check message boards for the latest graphic information before buying.

Ignoring Graphics, how does it work?

My application goes something like this - I have several pices of Ham gear I want to control remotely from my house. The "ham shack" is located above my garage, and since my son has moved out and no longer needing his room, I have a well heated and cooled room to set up as my main work station. I still use my office and lab, since all the tools and test systems are there. The solar setup is there as well and thus my ham equipment is powered by the solar batteries. The idea is that I will run some stock linux programs and be able to control my equipment as if I were actually sitting in front of them. This is specific to being a ham operator, but actually it applies to many situations where remote operation is a good option to have.

I have for sometime now been using the solar powered server to check my email. I log into the server using "ssh -X 123.456.789.123" and run "icedove" (thunderbird) and can then graphically go through my email as if I was using the systems desktop. The screen resoltuion is that of my workstation and not that of the X-server if it were running on the remote system. In fact most of the time, the X-server is not runing on my remote system at all - not needed. I suspect that most new users think the graphic system of your remote must be the same as that of the local to make things work - might be the case for windows, but not for Unix or linux system running the X system. In our case the D2700 graphic problem is not a problem when working remote.

There are some items to consider when doing this "remote" operation. I have real ethernet cables runing between buildings and thus when doing this remote process am doing 100MB transfers that go through two switches. Working remotely this way is pretty close to doing actual work on the machine. Recently I had to spend time at my Mothers house and took a 3G wireless hub to her place, she is not connected at all to the internet. I logged back into the solar powered server using ssh and was able to read and edit my mail. To say it was slow would be a major understatment. It takes a bit of patience, as updates can take minutes to happen, but it works and you can do real work this way, just not a lot of it. The idea is that here is an option that works well for high speed connections when situations are less than ideal.

I checked the power consumption when using the 500w supply, standby - system not on - was about 5 Watts. When running was close to 50 Watts. I started testing using regular SATA drive and changed to the final setup, using a laptop drive. I lost a few watts, but I had a PSU-80 power supply I pulled from the solar system, due to needing a good 12 volts, or it shuts down. I took a 12V 5A brick power supply and feed the PSU-80 with it. Consumption is now around 15 Watts and with standby about 1 watts. I tried the YTT100 110vac to 12v supply and the total consumption was about the same, just that it had no standby current draw that I could see. I will use the brick for now, as I think it has better filtering of spikes, as the YTT100 when powering the solar system, had several un-explained resets.

What I need for testing is the abiltiy to do windows, as the factory software is windows only for my ham gear. It is pretty common for me to setup dual boot systems, as needing to run some program on windows before I can use linux is not uncommon. I would rather not do this, but currently way too many companies will not provide data for linux support. For me it is just one of those things you end up doing that by the time your done, re-affirms your dislike for windows. Loading windows this time was clearly not a good trip. I have a corporate XP Pro install I use with service patch 2. It failed. I checked the web and saw that SATA support wasn't added until service patch 3, which I do not have a disk that includes it. I found several sites offering sp3, as it seems you can just load the sp3 files onto a image of a earlier install disk and make a new usable install disk.

What I choose to do however was learn that there is now two settings in the BIOS that control how things work. You have the new process that is AHCI that talks only to SATA drives and the old IDE emulation for software that doesn't know about SATA interfaces. I meerly went into the BIOS settings and set the drive interface to IDE and then the XP install disks worked normally. Remember you need to load windows first, then load linux, as windows will trash you linux system if you try to install linux first. The grub2 install will find your windows partition and make it an option for booting, so when powering up you will be given a choice of linux or windows, with default being linux - all of which can be changed.

Testing and Making it work

As it turned out, I hooked all my equipment up and did some testing using linux. I loaded all the ham programs from the debian site and tried fldigi and was unable to get to talk to my ham rig. To make sure all was correct, I re-booted to windows and ran the factory program, only to have it fail as well. I wasn't sure about my serial cables, so I tried another set of cables and this time the program worked. You need true straight through serial cables and appearantly the one set had some crossover going on. After that test, I re-booted and started checking linux programs again, still no luck and thus I know it is cabled correctly - must be linux hand shake.

Some serial testing is needed and two choices are minicom and cutecom. I like cutecom as it is graphical with a few more features than minicom. I suggest getting both on your system, as sometimes one is better than the other. After loading both programs, I used the command sheet for the rig, and could get proper command responses. This indicated that under linux all was well serially. At this point I did some more digging and discovered you need the complete Hamlib library and grig to do the talking. I added both sets of programs, used the proper grig command for my rig and it worked.

At this point, I have a low powered system that can talk to my ham gear which I can control remotely from inside the house. All the details and programs used to do that will be in another article. this artile was just covering a few of the items that caused problems and their soltuions. As to using the D2700MUD - I say no go - especially since the Beagle Bone Black just hit the market at $45. So it is time to get one, review it, and see how it works now that it has graphics on board. So next article is about the Beaglebone Black.

Pictures

Current setup with D2500CCE based system and solar power cabling.

Links

Site where I got my D2500CCE board and power supply.


Kibler Electronics, PO Box 535, Lincoln, CA 95648-0535, USA.
Email: bill@kiblerelectronics.com
Copyright © 2013, Kibler Electronics