When I began my approach for a By-Pass Lock screen solution, I knew that the USB/PCI Express Bridge chip I was using had the capability to enable DMA attacks. But I wasn’t sure how to configure it properly. In the end 20 Bytes of firmware did it. But getting to the 20 bytes of firmware was not the path I expected. It illustrates a common theme in my engineering career simple software solutions for hardware problems and simple software solutions for hardware problems.
I started by thinking– this device has driver support in Linux. So let me go and get that up and running and I can use this software stack that is already in place called a USB-FS (USB File System) and the Gadget-FS (Gadget File System). This set of software lets me go and interactively create USB devices, configure them and interface with them. I figure that’s the driver infrastructure that exists; that’s the software construction that exists; let me just build on that.
I quickly found out that the software driver stack only supported the older model of the chip. So I had to try to update the driver software. I tried the software patches that the chip manufacturer provided–these didn’t work so well. Another developer had been working on a similar project – i found his posts on the linux kernel development mailing list, and his patches worked a lot better.
By the time I finally got it up and running- I had spent probably several weeks just trying to get the patched kernel to build. So finally I get drivers built for my device. Yet I still didn’t know what to do. To fake out the computer (see previous post), I knew I needed to change some registers, but I don’t know how to access them nor which ones. So I spend a long time with the datasheet for the bridge chip, trying to understand the details of the system. As I look at the data sheet I realize that l had spent the past weeks just trying to get access to the hardware so I could configure registers. Now that I was actually taking the time to figure out what registers to configure I realized– I only needed to configure four registers.
I don’t need a driver. I don’t need a software stack. I don’t need to modify kernels or patch kernels and rebuild them. I just need to set these four registers in the easiest way possible. So that’s when I determined that I could just put firmware on the flash chip on this board, this firmware would just set those 4 registers, turn the power on and it works.
By the time I figured out which registers I needed to set it took me only two hours to get the board up and working. Where before that I had spent 6 to 8 weeks just getting the software infrastructure up and running.
This first big project I had done on my own and I have since changed my approaches to lots of projects. I now find that I spend a lot of times thinking about things before I touch hardware. I will think of a project in my mind for a while, in some cases years, before I even order the hardware. By the time the hardware is in hand I’ve been browsing data sheets for a while, working on something else, coming back to this project. When I finally build the project it only takes me 2 days, 3 days or 4 days to get it up and running.
Have a Productive Day,
Dear Reader, please share your comments and stories that are sparked by this piece. Have you found there’s a trade-off in rushing to a solution vs mulling it over? Contribute for how you can share a story at The Engineers’ Daughter.
Here’s a good summary of Firmware with illustrative pictures.
Datasheet for a PCI Express USB bridge chip, not necessarily the one used in this project
Linux Software stack that Joe referred to in this post.
If you’re interested in checking out open hardware projects consider this repository (similar to GitHub).
More on the engineering problem solving approaches in this abridged transcript of a conversation between Joe FitzPatrick and Anne Meixner.
Anne: So when you say thinking you’re doing things like reading things and maybe taking some notes or writing something down but you’re not touching anything yet until you have it more fully scoped it out.
Joe: It’s funny because you look at the typical engineering problem and the typical approach is to dive into the solution space. So the typical hardware person problem is going to go straight to putting hardware together to solve the problem.
Anne: As opposed to defining the problem.
Joe: Yes, as opposed to defining the problem. And it’s funny because I look at some of my habits and I almost think of them as laziness. Like I keep talking about, I keep saying things about it, I keep reading about it but I never do it. But once I finally do it; it happens really quickly. But I think it happens so quickly is because I have the luxury of taking time to mull over these ideas. Let them form and also bounce them off other people.
Anne: I concur there is sometimes a rush to fix the problem right away as opposed to thinking it through and maybe that comes with experience. Though some engineers never learn that. (Laughter- cackle and a giggle).
Joe: Well I think that common work places don’t lend to that (taking time to mull things over thinking). When a work place is very results oriented it might reward you for your trials or your failures but not reward you for your planning.
Anne: Yes, we both came from a very results focused company and you were in a more execution based group. This is talking about me but one time when I was looking to change positions. I had this one conversation with an engineer who had gone into management and was willing to talk to me. But he basically said “I’m not sure you can execute, we’re very execution focused here. And you’ve done…”- and he basically accused me of doing research. I did little “r” and big “D. But I realized he had only seen me at one point in my career. Early in my career, I had a project to do and I executed. And I’m thinking “This other guy that mentored him would never had made that assumption about me because he had saw me execute.” He saw me go and doing the work but there was also a planning part there.