Fazemos dois tipos de trabalho. Fazemos engenharia no seu Linux embarcado e firmware, e construímos o sistema de desenvolvimento com IA que os seus engenheiros usam para entregá-lo. Escolha o que corresponde ao seu problema.
Pacotes de suporte à placa, migrações de kernel, trabalho em sistemas de build, sistemas operacionais personalizados.
Agentes de código no seu próprio repositório, com a revisão de uma pessoa antes de cada merge.
Conte para nós sobre o seu produto. Ajudamos você a descobrir do que ele precisa e como chegar lá, antes de você se comprometer com qualquer coisa.
Comece pelo problema que você tem hoje. Se dois destes servirem, conte para nós, e um engenheiro vai dizer qual vem primeiro.
A sua equipe está sobrecarregada, é pequena ou é nova em Linux embarcado. O trabalho que bloqueia você não é o trabalho em que você quer gastar o seu tempo.
A forma como a maioria dos clientes trabalha conosco
Trabalhamos como parte da sua equipe. Assumimos o trabalho de Linux embarcado do seu jeito, construímos com os seus engenheiros e revisamos as mudanças deles. Deixamos a equipe capaz de seguir em frente, e você mantém a atenção no seu produto.
Por que isso importa. Linux embarcado é uma especialidade. Um parceiro que já conhece o kernel, o bootloader e o build remove o gargalo sem um plano de contratação.
Você está começando um produto, ou as placas ainda não chegaram.
Da escolha do silício e do módulo até o primeiro boot. Isso inclui o bring-up da placa, o bootloader, o kernel, um build Yocto e um SDK que os desenvolvedores da sua aplicação podem usar.
Por que isso importa. Essas primeiras escolhas decidem por quanto tempo o produto pode ter suporte. Elas custam caro para reverter depois que as placas são fabricadas.
O seu sistema está sobre uma toolchain antiga, ou você herdou uma que não escolheu.
Mude de sistema de build na direção que serve a você. Vá de LTIB, Buildroot ou um SDK do fabricante para o Yocto Project, ou faça o caminho inverso. Leve um kernel antigo do fabricante para um kernel com suporte de longo prazo (LTS). Ou assuma um sistema, para parar de pagar por um suporte de que você não precisa.
Por que isso importa. Um sistema que só um fornecedor consegue construir, ou que ninguém consegue reproduzir, põe em risco cada release futura. Dizemos qual destino serve à sua equipe e aos seus custos.
O seu produto já foi lançado, e as correções de segurança estão se acumulando.
Atualizações de release do Yocto Project, atualizações do kernel e do bootloader, acompanhamento de vulnerabilidades (CVEs) e um SBOM. O seu produto continua com as correções aplicadas, e você pode mostrar isso.
Por que isso importa. Produtos conectados precisam de atualizações de segurança por anos. Regras como o Cyber Resilience Act da UE tornam isso uma obrigação.
Os seus dispositivos estão em campo, e você não pode visitá-los.
Atualizações remotas (OTA), secure boot, acesso remoto e instaladores de produção. Um dispositivo é provisionado na fábrica e continua seguro em campo.
Por que isso importa. Uma correção que exige uma visita ao local custa muito mais que uma enviada remotamente, desde que a atualização possa falhar com segurança.
Os seus engenheiros querem entregar mais rápido com agentes de código, e você quer isso sob o seu controle. Ou a sua equipe tem mais trabalho pronto do que engenheiros para fazê-lo.
Montamos o sistema de desenvolvimento em volta de agentes de código dentro dos seus repositórios, com revisão e testes já preparados. Comece pelo Inicial, ou por um Diagnóstico se o seu caso não for padrão. Depois, adicione uma fila de agentes: os agentes pegam as issues prontas, e os seus engenheiros revisam o que volta.
Por que isso importa. Os agentes só aceleram uma equipe quando o acesso, a revisão e os testes estão preparados antes. Os seus engenheiros continuam no controle do que é entregue.
Agentes de código escrevem, testam e revisam o código. Os seus engenheiros decidem o que construir, e uma pessoa aprova cada merge.
Montamos este sistema dentro do seu repositório, sob controle de versão, ao lado do seu código. Se pararmos, ele fica com você. Começamos este trabalho em 2025. Hoje ele roda nos nossos próprios produtos e em código de clientes em C, Rust e Go.
Pago, curto
Lemos o seu repositório, o seu build e o seu processo. Você recebe uma resposta por escrito: onde os agentes ajudam, onde não ajudam e o que configurar primeiro.
Escopo fixo, preço fixo
Montamos o sistema de desenvolvimento com IA em um repositório, para uma stack para a qual já temos um kit. É o jeito mais rápido de vê-lo funcionar no seu próprio código.
Toda a sua base de código
Montamos o sistema completo nos seus repositórios: os registros de domínio, as regras do projeto e os agentes de revisão. Depois o entregamos aos seus engenheiros.
Autônoma
Os agentes pegam as issues que os seus engenheiros marcam como prontas, e devolvem pull requests. A sua equipe faz mais trabalho sem mais pessoas.
Contínua
Mantemos o sistema atualizado à medida que as ferramentas e a sua base de código mudam, para que ele não se degrade depois da entrega.
Ele vive no seu repositório. Ele fica sob controle de versão, ao lado do seu código. Se pararmos, ele fica com você.
Uma pessoa aprova cada merge. Os agentes escrevem, revisam e propõem. Os seus engenheiros decidem.
Ele funciona com código de hardware. Nós o usamos em C, Rust e Go, em produtos com Yocto Project, Zephyr Project e firmware UEFI.
Os agentes autônomos ficam isolados. Cada execução tem um token de uma hora para um repositório, limites de tempo e de custo, e uma parada de emergência.
Em um projeto de cliente
Estes são os trabalhos de engenharia que assumimos. Cada um é uma oferta, e não um trabalho que já fizemos.
Em atividade desde 2002 · Um commit no meta-freescale todo ano desde 2011
Construímos a camada de software entre o seu hardware e a sua aplicação. Você recebe um kernel, um bootloader e um build que os seus próprios desenvolvedores podem rodar.
O seu produto roda uma árvore do fabricante que ninguém atualiza. Nós o levamos para um kernel com suporte de longo prazo (LTS), e ele volta a receber correções de segurança.
Levamos um produto do LTIB, do Buildroot ou do LinuxLink PRO para o Yocto Project, para que um build gere sempre a mesma imagem.
Moldamos o sistema operacional em volta do produto: o que inicia, o que está presente, o tamanho da imagem e o tempo de boot.
Construímos o seu ambiente de desenvolvimento e de integração contínua com Nix e NixOS, para que um build de dois anos atrás ainda rode hoje.
Unimos o software ao projeto do hardware enquanto o hardware ainda é uma decisão, e não depois que as placas chegam.
Cada um destes trabalhos dura meses, e não dias.
Este é o software que os nossos engenheiros escrevem e mantêm hoje. Cada linha tem um registro público por trás.
Construímos o sistema de agentes em volta do seu código. Nós o usamos nos nossos próprios produtos e em código de clientes em C, Rust e Go.
Construímos distribuições Linux próprias com o Yocto Project. Contribuímos com o OpenEmbedded-Core desde 2011.
Mantemos o meta-freescale, a camada BSP para as plataformas NXP i.MX. Também construímos BSPs para outros hardwares.
Escrevemos drivers de kernel e device trees. Os nossos commits estão na árvore mainline desde 2007.
Portamos e configuramos o U-Boot. Mantemos três placas na árvore mainline do U-Boot.
Mantemos seis áreas do Zephyr Project, e o subsistema UpdateHub dentro dele. Escrevemos esse firmware em C e em C++, e publicamos o ZephyrBT, o nosso framework de árvores de comportamento.
Escrevemos software de dispositivos em C, C++, Rust e Go. Refizemos o suporte a Go no OpenEmbedded-Core em 2017.
Rodamos o firmware no Renode, para que um teste não precise de placa. Depois, o Twister e o Robot Framework executam esses testes na integração contínua, em cada pull request. Mantemos o pacote renode no nixpkgs.
Fazemos este trabalho para produtos nestes segmentos:
Um commit em todos os anos desde 2011, sem lacuna.
Os repositórios são públicos, então você pode confirmar isso antes de nos escrever.
O fundador ainda é o mantenedor designado do meta-freescale.
Escreva um parágrafo sobre o produto, o silício e o prazo. Um engenheiro que faz esse trabalho vai ler e responder para você.
Ou escreva para contato@ossystems.com.br