We’ve all had that sinking feeling as a piece of hardware stops responding and the nasty thought of “did I just brick this thing?” rockets to the front of our minds. [Florian Echtler] recently experienced this in extremis as his hacking on the University of Munich’s Microsoft Surface 2.0 left it unresponsive. He says this is an 8,000 Euro piece of hardware, which translates to around $10,000! Obviously it was his top priority to get the thing working again.
So what’s the first thing you should do if you get your hands on a piece of hardware like this? Try to run Linux on the thing, of course. And [Florian] managed to make that happen pretty easily (there’s a quick proof-of-concept video after the break). He took a Linux kernel drive written for a different purpose and altered it to interface with the MS Surface. After working out a few error message he packaged it and called to good. Some time later the department called him and asked if his Linux kernel work might have anything to do with the display being dead. Yikes.
He dug into the driver and found that a bug may have caused the firmware on the USB interface chip to be overwritten. The big problem being that they don’t just distribute the image for this chip. So he ended up having to dump what was left from the EEPROM and rebuild the header byte by byte.
Hats off to that guy :)
Also, spelling mistake (‘tail’ rather than ‘tale’) in the title.
M$ pobably designed it that way to fool guys who want to use a real OS on their hardware
dat cold chill
“linux may be the cause”
lame troubleshooting is lame.
I have to laugh at this one. A prime example of why I reserve desktop Linux for legacy hardware. If it fries your machine (and it does have the regrettable propensity to do just that), who cares?
If Linux fries your machine then your hardware is crap. You cannot rely on software to properly validate your input the same way you cannot rely on users to properly validate software’s input. Anyway, this is Microsoft branded so no wonder here.
If this hardware is this easily bricked, it deserves to be bricked.
Typical Microsoft engineering, I suspect just like all the little deliberate gottcha’s in ACPI.
Somehow I think the LambdaTable at the EVL was more robust.
It was working fine until he put linux on it. lol let go of the hate…
Any microcontroller with integrated program memory can be bricked by setting the wrong fuses (e.g. wrong clock source setting and code protection). Total control always means you can f*** up totally.
I visit this site more to lol its English failures than to read about the tech.
The comments are a good place to look, too.
ouch.
Im surprised they bave real firmware for EZ-ESB in the eprom, usually you just load it from host after USB enumeration.
So the “tail” was his “arse” being on the line if he didn’t fixed it??
I can’t make heads or tales of it.
“Hey, so do you think this might be to do with your Linux install?”
“No. I’m taking an early lunch.”
Grabs hat and runs for door, with his cape flying.
Somehow, I think a ‘bug’ (being a chip whose firmware can be overwritten without specific command) should be covered under Microsoft’s extensive support contract for these things.
‘Bricking’ – really?? What are you guys doing to the language?? Bricking used to mean catastrophic damage – turning the device into a brick or doorstop. I equate calling ‘whacking a couple of bytes of firmware’ bricking [sure someone was really nervous over their own destruction, but that has nothing to do with ‘bricked’ or ‘not bricked’] with being as inaccurate as what the newzz calls ‘hacking’.
6lz
Doesn’t work without fiddling with the contents of a EEPROM is “bricked” for most people…
Where have you been? We’ve referred to anything that requires one to, for example, hook up their device to a serial port to recover the device as “bricking” for a few years now. We’ve done so mostly because the new definition simply seems to be “to make unusable to the average and maybe intermediate user but not necessarily everyone”.
What’s bricked for you may be a small stumbling stone for me.