Drew Fustini: exclusive interview for AT

New exclusive interview for the AT blog with Drew Fustini. An RISC-V Ambassador, open-source hardware designer at OSHPark, and a Embedded Linux systems developer. He is also a member of the Board of Director at BeagleBoard.org Foundation. And if you want to know more about him, I invite you to continue reading this interview…

Architecnología: I always ask at the beginning: Who is Drew Fustini? (Describe yourself, please)

Drew Fustini: I am a hardware designer and embedded Linux developer, from Chicago (USA), now living in Berlin. I design open source hardware projects for OSH Park (an PCB manufacturing service) and I maintain Adafruit Python libraries for the BeagleBone. I also volunteer on the board of directors of Open Source Hardware Association (OSHWA) and BeagleBoard.org Foundation. I organize the Berlin Embedded Linux meetup (hopefully we can start meeting again in 2021!) and became a RISC-V Foundation ambassador earlier this year.

AT: When and how did you start being passionate about technology?

DF: I recall always being interested in how technology worked, especially computers and electronics. I had the privilege of having a PC in house from an early age as my father was an engineer at Bell Labs (the R&D division of AT&T). I mostly just played games like Centipede but I got familiar with using DOS. I first started programming when I got a graphing calculator in middle school that could run BASIC programs. I started making games for my calculator. My school had Macs and we learned Hypercard which was a mix of making an offline website and powerpoint presentation. But the exciting part was that you could program UI like buttons and animations using HyperScript. After a few years, I decided to branch out into C and C++. Along the way, I was fortunate to have a neighbor with internet access who told me I should make a website and gave me a book on HTML. That then led to learning Perl which was the way most people built web applications back then.

AT: Do you have a reference? Someone who has inspired you?

DF: I was fortunate to have computers both at home and at school from a young age. We didn’t have much in the way of computer classes but I did have access to these expensive systems. One important figure in my technology journey was my next door neighbor who was a programmer and also ran his own PC building business. This got me into webs development and enabled me to start making money doing that while in high school, and got me a summer internship at an internet service provider in Chicago.

AT: How did your role as RISC-V Ambassador begin?

DF: I was at the Embedded World tradeshow in Germany back in February for BeagleBoard.org (little did we know that would be the last event this year). Our booth was near the RISC-V Pavilion and I spent a lot of time talking with people from the RISC-V member companies and also Calista Redmond, CEO of the RISC-V Foundation (now RISC-V International). She told me they were about to begin an ambassador program for those that were passionate about RISC-V. My interest in RISC-V comes from my passion for open source hardware. I would love to see more open source at the chip level. RISC-V is an open instruction set standard (ISA) which allows for open source implementations. There can not be an open source implementation of a proprietary ISA like ARM or x86. Thus it is possible to design a RISC-V microprocessor that is completely open source.

AT: And how did you start as a Linux kernel hacker?

DF: I have been interested in operating systems since I was in high school. Back then I did Windows systems programming for fun (Win16 API). Later on I discovered Linux and have been using it for my personal systems like laptop and desktop ever since. I also got very interested in how Linux works and started reading books like Understanding the Linux Kernel. I didn’t do any kernel programming but I went on to read the excellent book about systems programming called Advanced Programming for the Unix Environment from front to back. It was a great way to understand the POSIX API which is essentially how userspace (e.g. applications) interact with the kernel. It was a vital skill set for being a good Linux systems administrator and application developer.

I started actually doing kernel programming by way of a challenge that I learned of while attending LinuxCon 2015 in Chicago (my hometown!). I got to meet many from the Linux kernel community such as Linus Torvalds and Gerg KH. I was too shy to talk to them but my more outgoing friend Renault said we shouldn’t miss the opportunity to say Hello 🙂 They were both very nice. Linus said one thing that we can do to help is run the Linux release candidates and report issues (Linux replies on thousands of people testing it on all sorts of hardware configurations). Greg KH told us about Eudyptula Challenge run by the mysterious «Little Penguin». Upon emailing Little Penguin. one would receive a kernel programming task to complete. They started off simple like writing a kernel module to print out «hello world» in the kernel log and built up skills. In total there were 20 tasks and it took almost 2 years for me to complete. In large parts this is because there would often be delays of weeks to get a response from Little Penguin. This is a good simulation of what kernel mailing lists are like – one has to learn patience and persistence when asking for others to review their kernel patches and working through their feedback. In the end, I had a simple patch accepted to the kernel that restructured some code in a driver to better conform to kernel coding standards. While small, it built my confidence and got me much more engaged in reading Linux kernel mailing lists and start attending kernel focused conferences like Linux Plumbers Conference.

AT: What exactly is your job within the kernel? Do you only work on the support code for the Beagle boards or Do you make some other contributions? Anything about the RISC-V arch dependent code?

DF: I do not have a job per se working on the kernel. But as a volunteer board member of the BeagleBoard.org Foundation, I am focused on improving the experience of people using the BeagleBone dev boards as well as reducing the software maintenance burden on our small volunteer team. The best way to do this is by making sure everything that is needed for the BeagleBone is in the upstream Linux kernel (this is also referred to «mainline», it is Linus Torvald’s linux kernel repo). The Texas Instruments SoC (System-on-Chip) used in the BeagleBone is well supported in Linux as it has been a very successful part used in many commercial projects from 3D printers, to autonomous robots, to GPS navigation units. However, there are customizations to the Linux kernel (e.g. kernel modules) that were created for our out-of-the-box developer experience which focuses on rapid prototyping. We have been maintaining these as a series of downstream patches for years after the relevant Linux kernel maintainers indicated that our solution was not acceptable for the upstream kernel. This often means that we are either setting a bad precedent or not find a sufficiently generic solution. This is important because Linux supports thousands of different types of hardware and relies heavily on well engineered abstractions.

Throughout the last year (since Linux Plumbers 2019), I have been working with gpio and pinctrl subsystem maintainers and developers to get the functionality BeagleBoard.org needs into the upstream kernel. The process is usually that I will try to get new functionality for a driver working on my BeagleBone and then share the code on the mailing list in what is called an RFC (request for comment). This is a way to solicit feedback from others with more experience and to test the water on what a correct solution might look like. After that initial feedback, I will polish it further to the point where I can post a PATCH to the mailing list with the code that I am asking to be added to the kernel. The maintainer might respond quickly saying that they applied the patch to their tree and it will go to Linus Torvalds for the next release. However, it is normal for feedback to result in me sending a second revision. This cycle can continue on for many cycles. I think the highest I have gotten to is PATCH v5. However, for more complex development tasks, like adding a new driver to Linux, a developer might end doing 20+ revisions to the patch.

AT: Do you think RISC-V will one day conquer home computing? What about HPC? Could NVIDIA having purchased Arm help to boost RISC-V?

DF: I think it will take a long time for anything to disrupt x86 (AMD and Intel) for home computing. Consumers expect a high level of performance for a low price while also having compatibility with software that might be decades old. I see an open instruction set (ISA) like RISC-V being very useful where companies want to have greater control over micro architecture design while being able to collaborate with other organizations on open source implementations. Mobile computing is a more likely target for RISC-V in the near future. I think within 2 years we will have mobile devices like phones that have RISC-V processors on the market. They may not be the highest performance devices but there are billions of phones and not all them need the highest end performance.

And even better fit for RISC-V is embedded controllers. Companies like Nvidia had their own in-house architecture for the system management controllers in their GPUs. They chose to adopt RISC-V in order to not have to do all the processor design and software toolchain support on their own from scratch. Similarly, Western Digital has committed to using RISC-V for all the controllers in their storage products. RISC-V allows them to leverage a growing software ecosystem while also having the freedom to innovate on microarchitecture.

For HPC, the Barcelona Supercomputing Center has been heavily involved in RISC-V, both in terms of hardware and software engineering. RISC-V adoption should also benefit from the European Processor Initiative.

In terms of Nvidia, I think we may see ARM licensees that are competitors to Nvidia start working on RISC-V designs as a way to mitigate risk. But many companies in China were already well along in the transition from ARM to RISC-V due political antics from the USA government and potentially the British government too. In general, RISC-V is a way for nations to have more sovereign control over processor technology.

AT: I have to confess that I didn’t know OSHPARK. But I find it very interesting to be able to send your designs to make them a reality.In the past I was interested in MPW services, and this is fantastic for PCBs too. Can you tell a funny story, or some crazy project that someone has sent?

DF: One thing that people often ask about OSH Park, and me, is why all the purple?! Our founder Laen started the service for a Portland electronics hobby group called Dorkbot PDX about ten years ago. They realized they could save money by combining all their individual board designs into one large PCB panel. Along the way, someone brought a purple circuit board once to a Dorkbot meeting. Laen thought it looked really cool and started experimenting with solder mask colors (the paint that is put on top of a circuit board, typically green). After a few attempts (which turned out brown), our classic purple shade was settled upon. Purple circuit boards are still pretty rare in industry so it is pretty fun that when we see a project with purple boards online or in person as it is likely that we manufactured it 🙂 The purple has been fully embraced by our team from purple versions of every possible piece of office equipment to my fingernails 🙂

Another common question is why the weird name?! It means «Open Source Hardware Park» and it comes from the ability for our customers to choose to share their projects on our website for others to use. For the first few years of the service, it was just called Dorkbot PDX PCB order. However, it got more and more popular and Laen, a full time systems administrator, was spending all night handling the orders and had to make the decision to turn it into a full business or stop doing it. Thankfully, he chose to quit his day job and start OSH Park.

AT: What is your work inside the BeagleBoard Foundation?

DF: I spoke about this a bit earlier when describing the kernel development that I am doing. Beyond coding, I am involved on a weekly basis with the other board members to discuss solutions to technical issues that have been raised in our community and also discuss strategy for future designs. I also would often attend events to represent BeagleBoard.org and give talks at conferences, although that has changed a bit during the pandemic.

AT: It would be great to have an SBC based on RISC-V. Will there be any Beagle boards in the future?

DF: Yes! We very much want to build a RISC-V Linux-capable open source hardware dev board (essentially a RISC-V BeagleBone). The biggest challenge right now is finding a System-on-Chip (SoC) that we can use that is both available in distribution and is cheap enough for us to make a board that is $100 or less. We have been meeting with several companies and there are some promising solutions on the horizon. 2020 has not been kind to anyone’s timelines but hopefully this is something that we can bring to market in 2021. I think the availability of a low-cost RISC-V single board computer will really increase adoption, similar to what the original BeagleBoard did for ARM back in 2008.

AT: RISC-V is still very young.It competes with veteran ISAs like POWER, ARM, SPARC, etc. What would you highlight about RISC-V that others don’t have (besides the license)? And anything you think still needs to be worked on to improve?

DF: I think RISC-V will help to make open source IP more of a norm in the chip industry. RISC-V itself is just an open standard but many companies implementing the RISC-V instruction set are collaborating in a way that I believe is new for the industry. Producing silicon chips (e.g. «taping out») is an expensive proposition so it is important to have confidence in the design. Traditionally, this means that companies license proprietary IP blocks (e.g. chip-level hardware implementations) from companies that guarantee their correctness. Organizations like OpenHW and CHIPS Alliance are focusing on how the industry can integrate open IP like open source RISC-V cores into products with confidence. It’s still early but I think this is a good trend in hardware to where software is today: commodity building blocks are open source and not reimplemented over and over again by each vendor.

AT: What do you think about the accelerator of the EPI project or Shakti CPU? And Any RISC-V based project that you are especially excited about?

DF: I think EPI is a positive to have more design diversity in the hardware industry. I believe the EU wants to encourage sovereign innovation instead of relying on companies Intel. This is a good opportunity for companies and organizations to find funding to try innovative approaches. Shakti out of India is very exciting, as it shows what can be accomplished when a nation decides to invest in homegrown technology instead of relying on existing proprietary vendors.

One gap I see right now is there are very limited choices when it comes to a RISC-V SoC that is capable of running Linux effectively. I was excited to see RIOS Labs announce at the recent RISC-V Global Summit that they are working on a low-cost RV64 SoC that they hope to have available early next year.