Well, got a nice perk this week at work: assisting in getting an embedded linux board up and running. To be honest: it is a nice little piece of work, called a FriendlyArm. It is an ARM9-based development board, costing less than $150 with an 3.5″ TFT with touchscreen (optional 7″ touchscreen). It is fitted with 64Mb RAM and 64Mb Flash, and 2Mb NOR.
I’ll be trying to get this to work, so expect updates on the blog. Eventually, I’d like to get Android running on this board as well (but memory may be a problem).
Full specs after the break
Read more…
Interesting… The Wine (Wine is not an Emulator) project has been allowing me to run Windows applications on my Linux machine at home for quite some time. Recently, I needed to burn an image to a dual-layer DVD and was having problems getting it to read in my in-dash navigation system. Several posts on the internet pointed out that I was best off using Verbatim media, but I also feared that the ancient firmware on my burner (an NEC ND-3500AG) might be to blame.
Newer firmware was available, but as is almost always the case only available on Windows. As I do not have a running Windows image on this machine (let alone the possibility to run DOS) I figured I might as well attempt the flash using Wine. Should it fail, I could always take the drive out and attempt a re-flash on a Windows-based machine. What spells my surprise to find that the flash worked flawlessly! I’m not advocating this route for each and every flash, but I’ve seen more success-stories of firmware flashes using Wine.
And yes, the subsequent burn worked flawlessly…
As listed in my previous post, I’m looking at finding out more about coredumps. The page I found the info below on lists that the limit is the maximum size of a process image that a coredump would be generated from.
However, the file will not be created unless your “core dump size limit” is set high enough to accomodate the core dump file.
Unfortunately, it doesn’t refer to the Unix/Linux version used and the age of the information is also unknown. So further investigation ensues.
OK, so here’s an interesting one: I’m currently doing the architecture for a new embedded controller running Linux as its OS. It will use a SoftPLC for the actual control of the hardware and I want it to have a proper way of handling OS failures. We’ve looked at the glibc backtrace() functions and they would solve part of the problem.
Our main problem is the fact that the root fs of the controller will be on a read-only cramfs and that the writable flash partition is only limited in size. We will have more memory than flash, meaning that we cannot accomodate full coredumps. Of course, for this the ulimit -c command has been invented, but I wonder what happens if I set the limit to 1Mb for example. If the process image is larger than this, would the coredump not be generated at all? Or would the generated coredump be limited to this size? And if it is limited to a certain size, is there a coredump size you should not dip below risking that the coredump becomes useless due to missing stack information? The online documentation I found was inconclusive, so its on to experimentation. I’ll update this post with my findings…
Well, I had another one this time. I’m running a Home Theater PC at home based on the fantastic MythTV but recently it failed on me. I couldn’t get it to boot anymore. The PC would start, show the BIOS screen and show the attached discs and then… nothing. As written here, I have had several disk failures in this machine already so I was suspecting that something in the vicinity of my SATA controller had failed internally.
I had left the PC sitting for over a week as I didn’t have time to fix the issue but this Saturday I finally started to look at the problem. After opening up the BIOS and doing several checks if the disks were present I was just about to give up and buy a new motherboard for my PC (it was an old beast to start with). And then my eye fell on the boot order. For some reason, I had this set in the following order
- boot from USB
- boot from HD
- boot from CD
And then the light struck… I had a memory card inserted in its USB adapter that was sitting snugly in the USB hub. I removed it and voila, the system booted! What I still don’t understand is why my BIOS didn’t give me an error that no OS could be found on the memory card…
My PC that I use at home is used amongst other things as a media center as well. For this, it was equipped with dual disks (one of 300Gb and one of 160Gb). I state was, as one of the disks had failed. Or perhaps I should say: alternately failed… I’m using Maxtor DiamondMax disks, and it seems that these are simply unreliable buggers (according to StorageReview, they are less reliable than 68% of all drives submitted in their storage survey). More than a year ago, my (then) 250Gb drive had failed and only recently I got time to take it out and bring it to the shop for an RMA. Thank god for their new extended warranty (was 1 year, is now 3 years, I believe)…
Anyways, after receiving a 300Gb replacement, I tried installing it in my PC. Nothing. It didn’t show up, not even passing the SATA drive validation during bootup. I tried re-seating all the cables: nothing. I inserted another power cable: nothing. I switched both SATA cables: now the 300Gb comes online and the 160Gb has failed…
Great… One of the SATA ports on my motherboard died. If anyone knows of a good SATA controller (with external eSATA connectors as well!) I’d be interested.
