dougg3

Blog author here. That's pretty similar to my thinking on it all now too.

I'm not just lazily telling Claude to find everything for me and then sitting back and relaxing. My brain is still doing work, it's just different work than it was before. Coming up with a good prompt takes effort and good communication skills. I'm still watching what the LLM does and redirecting it if it's going off into the weeds. On larger tasks (not really relevant to this reverse engineering project, admittedly) I'm still making design and architectural decisions.

I've done plenty of these kinds of huge multi-month reverse engineering projects in the past by hand (just see my past blog posts). I have no doubt I could have found this bug myself if I spent enough time digging into it. A majority of the work would have been boilerplate tedious stuff in Ghidra that I already know how to do, and it would have been incredibly boring. I'm enjoying being able to tick off some of these project ideas from my (neverending) list and having some fun while doing it. Also, the older I get, the more painful and tiring it is to stare at the screen for hours and hours.

I completely respect that this approach isn't for everyone though!

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.

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

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".

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.

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!

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.

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.

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.

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

XC68LC040RC25B

02E23G QEDP9348D MALAYSIA

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

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.