- Hardware
- Rockchip RV1108 · RV1106 · Raspberry Pi · x86-64
- The work
- A restored build, and updates that finish
The work
Fiscal transaction devices
A stalled build pipeline recovered, and device provisioning redesigned
Case data
- Industry
- Fiscal and point-of-sale hardware
- Product line
- Fiscal transaction devices, SAT and MFE class
- Silicon
- Rockchip RV1108
- Scope
- Development environment recovery, hardware validation imaging, build infrastructure, provisioning and authentication, production line integration, firmware update
Development environment
We rebuilt it and validated the build infrastructure, so the device platforms build and test reliably again.
Hardware validation
We restored and adapted the validation image. A new unit can be checked against the baseline hardware requirements again.
Build server
We recovered it. Its failure had stopped image generation completely.
Provisioning and authentication
We redesigned how a unit is provisioned and authenticated, from the strategy through to the implementation. A fiscal device must identify itself to the tax authority.
Production line
We adapted the production scripts and joined them to the manufacturing test fixtures. The line flashes and validates a unit with no manual step.
Fiscal compliance component
We shipped an update to the component that runs on the device.
A platform migrated, and a build brought up to date
One build producing two architectures, on a modernised Yocto release
Case data
- Industry
- Fiscal and point-of-sale hardware
- Product line
- Point-of-sale devices, several models
- Boards
- Raspberry Pi CM4 · Raspberry Pi 4 · x86-64
- Scope
- Platform migration, Yocto release migration, init system migration, application build rework, machine definitions, release engineering
The existing build, reproduced
We built what the customer already had before we changed any of it. A migration you cannot compare against is a rewrite.
Migration to our platform
We moved the product onto the O.S. Systems Embedded Linux platform, and then onto a current Yocto Project release.
Init system
We migrated the product to systemd.
Application build
We reworked how the Qt application is built. It was the largest single piece of this migration.
Two architectures, one build
We defined the machines for the Raspberry Pi boards and for x86-64, so one build produces the images for both.
Real-time clock
We added support for it in the platform.
Release engineering
We defined a development image and a homologation image, and we took the product through a major release.
Updates that finish, and boots that do not fail
The reliability work after the migration, including an update that could brick a unit
Case data
- Industry
- Fiscal and point-of-sale hardware
- Product line
- Point-of-sale devices in the field
- Boards
- Raspberry Pi CM4 · Raspberry Pi 4
- Scope
- Over-the-air updates, self-hosted update server, boot failure diagnosis, file system repair, board support, storage support
An update that did not finish
An update applied only in part, which is the worst way for one to fail. We found the cause and we fixed it.
Two boot failures
We diagnosed both. One of them was caused by an update, which is why the update work and this work are the same job.
Self-hosted updates
We set UpdateHub up against the customer's own server rather than a public cloud, because these devices report to a tax authority.
File system repair
The device now repairs its file system at boot instead of stopping.
Kernel panic
The unit now restarts itself after one, rather than sitting dead on a counter.
Newer boards
We added support for the Raspberry Pi CM4 and the Raspberry Pi 4, and we fixed NVMe storage support in U-Boot.
The fiscal module
Configuring it could hang the device. We found the fault and we fixed it.