From the “Well that’s a Pisser” department…
A few days back the Odroid C2 didn’t want to boot. Just sat there with a fast blinking red power light.
Despite being pretty sure I had the right chip in it, I figured it was most likely just the wrong chip in for some other CPU type. So it went into the box where systems live when not on the desktop.
Then I spent a couple of days rearranging the cluster and the desktop et. al. Using the XU4 as the power machine on the desktop when I wanted speed.
Just a couple of hours ago I shut down to swap the XU4 and Pi M3 between monitors. In the process also swapping keyboards and what power strip the power supply used.
On boot up, the Pi M3 worked Just Fine. The XU4, however, gave a red power light but refused to give a blinking CPU heartbeat (or even a blue light at all). OK… Maybe the SD card is corrupted or “something”…
So I took a couple of hours for diagnostic work. Took brand new 16 GB Sandisk mini-SD cards and wrote pristine images from the manufacturer “known to work” to each and once again tried to boot both cards. Both continued to act the same.
He’s Dead Jim
At this point I’m pretty sure both are dead cards. I get NOTHING on the monitor with either monitor, either kb/mouse, etc. etc.
Possible causes? I thought about static discharge. But the C2 is in the manufacturers case and ought to be OK. Plus, it’s been humid and raining when it first failed to boot.
The Odroid XU4 was “loose”, so has higher static risk. I have a towel over the desktop as cotton is generally a safe material. It stopped raining 2 days ago, but it still isn’t what I’d call dry and static laden air.
Ground loop? The two power strips on the desktop are plugged into 2 different things. One is straight wall power and the other is a UPS into the same socket. I *think* the wall socket has power and neutral reversed, but it’s a ground fault interrupter socket so nothing too big can happen. Might there have been some volts on the grounds between the power brick ground and the monitor ground? Maybe. Yet it has never bothered any system until now, including prior uses of the Odroids.
There’s a potential for physical fragility. The XU4 was working, shutdown, and monitor cables swapped. Pulling out the old one took some pull, and the board / heatsink flexed a little. Did something crack? These things are built on very thin cards, could it just be the thicker material of the Pi cards? Or better device attachment?
Who knows.
What I do know is I can’t get either one to indicate any attempt to boot with multiple different OS cards and monitors. Not even showing up on the router as a network presence.
It looks to me like they are just not very robust to handling / use.
OK, disappointed. Minor loss of money value. Some annoyance as my fastest SBC isn’t available for use or to drive video. All easily fixed with about a $50 new board buy and waiting 3 days…
But will it be replacement Odroids? A major reason for buying them was just to asses their use in a cluster or as a desktop. That’s done now. The C2 has a 64 bit instruction set that makes using it a bit harder as the arm64 code is still a bit young, so buggier than the armhf. The XU4 has a strange mix of 8 cores in 2 different types, so the scheduler is a bit odd, job completion times depend on what core type it gets assigned to first (as it never changes type after that), and it runs hot. Neither one a real candidate for a large cluster going forward given my OS of choice as Devuan.
Now add to that the fact that the Pi B+ laid loose on my desktop for a few years, went to Florida and back a couple of times, and never failed. The 2 x Pi M2 boards had similar lives. In and out of single cases. Into the dogbone case. Power plugged in anywhere. Run headless, or headfull, or having a monitor plugged and unplugged “whenever” and are still doing fine. The Pi M3 has been my “go to board” for all sorts of tests and changes and has been loose on the desk as often as in a case. Heck, even the Orange Pi has been loose laying on the desktop or draped over the Dogbone Stack loose since I bought it. Regularly handled while powered up. ALL of them having zero “issues” from my handling practices and power systems.
So what to do…
I think I’ll set both of them aside for a few days to “clear the attitude”, then do One Last Test of booting before giving up on them and just harvesting the heat sinks.
I’m also going to move up doing a search of the Devuan `1.0 release build boards. I’m leaning toward any of: Cubie / Banana Pi / Orange Pi. Need to look at cores, power, heat, performance, etc. etc. given that now I know what to look for.
I’d expected to lose a board or 2 during the cluster burn-in as I’m running them 100% to the wall 24 x 7 and the heat management on small SBCs is generally “not good”. What I didn’t expect was to have boards NOT in the cluster be the ones doing the dying…
So, needless to say, I’m not looking fondly at more Odroids…
Buying a replacement will have to wait a while. I’ve already blown my “mad money” for the month on the TV, and next month is Christmas so that money is going to others. Figure sometime next year I’ll have to know what to replace them with. Until then, I’m going to route the TV monitor cable over to the Odroid C1 and use it for videos. That will also let me check on its robustness to use and ability to provide a high enough frame rate. It is in the Dogbone Case and plugged into the common power strip used for everything but the standard desktops. That’s a small UPS plugged into a bigger one in the wall. The idea being that the big one in the wall gives me time to shut down anything non-essential and then the DNS / File server infrastructure stuff gets a longer run in case I’m out of the house when power fails.
So we’ll see if a 3rd one blows when the HDMI cable goes to a monitor plugged directly into the wall…
So, ok, the purpose was to assess the boards. They’ve now served that purpose. Moving on…
Musings from the Chiefio 
Well, the C1 is working to the desktop. Video (Youtube “Judas”) works in the small image at 240P. Larger screen images or higher resolution tend to go jerky (will vary with image complexity).
Good enough for background music while working on the other screen…
I’m sorry to hear that. I bought a C2, thinking the more up to date spec would make for a faster performance, and I am very pleased with it.
My favourite board was the Cubie 2 that I had. It ran for a year and a half without a restart. So I thought I’d give it an upgrade. I backed up everything, rebooted, and it never started again, no matter what I tried. I was heartbroken, especially as it had a SATA connection so I could hook up a proper harddrive.
I hope that doesn’t happen with the Odroid, as I have it set up with DuckDNS for dynamic IP, and LetsEncrypt for https, both free and nag-free.
With regards to a replacement, could I make a suggestiion. Try the Orange Pi Zero’s in a cluster. They’re cheap, about $8.99 for the 512MB RAM version. I loaded up Armbian on a couple of them (only a 150MB download), and they just worked. It’s a four core chip, with a MALI400 GPU. WiFi on board (including a little antenna).
The main thing is, it is not going to break the bank, while at the same time giving you all the things you would need to run a cluster. Ali Express also do cheap 8-way ethernet switches.
Look for the simplest solutions first, then you’re on your own.
If this helped (ha) send me some of that Black Rifle coffee.
If you examine the circuit board under a magnifier, you might luck out and find a break in the foil connections. I’ve done that a few times. A bit of solder to bridge the gap will fix. Trickier with denser boards.
Burned out light bulb on my stoves exhaust hood.
Put in a new bulb, no joy.
Proceeded to tear the whole thing apart, using my limited electrical diagnostic skills I determined that there were no “opens” and it was “hot”.
After about 2 hours of playing electrician, I got tired of playing (I knew there were no shorts and the socket was getting power) so I put in another bulb, and it lit.
(the first bulb I tried was faulty, GE by the way).
Talk about frustration, doubts of ones intellect, all because GE sold me a faulty bulb.
I’ve done enough debugging, I know how to do anything the wrong way 6 times in a row each subtly different ;-) That’s why they are in the box right now, not tossed. Even though I’m sure they are toast. In a day or two, I’ll retest starting from scratch again. Using the DVI HDMI monitor they both worked eith before, the same psu, the same keyboard, the same powersupply they worked on before. Tested with all prior SD cards labled for them, plus a completely new build. (If nothing else, it will hone the skills…)
Also going to check the socket polarity, measure any ground to ground volts, etc.
A couple of years ago, I lost a WiFi router and a computer to an electric spike. Electric wire crossbar on the power pole fell putting volts in the wrong place.. and sent a surge from WiFi router to aluminum window sill… and scorch marks from power in to antenna on the circuit board… so possible it was some odd groud volts or AC spike on the non protected power bar. So one thing I’ll do is just assure enough sockets are on the UPS for all computer stuff.
I suspect mist stongly some board flex cracked it as it was matched in time to that moment. The C2 harder to explain…
@Paul:
I have an Orange Pi One already, so some experience. Initially I was annoyed that it would not do video, now I know it just doesn’t like the DVI conversion. It also rapidly heat limited performance, so would need a BIG heatsink for full load constantly (one of the things I like about Odroid…comes with propper heat sink).
So with those caveats, it is in the running. But the less performance per core, the more cores needed and the longer the run time as some tssks are sequential… so prefence goes to bigger faster cores and boards.
I just need to figure out if the boards died from physical flex (so use good cases and don’t unplug / plug stiff HDMI alot… New cable was a tight fit…), or electrical (so check power and always use ups spike suppression), or weak design (so buy different vendor).
I’ll ask the spouse to do a visual check, she has superb close vision :-)
I can do a decent electrical audit.
Then a web check for sudden death horror stories…. if it’s weak design, the web will know…
I really liked the speed for browser use. Don’t kniw if I can settle for slower there now :-0
@uk (us): That’s why I’m doing a 2 day cool out then start over. Restarts me back on the basics first…
BTW, I’ve learned to check new bulbs in a known working socket if they don’t light up. Too many times replacing a bad part with a dead one… Now on power or networks, the mantra is to test with proven good parts. Test the part, then put it in. On nogo, test the part again, just to be sure it didn’t funt! on me.
@Jim2:
These are too dense with big heatsinks for me to fix, but if it is broken then I’ll know it is flex sensitive.
For now, even with their loss, I have too many computers for it to matter. At mist I would be able to use one of them at any one time (the C2 would not integrate into a v7 cluster well, the XU4 might, but would have different libraries and has odd scheduler action). For now, I just need to be happy with using some other box for the msin dedktop, and or swapping chips in obe for different roles. Not a big deal, really.
Whenever I finally get a distributed model running, then I might need more cores. But that is a long ways away. I’d already figured a uniform growth using only Devuan on v7 cores would be best for that (or make a whole new cluster on v8 64bit cores…) Using Pi M3 running armhf for now has a strong attraction, then someday, when stable, moving it all to arm64.
Well, not a decision needed now. I can work the issue for a while and just put the Mac on the desk for a fast browser, if the Pi M3 feels too slow now, having been spoiled by the XU4. Right now, I’m more interested in getting familiar with using GPU codes and what GPUs are better for that. There are specific boards that are much better for that, so I need the learn that stuff first, then choose.
sorry to hear about that board problem. IIRC there has been problems with the HDMI on small boards. Don’t know why or what, just that it seems to be a weak spot. I have a Rpi1 that worked. hooked it to HDMI and it never again booted. The Rpi2s working in a Dogbone stack work fine and the naked Rpi3 just gets banged around and always works. It is plugged HDMI and feeds on the old 19″Dell flat screen that I bought at Goodwill w USB AUX for power. I do sometimes get the lowpower complaint on the screen,but no reboot crashes. The on board WiFi always works. Damn little thing just always works. I pack it around to use it to trouble shoot my extended system so it gets rough treatment indoors and out.
I would think the small board cut off should be whether it will run heat sink only or is it a cooling fan must have. It would be nice to have better IO then the Rpi’s sport but at least they have several ports.
Devuan or maybe ArmDeVan sounds to be the foundation for the OS solution. I’m still stuck with a Windows brain. Not sure if this old dog is up to learning new tricks…pg
Nothing an AR-15 can’t fix ?
If you can’t fix it, use it for target practice, you’ll feel better :)
@u.k.(US):
Not really feeling bad. My major reason for the original buy was “evaluation” and part of that is “how sturdy”. For that reason I usually don’t mollycoddle things being tested. You don’t want to buy a dozen THEN find out what doesn’t work well over time.
So OK, I’d be happier if it had held up to mild abuse a bit more. Then again, I don’t consider plugging and unplugging the HDMI connector a few dozen times “abuse”… IMHO, the most likely issue is that the PC Board is too thin and flimsy with too much micro sized wires and parts. That means not enough strength to stand up to the hard push / pull of the HDMI (unless maybe fixtured in a sturdy mount / case)
The alternative being the circuit design is not robust to minor off volts that other boards ignore. Either is possible. (Or I just messed up the boot / chip/ whatever and tomorrow it will work fine ;-)
Still, it’s the information I wanted to get. For sturdy and always works, the Pi M3 still leads. For massive computes from a finicky board, the XU4 is workable. Just buy a good case, feed it UPS power only, and plug the monitor in and then leave it alone… ;-)
HPC High Performance Computing is always about coaxing finicky boxes to not die too soon. If you make them slower for greater robustness, then they aren’t fast enough. (There’s an ideal MTBF that’s fairly small. You checkpoint often and expect to restart after failures. IF it didn’t crash, you were wasting total computes by running too slow and you would get more done by crashing sooner but working much faster… IIRC, for our Cray, it was something like 300 hours? Once every 2 weeks? Then again, we tended to leave the speed switch on the slower setting. It was advised to leave it on faster (overclocked) until too many crashes,then back it off….
@P.G.:
I keep finding new toys to evaluate, and keep ending up back on the Pi M3 as bullet proof and just always works… I’m likely to still test out other boards (it is cheap for many of them) but I’m not expecting the answers to change much… I’m going to be looking up board thickness numbers if I can, since my strongest suspicion is that “it matters” and board flex is the cause of failure while too thin a board slows conduction cooling of the CPU chips.
Makes sense. The Pi folks designed this for kids to throw around in lab time. The dinky cheap board folks make them for developers to put into production gear where it is engineered into the package and shaving a penny adds to profits…
I just hope they come out with a Pi M4 that has 8 cores of A15 processor in January ;-)
Sounds like an engineer needs to build a HDMI receptacle that can stand up to the trials of rug-rats, should keep them busy for years :)
I think you are likely on the right track with the idea of a cracked board or a solder connection pulled loose due to forces used to plug and unplug the cables – at least that would be what I would look for in your situation. When I was working as an electronic technician repairing old radiation detection equipment we would see that often enough to include it in the trouble shooting process.
If that is the case a very bright light and a good 10x or higher loop will allow you to see hairline cracks that otherwise are invisible. Some of the failure cracks were hidden by traces of resin on the boards so I had to give them a good cleaning with methyl alcohol before doing the detailed examination of all the traces and solder connections. Good luck finding the root cause of those failures.
Old Sun systems had a series of problems of solder connections opening if the system got too hot. Turned out it was a corner cut by the contract manufacturer they did not use the proper high temp solder and when the cores got flogged really hard they would get hot enough to produce bad solder joints and fail.
EM – if the board is too flexible, I wouldn’t expect the Copper traces to be broken but maybe some of the ceramic SMD devices to crack at the ends. This can be very difficult to actually see, though. A crack in the middle of an SMD cap or resistor would be fairly visible, but the crack tends to be between the terminals and the device. If the joint that’s failed is below a ball-mounted SMD device then you just can’t see it anyway, though you may be able to use a hot-air gun to re-fuse the joint, though there the chances are that the pad would come off the board. Maybe…. Squirting some rework flux under the device would likely be needed, too.
Trying to work out how the board has flexed, and thus which joints have sustained the stress, may help in deciding where to concentrate the inspection or attempts at rework. The lens from a webcam or other old camera may be useful as a short-focus lens for inspection, though a microscope makes life a bit easier. Since you’ll be working with no schematic or other information then the chances of finding a fault and being able to fix it are pretty slim.
If the solder pad wasn’t designed to make the molten solder move during SMD reflow (most aren’t), and just relies of settling and fusing of the solder-paste, then even a joint that looks visually perfect may fail at high frequencies, or may work for a while and then fail to work at high frequencies after a minor stress. These are impossible to distinguish by visual inspection or with a DVM, and can only be found by scraping the joint with a hot soldering iron to re-melt the joint and move the impurities away from the solder/lead interface (the pad itself normally has a good connection in these circumstances). You only know which one has failed once it’s fixed. This probably can’t happen to BGA mounting, since the solder-balls on the device are fused on well and then are re-melted during reflow and the solder must move across the surface taking impurities outwards. Given that this type of fault doesn’t turn up that often, it’s more of a last-ditch effort to stroke each visible joint with a fine-tipped (and fairly hot) soldering-iron (and a squirt of rework flux) and see if the problem goes away.
Given that the SMD components and the board have different thermal expansion rates, the stress of thermal cycling can produce fatigue fractures in the solder joints, and after enough cycles these can become effectively open circuit. That will normally be seen first on the larger SMD devices and ones that get hot (high-power resistors), and of course if the board is flexed then an incipient crack (crack in a percentage of the joint volume) can become effectively open-circuit. If there are large SMD devices in the area that was stressed by the HDMI connector, it’s worth touching-up those joints first and seeing if the board comes alive afterwards. This fault may be actually visible as a line on the solder. The fault Larry describes seems to be this type of problem, and would tend to show more when they use Lead-free solder since the Lead-based solders can take a lot more movement before they fatigue-fracture. In fixing them, it’s probably a good idea to use a 60-40 Tin-Lead solder to get a joint that will last longer next time. Should be fixed by design and by putting stress-relief into the components, but of course that costs more….
The time taken to fault-find and fix would probably be uneconomic if you costed your time at professional rates. If the design is faulty (and it seems that it is) then it’s better to get something that is better-designed so the faults don’t appear.
LL and CIO: I also was an electronics tech and worked on computers and other stuff. Isopropyl alcohol works about as well as methyl and is easier to get and a bit less toxic.
CIO, I wonder if this would give you a leg up WRT parallel programming? It’s got 16 cores out of the box and programming examples for a kick start.
https://www.parallella.org/board/
@Larry:
On the first computer I ever built (part of a “team” of 4 of us – an Altair Mits 8800)
https://en.wikipedia.org/wiki/Altair_8800
the guy who paid for the fun (i.e. actually owned it) decided to socket mount the main chips so failures could be easily corrected. The “sockets” were just metal pin strips that had socket ends, not the full on plastic base things.
The thing would run a bit, then get errors. Wait. Repeat.
After a few weeks of despair he paid to send it to the factory for diagnosis.. to find out what “we” had done wrong…
He had insisted on doing all the chip insertion himself. Seems on a few chips he had missed the actual center insertion point and the ‘legs’ of the chips were outside the “socket” but touching. Worked when cold, then the chip would heat up and expand and the “legs” would move away to the outside from the socket pins…
The rest of the build team were relieved and he was much less prone to hubris ;-)
My first program (toggled in in assembler binary) was about 10? lines that copied itself from bottom of memory (default start address) to top of memory then ended. Nice blinky lights ;-)
Per the Odroids:
On the XU4, I suspect a surface mount failure as most probable. I was running it. Shut down, pulled one HDMI cable and put in the other from the TV. During the process, noted hard pull / push, felt small “shift” as board seemed to flex or heatsink shifted, then it would not boot. I’d generally tried to be careful to only hold it by board edges and “large bits” like the USB / Ethernet sockets, but the angles are awkward and the heat sink gigantic so hard to miss. IMHO, the most likely issue is just that they use a VERY thin PC board and it may not be up to the forces involved.
OTOH, just now, picking it up for a PC board look / see: Their is a little switch for SD vs eMMC boot that looks to now be in the eMMC position… on the end next to the HDMI socket. I wonder if Fat Fingers on that end of the card ‘slipped’ the switch? Hmmm…. Need to shut down this computer (PiM3) to test that. It would be a great bit of luck if that’s all it is…
The C2 is mounted in a case. I was trying different builds on different chips, then set it aside for a while, then had no boot. I suspect perhaps I’ve just “lost the plot” on which SD card is a C2 card. Either that, or no clue why it stopped since it is in a nice case to protect the board…
@Simon:
All good advice. Unfortunately, I have Farmers Hands (Dad’s side of the family… large paws that are great for a Smith with a big hammer, not so go for fine work) and old eyes… some of the connections and traces are so small I can’t see them worth a damn… I’d be prone to just giving it to some kid to “fix or learn by disassembly” which I did with so many clocks, radios, and TVs…
@Jim2:
Methyl is not that hard to get (lacquer thinner) but isopropyl is easier on the metabolism. (Diabetic prep 99% works better than the usual 70% / 30% water). I have a gallon of Methanol bought for use in a camp alcohol stove sitting around here somewhere.
Each tend to have slightly different ability to dissolve different things. Don’t know which one is best for resin. Heavier alcohols get more ‘gasoline like’ and methanol is more ‘water like’, so sometimes I try the series.
Per the Parallela:
I looked at it in some detail. It has some benefits and some “issues”. The benefit is all those cores on a relatively high speed cross connected internal network. The “issues” are:
1) Heat extraction problems. You basically must install heat sinks and a large fan yourself or it will run way hot. IMHO it’s a design fault to NOT have your board already handle the known heat loads.
2) Minimal CPU cores. As noted in another post, not all ARM cores are the same. These guys are not all that big and beefy a core design. Actual relative performance number I’ve forgotten, but “has issues”. I think there was no FPU, for example, and certainly no GPU to play with.
3) Memory balance issues. Again, it was some years ago I looked at it so a bit hazy now, but IIRC there isn’t much memory / CPU and getting bits TO the CPU core is a bit awkward. You have 1 GB and 18 cores, so on average 55 MB / core and they are all trying to get their bit serviced over the same communications fabric. Memory intensive problems will not do well here. Only very small memory footprint execution kernels will be fast and happy.
4) I/O off board balance issues. Again all those 18 cores share the Gb ethernet, so “comms / core” is low. Fine for doing things decomposed ON the board and handled as threads, not so go for things (like distcc) that are spread over a network.
So my conclusion was that it would be “fun to play with” and might even be a good idea for highly parallel parts of climate models IF custom written for the board architecture (i.e. assuring low memory footprint execution bits and lots of “computes per memory or fetch”); but would take more work to make do what I wanted and paying $99 for more “play time” was not for me “right now”.
I likely ought to add it to the board comparison here:
https://chiefio.wordpress.com/2017/11/19/1-dry-number-look-at-sbc-speeds/
just so the actual performance rank is more clear.
So I like the idea of the board, but I’m also certain that in terms of real performance benefit and also best skills to build, buying an NVIDEA Jetson would be the better thing to do. CUDA programming is going to be in huge demand “going forward” as every robot with vision will want to use it (or something like it).
https://www.amazon.com/NVIDIA-Jetson-TK1-Development-Kit/dp/B00L7AWOEC/ref=sr_1_2?ie=UTF8&qid=1511105190&sr=8-2&keywords=nvidia+jetson
$200 so twice as expensive, but way more computes and set up for easier programming. Has some minor heat extraction issues (needs a fan) but IIRC comes with one.
For me, for larger distributed tasks and more of an unknown size of compute kernel with unknown complexity, the better solution is a balanced system (Amdahl’s 2nd Law) with GigE communications fabric and as big a single core as I can afford (reduces need to decompose problem to little bits and saves programmer time – i.e. my time that I don’t have to excess…)
Well, having seen that switch setting on the XU4, I’m going to shut down and test it immediately. I’m really hoping I just fat fingered it…
Well, THAT’S a relief!
The Odroid XU4 has now booted. Mystery solved.
There is a tiny switch about the size of a coarse salt grain that swaps from eMMC booting to mini-SD card booting. It is located about 1 cm from the corner where you insert the HDMI cable. By avoiding the heat sink (that can shift) and holding the card edge (that is way too thin for a good grip surface) and pushing with a firm cable insertion, enough force goes into the switch to slide it the mm or 2 needed to change state. Perhaps some of the “flex” I felt was just the switch moving.
In any case, the XU4 is back… and I think my next “buy” will just be a case for it.
Still leaves the C2 mystery, but it’s next up for further examination…
One of the down sides of the newer modern electronics!
Like my phone you can’t hardly pick the thing up without accidentally pushing one of the buttons on the side because they are all skillfully located at the exact points a natural grip places your fingers. Fine when you are holding the phone the way they intended, but not so good from a random pickup off the table sort of situation or fishing the thing out of your pocket.
Glad you found that switch issue. Little things like that will drive you nuts finding them and I suspect and sent a lot of electronic gear to the garbage dumps.
Why I don’t toss things until I’ve given them a twice over AND done a ‘start from scratch’ redoo AND then inspect for parts to reuse…
FWIW, I’m driving the TV with it as I type.
Youtube Lady Gaga “Edge Of Glory” (lots of moving detail like brickwork):
I can get 360p Theatre Mode (larger than default but not whole screen) out of it fine. 240p full screen. Oddly, even with it set for 720p and with jumps and halts in the video, the cores are not all loaded up and not at 100% for any given core.
I’m running Armbian (default build is toward embedded market and not much care about displays. Has “compositing” issue with ‘jitter’ on drag of big screen elements, so not using GPU “right”.) uplifted to Devuan. I suspect that trying Ubuntu will work better for video (lots of ‘eye candy’ folks on Ubuntu…). So that test is “on the cards”.
I can now get tunes while typing ;-) Oh Boy!
From Joy (new Monitor!) to sorrow (Drat Dead!) to joy again (It Lives! With tunes!!) all in a day or two…
I’ve now put the XU4 on the TV and that’s where it’s going to stay. All monitor and board swapping to happen on the DVI / HDMI converter monitor… One “scare” was enough and I like my tunes ;-)
Glutton for punishment, and wouldn’t have it any other way.
@u.k.(us):
You have a future in Computer Systems Programming with a fine attitude like that! ;-)
Update on C2:
Well, I’ve tried everything I can think of. Did find one site saying might not boot if the ground on the HDMI cable is different from the computer (which mine was). Changed it and still no-go. Pretty much all combinations of OS tried. (New, old known to work, from SD, from eMMC).
I did manage to get the CPU Heartbeat blinky blue light, but only by using both USB and round plug power supplies at the same time. But still no boot.
At this point, IMHO, the most likely case is that the grounds were different and fried some part on the board (perhaps HDMI chip so no display?). At any rate, it’s in the junk box now. I may try other tests at some future time, but it just isn’t important enough anymore.
So lesson learned: Audit my power system, make sure neutral is really near ground and not the hot lead (a tester plugged into the wall says they are reversed) and don’t split boards between UPS and not (especially if ‘not’ fails a polarity tester). Maybe…
I’m mostly just happy the XU4 survived as I like it more and it works better with all the other V7 chips in a cluster… So “buy XU4 case” on the to do list as I think I’m done with the “jerk it around on the desktop and see what happens” phase ;-)
Note on Youtube:
I put a clean release of Odrobian /Ubuntu Mate on the XU4 and launched a youtube of Lady Gaga “Edge Of Glory” (same test as before). I can easily get 480p at full frame rate in theatre mode. 720p isOK, but has occasional small jumps / pauses. Not enough to bother, but there if you look for it. In full screen, 320p seems fine and the others have a few minor issues with 720p having full stops at time.
Overall, it’s clear that (*as expected”) Ubuntu Mate has spent more time getting the video to work well and Armbian has concentrated more on what embedded systems guys want. (Power management, effective build tools, etc.etc.) So I’m likely to try making an Ubuntu / LXDE and / or a Debian /LXDE uplifted to Devuan and see how they do. It would be nice to get decent video AND a Devuan attitude… But worst case is I keep an Ubuntu chip laying around for when I want to run Youtube on the XU4.
TV as Monitor:
Good news is I have more “productive desk time” as I can have the news running “one screen over” from the DVI monitor. Bad news is that if I’m doing PC stuff on it, and the computer is off too long, the TV powers down. Consequently, I’ve needed to power it back on more than I like. I’m trying to train myself to swap back to news on the Roku when I power down the computer… I could find no setting to tell it “DO NOT AUTO POWER DOWN WHEN IDLE!!!”… Otherwise, I’m quite happy with the whole thing. Moving the Roku from bedroom to office is also a bit of bother, so I’m planning to pick up the $25 optical Roku cheap unit for it. Don’t really need the radio remote when it is sitting 2 feet away on the desktop with clear line of sight.
eMMC bits:
I could not get the eMMC to boot on the C2 or on the XU4. I think there is some “magic sauce” to making it boot that I don’t have. Some R&D needed there… In the mean time, I’ve put a copy of the Devuan from the Pi M3 on it and used the mini-SD adapter to put it in the M3. So right now I’m running from the Pi M3 on eMMC. It feels “snappier” on launching windows and things. “Someday” I’ll so some A B testing of the eMMC vs a real mini-SD card. For now I’m just going to enjoy it ;-)
So, with that, I’m back to putting the XU4 into “production” and moving on…