In early 2018, before I had children and with much, MUCH more free time, I bought a used X61, plus a used X60 1400x1050 LCD, a new backlight, new internal stereo speakers, a new mainboard with an Intel Core i7-5600U from 51NB, plus new SSD, 32 GB RAM, and the original IBM logo of a X60 which was replaced by a Lenovo logo on my chassis. It's the exact same setup as mentioned here [0], except that I built it myself from the individual parts for cost reasons.
The board arrived from Shenzhen after a month or so. I then had to manually fit (including drilling away some parts) the X60 LCD into the X61 chassis, which was extremely stressful. But in the end it all worked out perfectly. This X62 has been my private machine for 8 years now, and I always travel with it. The display still works perfectly, the 32 GB RAM are still more than enough, and it is still very easy to get X61 replacement batteries on Amazon. But the best thing is the form factor; this thing is just so neat and small and practical. Also the quality of the chassis is incredible. Apart from many, many scratches on the lid, it is still in flawless condition.
I still use an X60 Tablet for travel, mostly as a terminal for the machines at home. Original CPU is good enough for VNC+Wireguard. AFAIK, there aren't any CPU/MB upgrades for X60/61 Tablet. I still like it because of the 4:3 screen.
I upgraded the screen to the 1400x1050 with a new display panel from china, but I had to cut the front screen protector and remove the "oil". It seems a little bit darker without that liquid inside and dust particles entered in that space. I couldn't find any LCD upgrade for the CCFL lamp at that time and now I'm not sure it's worth the effort.
I'd love to see a working coreboot for X60/61 Tablets that can still boot DOS and WinXP.
I had a ThinkPad X61T for a while, and assembled a full set of accessories for it, but it ran hot, and I never managed to get Wacom EMR stylus support in Mac OS working (bought it to be a Hackintosh).
I really wish that there was an updated ThinkPad which supported the current generation of styluses (was looking at an x230T until I got my Samsung Galaxy Book 12 and Staedtler Noris Digital Stylus).
I had a T420s which is a bit smaller than the T430 and I really loved this thing. Did my whole scholarship with it, even bought a second hand to have as a fail-safe. Really nice machine for its time
"Vibe reverse engineering" yep, was talking with a designer friend just yesterday who vibe coded a driver for his unsupported Wacom. He's not a developer but his pen tablet now works. It seems quite useful and efficient for this kind of work with a well established process (plug, get connectivity, do something, get data, do something else, get other data, transform that data (e.g. 0..1 mapped to a well defined resolution), validate) ideally over standards e.g. USB or BT capabilities.
Best of all he even published on Github the result so that, hopefully, others benefit from his effort without even having to do it again.
100% believe this one. The good thing about Wacom devices is that they're actually quite simple to deal with. All of the Wacom devices use a simple packet-based format that, while it varies per model, is quite well documented, what with being in the Linux kernel and several user mode tablet drivers (including OpenTabletDriver and TabletMagic.) You really don't need reverse engineering for Wacom, from old serial Graphires to the latest Intuous'. The knowledge, or at least certainly knowledge of where to look, should be baked into any frontier model.
When I was in college I had an ARM Chromebook which didn't have the Wacom driver, so I wound up trying to use the then-new Chrome USB APIs to make myself a tablet driver in a Chrome extension. This was long before LLM coding was a thing, but thanks to the Linux wacom.ko it wasn't really an obstacle.
The biggest problem I had was that while I was decoding digitizer inputs just fine I had nowhere to put them. I tried making a simple painting app in JS and it worked but without having native cursor movement it was just too jank and I gave up.
I eventually uploaded the code for posterity sake. I doubt it works at all anymore, even with the specific tablet it was hard-coded for. But it's still online, anyhow.
I'm speaking on behalf of my friend. I don't want to misconstrue his message. Even though not a developer himself he is familiar to the command line and can for example manager backend stuff like containers. In that sense he's not a random computer user. He also dared to try. If he writes a blob about his attempt I'll share it back here.
My point was to share a related anecdote on using LLM to making seemingly unusable hardware usable again, which seems feasible (hence sharing the anecdote to confirm from another source) and IMHO a positive use case, while so many others are not necessarily so.
This is really, really cool. I wonder, by extension, if it's feasible to reverse engineer all the various low-level firmware blobs too and have it hosted on LVFS so users can update it via fwupd (not sure if LVFS would be willing to host such firmware though).
But I would really like to see this trend take off, so we can take back control over smart devices and see more FOSS firmware pushed out to various devices (OpenWRT etc).
I may have tried this exact thing a few years ago without LLMs, though I can no longer remember if it was a ThinkPad X61 or not. I just know it was an Intel ICH that wasn't supported by Coreboot and wasn't documented at all. I tried for quite a while and getting it to output anything to the serial port was very exciting for me, but at that point I definitely hit a wall: the RAM initialization and other platform init was a complete mystery and the only way I was going to learn about it was by reverse engineering the BIOS, since it wasn't documented. Ultimately I just never found the time to get to it, so it never happened, which still to this day feels like a shame.
What a mixed blessing it is now that theoretically, especially as LLMs increase in competence, an idiot like me might actually be able to port Coreboot to an unsupported platform with some LLM-assisted reverse engineering. I mean, it's probably still a long shot without as much arcane knowledge as you gain from working in stuff like this professionally, but at this point it's probably the best shot I have since I probably won't find myself in such a scenario.
I guess I should try to find time to revisit a reverse engineering project that I haven't had time to dig deep into... It does feel like a shame that this way I'll never really improve my skills related to reversing, though.
I have an x61 myself, bought it last year to add to my Thinkpad collection. I haven't done much besides put in some real to verify it actually works. And suggestions on an OS?
antiX linux v26 might be of interest. I have the 32 bit version with the older Linux kernel (5.18.x I recollect) on a live usb. No mysterious graphics freezes.
The more straight forward (and 64 bit) candidate would be Slackware 15.0 with a few of Alien Bob's slackbuilds.
But, of course, the retro computing approach mentioned by another poster would look really nice and be a conversation piece.
most linux/bsd you can throw at it would just work fine. i personally like tinycore linux and porteus linux, they unpack the rootfs to ram so overall interaction with the system feels insanely quick on very underpowered systems with HDDs.
It's also quite nice w/ a stylus, and Win2K was absolutely my favourite OS despite lacking explicit stylus support (as Windows XP Tablet PC Edition had) --- just need a 3rd party note-taking tool w/ stylus support and HWR.
I never got into HWR. I already type faster than I write with a pen. Waiting for it to convert my scribbles to text, even if it gets it right first time, is just a painfully slow process even on an ipad pro. I'd rather just use a touchscreen keyboard to write
It's nice for when one wants to slow down and think, or if one needs to take notes --- back when I was in college, while professors would often object to laptops, no one complained of my using a tablet and stylus --- also allowed for sketches/diagrams which I found helpful/useful.
AFAIK the later Thinkpads including this one uses a Phoenix BIOS, so it's amusing to see the circularity of how things turned out; and continuing on that path, Phoenix sold its BIOS business to Lenovo a little earlier this year.
Yeah, it's pretty cut and dry. Constitutionally, only the federal government is allowed to regulate intellectual property, so re-implementing anything that isn't protected by a trademark, copyright, or patent is fair game, and trademarks don't cover design, copyright only covers media, and patents expire in 20 tears.
Even the clean-room isolation that Phoenix went through isn't legally required, it just makes nuisance lawsuits more difficult. BSD prevailed over UNIX System Laboratories, in their reimplementation of Unix, despite having directly worked with the source code.
> Constitutionally, only the federal government is allowed to regulate intellectual property
It turns out that's not exactly the case! See, e.g., Goldstein v. California, 412 U.S. 546 (1973). Before 1978, state (often common law) copyright used to cover a lot of pre-publication works, and until 2018 (when the federal law was amended) state copyright law covered pre-1972 sound recordings, and state copyright still covers obscure things like post-mortem moral rights in visual art or rights to "unfixed" works. See 1 Nimmer on Copyright §§ A.02 & 2.02. Other forms of intellectual property (trade secrets, rights of publicity) remain mostly creatures of state law, and some states also have trademark systems.
As with many things, this is a case of "it depends" - How you do it and for what reason, primarily. If you're reverse engineering code that's part of a DRM scheme for example, that's explicitly not allowed.
Coreboot is debatable for this, it's fine in the sense that nobody is going to come after you for it, but legally you're not doing a clean room implementation, you're looking at the original and creating a new functional replacement, which is fundamentally different to the Phoenix BIOS clone, and not in a good way.
But as I said, nobody is going to come after you for it so...
> but legally you're not doing a clean room implementation, you're looking at the original and creating a new functional replacement
Interesting legal question: if Claude reverse engineers the original and writes a spec, and ChatGPT implements the spec without seeing the original, is that a clean-room implementation? Asking for a friend with a trillion parameters
On my todo, i still have the pet project to make a simple libusb c project to control its gpios. The documentation id not very clear, and implémentations scarce. Now with LLMs i could make some progress.
You can get much more modern hardware with firmware. This was mostly an expirement to see how good LLM are at reverse engineering. Given that it went well I think making fully free (without Intel) x86-side firmware is possible.
IANAL but on a technical level I'd say it's clean room and not subject to the original copyright for at least 2 reasons: the LLM for sure hasn't seen init code for this platform before, and there is no leak on the internet. It hallucinated register semantics often, suggesting it hasn't seen the original code. Also, coreboot code looks and, to some extent, works differently than the vendor reference code that I have seen for other platforms, making it not subject to any copyright claims.
Lastly no copyright claim can be made on LLM generated works, but given the non-negligible human effort put into this, I'm not sure what the upshot is here. Still non copyrightable does not mean it's not free, it's something like public domain.
Companies put a ton of work into proprietary RAM training algorithms that I think would be hard to replicate. I know AMD has open sourced their older pre-Zen BIOS and that has made its way into coreboot, but Zen1+ is all proprietary.
awesome! hopefully T61 can also get some support soon..
these machines are amazing, but sadly they're showing signs of age these days. mine's already kinda unusable due to dim CCFL backlight and fan grinding noise.
thanks. i just checked and it seems like i was mistaken, the one i own now is a t60 not a t61. seems like it's already supported, gotta try installing coreboot on it.
>"...tools like SerialICE which runs the firmware in QEMU and forwards IO and MMIO to the actual hardware..."
I never knew about SerialICE prior to reading this article, or that it could forward IO/MMIO to actual hardware (i.e., act as a proxy)... In the past I was curious if a debugging tool like that could exist, and apparently, yes it can!
In early 2018, before I had children and with much, MUCH more free time, I bought a used X61, plus a used X60 1400x1050 LCD, a new backlight, new internal stereo speakers, a new mainboard with an Intel Core i7-5600U from 51NB, plus new SSD, 32 GB RAM, and the original IBM logo of a X60 which was replaced by a Lenovo logo on my chassis. It's the exact same setup as mentioned here [0], except that I built it myself from the individual parts for cost reasons.
The board arrived from Shenzhen after a month or so. I then had to manually fit (including drilling away some parts) the X60 LCD into the X61 chassis, which was extremely stressful. But in the end it all worked out perfectly. This X62 has been my private machine for 8 years now, and I always travel with it. The display still works perfectly, the 32 GB RAM are still more than enough, and it is still very easy to get X61 replacement batteries on Amazon. But the best thing is the form factor; this thing is just so neat and small and practical. Also the quality of the chassis is incredible. Apart from many, many scratches on the lid, it is still in flawless condition.
[0] https://geoff.greer.fm/2017/07/16/thinkpad-x62/
I still use an X60 Tablet for travel, mostly as a terminal for the machines at home. Original CPU is good enough for VNC+Wireguard. AFAIK, there aren't any CPU/MB upgrades for X60/61 Tablet. I still like it because of the 4:3 screen.
I upgraded the screen to the 1400x1050 with a new display panel from china, but I had to cut the front screen protector and remove the "oil". It seems a little bit darker without that liquid inside and dust particles entered in that space. I couldn't find any LCD upgrade for the CCFL lamp at that time and now I'm not sure it's worth the effort.
I'd love to see a working coreboot for X60/61 Tablets that can still boot DOS and WinXP.
I had a ThinkPad X61T for a while, and assembled a full set of accessories for it, but it ran hot, and I never managed to get Wacom EMR stylus support in Mac OS working (bought it to be a Hackintosh).
I really wish that there was an updated ThinkPad which supported the current generation of styluses (was looking at an x230T until I got my Samsung Galaxy Book 12 and Staedtler Noris Digital Stylus).
I have three of those setups I’m finally building …less!!1 than a decade later. Very hopeful those rare displays still work
Reminds me of my X230. Nowadays, I only use it for CAN-Bus related work on my car, but it is so small, yet so well build.
That's kind of like my T430: https://danangell.com/blog/posts/my-t430/
I wish it could go up to 32GB though. And the i7 in there shows its age. But it's still usable with modern software!
I had a T420s which is a bit smaller than the T430 and I really loved this thing. Did my whole scholarship with it, even bought a second hand to have as a fail-safe. Really nice machine for its time
"Vibe reverse engineering" yep, was talking with a designer friend just yesterday who vibe coded a driver for his unsupported Wacom. He's not a developer but his pen tablet now works. It seems quite useful and efficient for this kind of work with a well established process (plug, get connectivity, do something, get data, do something else, get other data, transform that data (e.g. 0..1 mapped to a well defined resolution), validate) ideally over standards e.g. USB or BT capabilities.
Best of all he even published on Github the result so that, hopefully, others benefit from his effort without even having to do it again.
100% believe this one. The good thing about Wacom devices is that they're actually quite simple to deal with. All of the Wacom devices use a simple packet-based format that, while it varies per model, is quite well documented, what with being in the Linux kernel and several user mode tablet drivers (including OpenTabletDriver and TabletMagic.) You really don't need reverse engineering for Wacom, from old serial Graphires to the latest Intuous'. The knowledge, or at least certainly knowledge of where to look, should be baked into any frontier model.
When I was in college I had an ARM Chromebook which didn't have the Wacom driver, so I wound up trying to use the then-new Chrome USB APIs to make myself a tablet driver in a Chrome extension. This was long before LLM coding was a thing, but thanks to the Linux wacom.ko it wasn't really an obstacle.
The biggest problem I had was that while I was decoding digitizer inputs just fine I had nowhere to put them. I tried making a simple painting app in JS and it worked but without having native cursor movement it was just too jank and I gave up.
I eventually uploaded the code for posterity sake. I doubt it works at all anymore, even with the specific tablet it was hard-coded for. But it's still online, anyhow.
https://github.com/jchv/crwacom
Neat, thanks for explaining and sharing the code too!
The author explained that the LLM needed a lot of hand-holding and that it was only possible because he himself is already an expert at it.
Quite a different message than yours.
I'm speaking on behalf of my friend. I don't want to misconstrue his message. Even though not a developer himself he is familiar to the command line and can for example manager backend stuff like containers. In that sense he's not a random computer user. He also dared to try. If he writes a blob about his attempt I'll share it back here.
My point was to share a related anecdote on using LLM to making seemingly unusable hardware usable again, which seems feasible (hence sharing the anecdote to confirm from another source) and IMHO a positive use case, while so many others are not necessarily so.
Why not just use TabletMagic?
No idea, sending him the link I'll see what he says about it, thanks!
This is really, really cool. I wonder, by extension, if it's feasible to reverse engineer all the various low-level firmware blobs too and have it hosted on LVFS so users can update it via fwupd (not sure if LVFS would be willing to host such firmware though).
But I would really like to see this trend take off, so we can take back control over smart devices and see more FOSS firmware pushed out to various devices (OpenWRT etc).
I may have tried this exact thing a few years ago without LLMs, though I can no longer remember if it was a ThinkPad X61 or not. I just know it was an Intel ICH that wasn't supported by Coreboot and wasn't documented at all. I tried for quite a while and getting it to output anything to the serial port was very exciting for me, but at that point I definitely hit a wall: the RAM initialization and other platform init was a complete mystery and the only way I was going to learn about it was by reverse engineering the BIOS, since it wasn't documented. Ultimately I just never found the time to get to it, so it never happened, which still to this day feels like a shame.
What a mixed blessing it is now that theoretically, especially as LLMs increase in competence, an idiot like me might actually be able to port Coreboot to an unsupported platform with some LLM-assisted reverse engineering. I mean, it's probably still a long shot without as much arcane knowledge as you gain from working in stuff like this professionally, but at this point it's probably the best shot I have since I probably won't find myself in such a scenario.
I guess I should try to find time to revisit a reverse engineering project that I haven't had time to dig deep into... It does feel like a shame that this way I'll never really improve my skills related to reversing, though.
I have an x61 myself, bought it last year to add to my Thinkpad collection. I haven't done much besides put in some real to verify it actually works. And suggestions on an OS?
antiX linux v26 might be of interest. I have the 32 bit version with the older Linux kernel (5.18.x I recollect) on a live usb. No mysterious graphics freezes.
The more straight forward (and 64 bit) candidate would be Slackware 15.0 with a few of Alien Bob's slackbuilds.
But, of course, the retro computing approach mentioned by another poster would look really nice and be a conversation piece.
most linux/bsd you can throw at it would just work fine. i personally like tinycore linux and porteus linux, they unpack the rootfs to ram so overall interaction with the system feels insanely quick on very underpowered systems with HDDs.
(stupid typo - it was meant to be put in some RAM to verify it actually works)
Windows 98SE.
Port any drivers you need with AI.
Only half-serious...
everything except graphics driver would probably actually work with 98SE..
Win2000 or WinXP would be a better choice due to numerous reasons though. Win2K with an SSD is absolutely going to fly on that thing.
It's also quite nice w/ a stylus, and Win2K was absolutely my favourite OS despite lacking explicit stylus support (as Windows XP Tablet PC Edition had) --- just need a 3rd party note-taking tool w/ stylus support and HWR.
I never got into HWR. I already type faster than I write with a pen. Waiting for it to convert my scribbles to text, even if it gets it right first time, is just a painfully slow process even on an ipad pro. I'd rather just use a touchscreen keyboard to write
It's nice for when one wants to slow down and think, or if one needs to take notes --- back when I was in college, while professors would often object to laptops, no one complained of my using a tablet and stylus --- also allowed for sketches/diagrams which I found helpful/useful.
I miss XP sometimes
Sure, USA citizens are not allowed to reverse engineer
...yes we are? After all, that's how the whole IBM PC-compatible industry started.
https://en.wikipedia.org/wiki/Phoenix_Technologies#Cloning_t...
AFAIK the later Thinkpads including this one uses a Phoenix BIOS, so it's amusing to see the circularity of how things turned out; and continuing on that path, Phoenix sold its BIOS business to Lenovo a little earlier this year.
Yeah, it's pretty cut and dry. Constitutionally, only the federal government is allowed to regulate intellectual property, so re-implementing anything that isn't protected by a trademark, copyright, or patent is fair game, and trademarks don't cover design, copyright only covers media, and patents expire in 20 tears.
Even the clean-room isolation that Phoenix went through isn't legally required, it just makes nuisance lawsuits more difficult. BSD prevailed over UNIX System Laboratories, in their reimplementation of Unix, despite having directly worked with the source code.
> Constitutionally, only the federal government is allowed to regulate intellectual property
It turns out that's not exactly the case! See, e.g., Goldstein v. California, 412 U.S. 546 (1973). Before 1978, state (often common law) copyright used to cover a lot of pre-publication works, and until 2018 (when the federal law was amended) state copyright law covered pre-1972 sound recordings, and state copyright still covers obscure things like post-mortem moral rights in visual art or rights to "unfixed" works. See 1 Nimmer on Copyright §§ A.02 & 2.02. Other forms of intellectual property (trade secrets, rights of publicity) remain mostly creatures of state law, and some states also have trademark systems.
As with many things, this is a case of "it depends" - How you do it and for what reason, primarily. If you're reverse engineering code that's part of a DRM scheme for example, that's explicitly not allowed.
Coreboot is debatable for this, it's fine in the sense that nobody is going to come after you for it, but legally you're not doing a clean room implementation, you're looking at the original and creating a new functional replacement, which is fundamentally different to the Phoenix BIOS clone, and not in a good way.
But as I said, nobody is going to come after you for it so...
> but legally you're not doing a clean room implementation, you're looking at the original and creating a new functional replacement
Interesting legal question: if Claude reverse engineers the original and writes a spec, and ChatGPT implements the spec without seeing the original, is that a clean-room implementation? Asking for a friend with a trillion parameters
Ch341a to the rescue.
On my todo, i still have the pet project to make a simple libusb c project to control its gpios. The documentation id not very clear, and implémentations scarce. Now with LLMs i could make some progress.
Kudos for getting this done!
Sad that free BIOSes are so far behind modern hardware, but this is very necessary work.
You can get much more modern hardware with firmware. This was mostly an expirement to see how good LLM are at reverse engineering. Given that it went well I think making fully free (without Intel) x86-side firmware is possible.
>Fully free
[The following question is only valid if you meant "free" as in "GPL/BSD"]
Is it completely clear that LLM code is considered "clean room" and won't leak copyrighted code?
IANAL but on a technical level I'd say it's clean room and not subject to the original copyright for at least 2 reasons: the LLM for sure hasn't seen init code for this platform before, and there is no leak on the internet. It hallucinated register semantics often, suggesting it hasn't seen the original code. Also, coreboot code looks and, to some extent, works differently than the vendor reference code that I have seen for other platforms, making it not subject to any copyright claims. Lastly no copyright claim can be made on LLM generated works, but given the non-negligible human effort put into this, I'm not sure what the upshot is here. Still non copyrightable does not mean it's not free, it's something like public domain.
Companies put a ton of work into proprietary RAM training algorithms that I think would be hard to replicate. I know AMD has open sourced their older pre-Zen BIOS and that has made its way into coreboot, but Zen1+ is all proprietary.
Most are using synopsys IP I think, so they don't really have a say in it.
i don't think it's really "far behind", it just can't run on hardwares that require manufacturer keys (e.g. intel bootguard)
afaik all modern x86 chromebooks ship with coreboot based firmware
Last time I bought a chromebook it was horribly locked down, I couldn't even install my own OS. Has that changed?
Not at all. If you're lucky you can (after some fiddling) install a real coreboot, this site is incredibly helpful for that: https://docs.mrchromebox.tech/docs/getting-started.html
awesome! hopefully T61 can also get some support soon..
these machines are amazing, but sadly they're showing signs of age these days. mine's already kinda unusable due to dim CCFL backlight and fan grinding noise.
Author of that blog article here. I could probably do a port if you're willing to test and provide some dumps while running the vendor firmware.
thanks. i just checked and it seems like i was mistaken, the one i own now is a t60 not a t61. seems like it's already supported, gotta try installing coreboot on it.
I have that problem too of buying many old laptops... I had an ASUS Eee PC phase and I bought 6 of them (3 different models and replacement parts).
>"...tools like SerialICE which runs the firmware in QEMU and forwards IO and MMIO to the actual hardware..."
I never knew about SerialICE prior to reading this article, or that it could forward IO/MMIO to actual hardware (i.e., act as a proxy)... In the past I was curious if a debugging tool like that could exist, and apparently, yes it can!
Anyway, great article!
Related:
https://www.serialice.com/index.html
https://github.com/coreboot/serialice
Unrelated, the Emacs-based design of the website is quite nice.
The blog is made with hugo and you can find the theme at https://github.com/ArthurHeymans/hugo-emacs-theme if you're interested
just 7-8 thinkpads is not an addiction :)
Ok