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.
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:
Makes me think of this anecdote from Linus Torvalds' officemate, from (1)
> At one point, Linus had implemented device files in /dev, and wanted to dial up the university computer and debug his terminal emulation code again. So he starts his terminal emulator program and tells it to use /dev/hda. That should have been /dev/ttyS1. Oops. Now his master boot record started with "ATDT" and the university modem pool phone number. I think he implemented permission checking the following day.
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.
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".
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.
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:
No reasonable EE would mistake this for anything but an electrolytic cap.
This is a very old package design from the transition between through hole and SMD. The process for making the vertical axial style common now hadn't been perfected and it was briefly cheaper to cast regular axial caps into an epoxy block.
No other component looks like this, it's a very distinct package and footprint from any other type of cap. No one tried to disguise anything, they really just thought this was the cheapest way to make a surface mount electrolytic cap.
It's more likely so these could be used with a pick and place machine. They're obviously lytics if you look at the ends. I don't know why everything has to be a conspiracy these days.
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:
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.
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.