Hacker News: dougg3

New comment by dougg3 in "Debugging BeagleBoard USB boot with a sniffer: fixing omap_loader on modern PCs"

dougg3 — Sun, 09 Nov 2025 18:27:28 +0000

Very cool that you worked on the OMAP3 and BeagleBoard! I didn't ask anybody else about it. I just decided to tinker with my USB sniffer to try to get to the bottom of what was going on.

I'm still a little puzzled about why the 2 second retry doesn't work. It might be worth diving in deeper to figure out why the data received during the retry never makes its way back to libusb. It's a bit of an edge case, but it seems like it could potentially be a bug. I might consider bringing that up as a question on the linux-usb list.

New comment by dougg3 in "Debugging BeagleBoard USB boot with a sniffer: fixing omap_loader on modern PCs"

dougg3 — Sun, 09 Nov 2025 18:22:07 +0000

That's a really excellent point. I will do that!

New comment by dougg3 in "Modifying an HDMI dummy plug's EDID using a Raspberry Pi"

dougg3 — Sun, 15 Jun 2025 17:53:46 +0000

Thank you! Hopefully it works for you.

I guess I should reword the way I said something in the previous message: when I said "it can force the monitor to always be detected", I really should have said "it forces the monitor to always be detected".

New comment by dougg3 in "Modifying an HDMI dummy plug's EDID using a Raspberry Pi"

dougg3 — Sun, 15 Jun 2025 17:31:43 +0000

Yeah, if you are 100% confident you're using your GPU's I2C controller it's probably fine, but the reason I warned about it repeatedly in the post was because I stumbled upon this GitHub issue where two people accidentally flashed their RAM SPD:

https://github.com/bulletmark/edid-rw/issues/5

New comment by dougg3 in "Modifying an HDMI dummy plug's EDID using a Raspberry Pi"

dougg3 — Sun, 15 Jun 2025 17:15:40 +0000

I also have a couple of passthroughs -- I probably should have mentioned them in the post as another option. The one I have is fancy -- it can read the EDID from a monitor, save it, and use it as an override for another monitor.

Another awesome thing is it can force the monitor to always be detected. One of my monitors virtually unplugs itself when I shut it off, which causes a bunch of issues for me, and the passthrough completely solved it. The one I use is the HD-EWB by THWT.

New comment by dougg3 in "Apple's long-lost hidden recovery partition from 1994 has been found"

dougg3 — Sun, 16 Mar 2025 18:16:45 +0000

That’s what that was? I noticed it while looking through the Apple HD SC Setup code and assumed it had something to do with A/UX, but had no idea. Good to know!

New comment by dougg3 in "Gooey rubber that's slowly ruining old hard drives"

dougg3 — Mon, 03 Mar 2025 05:09:01 +0000

Another option, if you can’t find a card, is a ZuluSCSI or BlueSCSI V2 in initiator mode to image the drive to an SD card. It’s pretty nifty! I’ve recently even been using ZuluSCSI as a USB-SCSI bridge with USB MSC initiator mode.

New comment by dougg3 in "Gooey rubber that's slowly ruining old hard drives"

dougg3 — Mon, 03 Mar 2025 00:34:42 +0000

There are indeed some aluminum electrolytics hiding on Quantum drives. They look sneakily like tantalum caps, but they're just cans hiding inside a plastic cover. Here's one where I accidentally broke the cover, revealing what's underneath:

https://i.imgur.com/LdjUx3v.jpeg

New comment by dougg3 in "An invalid 68030 instruction accidentally allowed the Mac Classic II to boot"

dougg3 — Sun, 26 Jan 2025 21:05:11 +0000

It also appears that I may not have been the first one to discover that something odd was going on with that bit, causing it to use A0-A7 (with weird results) instead of D0-D7:

https://eab.abime.net/showthread.php?t=119675

New comment by dougg3 in "An invalid 68030 instruction accidentally allowed the Mac Classic II to boot"

dougg3 — Sun, 26 Jan 2025 19:56:30 +0000

Don't you think, as a Mac ROM developer, the chances of your software bug being accidentally fixed by the CPU through an undocumented instruction are pretty low? That's what I was getting at when I wrote that.

Of course they would have fixed it if it had prevented the system from booting, I even said that in the article. I still think the odds of what happened here were pretty small. That's what I meant by miraculous.

New comment by dougg3 in "An invalid 68030 instruction accidentally allowed the Mac Classic II to boot"

dougg3 — Sun, 26 Jan 2025 11:22:11 +0000

I’ve been trying it out a bunch lately. From what I’ve seen, machines with Egret don’t have it enabled by default, but machines with the newer Cuda do.

New comment by dougg3 in "An invalid 68030 instruction accidentally allowed the Mac Classic II to boot"

dougg3 — Sun, 26 Jan 2025 06:12:08 +0000

My test of an 040 (no A1 change, D1 changed) was on a chip with the following markings:

XC68LC040RC25B

02E23G QEDP9348D MALAYSIA

New comment by dougg3 in "An invalid 68030 instruction accidentally allowed the Mac Classic II to boot"

dougg3 — Sun, 26 Jan 2025 02:56:44 +0000

Thank you! Yes, I will definitely make another post if and when someone figures out what the instruction does.

New comment by dougg3 in "An invalid 68030 instruction accidentally allowed the Mac Classic II to boot"

dougg3 — Sat, 25 Jan 2025 22:14:43 +0000

On the 040, it seems to do something that actually involves D1. Definitely doesn't touch A1 at all. I didn't test further, but it's possible it just handles the instruction as a normal CAS.

It did cause a system error the first time I stepped through the instruction with MacsBug on my LC 475, but then it was fine after that.

New comment by dougg3 in "An invalid 68030 instruction accidentally allowed the Mac Classic II to boot"

dougg3 — Sat, 25 Jan 2025 22:04:54 +0000

Author here. Yeah, I have a tendency to go into pretty big deep dives when I find stuff like this. It's so rewarding at the end, even if it does take a lot of time!

New comment by dougg3 in "Why is my CPU usage always 100%?"

dougg3 — Tue, 14 Jan 2025 05:26:08 +0000

Ha! Guilty as charged. I have a coworker who's probably very disappointed in me right now!

New comment by dougg3 in "Why is my CPU usage always 100%?"

dougg3 — Mon, 13 Jan 2025 19:43:19 +0000

To be fair, other non-cosmetic stuff uses the CPU percentage. This same bug was preventing fast user suspend on the OLPC until they worked around it. It was also a fun challenge.

New comment by dougg3 in "Why is my CPU usage always 100%?"

dougg3 — Mon, 13 Jan 2025 15:09:50 +0000

Author here. Thanks! I believe the register reads are just extending the delay, although the new approach does have a side effect of reading from the hardware multiple times. I don't think the multiple reads really matter though.

I went with the multiple reads because that's what Marvell's own kernel fork does. My reasoning was that people have been using their fork, not only on the PXA168, but on the newer PXAxxxx series, so it would be best to retain Marvell's approach. I could have just increased the delay loop, but I didn't have any way of knowing if the delay I chose would be correct on newer PXAxxx models as well, like the chip used in the OLPC. Really wish they had more/better documentation!

New comment by dougg3 in "Fixing an Elgato HD60 S HDMI capture device with the help of Ghidra"

dougg3 — Wed, 18 Sep 2024 01:26:48 +0000

Thanks! I wouldn't want to write it any other way. I think it helps convey just how much work it really was.

New comment by dougg3 in "Fixing an Elgato HD60 S HDMI capture device with the help of Ghidra"

dougg3 — Tue, 17 Sep 2024 13:59:33 +0000

I'm the author of this article and you're absolutely correct! This was a long, drawn-out project. For some context, I ordered the replacement regulators in February. The new LED driver chips were ordered in March, so that was around the time that I actually had the failed hardware fixed. Then everything sat idle for months. The firmware reverse engineering to figure out the LEDs was several weeks of on and off work in my spare time.

This type of thing is definitely not something you can just figure out in a couple hours (or even days).