Thursday, January 16, 2014

SuSE... Might as well be called SuCKE

Or ShiTTE... >-D

Last month, I was looking to install an operating system besides Windows that would be compatible with my wonderful nVidia 650-something-or-other graphics card and 4K display.  (4K = 4 times the resolution of 1080p HD.  Booyah!)  Windows 8 is nice, and handles this display wonderfully, but for optimal enjoyment of Android Studio, you should really run Linux (or possibly Mac OS too).  Plus, having Linux around on a dedicated disk is never a bad idea.  Having heard from some of my friends about how they think everything Canonical (makers of the very popular Ubuntu Linux) touches is evil, I figured I'd try a different distribution.  Stacy loves Linux Mint, but I can't wrap my head around some of its strange idiosyncrasies.  Maybe it doesn't help that she gave me an old version on a thumbdrive, but it was slow, would freeze up when I wanted to get serious with it, and there are icons that look like folder icons that you can't click on to explore its contents.  I mean, how stupid is that?  Doesn't that completely fly in the face of all the design dogma over the last 30 years?

As such, I gave SuSE a shi... er... a shot.  It's a flavor I hadn't had much experience with, so I figured I'd try it out.  After loading it onto a USB thumbdrive with UNetbootin, I proceeded to run the installer.  Little did I know, but an hour later, I'd be going to bed without seeing it finish because it was getting to be about 1 AM.  During that hour, I had almost managed to convince myself the installation had finished when the monitor inexplicably shut itself off.  After not having heard any of the usual aberrations in the fan noises, or the standard BIOS beep, or my hard drives making noises as if they were floppy drives (?!?) -- all these things are indicative of a reboot on my system --, I became skeptical and started moving the mouse and hitting the keyboard.  It turns out that the SuSE installer has a screen saver consisting of a blank screen.  What other installer does that?  I almost yanked out the USB drive, thinking I needed to remove that so my computer wouldn't boot back into the installer; had I done that, I would have screwed up the whole installation!  Oh, and one more dumb thing about this installer: after the screen saver was aborted, the progress bar did not move.  I can't vouch for what it did after I went to bed, but about 8 hours later, I finally woke up to a new Linux distro.

It was very difficult for me to begin using the OS, and in fact, I wasn't completely convinced it was done installing because the default video drivers overscanned my TV to the point where I couldn't see the corner edges (including their useless menu bar) for the first few minutes until I changed the TV itself to "Just Scan." (Just as an aside, whatever useless OS the Udoo shipped with from its Kickstarter does the same crappy behavior.)  This is something Windows fixes for me automatically; it has never overscanned my monitor unless I was using an old tube TV, and even then, I had drivers to tweak the scan and shrink it back to size.  Thus, I tried to seek new Linux drivers for my video card, only for another ugly problem to rear its head: it can't get online right out of the box!

First thing was it didn't recognize any of my on-board networking hardware.  I had to go into the Terminal & write sudo /usr/bin/NetworkManager . just to get it to recognize my ethernet ports. Once I did that, it let me on the network with an IP address from the router, but it still couldn't visit any Web sites for no apparent reason!  At least not in the traditional way; out of the box, when you're on an IPv4 network, it doesn't handle DNS properly.  I figured out how to get to Web pages from my SuSE install eventually, but I had to know their IP address ahead of time!  Most sites don't even let you type in http://[ip address] anymore in order to navigate to them, so this was useless.  Long story short, I had to hack resolv.conf to get it going with some kind of phony "" entry so it would actually do DNS properly.  It seems like the SuSE people insist the IPv4 people are just doing it wrong and need to move onto IPv6; well for us home users, that might not necessarily be an option.  How about just build a better, more resilient OS?

Once I got online, it took about 9 years just for Firefox to open a Web page, and for no apparent reason, I could hear the hard drive clunking away constantly.  What the hell is it doing to my drives?  The Internet does not exist on them!  And my computer is an Intel i7 920 with 12GB of DDR3-1066 RAM (yes, very 2008--but still, not bad specs), so why is it taking this long?!?  I tried typing "twtr" in the Google search bar just to see if Firefox & the Internet connection was alive; it took about a minute for anything after the first T to show up because evidently it took that long for it to fix its DNS entries and actually get on the Internet like a functional OS can.

I'm also particular about my user interfaces.  I hate customizing them, but I expect them to be the way I like them right out of the box.  Anything else and I will incessantly bitch and moan.  I get paid to write and test software and file bugs, not to dick around with setting up OSes and do menial IT tasks.  Oh, and Heaven forbid I find a bug I'm not getting paid to find.  I'm your worst nightmare of a consumer because it'd better be right or else I'll ditch it (hence my brief foray into Windows Phone until I found a decent version of Android).  Nevertheless, any decent Linux OS would allow you to right click and open a Terminal window; not SuSE.  Every time I wanted to open a terminal (which is by far the most important feature of the Linux OS), I had to go into their equivalent of a Start menu and type "T"... wait 9 years for the keyboard to start responding again... then go along with "e", "r", "m", etc.  Then, it'll show me all the music I can buy where the band's name has those letters in it.  Wait a minute now, I'm here to launch a program!  If I wanted music, I'd just use Spotify!  Finally after clicking on Programs, it shows me Terminal.  Phew.

The rest of the apps docked in the taskbar are useless to me, the settings are far away (on a 39" 4K monitor)--oh, and speaking of that 4K monitor, it didn't support 4K right off the bat.  Well, if it can't even find the proper way to scan my display so I can actually see all the sides & corners, why should I have expected 4K to work?  Wait, this is what I was getting drivers for.  I'd almost forgotten about that after just trying to get the Internet going.  

I went around trying to research whether the drivers listed in YaST (their software package installer) would actually support 4K, and came to the conclusion I needed to download the latest distributions straight from some website only to find out these were actually the same distributions YaST featured.  It's always nice to use the GUI package installer, until you realize it suffers from the same problems the OS installation does.  Once again, it took an absurd amount of time to install video drivers.  It's like watching CentOS boot up; the progress bar is like following a square-root curve as it asymptotically approaches x.  It makes a lot of headway in the beginning, only to baffle and frustrate you towards the end.  And once again, that stupid screen saver kicked on again, freezing my progress bar at 76% this time while installing the video drivers.  Well I had actual work to do, so I turned to another machine and hit my nose to the grindstone for another 4 hours, after which time I checked my video driver install; it had completed, but the OS was still incapable of taking full advantage of my 4K monitor.

That's it; time to kill it with fire.  However, I still had stuff to do for real to make myself money, so I ignored this system for a little while.  When it was time to come back to it... well... most of the GNOME desktops I've ever experienced show you a password prompt after you shake the mouse so you can get back onto your system after the monitors have fallen asleep/hit the screensaver.  Not this one; I had to swipe my mouse upward (yes, click & drag) before I could reveal the password box.  MY DESKTOP ISN'T A PHONE!  DON'T GIVE ME THAT CRAP!  I couldn't find a way to change it, except possibly to switch to a different desktop or an older version of Gnome.  Still, I haven't seen this with any other Linux installation I've played around with, so I'm still going to blame it on SuSE.  

SuSE is evidently an OS for people who want to/like to customize everything, and boy, do they force you to!  Right off the bat, it's very uncomfortable and nothing works.  Maybe I should have tried it before I installed it.

To this day, I still haven't actually killed it with fire, but the hard drive I installed it on is sitting on a table on the opposite side of my house.  Someday, when I'm up for attempting to install Linux on my PC again, I'll probably just stick with Ubuntu and call it a day.

Thursday, January 9, 2014

Mixing Logic With ISP Circuitry For Programming Firmware

For the LEDgoes manufacturing & assembly stage, it would be desirable to simply secure each board to a programming jig, and the jig would be able to program both chips without hassle or confusion.  This means that we will need to insert a switching mechanism somewhere in between the ISP (in-system programmer) headers and the actual programming pins on the board so only one board at a time gets programmed.  I am quite familiar with digital logic, but don't have a knack for understanding other types of circuitry, so it struck me as a possibility to use some 74-logic to route the signals sent from the ISP to one chip at a time.

The 7400 series of transistor-transistor logic (TTL) gates date back to the mid-1960s, shortly after the invention of the transistor itself.  Some chips in this series provide basic Boolean operations, others are counters or shift registers, and still others are flip-flops and latches (memory).  Over the last 50 years, this series has been tweaked to possess many different characteristics and one can choose optimizations between power consumption and speed, not to mention optimized size and cost.

The first step in this journey was to make a connector to go from my USBtinyISP to the breadboard.  Wiring up a 3x2-pin female header to the breadboard with long, brittle wires that have a tendency to fall out before the rest have been planted in place is tedious.  It requires some patience to set up, and since leaving the equipment in that configuration for more than a few hours isn't desirable (I usually want to do other things with it after a while), I ended up using some spare ribbon cable plus some of my own headers and blank DIP sockets lying around to make my own connector.  After a couple hours of soldering and tedious testing of every pin and its neighbor, I finished this project.  However, I had to cut the male headers on top later on since there wasn't enough clearance between pins to secure the USBtinyISP's header in place.

The custom cable.  No, I do not sell these.

Once the connector was made, I picked a spot on the breadboard for it to go, and planted a 74LS08 (quad AND gate) next to it.  The '08 chip has four "A" inputs, four "B" inputs, and four "Y" outputs.  If A and B are both logic level high (5 volts), then Y will output high as well; otherwise, Y will be low (0 volts).  If any of the inputs are left floating (not necessarily set to logic level high or low), then the Y output will also be high.  Thus, it is important to add pull-up or pull-down resistors to enforce a particular state when the pin is not being driven by the ISP programmer.  You will see which type I chose later on in the schematic.
Looks like fun to try and route!

The quad AND gate is perfect because the ISP utilizes four different signals: MISO (master input slave output), MOSI (master output slave input), SCK (serial clock), and RESET (for synchronization).  It also provides 5V and 0V (ground), but I use an external power source to provide those to the circuit.  Therefore, each of these signals was wired up to each "A" input on one of my '08 chips.  Each "B" input was wired up to a common signal, the chip select.  The chip select consists of an SPDT (single-pole double-throw) switch that can connect to either 5V or ground; the output from this switch goes into all the B inputs on the first '08 chip.  However, this is only enough to program one ATmega microcontroller on the LEDgoes board; since we need to program both microcontrollers on the board, we will need a second '08 chip.  The switch output needs to be inverted to the second chip so that the second microcontroller is not being programmed at the same time as the first one.  Luckily, I happened to have some transistors lying around, and the Internet proved to be a useful guide for constructing a single-input "NOT" gate using one PNP transistor and a few resistors.  I could have used the 74LS04 (6 inverters) part, but it takes up quite a bit of space and provides many more inverters than I need for this application.

With my circuit completely built on the breadboard, I went on to mate the USBtinyISP with my special connector and, alas, it failed to synchronize with the ATmega chip on my board.  Perplexed, I checked on the USBtinyISP by wiring the output from my connector straight to my board's headers using jumper wires, and that worked fine.  I played with various combinations of pull-up and pull-down resistors on the gate's inputs and outputs, and nothing seemed to do the trick.  I checked on the timing of the 7400-series chips, and all the ones I have are designed to typically operate at 50MHz.  This is many times faster than the USBtinyISP operates, and more than 3x faster than even my ATmega chips.  Therefore, it couldn't have been a timing issue; I had to assume it was an issue with the internal circuit.

Not being much of a circuit man myself, I attempted to jettison the '08 with another logic chip: the 74LS373 (octal D-latch).  This chip features eight "D" inputs and eight "Q" outputs.  As long as /OE is attached to ground (since it's active low, hence the slash) and L (the latch) is high, the signals going into D pass straight through Q.  However, once L is set to low, the values of Q freeze to whatever values D had right at the falling edge of the L signal (essentially, the very nanosecond L goes from high to low).  With L at ground, the inputs D can change all day long and never affect the outputs Q, so in essence, this chip is a (comparatively very expensive) form of memory.  For 1GB worth of RAM using standard DIP-socket '373 chips, it would cost you on the order of $100 million, even when buying in bulk from an electronics retailer.  That and I doubt there are even 1 billion of these chips in service or ready to be sold.  DRAM found in computers as conventional "memory" is far more efficient, but would be substantially more difficult to incorporate into this application (plus, it's really the latch behavior we're looking for anyway).

Now, I would need two '373 chips (because unfortunately there's no way to latch only 4 of the 8 outputs at a time), and would wire the switch output to the L pin on one '373 and the inverted switch output to the L pin on the other.  The four ISP signals would be routed into each D, and the output from this gate would be wired from Q into the headers on my LEDgoes panels.  There was just one problem; this approach failed too.  Even when wiring the special connector's outputs directly to my board, that failed.  I panicked, and it was getting late, so I simply called it a night.

Starting fresh the next day, I wired up each signal individually to the D-latch, and left the others passing straight through to the LEDgoes board.  I also found some wiring errors, and after correcting those, I was back on track with successful programming each time.  After hooking up just MOSI, testing it, and then adding SCK and RST successfully into the gate and seeing that programming still worked, I had real trouble with the MISO signal.  Every time I wired this signal from my special connector through the gate, programming would fail.  I tried various combinations of pull-up and pull-down resistors, and even load resistors.  I searched for schematics that might indicate how others corrected this problem, and without knowing what the impedance is on that particular signal compared to the others (and not finding any schematics with the answer), I had an epiphany:

You need all four signals present and synchronized for the ATmega chip to be programmed!

As such, it's OK if we just let MISO go straight through to both chips without passing through the gates first.  Without the presence of the other three signals, any fluctuations on MISO are meaningless.  Heck, even with two pins connected straight to both microcontrollers, it still shouldn't affect their contents anyway.  With this realization, I eliminated the need for a second 7400-series chip, and took the design back to a single '08 (quad AND) chip to do the job.  MOSI and MISO are both going straight through from the USBtinyISP to the pin headers on the boards, and only SCK and RST are getting toggled by the '08 chip.  Two of the gates are controlling SCK, two are controlling RST; and each of those gates receives input from either the switch or the inverted switch signal, thus only one chip at a time is seeing the SCK and RST signals.

Here's the jig I ended up designing.  I'll use the toner-transfer method to produce a PCB (with the top/red layer only) once I get approval from the "this makes sense" committee.

As a future project, it would be nice to ditch the physical switch and substitute that action for something the USBtinyISP could directly control.  What I envision would consist of perhaps an I2C-addressable register that would be set or cleared based on some combination or pattern of signals from the USBtinyISP.  With such a register, I could write a program to bit-bang the appropriate data from the USBtinyISP to switch that bit.  Or, perhaps I could use the GPIO pins on the Raspberry Pi to provide the whole feature set I need.  Once the electronics are done, I would write a script that incorporates the appropriate avrdude commands to write the firmware and check for validity of the output.  AVRdude outputs error messages when appropriate, but if it's something like a "Byte mismatch at 0x308: 0xFF != 0x37", then I tend to miss it (since it's not highlighted a different color on the terminal) and continue to work with the board, wondering why it's screwing up.

The circuit in a form that actually works.  Only MOSI & RST are going through the AND gates.

Thursday, January 2, 2014

Unboxing the Quo Computer

As fate would have it, I'm back to a nice pace of posts on the blog, especially since I've had a logjam of topics -- a bunch of ideas all came in at once.  This also means I get to usher my blog into 2014 on the very first Thursday of the new year, just in time for all the robots & spiders to come looking for new posts. ;)

Shortly before Christmas, I finally (and unexpectedly) received a Quo computer in the mail shortly before Christmas, just in time to install an ESX server right before the whole family came so they could have their own VMs on our server.  (They ended up bringing all their computers anyway, and used more electricity in 6 days than Stacy & I use by ourselves in a month. :-P)  Stacy pledged for this Kickstarter project back in March 2013, and for our particular system, the delivery date was expected to be June.  It still seems like we were one of the lucky ones to have received it by now.  The "unexpectedly" part comes in when, in early November, they finally sent us a tracking number, but the shipping company was waiting for the associated package for such a long time that we stopped even looking for updates there.  I was very surprised when it showed up at my door!

The biggest draw to the Quo computer is the relatively open firmware and UEFI BIOS, which facilitates the installation of Mac OSX and any other x86-compatible operating system onto the machine.  The Quo implementation of UEFI features not quite a graphical BIOS, but still keyboard and mouse-compatible, to facilitate setting up your boot order, chipset settings, and all those other goodies in the desired manner. It also provides the stock UEFI Shell for maximum flexibility and control, though it is a bummer to not have the scrollback capability to look at those extra-long printouts (like if you have a ton of hard drives and run the "map" command).

The legacy BIOS became obsolete probably 20 years ago, and a redesign was way overdue.  The mission-critical and enterprise space has seen UEFI going back at least 15 years with high-end HP/Intel servers, but it has only trickled down into the consumer space within the past couple years.  I could go on a pretty long diatribe about how UEFI is far superior to legacy BIOS (when done right, but it seems like most consumer hardware manufacturers were paid off quite nicely by Microsoft).  For one, you'll never have to tell the BIOS which drive to boot from; just set the UEFI Shell as the first boot option and go from there.  I'm sure most people like to configure GRUB to boot whatever OS they choose at that time, but I've always preferred changing that setting directly on the silicon.  Even better, though, is now you can choose your OS on the fly by simply navigating to the desired bootloader (yes, you can have multiple bootloaders), or even set up an "autoboot" to skip the UEFI Shell altogether and go directly into your OS of choice.  Autoboot was very easy for me to configure in my favorite flavor of Unix back in my days of messing around on big servers, but I haven't played around with setting it up in Windows, RHEL, Ubuntu, or any others.  (Granted, as a BIOS tester myself for enterprise servers at a very large computer company, I can attest to the many bugs Intel has in their UEFI reference code.  Oh well, we'll save that plus how to write UEFI Shell apps for another day as I haven't really put the UEFI Shell on the Quo through its paces yet.)  Though the UEFI Shell is basically its own OS, offering a robust command prompt, one of its few downsides is it's only single-threaded; you would need at least a very light operating system in order to take full advantage of your hardware.  Nevertheless, porting an NES emulator to UEFI is on my bucket list. :-D

I'll leave it to you to look at the specs of the "New Collector" edition that we pledged for, but we did ask for some additional upgrades including 16GB of DDR3 1600MT/s RAM and a nice Cooler Master(R) case.  The additional upgrades may have added to our wait time.  So, without further ado, here are pictures of the unboxing:

Not the box it was shipped in. :-P  I peeled that layer off first since it wasn't interesting.  However, as extra padding, they did box up the whole finished computer into the Cooler Master case box.

Also included was a pamphlet plus a T-shirt.  I think we already gave away the T-shirt to a relative.

Here's the top view of the system, now pulled out of the box.

The system has been removed from the wrapping.  This is not a small case.  The motherboard is laying flat toward the bottom of the grated area, and below it are four drive bays plus some additional 2.5" drive bays around the left side.  The system was pre-populated with an optical media drive plus a 1TB HDD.

Looking down from the top, you can easily see the motherboard.

This is a glimpse inside the case, where you can see the memory, CPU, and connectors.

Here's that UEFI Shell I was raving about earlier, complete with my little "UEFI Hello World" binary.  Even though there's definitely enough of UEFI that's open-sourced (through the EDK project), the toolchain to build UEFI binaries pretty much requires Microsoft Visual Studio.  Previously, I would test my binaries inside a special VirtualBox instance, but this ought to do me better.

And for those of you who were looking for a nice screenshot of this computer running OSX, perhaps with the results from some compelling benchmark test, sorry I made you read this far down only to tell you now that's not happening.  >-D  While I'm a supporter of running OSX on non-Apple hardware, I no longer have a reason to; in August, while awaiting this machine, my wife purchased this other computer at DEFCON for a very competitive price:

My real Macintosh

So there, the Quo will only be used for virtualization and UEFI experimentation.  Now, to just choose between Ubuntu Server Edition and Windows Server 2008, and which hypervisor to install underneath...