dougg3
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!
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.
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".
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.
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.
XC68LC040RC25B
02E23G QEDP9348D MALAYSIA
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.
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!
This type of thing is definitely not something you can just figure out in a couple hours (or even days).
Also, it lets you sniff USB traffic of a different host machine, e.g. USB communication between a game console and a USB controller.
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!
> 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!
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-...
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.
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!