Episode 30: Better Built By Burkhard
The Board-Support Package Is Not Enough!
The Board-Support Package Is Not Enough!
Some weeks ago, I ordered a Variscite iMX8M Nano development kit online. At least, I thought so. Instead of a confirmation e-mail, I got a phone call from a sales person, Max (name changed), the next day.
Max: “Who is your customer?”
Me: “I don’t have a concrete customer. I just want to evaluate your SoM like I did for the SoMs of Toradex, Seco, Avnet, DigiKey and others. Then, I can help my customers decide where to buy their SoMs.”
Max: “If you don’t have a customer, you won’t get a development kit.”
Me: “What!!!???”
Max: “All our potential customers get free support to customise the Linux image to their needs. This is often a substantial effort for our support engineers. If you only buy one SoM, this support is not justified.”
Me: “I don’t need any support. I do Yocto BSP customisations for a living like implementing custom Yocto layer, OTA updates, remote support via VNC, window managers, communication between Cortex-A and Cortex-M cores and secure boot. Your customers must do these things themselves. They often fail and must hire expensive consultants. Why don’t you build these features once and sell them to all your customers, say, with a premium on your SoMs?”
Max hesitating slightly: “You sort of got a point there. But that’s not how we do business here. I hope for your understanding that I can’t send you a development kit.”
Me: “I hope for your understanding that I cannot recommend Variscite to my customers then.”
I was sure that I would never hear from Max and Variscite again. But I was wrong. Two days later he called me and offered me a job. I politely declined. Max set up a meeting between an engineering manager, Aaron (name changed), and me to explore a cooperation.
Me: “Your customer’s core competency is definitely not customising Linux systems to their needs. It’s building their core applications on top of a custom Linux system. If you provided a basic Linux system with all the common features, you could save your customers a lot of time and money, couldn’t you?”
Aaron: “I doubt we can. The systems are too different for that. So, it’s very much the customers’ core job to build a custom Linux system. Anyway, we only provide the hardware.”
Me: “My experience is different. My customers have pretty much the same requirements. The little differences are dictated by the industry segment. I’d expect the same for your customers.”
Aaron: “OK. Our business is hardware, not software. But we have a large pool of software engineers (actually more than hardware engineers), who help customers to sort out their Yocto problems. They point customers to the documentation on our Wiki and even help with the implementation of recipes.”
Me: “You could provide recipes or scripts to automate the implementation of standard features. This would save your support engineers and your customers a lot of time and money.”
Aaron: “Automation is difficult because the requirements are varying too much. And, we don’t need it, because our Wiki’s are very good. You should try it out yourself.”
Me laughing: “I would like to but I don’t get a board from you 😉”
Aaron also laughing: “Fair point.”
A little bit later:
Me: “I am wondering how you differentiate your SoMs from the SoMs of other manufacturers. It can’t be the hardware, because it’s the same iMX8 SoC for everyone. It can only be on price.”
Aaron: “We ask customers to evaluate our and other SoMs. We let them decide on their own.”
Me: “Interesting approach. So, when do I get my board?”
Both laughing 😊
The board arrived two weeks later - after paying 400 USD (plus 50 USD delivery and 90 USD import duties). I’ll soon put Variscite’s board through the wringer like I did with the Toradex SoM (see the posts for building, flashing and customising the Toradex Linux image). I am pretty sure that it will turn out just fine.
Variscite’s positioning is characteristic for the chip industry. They understand SoM (system-on-module) as hardware-on-module. Instead, they should understand SoM as software-on-module, where module stands for hardware module. The system consists of both software and hardware.
The most important player of the system is still missing: the customer. The core business of customers is building the HMI or controller software for machines and devices. Their core business is certainly not building a custom Linux system with Yocto. They best buy the custom Linux system for a fixed price or for a premium on the SoM price, spend the time saved on their core business and get their products to the market faster.
I see steps from some SoM manufacturers to differentiate on software. Toradex stand out with their container operating system, Torizon. Torizon comes with remote access, remote and secure updates, fleet management and monitoring, and many more features out of the box. Toradex also provides a toolchain based on VSCode to develop the core applications.
Digi focus on the IoT field. They complement their SoMs with cellular and RF modules (LTE-M, Bluetooth LE, Zigbee, Wifi Mesh, LoRa, etc.). The IoT devices are managed and monitored through their IoT cloud solution and secured by Digi TrustFence. Their customers get the hardware and software for the deployment of IoT devices from one source.
Toradex and Digi provide clear additional value with software. What is the additional value that other SoM makers like Variscite, Boundary Devices, Seco and Avnet provide? Maybe, they are big enough to differentiate mostly on price. When will they change their strategy?
My Content
Setting Up Yocto Projects with kas
How to build the reference Linux image and SDK for the Toradex Verdin iMX8M Plus SoM with kas. Once you have created a kas configuration file (in YAML format), you can run Yocto builds with a single command - without having to specify a Docker container or even understand Docker files.
The post Qt Embedded Systems – Part 1: Building a Linux Image with Yocto shows the traditional process with using repo and writing your own Docker file. You can compare for yourself.
Installing Linux Images on Toradex Verdin Boards
Once you have built a Linux image, you must flash it on the board. The post describes this how to do it for Toradex boards.
Creating A Custom Yocto Layer
Once you have successfully built and run the reference image of the SoM maker, you must remove unnecessary packages (so-called bloatware) or packages under the wrong license, include your applications in the Yocto build and make your core application start automatically on power-up. In short, you must create your own custom Yocto layer.
SoM makers could provide a script that automatically generates the custom layer from a configuration. This would be considerable additional value for customers, because many of them fail at this step or spend a disproportional amount of time on it.
Around the Web
Till Adam: Choosing a CPU Is the i.MX 8 Right for Your Project?
Till provides an excellent guide when to use an iMX8 instead of an iMX6. He also cuts through the zoo of iMX8 variants (standard, X, Mini, Nano and Plus with 1, 2, 4 or 6 cores as Lite or not, etc.) and recommends when to use which variant.
I have some remarks:
An important criterion for SoC selection is the standard software with value added to the BSP - the main topic of this newsletter.
The iMX8M Plus is missing from Till’s list. It’s similar to the iMX8M Mini but adds a neural processing unit (NPU). The NPU offloads inferencing on deep neural networks from the CPU and GPU. So, it’s well suited for computer vision, speech recognition and other machine learning tasks. The iMX8M Plus is a cheaper and less power-guzzling alternative to the iMX8X.
There are many safety-critical applications that don’t have to display anything. For example, when a user presses the hardware button on a tablet, the UV cleaning robot in the neighbouring room must be guaranteed to stop. The hardware button is assigned to the Cortex-M core. The same could be done for LEDs for indicating dangerous things happening. Then, the iMX8M variants become alternatives to the iMX8X variants.
The iMX8 SoCs are not the only SoCs in the iMX family with a supporting Cortex-M core. The iMX6 SoloX and the iMX7 have one Cortex-M core on board. These SoCs are a good choice, if customers move their product from a microcontroller to a microprocessor. These SoCs have no OpenGL graphics acceleration and are low-performance. But they have low power consumption.
I’d add security as a selection criterion. All the iMX8 SoCs support secure boot. The Cortex-A cores support ARM TrustZone, the Cortex-M cores don’t. ARM TrustZone protects a secure world through hardware. So, we can create a secure world on the A cores but not on the M cores. However, we can secure the access to the software on the M cores.
In addition to maturity, I’d also look at the end of support for a chip. The support for the iMX8 series ends in 2034-2035, the support for the iMX8M series in 2033-2036, the extended support for most of the iMX6 SoCs in 2035 and the support for the iMX7 series in 2026-2029. You can check yourself on NXP’s Product Longevity page by selecting “Processors” as the “Category” and “iMX8 series”, “iMX8M series”, “iMX7 series” or “iMX6 series” as the “Family/Series”.
Tim Ottinger: Story Points: Why is this so hard?
“The [original idea] of story points is not to know how long something will take, but to help avoid overworking our teams.”
Tim’s statement immediately made sense to me. Story points are well-suited for that, as long as they are not misused for estimating efforts. Estimation can’t work, because the assumption, that the velocity in the equation story points * velocity = actual hours is a constant, is wrong. It’s actually exponential and not linear (think probability distribution).
When you say that one story is roughly twice as much as another story, “much” can mean different things. It can mean “more typing, more code reading, more communication, […], more complexity, or more time.” So, “more” can mean more by any of these factors, by other factors or by any combination. It certainly doesn’t only mean time.
Tim concludes:
“Don’t use story points. They’re too complicated, unreliable, and uncertain.”
Tim’s alternative to story points and planning is simple. You create a list of user stories and prioritise them by customer value. The team should be able to finish each story in less than a week. Shorter is better. Estimates are done by gut feeling: just less than a week. Code must always be runnable and testable. That’s all.
Joshua Kerievsky: Stop Using Story Points
Joshua came to pretty much the same conclusion as Tim but 10 years earlier.
Story points are NUTs: nebulous units of time.
Joshua tells the story of a customer team who did Scrum without the huge overhead of estimating and planning.
[The product manager] and her team simply used gut feel to choose the right amount of work for a 2 week iteration or 2 month release.
If they needed to adjust the plan, they did so, always keeping stakeholders informed.
She said that this gut feel approach to estimation and planning had been working just fine and that they had no need for story points or velocity calculations.
Agile thinking means to inspect your process and adapt it if it doesn’t work properly. And there are typically several good solutions to a problem.
Today, we have simpler, less defective agile estimation and planning approaches.
[…] to work on the same number of similarly-sized stories each sprint.
Others work without sprints in a flow-based model that includes periodic release planning.
Flow-based models like Kanban also work best with similarly-sized stories.