For more than 10 years, Codethink has been providing genius to some of the world’s most relevant technological organisations. Our specialists have supported and helped our clients in many open source projects, especially in Automotive, Finance, Medical and IoT industries.
One of these specialists is Ben Dooks, Senior Engineer and Open Source Consultant with more than 15 years’ experience contributing to Linux Kernel. Dooks joined Codethink 8 years ago, and since then he's been involved in a range of projects involving the Linux kernel, such as the MEG project, amongst others.
His knowledge and interest in the Linux kernel led him to test and research RISC-V, a shared enthusiasm in the company. There are currently many conversations around the open-source microcontroller, and of course, we could not miss the chance to ask our 'Kernel Guru' about RISC-V.
Interviewer: How did you start working with the Linux kernel?
Ben Dooks: In my previous job, I was working heavily with Samsung ARM SoC, and it turned out I got involved in writing a lot of that software support that went into the next kernel (around the 3.x development version). It turned out that we were better than Samsung doing this, so we ended up picking work for other companies that also wanted newer kernels for their devices. We wrote a lot of the support for this Samsung SoCs because that's what we need it to support our customers, and it turned into working with Samsung to improve their support of upstream kernels.
I: Which has been your most interesting project with Linux?
BD: The most interesting stuff I've done with Codethink it would be the MEG project because that wasn't just Linux kernel. That was actually designing interfaces and custom hardware.
I: Could you explain what RISC-V is?
BD: RISC-V is a computer architecture like Intel's x86 and ARM's 32 and 64 bit designs. It can be thought of as a language that the computer's hardware understands and how it interprets the 1s and 0s in memory.
I: What are the differences between Intel, ARM and RISC-V?
BD: While companies like Intel share the information about how these things work, so you can create some instructions that the Intel chip will understand, you can't implement your own Intel chip, unless you have a licence from Intel. Anyone trying to implement their own systems based on these proprietary specifications has to license the intellectual property or risk legal action.
What RISC-V is saying, is "'The design specifications are open for you to use. As long as you follow the specification, then everything should just work". No commercial licence is required.
Now, still, some companies sell their own proprietary version of RISC-V, but they are not allowed to sue you if you come along and make your own. So you can say 'I can make my own chip that did things with this specification, I can tell people, and I don't owe anybody royalties'.
I: How do you see the future of RISC-V?
BD: What I'm interested in this RISC-V is the number of companies that are going 'ah, this is all open, and we don't have to pay to use it, we'll try making products around it. The market for RISC-V is going to grow, and we would like to be ready for that. From recent developments, it looks like more big tech companies will be using RISC-V in various forms. People are actually starting to take notice, so it's interesting to see what happens. Codethink as experts in open-source can help with the emerging open software for RISC-V.
I: What are you expecting from RISC-V?
BD: RISC-V is emerging in areas where other architectures like Intel or ARM have been traditionally established. I would like to see some more open processor designs that people can play around with. I think RISC-V is at that point, because people understand how to use it and all the necessary support is just there ready for people to use.
I: What would you like to achieve with RISC-V?
BD: At the moment, I don't really have anything [to achieve]. I would want to to see what happens. We really shouldn't have to worry about the architecture that my software is running on. So for me, I'm agnostic to that debate about RISC-V vs other architectures. It's all about what the hardware can do for you, and that's not just the core processor architecture, there is all other stuff around that core that makes whatever-task-you-want usable, it's what makes systems interesting. It's a difficult one to answer.
Keep up with our RISC-V news
Fill out the form to receive our latest updates on the open CPU architecture in your inbox.
Related blog posts:
More about York Instruments and MEG project: Codethink helps York Instruments to deliver world-beating medical brain-scanner
Written by Ben Dooks and Kejia Hu: Investigating kernel user-space access
- Using Git LFS and fast-import together
- Testing in a Box: Streamlining Embedded Systems Testing
- SDV Europe: What Codethink has planned
- How do Hardware Security Modules impact the automotive sector? The final blog in a three part discussion
- How do Hardware Security Modules impact the automotive sector? Part two of a three part discussion
- How do Hardware Security Modules impact the automotive sector? Part one of a three part discussion
- Automated Kernel Testing on RISC-V Hardware
- Automated end-to-end testing for Android Automotive on Hardware
- GUADEC 2023
- Embedded Open Source Summit 2023
- RISC-V: exploring a bug in stack unwinding
- Adding RISC-V Vector Cryptography Extension support to QEMU
- Introducing Our New Open-Source Tool: Quality Assurance Daemon
- Long Term Maintainability
- FOSDEM 2023
- Think before you Pip
- BuildStream 2.0 is here, just in time for the holidays!
- A Valuable & Comprehensive Firmware Code Review by Codethink
- GNOME OS & Atomic Upgrades on the PinePhone
- Flathub-Codethink Collaboration
- Codethink proudly sponsors GUADEC 2022
- Tracking Down an Obscure Reproducibility Bug in glibc
- Web app test automation with `cdt`
- FOSDEM Testing and Automation talk
- Protecting your project from dependency access problems
- Porting GNOME OS to Microchip's PolarFire Icicle Kit
- YAML Schemas: Validating Data without Writing Code
- Deterministic Construction Service
- Codethink becomes a Microchip Design Partner
- Hamsa: Using an NVIDIA Jetson Development Kit to create a fully open-source Robot Nano Hand
- Using STPA with software-intensive systems
- Codethink achieves ISO 26262 ASIL D Tool Certification
- RISC-V: running GNOME OS on SiFive hardware for the first time
- Automated Linux kernel testing
- Native compilation on Arm servers is so much faster now
- Higher quality of FOSS: How we are helping GNOME to improve their test pipeline
- RISC-V: A Small Hardware Project
- Why aligning with open source mainline is the way to go
- Build Meetup 2021: The BuildTeam Community Event
- A new approach to software safety
- Does the "Hypocrite Commits" incident prove that Linux is unsafe?
- ABI Stability in freedesktop-sdk
- Why your organisation needs to embrace working in the open-source ecosystem
- RISC-V User space access Oops
- Tracking Players at the Edge: An Overview
- What is Remote Asset API?
- Running a devroom at FOSDEM: Safety and Open Source
- Meet the codethings: Understanding BuildGrid and BuildBox with Beth White
- Streamlining Terraform configuration with Jsonnet
- Bloodlight: Designing a Heart Rate Sensor with STM32, LEDs and Photodiode
- Making the tech industry more inclusive for women
- Bloodlight Case Design: Lessons Learned
- Safety is a system property, not a software property
- RISC-V: Codethink's first research about the open instruction set
- Meet the Codethings: Safety-critical systems and the benefits of STPA with Shaun Mooney
- Why Project Managers are essential in an effective software consultancy
- FOSDEM 2021: Devroom for Safety and Open Source
- Here we go 2021: 4 open source events for software engineers and project leaders
- Xmas Greetings from Codethink
- Call for Papers: FOSDEM 2021 Dev Room Safety and Open Source Software
- Building the abseil-hello Bazel project for a different architecture using a dynamically generated toolchain
- Advent of Code: programming puzzle challenges
- Full archive