Hacemos dos tipos de trabajo. Hacemos ingeniería en su Linux embebido y su firmware, y construimos el sistema de desarrollo con IA que sus ingenieros usan para entregarlo. Elija el que corresponde a su problema.
Paquetes de soporte de placa, migraciones de kernel, trabajo en sistemas de build, sistemas operativos a medida.
Agentes de código en su propio repositorio, con revisión de una persona antes de cada merge.
Cuéntenos sobre su producto. Le ayudamos a encontrar lo que necesita y cómo llegar ahí, antes de que usted se comprometa con algo.
Empiece por el problema que tiene hoy. Si dos de estos le sirven, díganos, y un ingeniero le dirá cuál va primero.
Su equipo está sobrecargado, es pequeño o es nuevo en Linux embebido. El trabajo que lo bloquea no es el trabajo en el que usted quiere usar su tiempo.
La forma en que trabajan con nosotros la mayoría de los clientes
Trabajamos como parte de su equipo. Tomamos el trabajo de Linux embebido a su manera, lo construimos con sus ingenieros y revisamos sus cambios. Los dejamos capaces de continuar, y usted mantiene la atención en su producto.
Por qué importa. Linux embebido es una especialidad. Un socio que ya conoce el kernel, el bootloader y el build elimina el cuello de botella sin un plan de contratación.
Usted está empezando un producto, o las placas aún no han llegado.
Desde la elección del silicio y del módulo hasta el primer arranque. Incluye la puesta en marcha de la placa, el bootloader, el kernel, un build con Yocto y un SDK para sus desarrolladores de aplicaciones.
Por qué importa. Estas primeras decisiones definen durante cuánto tiempo el producto puede tener soporte. Son caras de revertir una vez que las placas están fabricadas.
Su sistema está sobre una toolchain antigua, o usted heredó una que no eligió.
Cambie de sistema de build en la dirección que le conviene: de LTIB, Buildroot o un SDK del fabricante a Yocto Project, o al revés. Lleve un kernel antiguo del fabricante a un kernel con soporte a largo plazo (LTS). O asumimos un sistema, y usted deja de pagar un soporte que no necesita.
Por qué importa. Un sistema que solo un proveedor puede construir, o que nadie puede reproducir, pone en riesgo cada versión futura. Le decimos qué destino conviene a su equipo y a sus costes.
Su producto ya se lanzó, y las correcciones de seguridad se acumulan.
Actualizaciones de versión de Yocto Project, actualizaciones del kernel y del bootloader, seguimiento de vulnerabilidades (CVE) y un SBOM. Su producto recibe los parches, y usted lo puede demostrar.
Por qué importa. Los productos conectados necesitan actualizaciones de seguridad durante años. Normas como la Cyber Resilience Act de la UE convierten eso en una obligación.
Sus equipos están en campo, y usted no puede visitarlos.
Actualizaciones remotas (OTA), arranque seguro, acceso remoto e instaladores de producción. Un equipo se aprovisiona en la fábrica y queda seguro en campo.
Por qué importa. Una corrección que necesita una visita al sitio cuesta mucho más que una corrección remota, siempre que la actualización pueda fallar de forma segura.
Sus ingenieros quieren entregar más rápido con agentes de código, y usted quiere tenerlo bajo su control. O su equipo tiene más trabajo listo que ingenieros para hacerlo.
Configuramos el sistema de desarrollo con agentes de código dentro de sus repositorios, con revisión y pruebas listas. Empiece con la modalidad Inicial, o con un Diagnóstico si su caso no es estándar. Después, añada una cola de agentes: los agentes toman los issues listos, y sus ingenieros revisan lo que vuelve.
Por qué importa. Los agentes solo aceleran a un equipo cuando primero se configuran el acceso, la revisión y las pruebas. Sus ingenieros mantienen el control de lo que se entrega.
Los agentes de código escriben, prueban y revisan el código. Sus ingenieros deciden qué construir, y una persona aprueba cada merge.
Configuramos este sistema dentro de su repositorio, bajo control de versiones, junto a su código. Usted lo conserva si dejamos de trabajar juntos. Empezamos este trabajo en 2025. Hoy funciona en nuestros propios productos y en código de clientes en C, Rust y Go.
Pago, corto
Leemos su repositorio, su build y su proceso. Usted recibe una respuesta escrita: dónde ayudan los agentes, dónde no, y qué configurar primero.
Alcance fijo, precio fijo
Configuramos el sistema de desarrollo con IA en un repositorio, para un stack para el que ya tenemos un kit. Es la forma más rápida de verlo funcionar en su propio código.
Todo su código
Configuramos el sistema completo en sus repositorios: los registros del dominio, las reglas del proyecto y los agentes de revisión. Después se lo entregamos a sus ingenieros.
Sin supervisión
Los agentes toman los issues que sus ingenieros marcan como listos, y devuelven pull requests. Su equipo hace más trabajo sin más personas.
Continuo
Mantenemos el sistema actualizado a medida que cambian las herramientas y su código, así no se degrada después de la entrega.
Vive en su repositorio. Está bajo control de versiones, junto a su código. Usted lo conserva si dejamos de trabajar juntos.
Una persona aprueba cada merge. Los agentes escriben, revisan y proponen. Sus ingenieros deciden.
Funciona con código de hardware. Lo usamos en C, Rust y Go, en productos con Yocto Project, Zephyr Project y firmware UEFI.
Los agentes sin supervisión quedan sellados. Cada ejecución tiene un token de una hora para un repositorio, límites de tiempo y de coste, y un interruptor de parada.
En un proyecto de un cliente
Estos son los trabajos de ingeniería que hacemos. Cada uno es una oferta, y no un proyecto pasado.
En actividad desde 2002 · Un commit en meta-freescale cada año desde 2011
Construimos la capa de software entre su hardware y su aplicación. Usted recibe un kernel, un bootloader y un build que sus propios desarrolladores pueden ejecutar.
Su producto ejecuta un árbol del fabricante que nadie actualiza. Lo llevamos a un kernel con soporte a largo plazo (LTS), y así recibe correcciones de seguridad otra vez.
Llevamos un producto de LTIB, Buildroot o LinuxLink PRO a Yocto Project, así un build produce la misma imagen cada vez.
Adaptamos el sistema operativo al producto: qué se inicia, qué está presente, qué tamaño tiene la imagen y cuánto tarda en arrancar.
Construimos su entorno de desarrollo y de integración continua con Nix y NixOS, así un build de hace dos años aún funciona hoy.
Unimos el software al diseño del hardware mientras el hardware aún es una decisión, y no después de que llegan las placas.
Cada uno de estos trabajos dura meses, no días.
Este es el software que nuestros ingenieros escriben y mantienen hoy. Cada fila tiene un registro público que la respalda.
Construimos el sistema de agentes alrededor de su código. Lo usamos en nuestros propios productos y en código de clientes en C, Rust y Go.
Construimos distribuciones Linux a medida con Yocto Project. Contribuimos a OpenEmbedded-Core desde 2011.
Mantenemos meta-freescale, la capa BSP para las plataformas NXP i.MX. También construimos BSP para otro hardware.
Escribimos drivers del kernel y device trees. Nuestros commits están en el árbol mainline desde 2007.
Portamos y configuramos U-Boot. Mantenemos tres placas en el árbol mainline de U-Boot.
Mantenemos seis áreas de Zephyr Project, y el subsistema UpdateHub dentro de él. Escribimos este firmware en C y en C++. También publicamos ZephyrBT, nuestro framework de árboles de comportamiento.
Escribimos software de equipos en C, C++, Rust y Go. Rehicimos el soporte de Go en OpenEmbedded-Core en 2017.
Ejecutamos el firmware en Renode, así una prueba no necesita una placa. Después Twister y Robot Framework ejecutan esas pruebas en integración continua, en cada pull request. Mantenemos el paquete renode en nixpkgs.
Hacemos este trabajo para productos en estos sectores:
Un commit cada año desde 2011, sin interrupción.
Los repositorios son públicos, así usted lo puede confirmar antes de escribirnos.
El fundador aún es el mantenedor nombrado de meta-freescale.
Escriba un párrafo sobre el producto, el silicio y el plazo. Un ingeniero que hace este trabajo lo leerá y le responderá.
O escriba a contato@ossystems.com.br