Reviving A 15-Year Old Asus EeePC With Modern MX Linux

Welcome back to 2010 and the Asus eeePC Netbook, Seashell series. (Credit: Igor Ljubuncic)
Welcome back to 2010 and the Asus eeePC Netbook, Seashell series. (Credit: Igor Ljubuncic)

It’s often said these days that computers don’t become outdated nearly as quickly as they did in the past, with even a decade-old computer still more than capable of handling daily tasks for the average person. Testing that theory, [Igor Ljubuncic] revisited the Asus eeePC which he purchased back in 2010. Although it’s not specified exactly which model it is, it features an Intel Atom N450 (1 core, 2 threads) running at 1.67 GHz, 1 GB of 667 MHz DDR2 and a 250 GB HDD, all falling into that ultra-portable, 10.1″ Netbook category.

When new, the netbook came with Windows 7 Starter Edition, which [Igor] replaced with Ubuntu Netbook Remix 10.04, which was its own adventure, but the netbook worked well and got dragged around the world on work and leisure assignments. With increasingly bloated updates, Ubuntu got replaced by MX Linux 18, which improved matters, but with the little CPU struggling more and more, [Igor] retired the netbook in 2019. That is, until reviving it recently.

Upon booting, the CMOS battery was of course empty, but the system happily continued booting into MX Linux. The Debian update repositories were of course gone, but changing these to the archive version allowed for some (very old) updates. This raised the question of whether modern Linux would even run on this ancient Atom CPU, the answer of which turned out to be a resounding ‘yes’, as MX Linux still offers 32-bit builds of its most recent releases. A 15 minute upgrade process later, and a 2 minute boot later, the system was running a Linux 6.1 kernel with Xfce desktop.

As for the performance, it’s rather what you expect, with video playback topping out at 480p (on the 1024×600 display) and applications like Firefox lacking the compact density mode, wasting a lot of screen space. Amazingly the original battery seems to still deliver about half the runtime it did when new. All of which is to say that yes, even a ‘low-end’ 2010-era netbook can still be a very usable system in 2024, with a modern OS.

The Possibility Of Reverting Time On The Ageing Of Materials

Everyone knows that time’s arrow only goes in one direction, regardless of the system or material involved. In the case of material time, i.e. the ageing of materials such as amorphous materials resulting from glass transition, this material time is determined after the initial solidification by the relaxation of localized stresses and medium-scale reordering. These changes are induced by the out-of-equilibrium state of the amorphous material, and result in changes to the material’s properties, such as a change from ductile to a brittle state in metallic glasses. It is this material time which the authors of a recent paper (preprint) in Nature Physics postulates to be reversible.

Whether or not this is possible is said to be dependent on the stationarity of the stochastic processes involved in the physical ageing. Determining this stationarity through the investigation of the material time in a number of metallic glass materials (1-phenyl-1-propanol, laponite and polymerizing epoxy) was the goal of this investigation by [Till Böhmer] and colleagues, and found that at least in these three materials to be the case, suggesting that this process is in fact reversible.

Naturally, the primary use of this research is to validate theories regarding the ageing of materials, other aspects of which have been investigated over the years, such as the atomic dynamics by [V.M Giordano] and colleagues in a 2016 paper in Nature Communications, and a 2022 study by [Birte Riechers] and colleagues in Science Advances on predicting the nonlinear physical ageing process of glasses.

While none of these studies will give us time-travel powers, it does give us a better understanding of how materials age over time, including biological systems like our bodies. This would definitely seem to be a cause worthy of our time.

Header image: Rosino on Flickr, CC BY-SA 2.0.

Fukushima Daiichi: Cleaning Up After A Nuclear Accident

On 11 March, 2011, a massive magnitude 9.1 earthquake shook the west coast of Japan, with the epicenter located at a shallow depth of 32 km,  a mere 72 km off the coast of Oshika Peninsula, of the Touhoku region. Following this earthquake, an equally massive tsunami made its way towards Japan’s eastern shores, flooding many kilometers inland. Over 20,000 people were killed by the tsunami and earthquake, thousands of whom were dragged into the ocean when the tsunami retreated. This Touhoku earthquake was the most devastating in Japan’s history, both in human and economic cost, but also in the effect it had on one of Japan’s nuclear power plants: the six-unit Fukushima Daiichi plant.

In the subsequent Investigation Commission report by the Japanese Diet, a lack of safety culture at the plant’s owner (TEPCO) was noted, along with significant corruption and poor emergency preparation, all of which resulted in the preventable meltdown of three of the plant’s reactors and a botched evacuation. Although afterwards TEPCO was nationalized, and a new nuclear regulatory body established, this still left Japan with the daunting task of cleaning up the damaged Fukushima Daiichi nuclear plant.

Removal of the damaged fuel rods is the biggest priority, as this will take care of the main radiation hazard. This year TEPCO has begun work on removing the damaged fuel inside the cores, the outcome of which will set the pace for the rest of the clean-up.

Continue reading “Fukushima Daiichi: Cleaning Up After A Nuclear Accident”

Completed wire-wrap connection with WSU-30M tool. (Credit: Sparkfun)

3D Printing A Wire-Wrap Tool: Emergency Fix Or Permanent Solution?

Although less popular these days, wire-wrap is still a very relevant, easily reversible solder-free way to assemble (prototype) systems using wire-wrap wire and a wire-wrap tool. This latter tool can be either a hand or powered tool, but all it has to do is retain the stripped wire, fit around the wire-wrapping post and create a snug, oxidation-proof metal-metal contact fit. For the very common 30 AWG (0.25 mm) wire-wrap wire, the Jonard Tools (OK Industries) WSU-30M wire-strip-unwrap tool is pretty much the popular standard. It allows you to strip off insulation, wrap and unwrap connections all with one tool, but the question is whether you can just 3D print a wrap-unwrap tool that’s about as good?

First a note about cost, as although the genuine WSU-30M has risen in cost over the years, it can still be obtained for around $50 from retails like Mouser, while clones of varying quality can be obtained for around $15 from your favorite e-tailer website. From experience, these clones have quite sloppy tolerance, and provide a baseline of where a wrapping tool becomes unusable, as they require some modding to be reliable.

Wire-wrap tool model by [KidSwidden] on Thingiverse.
Taking a quick look at the wire-wrap tools available on Thingiverrse, we can see basically two categories: one which goes for minimally viable, with just a cylinder that has a hole poked on the side for the stripped wire to fit through, as these versions by [JLSA_Portfolio], [paulgeneres], [orionids] and [cmellano]. The WSU-30M and similar tools have a channel on the side that the stripped wire is fed into, to prevent it from getting tangled up and snagging. On the clone units this channel often has to be taped off to prevent the wire from escaping and demonstrating why retaining the wire prior to wrapping is a good idea.

This leads us to three examples of a 3D printed wire-wrap tool with such a wire channel: by [KidSwidden] (based on a Radio Shack unit, apparently), another by [DieKatzchen] and an interesting variation by [4sStylZ]. Naturally, the problem with such fine features is that tolerance matter a lot, with an 0.2 mm nozzle (for FDM printers) recommended, and the use of an SLA printer probably a good idea. It’s also hard to say what kind of wire-wrap connection you are going to get, as there are actually two variants: regular and modified.

The starting guide to wire-wrapping by Sparkfun uses the WSU-30M, which as the name suggests uses modified wire-wrap, which means that part of the wire insulation is wrapped around the bottom of the post, for extra mechanical stability, effectively like strain-relief. A lot of such essential details are covered in this [Nuts and Volts] article which provides an invaluable starting guide to wire-wrapping, including detecting bad wraps.

Naturally, the 3D printed tools will not include a stripper for the wire insulation, so you will have to provide this yourself (PSA: using your teeth is not recommended), and none of these 3D models include an unwrap tool, which may or may not be an issue for you, as careful unwrapping allows you to reuse the wire, which can be useful while debugging or reworking a board.

Top image: completed wire-wrap on a post. (Credit: Sparkfun)

When Raw Network Sockets Aren’t Raw: Raw Sockets In MacOS And Linux

Raw network sockets are a curious beasts, as unless you have a strong urge to implement your own low-level network protocol, it’s a topic that is probably best left to the (well-paid) experts. That said, you can totally use raw sockets in virtually every operating system, but one should be aware of a few things, the lack of portability being one of them. This is what tripped [Swagnik] up while trying to write a low-level network ping (ICMP) utility, by reading the Linux socket documentation while testing on MacOS. It’s all BSD-style sockets, after all, right?

As it turns out, the network stacks in Linux and MacOS have some subtle differences, which become apparent when you read the friendly manuals. For Linux, the raw(7) man entry for IPv4 sockets make it clear that the IP_HDRINCL socket option is default by default for IPPROTO_RAW sockets. This is different from MacOS, which is effectively FreeBSD with glossy makeup. Like FreeBSD, the MacOS man page makes it clear that the IP_HDRINCL option is not set by default.

So that’s easy, right? Just fire off a setsockopt() call on the raw socket and that’s done. Not quite. The Linux man page notes that it cannot receive all IP protocols, while the FreeBSD/MacOS version makes no such exceptions. There is also the issue of endianness, which is where [Swagnik]’s blog post seems to err. The claim is that on MacOS the received IPv4 raw socket header is in host (little endian) order, while the documentation clearly notes that these are in network (big endian) order, which the blog post also shows.

Where things get really fun is when moving from IPv4 raw sockets to IPv6 raw sockets, as [Michael F. Schönitzer] covered for Linux back in 2018 already. IPv6 raw sockets drop IP_HDRINCL and requires a whole different approach. The endianness also changes, as IPv6 raw sockets under Linux must send and will receive data in network byte order, putting it in line with FreeBSD raw sockets.

Raspberry Pi RP2350-E9 Erratum Redefined As Input Mode Leakage Current

Although initially defined as an issue with GPIO inputs when configured with the internal pull-downs enabled, erratum RP2350-E9 has recently been redefined in the datasheet (page 1341) as a case of increased leakage current. As it is now understood since we previously reported, the issue occurs when a GPIO (0 – 47) is configured as input, the input buffer is enabled, and the pad voltage is somewhere between logic LOW and HIGH. In that case leakage current can be as high as 120 µA with IOVDD = 3.3 V. This leakage current is too much for the internal pull-up to overcome, ergo the need for an external pull-down: 8.2 kΩ or less, per the erratum. Disabling the input buffer will stop the leakage current, but reading the input requires re-enabling the buffer.

GPIO Pad leakage for IOVDD=3.3 V (Credit: Raspberry Pi)
GPIO Pad leakage for IOVDD=3.3 V (Credit: Raspberry Pi)

The upshot of this issue is that for input applications, the internal pull-downs are useless, and since PIO applications cannot toggle pad controls, the input buffer toggling workaround is not an option. ADC usage requires one to clear the GPIO input enable. In general any circuit that relies on floating pins or an internal pull-down resistor will be affected.

Although this should mean that the affected A2 stepping of the RP2350 MCU can still be used for applications where this is not an issue, and external pull-downs can be used as a ‘fix’ at the cost of extra power usage, it makes what should have been a drop-in replacement a troubled chip at best. At this point there have still been no definite statements from Raspberry Pi regarding a new (B0) stepping, leaving RP MCU users with the choice between the less flashy RP2040 and the buggy RP2350 for the foreseeable future.

Header: Thomas Amberg, CC BY-SA 2.0.

Fixing An Elgato HD60 S HDMI Capture Device

There’s a special kind of satisfaction found in the act of repairing a previously broken device, which is why YouTube is full of repair channels and guides on how to do it yourself. Inspired by this, [Doug Brown] decided to give it a shot himself, with an Elgato HD60 S HDMI capture device as the patient. As per the eBay listing, the device did not show up as a USB device when connected to a computer — a quick probing of the innards revealed that not only were the board voltages being dragged down, but some of the components on the PCB were getting suspiciously hot.

One of the broken switching regulators on the Elgato HD60 S capture device PCB. (Credit: Doug Brown)

On a thermal camera the hot components in question turned out to part of the voltage regulator circuits, one a switching regulator (marked fiVJVE, for Fitipower FP6373A) and another a voltage inverter marked PFNI (Ti TPS60403DBV).

Since both took 5 V, the suspicion was an over-voltage event on the USB side. After replacing the FP6373A and TPS60403 with newly purchased ones, the voltage rails were indeed healthy, and the Elgato sprung to life and could be used for HDMI capture and pass-through. However, the device’s onboard LEDs stubbornly refused to follow the boot-up pattern or show any other color patterns. Was this just a busted Innotech IT1504 LED driver IC?

Swapping it with a pin-compatible Macroblock MB15040 didn’t improve the situation, and the LEDs worked fine when externally controlling the MB15040 on its SPI bus, as well as with the original IT1504. Asking Elgato whether there was a known issue with these status LEDs didn’t lead to anything, so [Doug] decided to tackle the presumed source of the problem: the Nuvoton M031LD2AE MCU that’s supposed to drive the LED driver IC. The PCB helpfully provides a 4-pin JST connector on the board for the MCU’s SWD interface, but Elgato did protect the flash contents, so a straight dump wasn’t going to work.

The binary firmware is however helpfully available from Elgato, with the MCU already running the latest version. This is the point where [Doug] loaded the firmware into Ghidra to begin to understand what exactly this firmware was supposed to be doing. Putting on a fresh MCU with the correct firmware definitely worked, but debugging was hard as the new MCU also enabled protections, so in Ghidra the offending code for this was identified and neutralized, finally allowing for on-chip debugging and leading down another rabbit hole only to find an SPI flash chip at the end.

Ultimately it turned out that all the hardware was working fine. The problem ended up being that the LED patterns stored on the SPI EEPROM had become corrupted, which caused the Nuvoton MCU to skip over them. The same issue was confirmed on a second HD60 S, which makes it seem that this is a common issue with these Elgato capture devices. As a next step [Doug] hopes to figure out a way to more easily fix this issue, as even the streamlined process is still quite convoluted. Whether it is an issue with Elgato’s software or firmware (updater) is unknown at this point, but at least there seems to be a fix for now, even if Elgato support seems to just tell owners to ‘ignore it if capturing works’.

There’s nothing quite as inspirational as reading about a successful repair. If you need another shot of endorphins, check out the work [BuyItFixIt] put into a video baby monitor to bring it back online.