Skip to content
Ftechiz Solutions Pvt Ltd

Work

What our engagements actually look like

Platform work happens under NDA, so these are anonymised profiles rather than named case studies. They describe the shape of the problems we take on and how they get solved.

Industrial controller

Exposing GPIO to applications on an i.MX 8M Plus carrier

A custom carrier around an i.MX 8M Plus system-on-module. The application team needed deterministic control of digital I/O — relays, interlocks, status LEDs and sensor triggers — addressed by name, running unprivileged, without sysfs workarounds.

i.MX 8M PlusDevice TreeIOMUXClibgpiodgpio-hogudev

What we did

  • Authored IOMUXC pinctrl nodes in the device tree, setting MUX_MODE and pad config — drive strength, pull, hysteresis and slew — per pin against the schematic
  • Mapped the signals across the GPIO1–GPIO5 banks and added I2C expanders as extra gpiochips where the module pinout ran out
  • Used gpio-hog for lines that must hold state from boot: power enables, resets and fail-safe outputs
  • Named every line with gpio-line-names and moved the application from sysfs to libgpiod
  • Set udev rules and group ownership so the application opens /dev/gpiochipN without root

Outcome

The application addresses I/O by signal name rather than bank and offset, runs unprivileged, and the pin map is documented against the schematic rather than living in one engineer's head.

Edge AI / HMI

RK3576 bring-up on a custom carrier

A product board built around an RK3576 module, where the Rockchip BSP targeted the evaluation board and the carrier had diverged — different panel, different camera, different power topology.

RK3576Rockchip BSPDevice TreeMIPI DSI / CSIRKNNPCIe

What we did

  • Ported the vendor kernel and device tree from the EVB to the carrier, reworking regulators, clocks and pin muxing
  • Brought up the MIPI DSI panel with correct timings and backlight control, plus HDMI as a second output
  • Integrated the MIPI CSI camera sensor and validated the capture path end to end
  • Enabled PCIe, USB roles and tuned eMMC, then enabled the NPU through RKNN for the on-device inference workload
  • Produced both Android and embedded Linux images from one board configuration

Outcome

A booting carrier with every peripheral verified against the schematic, and a reproducible build that produces either OS target from the same tree.

Logistics / asset tracking

Yocto image for a UHF RFID reader

A UHF RFID reader that needed a lean, field-updatable Linux image rather than Android — fast boot, small footprint, and a rootfs that survives power loss in a warehouse.

YoctoBitBakeEPC Gen2 UHFsystemdRAUClibgpiod

What we did

  • Built a custom meta layer with the machine configuration and BitBake recipes for the reader application and the RF module SDK
  • Brought up the UHF module over its serial interface: kernel configuration, stable udev naming, and power sequencing for the RF front end
  • Exposed EPC Gen2 read and write, antenna port selection and transmit power control through the application interface
  • Locked the image down with a read-only rootfs plus a writable overlay for captured data, systemd services and a hardware watchdog
  • Added RAUC A/B updates and generated the licence compliance manifest for the packages actually shipped

Outcome

A reproducible image that boots quickly, survives unclean power-down, and can be updated in the field without collecting devices.

Automotive Tier-1

Cluster and IVI bring-up on a new SoC

A cockpit programme moving from a legacy RTOS cluster to a single Android Automotive SoC driving both the instrument cluster and the centre stack, with a fixed rearview-camera deadline.

AAOSVHALSOME/IPMulti-displaySuspend-to-RAM

What we did

  • Ported the vendor BSP onto custom cockpit hardware and authored the device tree
  • Implemented VHAL over CAN and SOME/IP for the programme's vehicle signal set
  • Built the early-boot graphics path so the rearview camera meets its regulatory window
  • Set up multi-display composition across cluster, centre stack and passenger screens

Outcome

A cockpit platform holding its boot-time budget across temperature corners, with vehicle data reaching applications through a stable Car API surface.

Industrial OEM

Rugged handheld from reference board to GMS approval

A rugged handheld for field service, built on a custom board derived from a silicon vendor reference design, needing GMS certification and a five-year support commitment.

AOSPAIDLCTS / VTS / GTSTradefedTreble

What we did

  • Brought up display, touch, barcode scanner, cellular modem and charging on custom hardware
  • Migrated legacy HIDL HALs to AIDL and validated the VINTF manifests
  • Automated CTS, VTS and GTS in CI against a small on-premise device farm
  • Worked the failure list down and prepared the submission evidence package

Outcome

GMS approval achieved on the planned submission cycle, with regression gates that keep the suites passing through monthly security merges.

Consumer electronics

Android TV platform with a fleet update path

A set-top box maker shipping into multiple operator markets, each wanting a different launcher and app bundle from one maintained platform.

Android TVA/B OTAAVBSELinuxupdate_engine

What we did

  • Established one AOSP base with per-operator product configurations
  • Built A/B seamless updates with staged rollout and rollback protection
  • Implemented verified boot with a per-operator key hierarchy
  • Replaced permissive SELinux domains with enforcing policy before launch

Outcome

One platform serving several operator SKUs, updatable in the field without truck rolls and shipping with an enforcing security posture.

Edge AI / robotics

Camera pipeline and accelerator enablement

A robotics platform needing several synchronised camera streams into an on-device inference pipeline, on hardware where the vendor camera stack did not cover the sensor set.

V4L2Camera HAL3GrallocDMA-BUFCustom SDK

What we did

  • Wrote V4L2 drivers for the sensor modules and integrated the ISP path
  • Implemented Camera HAL3 with concurrent multi-camera streaming
  • Tuned buffer allocation and DMA to hold frame rate under thermal load
  • Delivered a vendor SDK so the application team could consume streams directly

Outcome

Synchronised multi-camera capture feeding the inference stack at target frame rate, with a documented interface for the application team.

Common ground

What people arrive with

Most first conversations start with a symptom rather than a service name. These are the ones we hear most.

“The board boots to a console but the display stays blank.”
Usually panel timings, the regulator or reset sequence, or a DSI lane mapping that does not match the schematic. We work it from the device tree down with a scope on the lines.
“We are stuck on a vendor kernel and cannot take security patches.”
Splitting the vendor tree into a Generic Kernel Image plus vendor modules, resolving KMI symbol breakage, and adding ABI monitoring so it stays upgradable.
“CTS has hundreds of failures and submission is close.”
Triage first — separating genuine platform defects from harness and environment problems — then fixing the defects at the layer that causes them rather than papering over the test.
“We need the same product on two different SoCs.”
One product configuration with a clean vendor interface, so the parts that differ stay behind the HAL boundary instead of forking the whole platform.
“Devices are in the field and we have no safe way to update them.”
A/B or virtual A/B partitioning, update_engine or RAUC, rollback protection and staged rollouts — proven on the bench before it ever reaches a customer device.
“Android is too heavy for this device.”
A Yocto or Buildroot image instead: smaller footprint, faster boot, and a real-time kernel where the control loop needs one.
“The engineer who built our platform has left.”
We pick up undocumented trees — reconstructing the build, writing down what the carried patches do, and handing back something the next engineer can work on.
“It works on the bench and fails in the chamber.”
Thermal and voltage corner debugging: boot reliability, suspend and resume, DDR margining and the intermittent faults that only appear under stress.

Want the detailed version?

We can walk through comparable work in a call, including the parts that went wrong and what we changed because of them. References available where customers have agreed to them.