dougg3

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

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

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.

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

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

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.

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!

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

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.

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!

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

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

It lets you see the raw underlying packets like IN, OUT, SETUP, DATA0/1, etc. That capability would be most useful for USB device firmware developers who might want to see these packets to track down an issue with the DATA0/1 toggling or something like that which wouldn’t be visible in a higher-level software trace like USBpcap or usbmon.

Also, it lets you sniff USB traffic of a different host machine, e.g. USB communication between a game console and a USB controller.

Larry’s work on maintaining a bunch of Realtek’s vendor drivers on GitHub was huge for a lot of the community. Even today these forks often work much better than the mainline drivers. He will be missed! As others said, he was a huge inspiration.

Sorry, I somehow missed your comment until now. Didn't get any notifications. I tend to do it more like what you first said, mocking low-level calls.

I typically put all hardware-specific code for one platform into its own directory. Then I can have multiple directories for different hardware implementations, like MCU #1, MCU #2, and PC. I just implement the same API in all three. It's basically just a HAL. Each build only compiles one of those directories -- the one that matches the architecture I'm building for.

For example I might have a function that does an SPI transaction. On the two hardware builds it will actually communicate with the SPI peripheral in the MCU, but on the PC build it will talk to something I've written to pretend to be the SPI device. So it does take a little bit of up-front work writing code that pretends to be the various devices. In some ways you could call that an emulator, but not in the way you were asking I think.

You can make it as simple or complex as you want to. You could do a full-fledged object-oriented SPI class in C++ (or "class" in C), with different class implementations for different hardware builds. Or you could just make a single function that does SPI stuff and reimplement it for each hardware build.

In one case I have a Qt GUI that pretends to be the UI for the device so the PC hardware-specific code ends up providing its own main() and runs the actual shared codebase in a separate thread. So that particular codebase has a provision to rename the shared main() to not actually be main() on the PC build so it plays nicely with Qt needing to actually provide main().

One downside is you won't catch certain bugs on the PC. There have been a few bugs that slipped past because the hardware build was 32-bit but my PC build was 64-bit for example. But those errors are fairly rare. I probably should be doing the PC build as 32-bit to make it more similar anyway. Still, it wouldn't catch every little problem that might pop up on hardware. It definitely accelerates my productivity though!

This is a really impressive project! It was a fun read. Thanks for sharing! I like this writing style.

As an aside, I try to create a dual-target build for all my embedded projects, with a native host build for rapid prototyping/debugging

I find myself doing the same thing on my embedded projects, including at my job. I actually find myself using the PC build much more frequently than the hardware for my day-to-day work now that the hardware layer is stable and tested. More people should do this!

Hi, I’m the author of this post. I’m not aware of a similar Pico project that acts as an Altera USB Blaster clone. Seems like an interesting project idea though! The CH552 firmware I used would provide a good sample to start from.

This same kind of thing happened to a family member several years ago on his Dell Inspiron 3650 minitower. Dell’s automatic updates installed a BIOS update (3.9.0) that bricked the computer. It would just power off and on automatically forever, no way to even access the BIOS. A bunch of other people online ran into the exact same problem.

I ended up reflashing the 3.9.0 BIOS to the flash chip and it fixed it [1]. Later on, people discovered that changing an Intel ME-related jumper on the motherboard also fixed it - a much easier fix.

It seems crazy to me that manufacturers include BIOS updates as part of automatic updates, especially for out-of-warranty systems.

[1] https://www.downtowndougbrown.com/2019/06/fix-dell-inspiron-...

Nice systemd solution, it seems very elegant!

To be clear, my init script is named S00datetime, not 500datetime. It's actually the very first one that runs from rcS. So the date is restored very, very early in the boot process before pretty much everything else.

Interesting, thanks for mentioning CUSE. If I’m understanding it correctly, it seems like it would be a perfect solution for this. Allows leaving the logic in userspace which is much easier to deal with (filesystem access, sharing the UART) but would still show up as an RTC device. I may need to play further with this!

Author here. That's very much a fair point. I was thinking more from the perspective of firmware developers maintaining fixed userlands when I wrote that.

It would definitely be an interesting challenge to figure out how to multiplex the UART between being a normal UART and accesses from an RTC driver in order to allow it to be a real RTC!

Ah, that’s another interesting possibility. I definitely observed that the actual HDMI refresh rate is 59.94 Hz while playing Super Mario Maker, but no idea what the game’s internal frame rate is.