Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I debugged a boot issue on the Apple Newton this way. The latest flash image was a brick on production hardware (no available LEDs, GPIOs, etc.) but not on development hardware. But I could flash a new OS image.

So I wrote some small loops that did different stuff on the bus (so that they sounded different) and salted the boot path with them, then listened in on my portable AM radio. Found the problem inside of an hour by moving the loops further down the path.

There were probably other ways to do this (could have coaxed a hardware tech in the lab to solder in a GPIO), but this way was more fun. :-)



Reminds me of the CHDK hackers trying to dump firmware off a Canon camera. They could get the altered firmware to activate and could read memory and control an LED, so... they blinked the firmware out through the LED, and read it with a ball mouse's optical sensor attached to a microphone cord. :-)


I half-remember reading that someone dumped the firmware of an older iPod by listening to hard disk noises.

Thinking back this doesn't make much sense.

EDIT: I was maybe ⅓ right https://web.archive.org/web/20070613032334/http://www.ipodli...


meanwhile on the web: "The undefined variable foo on line 13 is not a function"


To a non-hardware guy this sounds like strange witchcraft. Very cool.


Thats probably the most commitment I've ever seen for fixing a bug like that

Thats awesome


What was the problem?


IIRC it was some improperly guarded code that was intended to run only on the non-production development systems (some debugging support). The kernel would touch a non-existent h/w register and trap, which was fatal. Removing the code was the fix.


Logging by sound? I love it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: