In June 2022 I heard from Horst who had been passed a t5525. After playing with it for a while he came across this website and sent me this assessment of the t5525.
The capacitors on the board are high-quality polymer capacitors of the Sanyo OSCON type in my unit; I expect this to be similar in other models. As such, the capacitors are likely to last an obscene amount of time; they're also over-specified for what is strictly required for ensuring good power regulation. This means even the cheapest 12V brick, as long as it is correctly polarised and putting out a solid 12V at 1.6A, will be sufficient to run the device. I would of course recommend a minimum 2A supply, just to ensure there is not a sag under load as is sometimes seen with cheaper switchmode bricks.
The storage on the board is laughable, as you've noted: I replaced the internal 256MB ATA flash module (manufactured by Apacer in my case) with a 16GB 'HyperDisk' DoM that is allegedly industrial-grade. The BIOS recognises it fully, and such HyperDisk modules are available up to 64GB. I have seen no evidence that the BIOS would be incapable of addressing a 64GB device, so having verified that a new DoM that is electrically compatible functions, I think that provides a sensible upper bound on how we may be confident that storage can be upgraded.
The use of the DoM did require case modification to achieve - the small cutout I made to facilitate this did not increase any emissions that I have the ability to test.
The thermal engineering of the t5520 is simply excellent. The heatsink has more than adequate thermal mass to effectively cool the Eden 800 and the southbridge chip. The heatsink is stuck to these two chips with a thin layer of thermal adhesive which required a little force to break; it is also screwed to the metal chassis by two screws that connect to a smaller heat-transfer assembly.
The interface between the heat-transfer and the case is made with some sort of impregnated fiberglass tape, like a thermal pad but thinner. I have replaced all of the tape interfaces with Noctua NT-H1 after cleaning, to provide a little extra reliability in the long term.
The larger thermal pads present have (reasonably, after 15 years) broken down into a chalky compound which I do not have much faith in; these I have replaced with new thermal pad material to again ensure reliability. While I have no reason to believe any part of the system will become especially hot in normal usage, I would rather be safe than sorry.
I would also remark that the Eden may be able to be overclocked, to a 6.5 or 7 multiplier, but given contemporary data about the performance of the C3 architecture, I do not expect that any useful performance gain would be had.
The RAM of this board is again, anaemic; even in 2006 the amount of RAM provided was underwhelming. Looking at the board, I suspect that it would be possible to replace the DDR DRAM ICs with higher-density ones, to potentially bring it to 256MB RAM - I haven't tested this yet. It may also be possible to push to 512MB, but I do not know off the top of my head if chips were available to support 512x8 across 4 DRAM ICs. This note is important due to software considerations.
FreeBSD 10.1 boots from USB on the t5520. I expect it will also install just fine. I have not yet tested a more recent version of FreeBSD, however the documentation still remarks that a FreeBSD system may function within 64MB of RAM if sufficiently tuned.
PC-DOS of course works fine, as does FreeDOS, as will MS-DOS, as (likely) would X-DOS.
The system certainly has enough grunt to run Windows 3.1, and with the "generic" vesa drivers more recently developed, it might even do so impressively. Windows 98SE is probably where it's at for the amount of RAM and the speed of the CPU; I haven't tested this configuration.
Linux support is ... interesting. No modern Linux live media boots that I have been able to find. I have tested :
As such, we can see that it is not necessarily the modern linux kernel that causes issues, at least.
I suspect that upgrading to 256MB of RAM might provide sufficient "breathing room" to overcome this hurdle. The BIOS would support it, and there is no reason in hardware that the board wouldn't handle such an upgrade.
Whilst it took some work, I now have a modern Linux running. Using a faster machine (with considerably more memory) to compile packages, I have Gentoo Linux running on the t5525. Trying to compile basically anything using portage results in an out-of-memory process kill, so it's a laughable choice of distribution, if only you think about it for a moment. However, the installed system uses only 19MB of RAM with four mingetty instances, the OpenSSH sshd, and a bash login shell.
I don't believe any production Linux distribution has live media capable of booting with so little RAM, so it will fall to someone who wants to replicate my efforts to make their own. I ended up partitioning a 4GB USB flash drive with a 20MB ext2 /boot, and the remainder as an ext4 root partition. This was sufficient to fit a slimmed-down kernel, the GRUB bootloader, and a relatively complete command-line only linux install with such favourites as: irssi, tmux, weechat, vim, and - just in case - a webserver package, nginx.
This install was copied directly on to the 16GB DoM, partitioned with a more generous 64MB ext2 /boot and the remainder as ext4 once more. I don't think a graphical interface is necessarily in this machine's future, but iceWM, fluxbox, and JWM may be suitable if someone else wants to traverse that path.
Just a few comments from me - things that came to mind as I read his article.
FYI In the early 2000s there was an issue ('Capacitor Plague') with the decoupling electrolytic capacitors used on the power lines in some thin clients - rumour (and it is only Internet rumour and so almost certainly untrue) had it that a far eastern manufacturer ripped off a competitor's design but somehow managed to miss out an essential ingredient. The net result was that after a few years or more they would fail.
Ignoring the cause, the fact is that a number of poor quality electrolytic capacitors were used in thin clients of that era and suffered from premature failure. You could see which ones had failed as they were the ones that had swelled up and had the bulging bottoms.
This was particularly evident with Neoware thin clients tho' other suppliers also suffered from it.
'Dead' thin clients from that era could often be revived by swapping out the decoupling capacitors.
(Just thought I'd mention it. From Horst's comments it obviously does not apply to the t5525).
It has been a while since I did anything with an old thin client fitted with minimal RAM. The last time I looked at this - a thin client with only 64MB of RAM - where things failed at was step 1 when they were trying to expand the kernel. The kernel (and supporting RAM disk) are compressed to save space. The first thing that happens when control is passed to the loaded kernel is that it has to expand itself. i.e. You need enough RAM to hold the compressed kernel and also the space to expand it into. In these circumstances there may well be a benefit in running with a larger (uncompressed) kernel and putting up with a slightly longer load time. I never explored this.
Not forgetting of course that building a specific t5520 kernel would allow you to only include the specific drivers required by the hardware and so reducing the size of the kernel.
As reported elsewhere I find that Tiny Core Linux in its current version (13.1) still manages to run on the t5520.