Desenvolvendo Sistemas Linux Embarcado

Transcrição

Desenvolvendo Sistemas
Linux Embarcado
Embedded Labworks
Por Sergio Prado. São Paulo, Novembro de 2012
® Copyright Embedded Labworks 2004-2013. All rights reserved.
Embedded
Labworks
SOBRE ESTE DOCUMENTO
✗
✗
Este documento é baseado no material de treinamento
disponibilizado pela Free Electrons em:
http://free-electrons.com/doc/training/embedded-linux
Este documento é disponibilizado sob a Licença Creative
Commons BY-SA 3.0.
http://creativecommons.org/licenses/by-sa/3.0/legalcode
✗
Os fontes deste documento estão disponíveis em:
http://e-labworks.com/treinamentos/linux/source
Embedded
Labworks
SOBRE O INSTRUTOR
✗
✗
✗
Sergio Prado tem mais de 15 anos de experiência em desenvolvimento de
software para sistemas embarcados, em diversas arquiteturas de CPU
(ARM, PPC, MIPS, x86, 68K), atuando em projetos com Linux embarcado e
sistemas operacionais de tempo real.
É sócio da Embedded Labworks, onde atua com consultoria, treinamento e
desenvolvimento de software para sistemas embarcados:
http://e-labworks.com
Mantém um blog pessoal sobre Linux e sistemas embarcados em:
http://sergioprado.org
Embedded
Labworks
AGENDA DO TREINAMENTO
✗
✗
✗
DIA 1: Introdução e arquitetura de sistemas Linux embarcado, shell
do Linux, hardware, toolchain, bootloader e kernel.
DIA 2: Sistemas de arquivo, módulos do kernel, dispositivos de
armazenamento e sistemas de build.
DIA 3: Compilando e desenvolvendo bibliotecas e aplicações,
licenças de software, aplicações gráficas em Qt, debugging e
tracing.
Embedded
Labworks
AMBIENTE DE LABORATÓRIO
/opt/labs/
dl/
docs/
guides/
hardware/
training/
videos/
ex/
tools/
Ambiente de laboratório
Aplicações e pacotes opensource
Que serão usados durante as
atividades de laboratório
Documentação
Guias de consulta (shell, vi, etc)
Documentação do hardware
Slides e atividades de laboratório.
Vídeos
Exercícios de laboratório
Ferramentas de uso geral
Embedded
Labworks
ORIENTAÇÕES GERAIS
✗
Pergunte...
✗
Expresse seu ponto de vista...
✗
Troque experiências...
✗
Ajude...
✗
Participe!
Embedded
Labworks
Linux Embarcado
Introdução à Linux embarcado
Embedded
Labworks
OS 3 MARCOS
✗
✗
✗
1970: Engenheiros da Bell Labs, liderados por Ken Thompson e
Dennis Ritchie, criam o sistema operacional UNIX.
1983: Richard Stallman, projeto GNU e o conceito de software livre.
Começa o desenvolvimento do gcc, gdb, glibc e outras ferramentas
importantes.
1991: Linus Torvalds, projeto do kernel Linux, um sistema
operacional UNIX-like. Em conjunto com o projeto GNU, nasce o
sistema operacional GNU/Linux.
Embedded
Labworks
Em 1991...
”I'm doing a (free) operating system (just a
hobby, won't be big and professional like
gnu) for 386(486) AT clones. This has been
brewing since april, and is starting to get
ready. I'd like any feedback on things
people like/dislike in minix, as my OS
resembles it somewhat (same physical
layout of the file-system (due to practical
reasons) among other things).”
Embedded
Labworks
20 ANOS DEPOIS
Embedded
Labworks
VÍDEO (OS 20 ANOS DO LINUX)
Embedded
Labworks
O KERNEL
✗
✗
✗
✗
Linux é o kernel!
http://www.kernel.org
As distribuições Linux (Ubuntu, Fedora, Debian, Slackware, etc)
integram o kernel Linux, bibliotecas e aplicações.
O correto é chamar estas distribuições de sistemas operacionais
GNU/Linux.
Linux embarcado é o uso do kernel Linux e de diversos
componentes open-source em sistemas embarcados.
Embedded
Labworks
PRINCIPAIS CARACTERÍSTICAS
✗
✗
Portabilidade para mais de 20 arquiteturas!
Escalabilidade: o mesmo kernel roda em relógios, em celulares e
em servidores da bolsa de valores!
✗
Livre de royalties.
✗
Roda em dispositivos com pouquíssimos recursos.
Embedded
Labworks
PRINCIPAIS CARACTERÍSTICAS (cont.)
✗
✗
Estabilidade: capaz de rodar por muito tempo sem precisar de um
único reboot.
Modularidade: capaz de rodar apenas o que é necessário para seu
projeto.
✗
Multicore: suporta múltiplas CPU.
✗
Recursos ”infinitos” disponíveis na internet.
Embedded
Labworks
REUSO DE COMPONENTES
✗
✗
✗
Uma das principais vantagens do uso do Linux em sistemas
embarcados: reuso de componentes!
A comunidade open-source já fornece implementações prontas para
as principais funcionalidades dos projetos: suporte à hardware,
protocolos de rede, bibliotecas gráficas, criptografia, etc.
Suporte à hardware. Ex: Linux foi o primeiro kernel a suportar os
padrões USB 2.0, USB 3.0, bluetooth, etc.
✗
Desenvolvimento rápido baseado em componentes prontos.
✗
Foco no seu produto, core business, time-to-market!
Embedded
Labworks
BAIXO CUSTO
✗
✗
✗
Sem royalties: use e abuse de software livre!
Se sua aplicação usa apenas software livre, incluindo as
ferramentas de desenvolvimento, seu custo de software é zero! Seu
único custo será a aquisição de know-how.
Permite que você possa investir mais no hardware e em
treinamento para sua equipe!
Embedded
Labworks
CONTROLE TOTAL
✗
✗
✗
✗
Trabalhando com software livre, você tem o código-fonte de todos
os componentes do seu sistema.
Liberdade para modificar, otimizar, debugar, melhorar.
Não fica preso à prioridade que fornecedores ou terceiros darão ao
seu projeto.
Total controle do software do seu projeto!
Embedded
Labworks
QUALIDADE
✗
✗
✗
✗
Muitos componentes open source são usados em milhares de
sistemas ao redor do mundo.
Normalmente a qualidade é bem melhor que a de softwares
proprietários (muitas pessoas olhando o mesmo problema!).
Permite uma sólida base para seu projeto.
É claro, nem todo software open software é de boa qualidade,
portanto tome cuidado. Procure sempre aqueles mais usados em
outros projetos e com uma comunidade mais ativa.
Embedded
Labworks
SUPORTE DA COMUNIDADE
✗
✗
✗
✗
Componentes open-source são desenvolvidos por uma comunidade
de desenvolvedores e usuários.
As comunidades podem te fornecer suporte de alta qualidade. Você
tem contato inclusive com os principais desenvolvedores dos
projetos.
Geralmente melhor que o suporte em empresas comerciais, mas
você precisa saber como usar corretamente o suporte da
comunidade.
Permite você resolver os problemas mais rapidamente!
Embedded
Labworks
MITOS
✗
Mito 1: ”Linux is Free”.
✗
✗
Linux não é grátis, Linux é livre! Do 2o. parágrafo da GPL: ”When we
speak of free software, we are refering to freedom, not price”.
Mito 2: ”Não consigo proteger a propriedade intelectual do meu
produto”.
✗
Consegue sim, basta tomar alguns cuidados com licenças de
software!
Embedded
Labworks
Linux Embarcado
Arquitetura básica
Embedded
Labworks
ARQUITETURA BÁSICA
Biblioteca
Biblioteca
Toolchain
Biblioteca
Biblioteca
Biblioteca C
Linux kernel
Bootloader
Hardware
Embedded
Labworks
COMPONENTES DO SISTEMA
✗
✗
✗
✗
✗
Hardware: seu produto!
Bootloader: iniciado pelo hardware, responsável pela inicialização
básica, carregamento e execução do kernel Linux.
Kernel Linux: Núcleo do sistema operacional. Gerencia CPU, memória e
I/O, exportando serviços para as aplicações do usuário.
Rootfs: sistema de arquivos principal.
✗
Biblioteca C: interface entre o kernel e as aplicações do usuário.
✗
Bibliotecas e aplicações do usuário.
Toolchain: conjunto de ferramentas para gerar os binários do sistema.
Embedded
Labworks
HARDWARE
Biblioteca
Biblioteca
Toolchain
Biblioteca
Biblioteca
Biblioteca C
Linux kernel
Bootloader
Hardware
Embedded
Labworks
HARDWARE
Embedded
Labworks
CPU
✗
Suporta mais de 25 arquiteturas diferentes (x86, ia64, ARM, PPC, MIPS,
SuperH, Blackfin, Coldfire, etc).
✗
32/64 bits: não foi feito para microcontroladores!
✗
Originalmente projetado para CPUs com MMU (Memory Management Unit).
✗
✗
O projeto uClinux foi criado para que o Linux pudesse ser usado em CPUs
sem MMU.
http://www.uclinux.org/
Mas boa parte do uClinux já foi integrado à árvore oficial do kernel,
possibilitando o uso do Linux em diversas CPUs sem MMU (m68k e arm
sem MMU, H8/300 da Hitachi, ADI Blackfin, etc).
Embedded
Labworks
MEMÓRIA RAM
✗
Um sistema bem básico pode funcionar com até 8MB de RAM.
✗
Ideal para começar: 32MB.
Embedded
Labworks
DISPOSITIVOS DE ARMAZENAMENTO
✗
✗
✗
Suporta armazenamento em memória flash NAND ou NOR.
Suporta dispositivos de armazenamento em bloco, incluindo discos
e cartões SD/MMC.
Um sistema bem básico pode funcionar com 2M de armazenamento
(ou até menos!).
Embedded
Labworks
COMUNICAÇÃO
✗
✗
✗
✗
O Linux suporta muitos barramentos comuns em sistemas
embarcados: I2C, SPI, CAN, 1-wire, SDIO, USB, etc.
E também os principais protocolos de rede: Ethernet, Wi-Fi,
Bluetooth, CAN, IPv4, IPv6, TCP, UDP, etc.
Se o barramento ou protocolo não possuir restrições de licença, é
bem provável que esteja implementado no kernel.
Já protocolos ou barramentos com restrições de licença tem
dificuldade para entrar na árvore oficial do kernel (Ex: Zigbee).
Embedded
Labworks
CRITÉRIOS PARA SELEÇÃO
✗
✗
✗
Certifique-se de que o hardware já é suportado pelo Linux e por um
bootloader open-source.
Suporte nas versões oficiais dos projetos (kernel e bootloader) é
bem melhor: maior qualidade e novas versões disponíveis.
A diferença entre uma plataforma suportada na árvore de projeto
original do kernel, e outra plataforma não suportada de forma
oficial, pode te trazer grandes consequências em termos de custo e
tempo de desenvolvimento!
Embedded
Labworks
TOOLCHAIN
Biblioteca
Biblioteca
Toolchain
Biblioteca
Biblioteca
Biblioteca C
Linux kernel
Bootloader
Hardware
Embedded
Labworks
TOOLCHAIN
✗
✗
Conjunto de ferramentas de programação usadas para gerar
determinado produto, seja um software ou mesmo um sistema
completo.
Quando a plataforma de desenvolvimento (host) é diferente da
plataforma alvo (target), chamamos o toolchain de
cross-compiling toolchain.
Embedded
Labworks
TOOLCHAIN (cont.)
Código-fonte
Host
Cross-compiling toolchain
Toolchain nativo
x86
Binário x86
Target
Binário ARM
x86
ARM
Embedded
Labworks
COMPONENTES DO TOOLCHAIN
✗
Compilador (gcc).
✗
Assembler e Linker (binutils).
✗
Standard C Library (glibc, uclibc, dietlibc, etc).
Embedded
Labworks
TOOLCHAINS PRONTOS
✗
✗
✗
Code Sourcery (ARM):
http://www.codesourcery.com/gnu_toolchains/arm/
MIPS:
http://www.linux-mips.org/wiki/Toolchains
Linaro (ARM):
https://wiki.linaro.org/WorkingGroups/ToolChain
Embedded
Labworks
FERRAMENTAS OPEN SOURCE
✗
✗
Crosstool-ng:
http://crosstool-ng.org/
Buildroot:
http://buildroot.uclibc.org/
Embedded
Labworks
SISTEMA LINUX EMBARCADO
Biblioteca
Biblioteca
Toolchain
Biblioteca
Biblioteca
Biblioteca C
Linux kernel
Bootloader
Hardware
Embedded
Labworks
SISTEMA LINUX EMBARCADO (NA FLASH)
Bootloader
Kernel
Rootfs
Memória flash
Embedded
Labworks
BOOTLOADER
Biblioteca
Biblioteca
Toolchain
Biblioteca
Biblioteca
Biblioteca C
Linux kernel
Bootloader
Hardware
Embedded
Labworks
BOOTLOADER
✗
✗
Todo hardware possui um mecanismo de inicialização, que é
responsável por carregar e executar o bootloader.
O bootloader é responsável por carregar e executar o kernel do
sistema operacional (no nosso caso, o Linux).
Embedded
Labworks
FUNCIONALIDADES DO BOOTLOADER
✗
✗
✗
Inicializar o hardware antes de executar o kernel, como por
exemplo configurar a controladora de SDRAM.
Passar parâmetros para o kernel.
Prover mecanismos para carregar e gravar o kernel e o sistema de
arquivos na memória flash.
✗
Inicializar via rede ou pelo cartão SD.
✗
Rotinas de diagnóstico de hardware.
Embedded
Labworks
PRINCIPAIS BOOTLOADERS
✗
✗
x86:
✗
LILO
✗
Grub
ARM, MIPS, PPC e outras arquiteturas:
✗
U-Boot
✗
Barebox
✗
Redboot
Embedded
Labworks
KERNEL
Biblioteca
Biblioteca
Toolchain
Biblioteca
Biblioteca
Biblioteca C
Linux kernel
Bootloader
Hardware
Embedded
Labworks
INICIALIZAÇÃO BÁSICA
✗
Inicializa CPU, memória e barramentos.
✗
Configura a memória virtual (se tiver MMU).
✗
Inicializa os device drivers.
✗
Inicia o escalonador de tarefas.
✗
Inicia threads do kernel.
✗
Monta sistema de arquivos principal (rootfs) e chama o processo
init.
Embedded
Labworks
CARACTERÍSTICAS DO KERNEL
✗
✗
✗
Gerencia execução de processos e controla acesso à memória e
I/O.
Conceito de kernel space x user space.
Interface de user space com kernel space via chamadas do sistema
(system calls).
✗
Acesso ao hardware via arquivos de dispositivo.
✗
Gerenciamento dinâmico dos módulos do kernel.
Embedded
Labworks
EXEMPLO DE SYSTEM CALL
Embedded
Labworks
ROOTFS
Biblioteca
Biblioteca
Toolchain
Biblioteca
Biblioteca
Biblioteca C
Linux kernel
Bootloader
Hardware
Embedded
Labworks
COMPONENTES BÁSICOS
✗
Biblioteca do sistema (uClibc, glibc, eglibc, dietlibc, etc).
✗
Mecanismo de inicialização.
✗
Bibliotecas e aplicações.
Embedded
Labworks
APLICAÇÕES PARA EMBARCADOS
✗
Dropbear: cliente e servidor SSH (~110K).
✗
Thttpd: servidor web (~88K).
✗
DirectFB: biblioteca gráfica (~1,4MB).
✗
SQLite: Banco de dados (~250KB).
Embedded
Labworks
BUSYBOX
✗
✗
✗
O canivete suíço de sistemas embarcados com Linux!
Combina versões mais leves de ferramentas UNIX em um único
binário, otimizado por tamanho.
Geralmente as ferramentas são mais limitadas em termos de
funcionalidades comparadas às originais.
Embedded
Labworks
BUSYBOX – TUDO ISSO EM ~1MB!
Embedded
Labworks
SISTEMA LINUX
“Desenvolver um sistema Linux embarcado
é como brincar de Lego!”
Embedded
Labworks
BUILD SYSTEM
✗
Um build system é capaz de:
✗
Gerar o toolchain.
✗
Compilar e gerar a imagem do bootloader.
✗
Configurar, compilar e gerar a imagem do kernel.
✗
Configurar, compilar bibliotecas e aplicações, e gerar a imagem final
do rootfs.
Embedded
Labworks
ALGUNS BUILD SYSTEMS
✗
✗
Proprietários:
✗
Monta Vista.
✗
Wind River.
✗
TimeSys.
Open source:
✗
Buildroot.
✗
OpenEmbedded.
✗
Yocto.
✗
PTXdist.
✗
LTIB.
Embedded
Labworks
OS 3 PAPÉIS DO DESENVOLVEDOR
✗
✗
✗
Desenvolvedor de aplicações: desenvolve aplicações Linux.
Integrador: Integra todos os componentes (bootloader, kernel,
bibliotecas e aplicações) em um sistema Linux embarcado.
Desenvolvedor de BSP (Board Support Package): porta o kernel e
o bootloader, desenvolve os device drivers para os dispositivos de
hardware usados no produto, etc.
Nosso foco neste treinamento: integrador e
desenvolvedor de aplicações!
Embedded
Labworks
VAMOS COMEÇAR?
Embedded
Labworks
Linux Embarcado
Ambiente de desenvolvimento
Embedded
Labworks
AMBIENTE DE DESENVOLVIMENTO
✗
Um ambiente de desenvolvimento para Linux embarcado é
composto normalmente por 3 componentes principais:
✗
Toolchain (ferramentas de compilação).
✗
Buildsystem (ferramenta de geração do sistema Linux).
✗
IDE para desenvolvimento e debugging de aplicações.
Embedded
Labworks
SOLUÇÕES
✗
✗
✗
Existem soluções prontas, fornecidas por empresas como
MontaVista, Wind River e TimeSys, com seu próprio ambiente e
ferramentas de desenvolvimento. Elas usam um conjunto de
componentes open-source e proprietários.
Existem também soluções open source, completamente abertas e
suportadas pela comunidade.
No nosso treinamento, usaremos soluções abertas! Aprendendo a
base, migrar depois para outras soluções é bem mais fácil!
Embedded
Labworks
SO DE DESENVOLVIMENTO
✗
✗
✗
É fortemente recomendado o uso do Linux como sistema
operacional para desenvolvimento em Linux embarcado!
Todas as ferramentas disponíveis na comunidade open source
foram feitas para rodar em Linux. Você pode ter problemas em
tentar rodar em outro sistema operacional, e provavelmente não
terá suporte da comunidade.
Usando Linux, você aprende Linux!
Embedded
Labworks
QUE DISTRIBUIÇÃO USAR?
Embedded
Labworks
HOST E TARGET
✗
Host: máquina de desenvolvimento.
✗
Target: hardware, produto, kit de desenvolvimento.
✗
Conectados normalmente por uma conexão serial (RS232, USB,
Ethernet, etc).
Serial
Host
Ethernet
Target
Embedded
Labworks
NOSSA PRINCIPAL FERRAMENTA!
Embedded
Labworks
PERMISSÕES
✗
Linux é um sistema multi-usuário:
✗
✗
✗
root é o usuário administrador que tem permissão para executar
qualquer operação privilegiada como mudar a configuração do
sistema ou montar um sistema de arquivos.
Outros usuários não tem todos os mesmos privilégios de
administração.
Durante o treinamento, para executar operações que necessitem de
privilégios de administrador, usaremos o comando sudo. Exemplo:
$ sudo mount /dev/sdb1 /mnt/usb
Embedded
Labworks
GUIAS DE REFERÊNCIA E ESTUDO
✗
Alguns guias de referência e estudo estão disponíveis no ambiente
de laboratório em docs/guides:
✗
GuiaFocaLinux.pdf (guia foca Linux iniciante/intermediário).
✗
Guia-Ubuntu.pdf (guia do iniciante Ubuntu).
✗
vi.pdf (editor de textos vi).
✗
shell.pdf (linha de comandos do shell).
✗
canivete-shell.pdf (canivete suíço do shell).
✗
lkn.tar.gz (livro Linux Kernel in a Nutshell).
✗
ldd3.tar.bz2 (livro Linux Device Drivers 3ed).
Embedded
Labworks
LABORATÓRIO
Estudando a linha de comandos
Embedded
Labworks
Linux Embarcado
i.MX53 Quick Start Board
Embedded
Labworks
i.MX53 QUICK START BOARD
Embedded
Labworks
CARACTERÍSTICAS
✗
CPU i.MX535 de 1GHz da Freescale (Cortex-A8).
✗
1GB de memória RAM DDR3.
✗
Conector para cartão SD/MMC, microSD e interface SATA.
✗
✗
Saídas de áudio estéreo e vídeo VGA, e entrada para microfone.
Conector de expansão com saídas HDMI, display LCD, câmera e
SDIO.
Interfaces USB host/device, Ethernet, UART, JTAG, botões, leds, etc.
Embedded
Labworks
DIAGRAMA DE BLOCOS
Embedded
Labworks
REFERÊNCIAS E DOCUMENTAÇÃO
✗
✗
A documentação do hardware esta disponível no ambiente de
laboratório em docs/guides:
✗
CPU_DS_iMX53.pdf (i.MX53 datasheet)
✗
BOARD_DS_IMX53.pdf (board reference)
✗
BOARD_UG_IMX53.pdf (user's guide)
✗
BSP_LINUX_mx53.tar.gz (Linux BSP)
Recursos na internet:
http://www.freescale.com/imxquickstart
http://community.freescale.com/community/imx
Embedded
Labworks
CONECTANDO O HARDWARE
Embedded
Labworks
LABORATÓRIO
Conectando e testando o hardware
Embedded
Labworks
Linux Embarcado
Toolchain
Embedded
Labworks
O QUE SÃO TOOLCHAINS?
✗
✗
✗
Ao pé da letra, e traduzindo literalmente, toolchain é uma "corrente
de ferramentas". Na prática, é um conjunto de ferramentas de
compilação.
Você se lembra do processo de compilação de um código em C? Ele
envolve normalmente as seguintes etapas: pré-processamento,
compilação, montagem (assembler) e linkagem.
Cada uma destas etapas é executada por uma ferramenta
(pré-processador, compilador, assembler e linker), e todas elas
fazem parte do toolchain.
Embedded
Labworks
TIPOS DE TOOLCHAIN
✗
✗
✗
✗
As ferramentas de desenvolvimento normalmente disponíveis em um
desktop GNU/Linux são chamadas de toolchain nativo.
Este toolchain roda na sua máquina e compila código para ser executado
na sua máquina, geralmente um x86.
Em desenvolvimento de sistemas embarcados normalmente é complicado
(às vezes até impossível) usar um toolchain nativo, porque precisamos de
bastante espaço em disco, capacidade de processamento, memória, etc.
Portanto, para esta tarefa, o melhor é usar um cross-compiling
toolchain, que roda na sua plataforma de desenvolvimento mas gera
código para a sua plataforma alvo.
Embedded
Labworks
TIPOS DE TOOLCHAIN (cont.)
Código-fonte
Toolchain nativo
Host
Cross-compiling toolchain
x86
Binário x86
Target
Binário ARM
x86
ARM
Embedded
Labworks
COMPONENTES DO TOOLCHAIN
Compilador (GCC)
Biblioteca C padrão
Binutils
Headers do kernel
Debugger (GDB)
Toolchain
Embedded
Labworks
COMPILADOR GCC
✗
✗
✗
Compilador GNU C, o famoso compilador de software livre.
http://gcc.gnu.org/
Compatível com as linguagens C, C++, Ada, Fortran e Java, dentre
outras.
Pode gerar código para diversas arquiteturas, incluindo ARM, AVR,
Blackfin, MIPS, PowerPC, x86, etc.
Embedded
Labworks
BINUTILS
✗
✗
Binutils é um conjunto de ferramentas para manipular arquivos
binários para uma arquitetura específica.
http://www.gnu.org/software/binutils/
Algumas das principais ferramentas disponibilizadas pelo binutils:
✗
as: assembler, gera o binário baseado em um código Assembly.
✗
ld: linker.
✗
ar, ranlib: usadas para gerar arquivos .a (normalmente bibliotecas).
✗
objdump, readelf, size, nm, strings: inspecionar binários.
✗
strip: remove partes não usadas do binário para diminuir seu
tamanho.
Embedded
Labworks
BIBLIOTECA C
✗
✗
✗
O que é a biblioteca C?
✗
Interface entre as aplicações e o kernel.
✗
API para desenvolvimento de aplicações.
O toolchain depende da biblioteca C, já que
ele irá linká-la com sua aplicação para
gerar os binários para a arquitetura-alvo.
Diversas bibliotecas C estão disponíveis:
glibc, eglibc, uClibc, dietlibc, etc.
Aplicações
Biblioteca C
Kernel
Embedded
Labworks
GLIBC
✗
Biblioteca C do projeto GNU.
http://www.gnu.org/software/libc/
✗
Usada em boa parte dos sistemas GNU/Linux (desktop e servidores).
✗
Projetada com foco em performance e portabilidade.
✗
✗
Dependendo do seu sistema, pode não ser uma boa escolha, já que possui um
consumo considerável de espaço em disco/flash e memória RAM.
Existe uma variante chamada eglibc (embedded glibc) compatível com a glibc
(binário e código-fonte) e com foco em sistemas embarcados. Atualmente a
eglibc é usada inclusive em algumas distribuições Linux.
Embedded
Labworks
UCLIBC
✗
✗
✗
Mais leve e projetada para sistemas embarcados.
http://www.uclibc.org/
Foco maior na economia de recursos do que na performance.
Em uma arquitetura ARM, chega a ser 4 vezes menor que a glibc, com
aproximadamente 600K!
✗
Altamente configurável.
✗
Comunidade de desenvolvimento do projeto bem ativa.
✗
Usada em grande parte do dispositivos de consumo com Linux embarcado.
Embedded
Labworks
COMPARANDO GLIBC E UCLIBC
Comparação realizada em uma arquitetura ARM
Embedded
Labworks
KERNEL HEADERS
✗
Sabemos que o toolchain depende da biblioteca C do sistema.
✗
Mas a biblioteca C, por sua vez, depende do kernel! Por que?
✗
✗
✗
Chamadas de sistema.
✗
Definições de constantes.
✗
Estruturas de dados.
Por isso, para compilar a biblioteca C, o toolchain precisa dos
arquivos de cabeçalho do kernel.
Disponíveis em <linux/...>, <asm/...> e alguns outros diretórios
dentro do diretório include nos fontes do kernel.
Embedded
Labworks
KERNEL HEADERS (EXEMPLOS)
✗
Números das chamadas de sistema em <asm/unistd.h>:
#define __NR_exit 1
#define __NR_fork 2
#define __NR_read 3
✗
Definições de constantes em <asmgeneric/fcntl.h>:
#define O_RDWR 00000002
✗
Estruturas de dados em <asm/stat.h>:
struct stat {
unsigned long st_dev;
unsigned long st_ino;
[...]
};
Embedded
Labworks
USANDO TOOLCHAINS
✗
Existem basicamente duas soluções para instalar e usar um
toolchain:
1. Usar um toolchain pronto, fornecido por uma empresa ou pela
comunidade.
2. Configurar e gerar seu próprio toolchain de acordo com suas
necessidades.
Embedded
Labworks
USANDO UM TOOLCHAIN PRONTO
✗
Solução adotada em muitos projetos:
✗
✗
✗
✗
Vantagem: simples e conveniente.
Desvantagem: inflexível, você não consegue otimizar o toolchain de acordo
com suas necessidades.
Possíveis escolhas:
✗
Toolchain fornecido pelo fabricante do chip (ex: Freescale).
✗
Toolchain fornecido por empresas especializadas (ex: Mentor Graphics).
✗
Toolchain fornecido pela comunidade (ex: Linaro).
Uma referência bem completa de toolchains em:
http://elinux.org/Toolchains
Embedded
Labworks
INSTALANDO E USANDO
✗
Basta seguir o procedimento do fornecedor da solução.
✗
Normalmente, estes são os passos:
✗
Baixar e descompactar a toolchain em um diretório na sua máquina.
✗
Adicionar no PATH o diretório onde se encontram os binários:
export PATH=/path/to/toolchain/bin/:$PATH
✗
Compilar sua aplicação usando o toolchain:
PREFIXgcc teste.c o teste
✗
O PREFIX depende da configuração do toolchain, e permite
diferenciar toolchains nativos de toolchains para cross-compilação.
Embedded
Labworks
LABORATÓRIO
Instalando e testando um toolchain pronto
Embedded
Labworks
GERANDO SEU PRÓPRIO TOOLCHAIN
✗
Gerar um toolchain manualmente é uma tarefa difícil e dolorosa!
Pode levar muitos dias!
✗
✗
É necessário aprender muitos detalhes, muito componentes para
configurar e compilar.
Muitas decisões para serem feitas manualmente: versão da
biblioteca C, headers do kernel, binutils, etc.
✗
Precisa dos headers do kernel e dos fontes de todos os componentes.
✗
Precisa estar familiarizado com o gcc.
✗
Algumas plataformas necessitam que sejam aplicados patches em
alguns componentes antes de compilar.
Embedded
Labworks
USANDO FERRAMENTAS
✗
✗
✗
Existem ferramentas que automatizam o processo de geração de
toolchains.
Você não precisa se preocupar com o processo de geração do
toolchain, dependências, patches, etc.
E por outro lado, estas ferramentas oferecem a flexibilidade de
configuração e seleção dos componentes do toolchain e de suas
versões.
Embedded
Labworks
ALGUMAS FERRAMENTAS
✗
✗
✗
✗
✗
Crosstool (suporta apenas glibc):
http://www.kegel.com/crosstool
Crosstool-ng (suporta glibc, uClibc, eglibc):
http://crosstool-ng.org/
Buildroot (sistema de build completo, apenas uClibc):
http://www.buildroot.net
PTXDist (suporta uClibc ou glibc):
http://www.pengutronix.de/software/ptxdist/index_en.html
OpenEmbedded (sistema de build completo):
http://www.openembedded.org/
Embedded
Labworks
LABORATÓRIO
Compilando seu próprio toolchain com o crosstool-ng
Embedded
Labworks
Linux Embarcado
Bootloader
Embedded
Labworks
BOOTLOADERS
✗
O bootloader é o código responsável por:
✗
✗
✗
✗
Inicialização básica do hardware.
Carregar outro binário (normalmente um sistema operacional) da
memória flash, da rede ou de outro dispositivo de armazenamento
não volátil para a RAM.
Passar o controle da CPU para este binário.
Além destas funcionalidades básicas, a maioria dos bootloaders
possui uma linha de comandos para a execução de diferentes
operações, como verificação de memória, formatação da flash e
rotinas de diagnóstico.
Embedded
Labworks
BOOTLOADERS NO X86
✗
✗
✗
✗
BIOS
em ROM
Plataformas x86 normalmente vem acompanhadas de uma
memória não-volátil, a BIOS.
Um programa na BIOS é executado no boot do equipamento, que
faz a inicialização básica do hardware, carrega para a memória e
executa os primeiros 512 bytes do dispositivo de boot. Estes 512
bytes também são chamados de MBR.
A MBR é o bootloader de 1o. estágio, que é o responsável por
carregar um bootloader de 2o. estágio do disco para a RAM.
O bootloader de 2o. estágio é mais completo, entende sistemas
de arquivo, consegue ler o sistema operacional do disco e
carregar para a memória.
Estágio 1
512 bytes
do disco
Estágio 2
do disco
SO
do disco
Embedded
Labworks
BOOTLOADERS NO X86 (cont.)
✗
✗
✗
LILO, já foi bastante utilizado, mas caiu em desuso.
http://lilo.alioth.debian.org/
GRUB, Grand Unified Bootloader, é o mais poderoso e o padrão
atualmente em desktops e servidores.
http://www.gnu.org/software/grub/
Syslinux, mais utilizado em boot pela rede e por mídias removíveis
(floppy disk, pendrive, CD/DVD, etc).
http://www.syslinux.org/
Embedded
Labworks
BOOT EM CPUs EMBARCADAS
✗
✗
✗
✗
Memória
física
Quando alimentada, a CPU começa a execução em
um endereço fixo.
Não existe nenhum mecanismo de boot provido
pela CPU ou pela plataforma.
O projeto de hardware deve garantir que a
memória flash esteja com seu barramento de
endereços ligados corretamente, de forma que o
endereço de início de execução das instruções
esteja acessível pela CPU.
Solução comum em microcontroladores.
Execução
começa aqui
NOR flash
RAM
Embedded
Labworks
BOOT EM CPUs EMBARCADAS (cont.)
✗
✗
✗
✗
Memória
física
Neste caso, como o código é executado direto da flash (XIP),
o uso de memórias flash NOR é obrigatório.
Mas como o Linux precisa de pelo menos alguns MBs de
memória, o uso de flash NOR é inviável por ser muito mais
cara. Por este motivo, o Linux usa normalmente memórias
flash NAND.
Execução
começa aqui
NOR flash
Mas como não conseguimos executar código diretamente de
memórias flash NAND, precisamos de RAM.
E quem irá configurar a controladora da SDRAM e carregar o
código da flash para a RAM no boot do equipamento? O
bootloader!
RAM
Embedded
Labworks
BOOT EM LINUX EMBARCADO
✗
Em Linux embarcado, e principalmente em plataformas ARM, é
muito comum termos um processo de boot dividido em 3 estágios:
1. A CPU tem um código de boot integrado em uma ROM interna,
responsável por carregar o bootloader de 1o. estágio de uma unidade
de armazenamento não volátil para a memória RAM interna (SRAM ou
IRAM).
2. O bootloader de 1o. estágio deve inicializar o hardware (CPU, DRAM,
GPIOs, etc) e carregar um bootloader de 2o. estágio para a RAM.
3. O bootloader de 2o. estágio carrega o sistema operacional (kernel
Linux) para a RAM e executa.
Embedded
Labworks
LPC3250 (NXP)
ROM Code
Kickstart/S1L
Tenta o boot pela porta serial (modo de serviço), SPI,
barramento externo e flash NAND, carregando o código para a
SRAM (56KB).
Kickstart roda da SRAM, inicializa hardware e carrega o stage 1
loader, um bootloader completo que possui diversas funções
para configurar o hardware. O S1L carrega o bootloader de 2o.
estágio para a RAM.
U-Boot
Roda da RAM. Inicializa alguns dispositivos de hardware (rede,
USB, etc). Carrega a imagem do kernel na RAM e passa o
controle para ele.
Linux Kernel
Roda da RAM. Assume o controle do sistema (a partir daqui, o
bootloader não existe mais).
Embedded
Labworks
i.MX28 (FREESCALE)
ROM Code
Bootlets
Código de boot em ROM iniciado quando o i.MX28 é resetado. Lê
as chaves de seleção do modo de boot para identificar a fonte
do boot (USB, SD/MMC, NAND, I2C, SPI, JTAG).
O ROM code trabalha com o conceito de boot stream, um
conjunto de bootlets, que são pequenos executáveis para
extender o bootloader, como o “power_prep” (configura PM) e o
“boot_prep” (configura a memória SDRAM e carrega o U-Boot).
U-Boot
Inicializa alguns dispositivos de hardware (rede, USB, etc).
Carrega a imagem do kernel na RAM e passa o controle para
ele.
Linux Kernel
Embedded
Labworks
i.MX53 (FREESCALE)
ROM Code
U-Boot (1)
Código de boot em ROM iniciado quando o i.MX53 é resetado. Lê
o registrador BOOT_MODE ou um conjunto de GPIOs para
determinar o dispositivo de boot (NOR/NAND, cartão SD/MMC,
SATA, etc).
Carrega “um pedaço” do U-Boot para a RAM interna (72K). Este
código do U-Boot irá inicializar o hardware (clock, SDRAM, etc)
e carregar o U-Boot completo para a RAM.
U-Boot (2)
Inicializa alguns dispositivos de hardware (rede, USB, etc).
Carrega a imagem do kernel na RAM e passa o controle para
ele.
Linux Kernel
Embedded
Labworks
OMAP3530/AM35x (TI)
ROM Code
Procura por imagens de boot na NAND, UART, USB e MMC, e
carrega para a SRAM (64KB). Um botão pode mudar a ordem da
busca.
X-Loader
Roda da SRAM. Inicializa a controladora da SDRAM, NAND ou
MMC, e carrega o bootloader de 2o. estágio para a RAM.
U-Boot
controle para ele.
Linux Kernel
Embedded
Labworks
AT91 (ATMEL)
ROM Code
Procura por imagens de boot em diversos dispositivos de
armazenamento, e carrega para a SRAM (4KB).
AT91Bootstrap
Roda da SRAM. Inicializa a controladora da DRAM e carrega o
bootloader de 2o. estágio para a RAM.
U-Boot
controle para ele.
Linux Kernel
Embedded
Labworks
BOOTLOADERS EM LINUX EMBARCADO
✗
✗
O bootloader de 1o. estágio é normalmente fornecido pelo
fabricante do chip, e cada plataforma tem o seu. Nosso foco é no
bootloader de 2o. estágio.
Existem alguns bootloaders open source. Dentre eles, os dois mais
conhecidos e utilizados são:
✗
✗
U-Boot: bastante popular em ARM, mas também usado em outras
arquiteturas como MIPS e PPC.
http://www.denx.de/wiki/U-Boot
Barebox: sucessor do U-Boot, melhor projeto, melhor código,
desenvolvimento ativo, mas ainda com pouco suporte à hardware.
http://www.barebox.org
Embedded
Labworks
U-BOOT
✗
✗
✗
✗
Bootloader open-source (GPLv2) mais utilizado atualmente.
Suporta uma grande variedade de CPUs, incluindo PPC, ARM, MIPS,
Coldfire, x86, etc.
Desde 2008, segue um intervalo fixo de release, onde a cada dois
ou três meses uma versão é liberada (as versões são nomeadas
com o formato YYYY.MM).
Documentação disponível em:
http://www.denx.de/wiki/U-Boot/Documentation
Embedded
Labworks
FUNCIONALIDADES DO U-BOOT
✗
Exibir informações do hardware (memória, periféricos, etc).
✗
Manipular a RAM (ler, escrever, comparar, testar, etc).
✗
Manipular memórias flash (ler, escrever, apagar, etc).
✗
Boot via memória flash.
✗
Boot via rede (bootp, tftp, dhcp, serial).
Embedded
Labworks
FUNCIONALIDADES DO U-BOOT (cont.)
✗
Boot por interfaces SD/MMC ou USB.
✗
Entende partições FAT.
✗
Configuração por variáveis de ambiente e suporte à scripts.
✗
Executa código bare-metal.
✗
Carrega e executa imagens do kernel Linux.
✗
Etc!
Embedded
Labworks
BAIXANDO O U-BOOT
✗
✗
✗
✗
É de responsabilidade do fabricante disponibilizar os fontes do U-Boot
(porte) para a sua plataforma.
O fabricante pode fazer isso e enviar o código para a árvore principal do
projeto (mainline). Neste caso, os fontes podem ser baixados no site do
projeto em:
Mas nem sempre o fabricante faz isso! Neste caso, o fabricante irá
disponibilizar os fontes em um outro local, provavelmente no seu site junto
com o BSP (Board Support Package) da plataforma.
Portanto, consulte a documentação da sua plataforma para saber como e
onde baixar os fontes do U-Boot.
Embedded
Labworks
CONFIGURANDO O U-BOOT
✗
O U-Boot suporta diversas arquiteturas e plataformas. Antes de
compilar o U-Boot, você precisa configurá-lo para a sua
plataforma com o comando abaixo:
make <board>_config
✗
Substitua <board> pelo nome da sua plataforma no U-Boot. Por
exemplo, para configurar o U-Boot para o kit de desenvolvimento
i.MX53 Quick Start Board:
make mx53_loco_config
Embedded
Labworks
COMPILANDO O U-BOOT
✗
Para compilar o U-Boot, basta executar o comando make passando o prefixo
do cross-compiler. Exemplo:
make CROSS_COMPILE=armlinux
✗
✗
✗
Não se esqueça de incluir na variável de ambiente PATH o caminho do diretório
do toolchain.
No final, será gerada a imagem do u-boot para ser gravada no target.
Se você quiser fazer uma compilação limpa, ou configurar o U-Boot para outra
placa, execute antes o comando abaixo para fazer a limpeza:
make mrproper
Embedded
Labworks
GRAVANDO O U-BOOT
✗
O processo de gravação do U-Boot pode ser feito de diferentes
formas, dependendo do target:
✗
✗
✗
O bootloader de 1o. estágio pode fornecer um mecanismo de escrita
na flash.
O sistema pode ser configurado para iniciar por uma mídia removível
(Ex: cartão SD).
A CPU pode fornecer um monitor de boot que se comunica via serial
ou USB.
✗
JTAG.
✗
Etc!
Embedded
Labworks
LABORATÓRIO
Compilando e gravando o U-Boot
Embedded
Labworks
Linux Embarcado
Kernel Linux
Embedded
Labworks
VISÃO GERAL
Aplicação
Aplicação
Biblioteca
Biblioteca
Aplicação
User space
Biblioteca C
Chamadas de sistema
Notificação de eventos
Exportação de informações
Kernel
Gerenciamento do hardware
Notificação de eventos
Hardware
Embedded
Labworks
HISTÓRICO
✗
✗
✗
✗
O kernel é um dos componentes do sistema operacional, que requer
bibliotecas e aplicações para prover funcionalidades aos usuários.
Criado em 1991 pelo estudante finlandês Linus Torvalds, começou
a ser usado rapidamente como sistema operacional em projetos de
software livre.
Linus Torvalds foi capaz de criar uma comunidade grande e
dinâmica de desenvolvedores e usuários ao redor do projeto.
Atualmente, centenas de pessoas e empresas contribuem com o
projeto.
Embedded
Labworks
COLABORAÇÃO
Embedded
Labworks
ARQUITETURA
Embedded
Labworks
GERENCIAMENTO DE PROCESSOS
✗
✗
✗
✗
✗
Um processo é um programa em execução, que possui um identificador (PID) e
esta associado à um conjunto de recursos como arquivos abertos, mapeamento
de memória, etc.
Um processo contém uma ou mais linhas de execução, chamadas de threads.
Cada thread possui um contador de programa, uma região do stack e uma cópia
dos registradores da CPU.
Internamente, o Linux não diferencia processos e threads. Uma thread nada mais
é do que um processo que compartilha recursos com outras threads!
Por este motivo, o Linux escalona threads, e não processos.
Embedded
Labworks
GERENCIAMENTO DE PROCESSOS (cont.)
✗
✗
✗
✗
Trade-off entre capacidade de processamento e tempo de resposta
(latência).
O Linux é um sistema multitasking preemptivo.
Ele possui o conceito de classes de escalonador, onde cada classe
possui um algoritmo de escalonamento, que decide qual processo
deve ser executado, quando e por quanto tempo.
O escalonador padrão do Linux é o CFS (Completely Fair
Scheduler), onde cada processo recebe uma "porcentagem justa"
da CPU (foco em performance).
Embedded
Labworks
GERENCIAMENTO DE PROCESSOS (cont.)
✗
✗
✗
✗
Possui também um escalonador para processos de tempo real, que
tem prioridade sobre o CFS.
Mas mesmo assim, o Linux não pode ser considerado um sistema
operacional determinístico (em alguns trechos do código a latência
para atender um pedido de interrupção pode ser muito grande).
Existem um conjunto de patches (PREEMPT_RT) que podem ser
aplicados no kernel e melhorar este cenário de alta latência.
Uma opção para o uso do Linux em aplicações hard real-time é a
utilização de um kernel de tempo real em conjunto com o Linux
(RTLinux, RTAI, Xenomai).
Embedded
Labworks
GERENCIAMENTO DE MEMÓRIA
✗
✗
✗
O Linux trabalha com o mecanismo de memória virtual para
gerenciar a memória do sistema.
Em um sistema com memória virtual, todo o acesso à memória do
sistema é realizado através de endereços virtuais, que são
convertidos (por hardware) para endereços físicos durante o
acesso à memória do sistema.
A MMU (Memory Management Unit) é o hardware que implementa o
mecanismo de memória virtual, gerenciando a memória do sistema
e fazendo a conversão entre endereços de memória físicos e
virtuais.
Embedded
Labworks
GERENCIAMENTO DE MEMÓRIA (cont.)
✗
Um sistema com MMU é capaz de prover:
✗
✗
✗
✗
✗
Maior endereçamento de memória para os processos: em uma
arquitetura de 32 bits, os processos tem acesso à um endereçamento
linear de 4G de memória virtual.
Proteção: cada processo só enxerga seu espaço de endereçamento,
onde um acesso inválido gera uma exceção (segmentation fault).
Memory mapping: possibilidade de mapear um arquivo físico em
memória.
Compartilhamento: os processos podem compartilhar memória (código,
dados, etc), usado por exemplo em mecanismos de IPC.
SWAP: se faltar memória física, possibilita salvar e recuperar páginas
de memória do disco.
Embedded
Labworks
SISTEMA DE ARQUIVO VIRTUAL
✗
✗
O Linux é fortemente baseado em arquivos (quase tudo no sistema
é representado por um arquivo).
O kernel implementa a camada VFS (Virtual Filesystem) que
abstrai o acesso aos arquivos, possibilitando que rotinas de acesso
ao arquivo (open, read, write, close, etc) sejam mapeadas para
diferentes destinos.
Embedded
Labworks
SISTEMA DE ARQUIVO VIRTUAL (cont.)
✗
Exemplo 1: Mapeando um arquivo físico em um dispositivo de
armzenamento (copiando um arquivo do HD para um pendrive):
cp /usr/sbin/app /mnt/pendrive/
✗
Exemplo 2: Mapeando um arquivo virtual (listando a estatística de
uso de memória do sistema):
cat /proc/meminfo
✗
Exemplo 3: Mapeando o acesso ao hardware (escrevendo na porta
serial):
echo "Teste" > /dev/ttyS0
Embedded
Labworks
KERNEL SPACE x USER SPACE
✗
✗
✗
Existe uma separação bem definida entre o kernel (kernel space) e
as bibliotecas e aplicações do usuário (user space).
O kernel roda em modo privilegiado, com total acesso à todas as
instruções da CPU, endereçamento de memória e I/O, enquanto que
os processos do usuário rodam em modo restrito, com acesso
limitado aos recursos da máquina.
Por isso, existe uma interface de comunicação, baseada chamadas
de sistema (system calls), para que as bibliotecas e aplicações
tenham acesso aos recursos da máquina.
Embedded
Labworks
CHAMADAS DE SISTEMA
✗
✗
✗
✗
O Linux possui aproximadamente 300 chamadas de sistema.
Operações em arquivos, operações de rede, comunicação entre
processos, gerenciamento de processos, mapeamento de memória,
timers, threads, mecanismos de sincronização, etc.
As chamadas de sistema são abstraídas pela biblioteca C padrão. As
aplicações normalmente não precisam fazer uma chamada direta.
Tudo é feito através da biblioteca C padrão.
A interface de chamadas de sistema é bem estável. Durante novas
versões do kernel, apenas novas chamadas de sistema são
adicionadas.
Embedded
Labworks
VERSIONAMENTO
✗
Antes da versão 2.6:
✗
Uma árvore de versões estáveis (1.0, 2.0, 2.2, 2.4).
✗
Uma árvore de versões de desenvolvimento (2.1, 2.3, 2.5).
✗
A partir de 2003, apenas uma árvore: 2.6.X.
✗
Em 2011, a versão mudou para 3.0.
Embedded
Labworks
CICLO DE RELEASE
✗
✗
✗
Processo de desenvolvimento a cada aproximadamente 3 meses.
✗
Merge window: 2 semanas (até sair 3.X-rc1).
✗
Bug fixing: 6 a 10 semanas (3.X-rc2, 3.X-rc3, etc).
Em aproximadamente 3 meses temos a liberação do release final
3.X.
Para acompanhar as mudanças no kernel:
http://wiki.kernelnewbies.org/LinuxChanges
http://lwn.net
Embedded
Labworks
FONTES DO KERNEL
✗
✗
A versão oficial do código-fonte do kernel liberada por Linus
Torvalds encontra-se em:
Baixando os fontes por http:
wget http://www.kernel.org/pub/linux/kernel/v3.0/linux3.6.tar.bz2
tar xjfv linux3.6.tar.bz2
✗
Baixando os fontes pelo git:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Embedded
Labworks
FONTES DO KERNEL (cont.)
✗
Muitas comunidades e fabricantes de hardware podem manter versões
alternativas do kernel:
✗
✗
✗
✗
Fabricantes de hardware podem manter versões específicas do kernel com
suporte às suas plataformas de referência (BSP).
Comunidades podem manter versões do kernel voltadas à arquiteturas
específicas (ARM, MIPS, PPC), sub-sistemas (USB, PCI, network), sistemas
de tempo-real, etc.
Normalmente nestas versões alternativas são disponibilizados os
patches para serem aplicados em uma determinada versão do kernel.
Portanto, consulte a documentação da sua plataforma para saber como
e onde baixar os fontes do Linux.
Embedded
Labworks
TAMANHO DOS FONTES DO KERNEL
✗
✗
✗
Fontes do kernel 3.4.9:
✗
Tamanho total: 518MB
✗
~38.600 Arquivos
✗
~15.400.000 linhas de código
Porque os fontes são tão grandes? Milhares de drivers de
dispositivo, diversos protocolos de rede, suporte a diferentes
arquiteturas e plataformas.
O core do kernel é bem pequeno!
Embedded
Labworks
TAMANHO DOS FONTES DO KERNEL (cont.)
Linux 2.6.39
Embedded
Labworks
LICENÇA
✗
✗
Todo o código-fonte do Linux é software livre e liberado sob a
licença GPLv2.
Isso significa que:
✗
✗
Quando você receber ou comprar um equipamento com Linux
embarcado, você tem o direito de requisitar os fontes, alterá-los e
redistribuí-los!
Quando você produzir um equipamento com Linux embarcado, você
precisa liberar os fontes do kernel sob as mesmas condições, sem
restrições.
Embedded
Labworks
LICENÇA (cont.)
✗
✗
Portanto, é ilegal distribuir um binário do kernel com módulos
compilados estaticamente.
Os módulos do kernels são uma área cinza: é um trabalho derivado
do kernel ou não?
✗
✗
✗
A opinião geral da comunidade é de que drivers fechados são ruins.
Sob um ponto de vista legal, cada driver é provavelmente um caso
diferente. Ex: Nvidia.
É realmente útil manter um driver proprietário?
Embedded
Labworks
VANTAGENS DE DRIVERS GPL
✗
✗
✗
✗
Você não precisa escrever um driver do zero, podendo reusar o
código de outros drivers.
Você pode integrar o seu driver na árvore oficial do kernel, e não se
preocupar com qualquer alteração em APIs internas do Linux. Custo
zero de manutenção e melhorias no driver!
Com drivers abertos você tem suporte da comunidade, com mais
pessoas revisando e colaborando com seu driver.
Os usuários e a comunidade tem uma visão positiva da empresa.
Embedded
Labworks
LABORATÓRIO
Baixando e estudando os fontes do kernel
Embedded
Labworks
CONFIGURANDO O KERNEL
✗
✗
✗
✗
O kernel possui centenas de drivers de dispositivo, diversos
protocolos de rede e muitos outros itens de configuração.
O kernel é bem modular, milhares de opções estão disponíveis para
serem habilitadas ou desabilitadas.
O processo de configuração serve para você configurar o kernel
para ser compilado para sua CPU/plataforma.
O conjunto de opções que você irá habilitar depende:
✗
Do seu hardware (device drivers, etc).
✗
Das funcionalidades (protocolos de rede, sistemas de arquivo, etc).
Embedded
Labworks
CONFIGURAÇÃO
✗
As configurações são salvas em um arquivo chamado .config no diretório
principal dos fontes do kernel, e possuem o formato key=value. Exemplo:
CONFIG_ARM=y
✗
Dificilmente você vai precisar editar o arquivo .config manualmente. Existem
ferramentas de interface gráfica para configurar o kernel e gerar o arquivo
de configuração automaticamente:
make menuconfig
make gconfig
make xconfig
make nconfig
Embedded
Labworks
make xconfig
Embedded
Labworks
make gconfig
Embedded
Labworks
make nconfig
Embedded
Labworks
make menuconfig
Embedded
Labworks
CONFIGURANDO O KERNEL (cont.)
✗
✗
O kernel é um binário único, resultado do processo de linkagem de
todos os arquivos-objeto das funcionalidades que você habilitou,
incluindo os device drivers.
O kernel permite que algumas funcionalidades possam ser
habilitadas e compiladas de duas formas:
✗
✗
Estática ou built-in: a funcionalidade selecionada é linkada
estaticamente à imagem final do kernel.
Dinâmica ou módulo: é gerado um módulo daquela funcionalidade
(arquivo com extensão .ko). Este módulo não é incluido na imagem final
do kernel. Ele é incluido no sistema de arquivos e pode ser carregado
dinamicamente (em tempo de execução), conforme a necessidade.
Embedded
Labworks
OPÇÕES DE CONFIGURAÇÃO
✗
Opções booleanas (verdadeiro/falso):
[ ] → Opção desabilitada
[*] → Opção habilitada
✗
Opções de 3 estados:
< > → Opção desabilitada
<*> → Opção habilitada (builtin)
<M> → Opção habilitada (módulo)
✗
Números inteiros. Ex: (17) Kernel log buffer size
✗
Strings. Ex: (iso88591) Default iocharset for FAT
Embedded
Labworks
DEPENDÊNCIAS
✗
Na configuração do kernel, podem existir dependências entre
funcionalidades:
✗
✗
Exemplo 1: o driver de um dispositivo I2C depende da habilitação do
barramento I2C para ser habilitado.
Exemplo 2: o driver do barramento USB é habilitado automaticamente
quando o driver de um dispositivo USB é habilitado.
Embedded
Labworks
CONFIGURAÇÃO POR ARQUITETURA
✗
✗
Toda a configuração do kernel é dependente da arquitetura.
Por padrão, o kernel considera uma compilação nativa, então irá usar a
arquitetura da máquina de desenvolvimento (normalmente x86) no comando
abaixo:
make menuconfig
✗
Portanto, para configurar para ARM por exemplo, você precisa especificar a
arquitetura:
make ARCH=arm menuconfig
✗
Ao invés de passar a variável ARCH na chamada do make, você pode também
definí-la como variável de ambiente ou alterar o arquivo Makefile do diretório
principal do kernel.
Embedded
Labworks
CONFIGURAÇÕES PRÉ-DEFINIDAS
✗
✗
Arquivos de configuração pré-definidos para diversas plataformas
estão disponíveis em arch/<arch>/configs/.
O uso de arquivos pré-configurados é a forma padrão de configurar
um kernel para uma plataforma específica. Por exemplo, para
carregar a configuração padrão do kit de desenvolvimento i.MX53
Quick Start Board:
make imx5_defconfig
✗
Se você mexeu na configuração padrão e deseja salvá-la, pode
criar uma cópia conforme exemplo abaixo:
cp .config arch/<arch>/configs/myconfig_defconfig
Embedded
Labworks
VALIDANDO O ARQUIVO DE CONFIGURAÇÃO
✗
O comando abaixo faz a validação e a consistência do arquivo de
configuração do kernel:
make oldconfig
✗
✗
Ele avisa e configura automaticamente parâmetros e dependências
que antes não existiam.
Deve ser usado sempre que:
✗
Você alterar o arquivo .config manualmente.
✗
Você reutilizar o mesmo .config em diferentes versões do kernel.
Embedded
Labworks
LABORATÓRIO
Configurando o kernel
Embedded
Labworks
COMPILANDO O KERNEL
✗
Depois de configurado, para compilar nativamente basta executar:
make
✗
✗
Não precisa de previlégios de root!
Para cross-compilar, você precisa indicar a arquitetura e o prefixo do
cross-compiler. Exemplo:
make ARCH=arm CROSS_COMPILE=armlinux
✗
O comando acima irá gerar uma imagem genérica para ARM. Se você
quiser gerar uma imagem específica para determinado bootloader, deve
adicionar ao fim do comando o nome da imagem. Exemplo para o U-Boot:
make ARCH=arm CROSS_COMPILE=armlinux uImage
Embedded
Labworks
COMPILANDO O KERNEL (cont.)
✗
Ao fim do processo de compilação, serão geradas as seguintes imagens:
✗
✗
✗
vmlinux: gerada no diretório raiz dos fontes, é a imagem do kernel no
formato ELF, que não é bootavel, mas pode ser usada para debugging.
Módulos do kernel: arquivos com extensáo .ko dentro dos respectivos
diretórios dos drivers.
Em arch/<arch>/boot/:
✗
✗
✗
Image: imagem final do kernel, bootável e descomprimida.
*Image: imagem bootável e comprimida do kernel (bzImage para x86,
zImage para ARM, etc).
uImage: imagem do kernel para o U-Boot (opcional).
Embedded
Labworks
INSTALANDO O KERNEL
✗
Para instalar o kernel, basta executar o comando abaixo:
make install
✗
✗
✗
Este comando irá instalar os seguintes arquivos no diretório /boot:
✗
vmlinuz-<version> (imagem do kernel comprimida)
✗
System.map-<version> (endereços dos símbolos do kernel)
✗
config-<version> (arquivo de configuração do kernel)
Normalmente não é usado em sistemas embarcados!
Em sistemas embarcados, normalmente gravamos o kernel em um
dispositivo de armazenamento (cartão SD, memória flash, etc).
Embedded
Labworks
FAZENDO A LIMPEZA
✗
Remove todos os arquivos gerados (imagens, arquivos-objeto, etc).
make clean
✗
Remove todos os arquivos de gerados e arquivos de configuração
(usado quando pretende-se mudar de plataforma).
make mrproper
✗
Além dos arquivos gerados e arquivos de configuração, remove
também arquivos de backup (bom para gerar patches).
make distclean
Embedded
Labworks
LINHA DE COMANDOS DO KERNEL
✗
✗
✗
Ao ser carregado, o kernel pode receber um conjunto de
parâmetros. Chamamos esses parâmetros de linha de comandos do
kernel.
Esta linha de comandos pode ser passada ao kernel de duas
formas:
✗
Pelo bootloader.
✗
Hardcoded
na
configuração
CONFIG_CMDLINE.
do
kernel,
através
da
opção
Esta linha de comandos é uma string com diversas opções no
formato key=value.
Embedded
Labworks
LINHA DE COMANDOS DO KERNEL (cont.)
console=ttySAC0 root=/dev/mtdblock3 rootfstype=jffs2
✗
✗
✗
Onde:
✗
console = dispositivo que será usado como console
✗
root = dispositivo onde se encontra o sistema de arquivos
✗
rootfstype = tipo do sistema de arquivos (JFFS2)
Existem dezenas de outras opções!
Documentação disponível em:
Documentation/kernel-parameters.txt
Embedded
Labworks
LABORATÓRIO
Compilando e testando o kernel
Embedded
Labworks
Linux Embarcado
Rootfs
Embedded
Labworks
SISTEMAS DE ARQUIVO
✗
✗
✗
Sistemas de arquivo são usados para organizar dados, de forma
hierárquica, em diretórios e arquivos disponíveis em dispositivos
de armazenamento (locais ou remotos).
Em sistemas Unix, aplicações e usuários enxergam apenas uma
hierarquia única e global de arquivos e diretórios, que podem ser
compostos por diferentes sistemas de arquivo.
Um ou mais sistemas de arquivo são montados em locais
específicos nesta hierarquia de diretórios.
Embedded
Labworks
SISTEMAS DE ARQUIVO (cont.)
✗
✗
✗
Quando um sistema de arquivo é montado em um diretório, este
diretório é chamado de ponto de montagem ou mount point, e o
conteúdo deste diretório irá refletir o conteúdo armazenado no
dispositivo de armazenamento.
Isso permite que aplicações acessem diretórios e arquivos
facilmente independentemente da localização ou do tipo do
dispositivo de armazemanento.
Tudo o que as aplicações enxergam são arquivos e diretórios!
Embedded
Labworks
O COMANDO MOUNT
✗
O comando mount permite montar um sistema de arquivo:
mount t type device mountpoint
✗
Onde:
✗
✗
✗
-t type é opcional e identifica o tipo do sistema de arquivo (fat, ext3,
jffs2, etc).
device é o dispositivo de armazenamento, ou local na rede, onde
estão armazenados os dados.
mountpoint é o diretório onde os arquivos serão acessados, também
chamado de ponto de montagem.
Embedded
Labworks
O COMANDO UMOUNT
✗
O comando umount permite desmontar um sistema de arquivo:
umount <dispositivo ou ponto de montagem>
✗
Quando trabalhamos com dispositivos removíveis, é necessário
executar o umount antes de remover o dispositivo, já que o Linux
por padrão mantém em cache as alterações realizadas no
dispositivo para melhorar a performance, e o umount garante que
estas alterações sejam realizadas antes da remoção do
dispositivo.
Embedded
Labworks
MONTANDO UM SISTEMA DE ARQUIVO
✗
Criando o diretório (ponto de montagem):
mkdir /mnt/usbkey
✗
Montando um pendrive:
mount t vfat /dev/sda1 /mnt/usbkey
✗
Verificando o conteúdo:
ls /mnt/usbkey
docs prog.c picture.png movie.avi
✗
Desmontando o dispositivo USB:
umount /mnt/usbkey
Embedded
Labworks
SISTEMA DE ARQUIVO ROOT
✗
✗
✗
✗
Um sistema de arquivo específico é montado na raiz principal da
hierarquia, identificado pelo /.
Este sistema de arquivo é chamado de root ou rootfs.
Como ele é o primeiro sistema de arquivo a ser montado, não tem
como fazê-lo com o comando mount, já que o mesmo ainda não
esta disponível. Lembre-se: ainda não existe nenhum sistema de
arquivo montado!
Por isso, o responsável por esta tarefa é o kernel, de acordo com a
opção root na linha de comandos do kernel.
Embedded
Labworks
SISTEMA DE ARQUIVO ROOT (cont.)
✗
Se você não passar a opção root na linha de comando, o kernel
entra em pânico!
Please append a correct "root=" boot option Kernel panic not syncing: VFS: Unable to mount root fs on unknown block(0,0) ✗
Passando a opção root para o kernel:
... console=ttyS2,115200n8 root=/dev/sda2 ...
Embedded
Labworks
LOCALIDADES DO ROOTFS
✗
✗
O rootfs pode ser montado de diferentes localidades:
✗
Da partição de um HD.
✗
Da partição de um pendrive.
✗
Da partição de um cartão SD.
✗
Da partição de uma memória flash NAND.
✗
Pela rede, através do protocolo NFS.
✗
Da memória, pré-carregado pelo bootloader.
É nossa a decisão de como iniciar o sistema, e assim configurar
corretamente a opção root do kernel.
Embedded
Labworks
MONTANDO O ROOTFS
✗
Partição de um HD ou pendrive USB:
✗
root=/dev/sdXY, onde X é uma letra que indica o dispositivo e Y é
o número da partição.
✗
✗
Exemplo: root=/dev/sdb2
Partição de um cartão SD
✗
root=/dev/mmcblkXpY, onde X é um número de identificação do
dispositivo, e Y é o número da partição.
✗
Exemplo: root=/dev/mmcblk0p2
Embedded
Labworks
MONTANDO O ROOTFS (cont.)
✗
Partição de uma memória flash NAND:
✗
root=/dev/mtdblockX, onde X é o número da partição.
✗
Exemplo: root=/dev/mtdblock3
Embedded
Labworks
MONTANDO O ROOTFS VIA REDE
✗
Uma vez que sua rede esteja funcionando, o rootfs pode estar na
sua máquina de desenvolvimento, e ser exportado via protocolo
NFS (Network File System).
Host
Servidor NFS
✗
✗
Target
Cliente NFS
Muito mais fácil e rápido de atualizar o rootfs sem precisar gravar
na flash e reiniciar o equipamento.
Possibilidade de ter um rootfs bem grande, podendo incluir
ferramentas e binários que não caberiam na flash do equipamento.
Embedded
Labworks
MONTANDO O ROOTFS EM MEMÓRIA
✗
✗
Também é possível ter uma imagem de rootfs integrada à imagem
do kernel, sendo por consequência carregada em memória junto
com o kernel.
Este mecanismo é chamado de initramfs.
Kernel
Initramfs
(cpio archive)
Imagem do kernel (uImage, zImage, bzImage, etc)
Embedded
Labworks
INITRAMFS
✗
Vantagens:
✗
✗
✗
Pode ser usado como um passo intermediário para montar o
verdadeiro rootfs (mecanismo comum em desktops e servidores).
Em Linux embarcado, pode ser a solução para sistemas com
pouquíssimos recursos. O boot é mais rápido, e como o sistema de
arquivo já esta em memória, as aplicações também iniciam mais
rapidamente.
Desvantagens:
✗
Como o initramfs é montado em RAM, o armazenamento é volátil
(perde as informações ao reiniciar).
Embedded
Labworks
ORGANIZAÇÃO DO ROOTFS
✗
✗
A organização do rootfs no Linux é padronizada pelo Filesystem
Hierarcy Standard.
http://www.pathname.com/fhs/
A maioria dos sistemas Linux estão de acordo com este padrão
porque:
✗
✗
As aplicações esperam este formato.
Facilita o trabalho de usuários e desenvolvedores quando precisam
trabalhar com diferentes sistemas Linux.
Embedded
Labworks
DIRETÓRIOS MAIS IMPORTANTES
/bin
/boot
/dev
/etc
/home
/lib
/media
/mnt
/proc
Programas básicos
Imagem do kernel (apenas quando o bootloader suporta carregar o kernel
do sistema de arquivos, normalmente usado
em arquiteturas x86)
Arquivos de dispositivo
Arquivos de configuração
Diretório de arquivos dos usuários
Bibliotecas básicas do sistema
Ponto de montagem para mídias removíveis
Ponto de montagem para mídias estáticas
Ponto de montagem do sistema de arquivo virtual ”proc”
Embedded
Labworks
DIRETÓRIOS MAIS IMPORTANTES (cont.)
/root
/sbin
/sys
/tmp
/usr
/usr/bin
/usr/lib
/usr/sbin
/var
Home do usuário root
Aplicações de administração do sistema
Ponto de montagem do sistema de
arquivo virtual sysfs
Arquivos temporários
Aplicações e dados dos usuários
Aplicações básicas do usuário
Bibliotecas do usuário
Aplicações de administração do usuário Arquivos de dados (logs, banco de
dados, arquivos temporários, etc)
Embedded
Labworks
ARQUIVOS DE DISPOSITIVO
✗
✗
Um conceito muito importante trazido do mundo Unix: boa parte
dos ”objetos do sistema” são representados como arquivos,
permitindo que as aplicações manipulem estes objetos usando uma
API comum (open, read, write, etc).
Da mesma forma, os dispositivos de hardware também são
representados no Linux através de arquivos, chamados de arquivos
de dispositivo, e disponíveis no diretório /dev.
Embedded
Labworks
INFORMAÇÕES DOS DISPOSITIVOS
✗
Internamente, cada arquivo de dispositivo esta associado à três
informações básicas:
✗
Major number: indica a categoria do dispositivo.
✗
Minor number: indica o número do dispositivo.
✗
Tipo do dispositivo:
✗
✗
Dispositivos de bloco: composto por blocos de dados de
tamanho fixo, endereçáveis e de acesso aleatório, que podem ser
lidos e/ou escritos. Exemplos: HD, pendrive, etc.
Dispositivo de caractere: possibilita o acesso sequencial de
bytes, sem começo, sem fim e sem tamanho! Exemplos: portal
serial, interface de rede, placa de som, etc.
Embedded
Labworks
EXEMPLOS
✗
Exemplos de arquivos de dispositivo:
ls la /dev/ttyS* /dev/sda1
brwrw 1 root disk 8, 1 20120125 06:54 /dev/sda1
crwrw 1 root dialout 4, 64 20120125 06:54 /dev/ttyS0
✗
Escrevendo ”Hello” na porta serial:
int fd;
fd = open(“/dev/ttyS0”, O_RDWR);
write(fd, “Hello”, 5);
close(fd);
Embedded
Labworks
CRIANDO ARQUIVOS DE DISPOSITIVO
✗
Para sistemas mais simples, os arquivos de dispositivo podem ser
criados manualmente com o comando mknod (é necessário ter
privilégio de root):
mknod /dev/<device> [c|b] major minor
✗
Para sistemas mais complexos, existem mecanismos para
adicionar e remover arquivos de dispositivo dinamicamente:
✗
devtmpfs
✗
udev
✗
mdev
Embedded
Labworks
SISTEMA DE ARQUIVO VIRTUAL PROC
✗
✗
✗
O sistema de arquivo virtual proc exporta (normalmente para o
diretório /proc) um conjunto de informações do kernel, incluindo
estatísticas dos processos, memória e uso de I/O.
O proc também possibilita ajustar parâmetros do kernel em tempo
de execução.
Muitas aplicações, como os comandos ps e top, usam as
informações disponíveis no /proc para exibirem informações dos
processos rodando no sistema.
Embedded
Labworks
SISTEMA DE ARQUIVO VIRTUAL PROC (cont.)
✗
Montando o proc:
mount t proc none /proc
✗
Mais informações na documentação do kernel:
Documentation/filesystems/proc.txt
Embedded
Labworks
SISTEMA DE ARQUIVO VIRTUAL SYSFS
✗
✗
✗
O sistema de arquivo virtual sysfs exporta (normalmente para o
diretório /sys) informações de drivers e dispositivos de hardware
conectados ao sistema.
Usado por aplicações que querem ler informações dos dispositivos
de hardware conectados ao sistema. Ex: mdev, udev, etc.
Pode ser usado também para parametrizar ou configurar
determinado hardware.
Embedded
Labworks
SISTEMA DE ARQUIVO VIRTUAL SYSFS (cont.)
✗
Montando o sysfs:
mount t sysfs none /sys
✗
Mais informações na documentação do kernel:
Documentation/filesystems/sysfs.txt
Embedded
Labworks
A INICIALIZAÇÃO
✗
✗
✗
Após montar o rootfs, o kernel irá tentar executar uma aplicação
de inicialização, também chamado de processo init.
Para isso, o kernel tenta executar os binários /sbin/init,
/bin/init, /etc/init e /bin/sh.
Você pode passar também o nome do programa de inicialização
através do parâmetro init da linha de comandos do kernel.
Exemplo:
init=/usr/bin/init
Embedded
Labworks
A INICIALIZAÇÃO (cont.)
✗
Se nenhuma destes programas de inicialização forem encontrados,
o kernel entra em pânico!
Kernel panic not syncing: No init found.
✗
Assim que executado, o processo init é o responsável pela
inicialização do restante do sistema.
Embedded
Labworks
VISÃO GERAL DO BOOT
Bootloader
Carrega o kernel para a RAM e inicia
Kernel
Monta o rootfs indicado por ”root=”
Inicia a aplicação ”init”
/sbin/init
Inicia outros serviços e aplicações
Shell
Outras aplicações
Rootfs
Embedded
Labworks
MECANISMOS DE INICIALIZAÇÃO
✗
✗
✗
Depois que o kernel chamou a aplicação init, é responsabilidade do
rootfs o restante da inicialização do sistema.
Existem diferentes mecanismos de inicialização, como systemd,
upstart, openrc e sysvinit (System V Init).
Devido à simplicidade de uso e utilização em soluções mais
simples, vamos estudar aqui o sysvinit.
Embedded
Labworks
SYSTEM V INIT
✗
O sysvinit possui basicamente os seguintes componentes:
✗
Aplicação init (o pai de todos os processos).
✗
Arquivo de configuração /etc/inittab.
✗
Scripts de inicialização em /etc/init.d/ ou /etc/rc.d/.
Embedded
Labworks
/etc/inittab
# Startup the system
null::sysinit:/bin/mount t proc proc /proc
null::sysinit:/bin/mkdir p /dev/pts
# now run any rc scripts
::sysinit:/etc/init.d/rcS
# Put a getty on the serial port
ttySAC0::respawn:/sbin/getty L ttySAC0 115200 vt100
# Stuff to do for the 3finger salute
::ctrlaltdel:/sbin/reboot
# Stuff to do before rebooting
null::shutdown:/usr/bin/killall syslogd
Embedded
Labworks
/etc/init.d/rcS
#!/bin/sh
for i in /etc/init.d/S??*; do
case "$i" in
*.sh)
. $i ;;
*)
$i start
;;
esac
done
Embedded
Labworks
/etc/init.d/
ls l init.d/
total 8
rwxrxrx 1 root root 408 20110831 08:44 rcS
rwxrxrx 1 root root 478 20110908 15:02 S01logging
rwxrxrx 1 root root 1365 20110831 08:44 S20urandom
rwxrxrx 1 root root 282 20110831 08:44 S40network
rwxrxrx 1 root root 1092 20110908 16:05 S50dropbear
rwxrxrx 1 root root 73 20110913 14:50 S60leds
Embedded
Labworks
CRIANDO UM ROOTFS BÁSICO
✗
✗
✗
Um sistema Linux precisa de um conjunto básico de programas
para funcionar (init, shell, comandos básicos, etc).
Normalmente estes programas são fornecidos em diferentes
projetos e é trabalhoso integrar manualmente todos estes
componentes.
O Busybox é uma solução alternativa, trazendo uma quantidade
grande e comum de programas usados em sistemas Linux, mas
com tamanho reduzido, perfeito para sistemas embarcados!
http://www.busybox.net/
Embedded
Labworks
APLICAÇÕES DISPONÍVEIS NO BUSYBOX
[, [[, addgroup, adduser, adjtimex, ar, arp, arping, ash, awk, basename, bbconfig, bbsh, brctl, bunzip2,
busybox, bzcat, bzip2, cal, cat, catv, chat, chattr, chcon, chgrp, chmod, chown, chpasswd, chpst, chroot,
chrt, chvt, cksum, clear, cmp, comm, cp, cpio, crond, crontab, cryptpw, cttyhack, cut, date, dc, dd, deallocvt,
delgroup, deluser, depmod, devfsd, df, dhcprelay, diff, dirname, dmesg, dnsd, dos2unix, dpkg, dpkg_deb,
du, dumpkmap, dumpleases, e2fsck, echo, ed, egrep, eject, env, envdir, envuidgid, ether_wake, expand,
expr, fakeidentd, false, fbset, fbsplash, fdflush, fdformat, fdisk, fetchmail, fgrep, find, findfs, fold, free,
freeramdisk, fsck, fsck_minix, ftpget, ftpput, fuser, getenforce, getopt, getsebool, getty, grep, gunzip, gzip,
halt, hd, hdparm, head, hexdump, hostid, hostname, httpd, hush, hwclock, id, ifconfig, ifdown, ifenslave,
ifup, inetd, init, inotifyd, insmod, install, ip, ipaddr, ipcalc, ipcrm, ipcs, iplink, iproute, iprule, iptunnel,
kbd_mode, kill, killall, killall5, klogd, lash, last, length, less, linux32, linux64, linuxrc, ln, load_policy, loadfont,
loadkmap, logger, login, logname, logread, losetup, lpd, lpq, lpr, ls, lsattr, lsmod, lzmacat, makedevs, man,
matchpathcon, md5sum, mdev, mesg, microcom, mkdir, mke2fs, mkfifo, mkfs_minix, mknod, mkswap,
mktemp, modprobe, more, mount, mountpoint, msh, mt, mv, nameif, nc, netstat, nice, nmeter, nohup,
nslookup, od, openvt, parse, passwd, patch, pgrep, pidof, ping, ping6, pipe_progress, pivot_root, pkill,
poweroff, printenv, printf, ps, pscan, pwd, raidautorun, rdate, rdev, readahead, readlink, readprofile, realpath,
reboot, renice, reset, resize, restorecon, rm, rmdir, rmmod, route, rpm, rpm2cpio, rtcwake, run_parts, runcon,
runlevel, runsv, runsvdir, rx, script, sed, selinuxenabled, sendmail, seq, sestatus, setarch, setconsole,
setenforce, setfiles, setfont, setkeycodes, setlogcons, setsebool, setsid, setuidgid, sh, sha1sum, showkey,
slattach, sleep, softlimit, sort, split, start_stop_daemon, stat, strings, stty, su, sulogin, sum, sv, svlogd,
swapoff, swapon, switch_root, sync, sysctl, syslogd, tac, tail, tar, taskset, tcpsvd, tee, telnet, telnetd, test,
tftp, tftpd, time, top, touch, tr, traceroute, true, tty, ttysize, tune2fs, udhcpc, udhcpd, udpsvd, umount,
uname, uncompress, unexpand, uniq, unix2dos, unlzma, unzip, uptime, usleep, uudecode, uuencode,
vconfig, vi, vlock, watch, watchdog, wc, wget, which, who, whoami, xargs, yes, zcat, zcip
Embedded
Labworks
LABORATÓRIO
Gerando um rootfs simples e testando com NFS
Embedded
Labworks
Linux Embarcado
Kernel modules
Embedded
Labworks
KERNEL MONOLÍTICO E MICROKERNEL
✗
✗
Kernel monolítico: o sistema operacional inteiro roda em kernel
space, com total acesso aos recursos da máquina (CPU, memória e
I/Os), e provê para as aplicações (userspace) uma interface de
comunicação através de chamadas de sistema (system calls).
Microkernel: apenas o básico do kernel roda em userspace
(gerenciamento de memória e processos). O resto roda em
userspace, incluindo sistemas de arquivos, device drivers,
protocolos de rede, etc!
Embedded
Labworks
MONOLÍTICO X MICROKERNEL
Embedded
Labworks
O KERNEL LINUX
✗
✗
✗
✗
O Linux é um kernel monolítico.
Mas internamente o Linux é bem modular. Cada funcionalidade é
abstraída em um módulo, com uma interface de comunicação bem
definida. Por isso, permite um sistema de configuração onde você
pode adicionar ou remover determinada funcionalidade.
E o Linux permite que você adicione dinamicamente “pedaços de
código do kernel” em tempo de execução!
Chamamos esses “pedaços de código” de módulos do kernel.
Embedded
Labworks
VANTAGENS DOS MÓDULOS
✗
✗
✗
✗
Ajuda a manter a imagem do kernel bem pequena.
Módulos tornam fácil o desenvolvimento do kernel, como por
exemplo device drivers, sem precisar reiniciar o equipamento.
O tempo de boot fica menor: menos código para ser executado na
inicialização do kernel.
Cuidado: módulos rodam em kernel space. Uma vez carregados,
eles tem total controle do sistema! Por isso só podem ser
carregados como root.
Embedded
Labworks
COMPILANDO OS MÓDULOS
✗
Para compilar apenas os módulos, basta executar:
make modules
✗
Para cross-compilar os módulos, não esqueça de indicar a
arquitetura e o prefixo do cross-compiler. Exemplo:
make ARCH=arm CROSS_COMPILE=armlinux modules
Embedded
Labworks
INSTALANDO OS MÓDULOS
✗
Para instalar os módulos nativamente, basta executar o comando
abaixo:
make modules_install
✗
✗
No caso de um ambiente de compilação cruzada, os módulos
devem ser instalados no rootfs do target.
Para isso, devemos passar o parâmetro INSTALL_MOD_PATH no
comando de instalação:
make ARCH=<arch> INSTALL_MOD_PATH=<dir>/ modules_install
Embedded
Labworks
DEPENDÊNCIAS DOS MÓDULOS
✗
✗
✗
✗
Alguns módulos dependem de outros módulos, que precisam ser
carregados primeiro.
Exemplo: o módulo usb_storage depende do módulo usbcore.
As dependências entre os módulos estão descritas em
/lib/modules/<kernelversion>/modules.dep .
Este arquivo é gerado quando você instala os módulos.
Embedded
Labworks
CARREGANDO UM MÓDULO
✗
O comando insmod carrega apenas um módulo. É necessário
passar o caminho completo do módulo.
insmod <module_path>.ko
✗
O comando modprobe carrega um módulo e todas as suas
dependências. Deve-se passar apenas o nome do módulo, sem a
extensão .ko e sem seu caminho completo.
modprobe <module_name>
Embedded
Labworks
DESCARREGANDO UM MÓDULO
✗
O comando rmmod descarrega apenas um módulo. Possível apenas
se o módulo não estiver mais em uso. Deve-se passar apenas o
nome do módulo, sem a extensão .ko e sem seu caminho completo.
rmmod <module_name>
✗
O comando modprobe descarrega um módulo e todas as suas
dependências (que não estão sendo usadas). Deve-se passar
apenas o nome do módulo, sem a extensão .ko e sem seu caminho
completo.
modprobe r <module_name>
Embedded
Labworks
LISTANDO INFORMAÇÕES DOS MÓDULOS
✗
O comando modinfo lê informações de um módulo, como sua
descrição, parâmetros, licença e dependências. Deve-se passar
apenas o nome do módulo, sem a extensão .ko e sem seu caminho
completo.
modinfo <module_name>
✗
O comando lsmod lista todos os módulos carregados.
lsmod
Embedded
Labworks
PASSANDO PARÂMETROS
✗
Descobrindo os parâmetros disponíveis do módulo:
modinfo <module>
✗
Passando um parâmetro via insmod:
insmod <module> param=value
✗
Para passar um parâmetro via modprobe, configurar o parâmetro em
/etc/modprobe.conf ou em qualquer arquivo em /etc/modprobe.d/:
options <module> param=value
✗
Para passar um parâmetro via linha de comandos do kernel:
<module>.param=value
Embedded
Labworks
LOGS DO KERNEL
✗
✗
✗
✗
O kernel mantém um log de mensagens na memória em um buffer
circular.
Quando um novo módulo é carregado, informações relevantes são
enviadas ao log do kernel.
Este log de mensagens pode ser exibido através do comando
dmesg (diagnostic message).
Mensagens de log também são exibidas na console.
Embedded
Labworks
LABORATÓRIO
Compilando, instalando e carregando módulos
Embedded
Labworks
Linux Embarcado
Sistemas de Arquivo
Embedded
Labworks
SISTEMAS DE ARQUIVO
✗
Um sistema de arquivo é uma representação dos dados dentro de
um dispositivo de armazenamento.
✗
Exemplos de sistemas de arquivo: FAT, NTFS, EXT2, EXT3, JFFS2.
✗
Mas por que existem diferentes sistemas de arquivo?
✗
Performance.
✗
Segurança.
✗
Economia de espaço em disco.
✗
Uso em diferentes tipos de dispositivo de armazenamento.
Embedded
Labworks
DISPOSITIVOS DE ARMAZENAMENTO
✗
✗
No Linux, os dispositivos de armazenamento são classificados em dois
tipos: dispositivos de bloco e memórias flash.
Isso porque, dentro do kernel, eles são manipulados por sub-sistemas
diferentes:
✗
✗
✗
Dispositivos de bloco podem ser lidos ou escritos normalmente sem a
necessidade de apagar antes, e ”virtualmente” não possuem limites de
escrita. Exemplo: HD.
Memórias flash trabalham em blocos e para serem escritas precisam ser
apagadas antes. Exemplo: flash NAND.
Por este motivo,
separadamente.
vamos
estudar
estes
dois
sub-sistemas
Embedded
Labworks
LISTANDO DISPOSITIVOS DE BLOCO
✗
Uma lista com todos os dispositivos de bloco disponíveis no
sistema pode ser obtido em /proc/partitions:
cat /proc/partitions major minor #blocks name
8 0 312571224 sda
8 1 303903744 sda1
8 2 1 sda2
8 5 8665088 sda3
Embedded
Labworks
SISTEMAS DE ARQUIVO TRADICIONAIS
✗
✗
✗
Existem sistemas de arquivo específicos para dispositivos de
bloco.
E tudo começou com o tradicional sistema de arquivo ext2,
presente no Linux desde praticamente as primeiras versões.
É um sistema de arquivo bem estável, mas com um grande
problema: pode deixar o sistema em um estado inconsistente após
um crash ou um reboot não esperado, fazendo com que o sistema
precise usar ferramentas de verificação de disco no próximo boot
(fsck.ext2).
Embedded
Labworks
SISTEMAS DE ARQUIVO TRADICIONAIS (cont.)
✗
✗
É o mesmo caso do vfat, a implementação do sistema de arquivo
FAT no Linux. Quem nunca precisou executar um Scandisk depois de
um reboot inesperado no DOS ou no Windows!?
O ext2 foi usado durante um bom tempo no Linux (quase 10 anos).
Então começaram a aparecer alguns sistemas de arquivo com uma
característica especial chamada de journaling.
Embedded
Labworks
JOURNALING
✗
✗
Um sistema de arquivo com journal
foi projetado para manter a
consistência dos dados mesmo
após um crash do sistema ou um
reboot inesperado.
Todas as alterações são salvas em
um journal (uma espécie de log)
antes de serem aplicadas no
arquivo.
Aplicação
User space
Escreve no arquivo
Kernel space
Escreve uma
entrada no journal
Escreve no arquivo
Limpa entrada no
journal
Embedded
Labworks
JOURNALING (cont.)
✗
Reboot
Não
Journal
vazio?
Descarta entradas
incompletas no
journal
✗
Sim
Executa
journal
Sistema de arquivo OK
Devido ao mecanismo de
journaling, o sistema de
arquivo nunca fica em um
estado
inconsistente
(corrompido).
Os últimos dados salvos,
no entanto, podem ser
perdidos.
Embedded
Labworks
SISTEMAS DE ARQUIVO COM JOURNALING
✗
✗
✗
✗
O ext3 foi o padrão para sistemas de arquivo com journal durante um bom
tempo. Ele é basicamente o ext2 com a funcionalidade de journaling.
O ext4 é a nova geração com muitas melhorias, e é o sistema de arquivo padrão
das distribuições Linux atuais.
O btrfs (também chamado de ”ButterFS”) é a próxima geração e visa substituir o
ext4. Já esta disponível na árvore oficial do kernel, mas ainda em estado
experimental.
Existem muitos outros sistemas de arquivo com journaling, incluindo reiserFS,
JFS e XFS, que possuem aplicações específicas, como por exemplo trabalhar
com arquivos muito pequenos ou com carga de trabalho muito alta.
Embedded
Labworks
QUAL ESCOLHER?
✗
✗
✗
✗
Na prática, você usará o ext3 ou o ext4 em dispositivos de bloco.
Para dispositivos de bloco que usam memória flash (cartão SD/MMC,
pendrive, etc), você pode querer desabilitar o journaling ou usar o
ext2 para limitar a quantidade de escritas geradas pelo journal.
Você só usará o vfat e o ntfs se quiser manter interoperabilidade com
sistemas Windows.
Sistemas de arquivo como o reiserFS, o JFS e o XFS são usados
normalmente em servidores, e tem pouca aplicação em Linux
embarcado.
Embedded
Labworks
SISTEMAS DE ARQUIVO COMPRIMIDOS
✗
✗
✗
Sistemas embarcados possuem normalmente poucos recursos
armazenamento. Por este motivo, você pode querer usar um sistema
arquivo que comprima os dados, deixando o tamanho da imagem
sistema de arquivo menor, e ocupando menos espaço no dispositivo
armazenamento.
de
de
do
de
Um sistema de arquivo comprimido, como o próprio nome diz, armazena
os dados de forma comprimida no dispositivo de armazenamento.
Como algoritmos para escrever de forma comprimida são bem mais
complicados de implementar sem afetar a performance e a confiabilidade
do sistema, boa parte dos sistemas de arquivo comprimidos são de
apenas leitura.
Embedded
Labworks
CRAMFS
✗
✗
✗
O CramFS (Compressed ROM Filesystem) é um exemplo de sistema
de arquivo comprimido de apenas leitura, desenvolvido
especialmente para sistemas embarcados ou dispositivos com
baixa capacidade de armazenamento.
http://sourceforge.net/projects/cramfs/
Os dados são comprimidos com a biblioteca zlib, suportando
arquivos de até 16M, e com tamanho máximo total da imagem de
até 256MB.
Você só vai precisar do CramFS se seu kernel for muito antigo
(anterior à versão 2.6.29).
Embedded
Labworks
SQUASHFS
✗
✗
✗
✗
O SquashFS é uma espécie de sucessor do CramFS, visando atingir os
mesmos objetivos, mas com melhor compressão, melhor
performance de leitura e suporte à arquivos e sistemas maiores.
http://squashfs.sourceforge.net
Gera um sistema de arquivo em torno de 3 vezes menor que o ext3.
http://elinux.org/Squash_Fs_Comparisons
Muito usado em sistemas embarcados para partições que podem ser
apenas de leitura (kernel, binários, etc).
Usado também em distribuições que rodam direto de um pendrive ou
CD/DVD (Live CD).
Embedded
Labworks
SISTEMAS DE ARQUIVO VOLÁTEIS
✗
✗
✗
✗
Quando trabalhamos com Linux embarcado, às vezes precisamos
criar arquivos temporários, armazenar informações de processos
em execução, fazer log, etc.
Fazer isso em um dispositivo de armazenamento pode ser muito
custoso, envolve operações de I/O e pode consumir a vida útil do
dispositivo no caso de memórias flash.
Outro ponto é que estas informações são voláteis, ou seja, não tem
mais utilidade após o boot.
São nestes casos que usamos sistemas de arquivo voláteis.
Embedded
Labworks
SISTEMAS DE ARQUIVO VOLÁTEIS (cont.)
✗
✗
✗
Com um sistema de arquivo volátil, você consegue manter um
diretório do sistema montado em RAM. Ou seja, tudo o que você
escrever neste diretório, vai para a memória RAM!
Consequentemente, você irá perder estas informações no boot do
equipamento. Mas é a solução perfeita para armazenar dados e
arquivos temporários.
O sistema de arquivo volátil padrão no Linux atualmente é o tmpfs.
Embedded
Labworks
TMPFS
✗
✗
✗
O tmpfs é um sistema de arquivo útil para armazenar dados
temporários em RAM (arquivos temporários, logs, etc).
Não gasta muita RAM, cresce e diminui automaticamente conforme
o uso (configurável durante a montagem).
Como usar:
mount t tmpfs tmp /tmp
✗
Para mais informações, veja a documentação no kernel:
Documentation/filesystems/tmpfs.txt
Embedded
Labworks
Você pode dividir seu dispositivo de bloco em
partições:
✗
✗
✗
Uma partição squashfs para o rootfs (kernel,
binários, etc). Salva espaço, e por ser apenas
leitura, fica protegido de alterações acidentais no
sistema de arquivos.
Uma partição ext3 para leitura e escrita de dados
do usuário e de configuração.
squashfs
rootfs
comprimido
ext3
dados e
configuração
Dados temporários em RAM com o tmpfs.
Tmpfs
dados
voláteis
RAM
✗
Dispositivo de Bloco
MISTURANDO TUDO
Embedded
Labworks
LABORATÓRIO
Iniciando o rootfs de um dispositivo de bloco
Embedded
Labworks
MEMÓRIAS FLASH
✗
✗
✗
✗
Algumas limitações diferem as memórias flash de dispositivos de bloco
tradicionais como HDs.
As memórias flash só podem ser apagadas em blocos. Estes blocos são
chamados de erase blocks, e podem variar de algumas dezenas para
algumas centenas de KB.
Quando você apaga um bloco da flash, todos os bits assumem tipicamente
o valor 1. Com um bloco apagado, você pode escrever em qualquer posição
da flash.
Porém, se você escrever 0 em qualquer um dos bits de qualquer posição
da flash, você só consegue fazê-lo voltar para 1 apagando todo o bloco
correspondente da flash!
Embedded
Labworks
MEMÓRIAS FLASH (cont.)
✗
✗
✗
Outra limitação das memórias flash é a quantidade de vezes que
você pode apagar e escrever nela (program/erase cycles).
Esta limitação, dependendo do modelo e do fabricante da flash,
pode variar entre 100.000 e 1.000.000 ciclos. Parece muito, mas
basta você deixar sua aplicação fazendo log em memória flash
para transformá-la em um peso de papel!
É por este motivo que existe uma funcionalidade chamada wear
leveling, que minimiza o problema, e que pode ser implementada
por software ou diretamente em chips controladores de flash.
Embedded
Labworks
MEMÓRIAS FLASH (cont.)
✗
✗
✗
✗
Mesmo assim, depois de certo tempo de uso da flash, um ou mais
blocos serão inutilizados.
Por este motivo, existe uma técnica chamada de BBM (Bad Block
Management).
Quando sai de fábrica, as memórias flash já possuem gravada
nelas uma tabela de bad blocks.
Toda camada de software que trabalha com memórias flash deve
ser capaz de ler e identificar estes bad blocks para não utilizar
regiões inválidas da flash.
Embedded
Labworks
TIPOS DE MEMÓRIAS FLASH
✗
Além destas características especiais, existem basicamente dois
tipos de memória flash:
✗
✗
✗
Flash NOR: Acesso aleatório para leitura de dados (byte a byte),
velocidade alta para leitura mas lenta para apagar e escrever, baixa
densidade, menor durabilidade, alto custo por MB. Usada para armazenar
código, substituir ROM.
Flash NAND: Acesso de leitura em blocos, velocidade baixa para leitura
mas alta para apagar e escrever, alta densidade, maior durabilidade,
baixo custo por MB. Usada para armazenar dados.
É por causa de todas estas características e limitações das memórias
flash que existe um sub-sistema específico no kernel chamado de
MTD para tratar memórias flash.
Embedded
Labworks
MTD (MEMORY TECHNOLOGY DEVICES)
Interface com o sistema de arquivos
MTD User modules
ubifs
Char device
MTD Chip drivers
NAND flash
jffs2
Read-only block device
NOR flash
DiskOnChip flash
RAM chips
ROM chips
Hardware
yaffs2
Block device
Block device
Virtual memory
Virtual devices
Embedded
Labworks
CAMADAS DO SUB-SISTEMA MTD
✗
✗
✗
A camada de baixo (MTD chip drivers) conversa diretamente com o
hardware, enquanto que a camada de cima (MTD user modules)
implementa os diferentes sistemas de arquivo e mecanismos de
acesso à flash.
Cada memória tem o seu MTD chip driver para possibilitar o acesso
ao hardware da flash. Mas cada sistema pode usar um ou mais
MTD user modules.
Cada um dos MTD user modules irá tratar de forma diferente a
flash. É neste contexto que as memórias flash também são
chamadas de dispositivos MTD.
Embedded
Labworks
MTDCHAR
✗
✗
✗
✗
O driver mtdchar implementa o módulo "char device" da flash. Ele
cria um dispositivo de caractere para cada partição de um dispositivo
MTD no sistema, normalmente chamado de /dev/mtdX, onde X é o
número da partição.
Com este módulo, você tem acesso sequencial (byte a byte) de toda a
flash.
Além disso, ele disponibiliza comandos ioctl() para você poder
manipular a flash (ler informações, apagar/gravar na flash, etc).
A principal utilidade deste módulo é no gerenciamento da flash,
quando usamos o pacote mtd-utils.
Embedded
Labworks
MTD-UTILS
✗
O mtd-utils é um conjunto de ferramentas para manipular
dispositivos MTD:
✗
mtdinfo retorna informações detalhadas do dispositivo.
✗
flash_eraseall apaga todo o dispositivo.
✗
flashcp escreve em memórias flash NOR.
✗
nandwrite escreve um memórias flash NAND.
✗
✗
mkfs.jffs2 e mkfs.ubifs cria os respectivos sistemas de arquivo na
flash.
Para mais informações consulte o site do projeto:
http://www.linux-mtd.infradead.org/
Embedded
Labworks
MTDBLOCK
✗
✗
✗
✗
O driver mtdblock implementa o módulo "block device" da flash.
Ele cria um dispositivo de bloco para cada partição de um dispositivo
MTD no sistema, normalmente nomeado /dev/mtdblockX, onde X é o
número da partição.
Este módulo permite acesso de leitura/escrita por bloco, como se
fosse um HD mesmo, mas não gerencia bad blocks e também não
trabalha com wear leveling em escritas.
Portanto, se você quiser um sistema de arquivo que trabalhe com
todas as limitações da flash, incluindo bad blocks e wear leveling,
você vai precisar de um sistema de arquivo específico para flash.
Embedded
Labworks
JFFS2
✗
✗
✗
✗
É um dos sistemas de arquivo para flash mais antigos ainda em
utilização.
http://www.linux-mtd.infradead.org/doc/jffs2.html
Vantagens: compressão em tempo de execução (economiza espaço),
confiabilidade, wear leveling e algoritmo ECC.
Desvantagens: não escala muito bem em memórias flash com
capacidades muito grandes. O kernel precisa varrer todo o sistema
de arquivo no momento da montagem.
Habilitando no kernel a opção CONFIG_JFFS2_SUMMARY reduz
drasticamente este tempo de montagem.
Embedded
Labworks
YAFFS2
✗
✗
✗
É um dos sucessores do JFFS2, com o objetivo de corrigir os
problemas de performance em memórias flash muito grandes.
http://www.yaffs.net/
Vantagens: tempo de boot rápido, confiabilidade, wear leveling e
algoritmo ECC.
Desvantagens: suporta apenas memórias flash NAND e não
comprime os dados.
Embedded
Labworks
UBIFS
✗
Evolução do jffs2, dos mesmos desenvolvedores do mtd-utils,
disponível a partir do kernel 2.6.27.
http://www.linux-mtd.infradead.org/doc/ubifs.html
✗
Trabalha com volumes lógicos em cima de dispositivos MTD.
✗
Overhead de metadata em partições pequenas.
✗
Mas com a capacidade das memórias flash aumentando cada vez
mais, deve se tornar nos próximos anos o sistema de arquivo
padrão para dispositivos MTD.
Embedded
Labworks
DICAS PARA TRABALHAR COM FLASH
✗
✗
✗
✗
✗
Não use a memória flash como região de swap!
Não use a memória flash para armazenamento volátil como logs e
arquivos temporários (use tmpfs nestes casos).
Monte seu rootfs como apenas leitura, ou use o squashfs, quando
possível.
Use a opção de montagem noatime para evitar atualizar o sistema de
arquivos toda vez que você acessa um arquivo.
Não use a opção de montagem sync (atualização escreve
imediatamente no sistema de arquivo).
Embedded
Labworks
ESCOLHENDO O SISTEMA DE ARQUIVO
Dados
Voláteis?
Não
Somente
Leitura?
Não
Dispositivo
Sim
Sim
tmpfs
Bloco
Tem flash?
Sim
Não
MTD
squashfs
ext2 (noatime)
ubifs ou jffs2
ext3 ou ext4
Embedded
Labworks
LABORATÓRIO
Iniciando o rootfs da memória flash
Embedded
Labworks
Linux Embarcado
Build system
Embedded
Labworks
O DESAFIO: INTEGRAR TUDO ISSO
Biblioteca
Biblioteca
Toolchain
Biblioteca
Biblioteca
Biblioteca C
Linux kernel
Bootloader
Hardware
Embedded
Labworks
O DESAFIO: INTEGRAR TUDO ISSO (cont.)
u-boot.bin
uImage
rootfs.img
Embedded
Labworks
INTEGRANDO TUDO
✗
✗
✗
O que vimos até aqui foi um passo-a-passo de como desenvolver
um sistema Linux embarcado do zero.
Na prática, não precisamos desenvolver um sistema Linux
manualmente, ja que é uma atividade trabalhosa, demorada e
suscetível à erros.
Portanto, temos normalmente duas possíveis soluções para
trabalhar no desenvolvimento de sistemas com Linux embarcado:
1. Usar uma distribuição Linux pronta.
2. Usar um sistema de build (build system).
Embedded
Labworks
DISTRIBUIÇÃO PRONTA
✗
✗
✗
Existem diversas distribuições comerciais prontas para Linux
embarcado: MontaVista, Timesys Linux, Wind River Linux, etc.
Existem também diversas soluções abertas, incluindo Android,
Emdebian, Ubuntu embedded, Tizen, Angstrom, Meego, etc.
Vantagens:
✗
Simplicidade de uso.
✗
Facilidade na instalação de novos pacotes.
✗
Framework de desenvolvimento pronto e funcional.
Embedded
Labworks
DISTRIBUIÇÃO PRONTA (cont.)
✗
Desvantagens:
✗
✗
Falta flexibilidade (compatibilidade com plataforma de hardware,
mecanismo de inicialização, framework de desenvolvimento
disponível, erros em pacotes da distribuição, etc).
Normalmente o rootfs é grande, ocupa muito espaço no dispositivo de
armazenamento.
✗
Tempo de boot normalmente alto.
✗
Requer customização para deixar o sistema mais leve.
✗
Difícil de levantar quais pacotes open source são usados.
Embedded
Labworks
BUILD SYSTEM
✗
✗
✗
✗
O build system permite gerar um sistema Linux completo do zero.
Ele automatiza o processo de geração dos diversos componentes
do sistema, incluindo o toolchain, o kernel, o bootloader, as
bibliotecas e as aplicações.
Normalmente já contém um conjunto grande de pacotes
configurados para serem habilitados e utilizados pelo seu sistema.
E facilita o trabalho de adicionar novos pacotes se necessário.
Embedded
Labworks
BUILD SYSTEM (cont.)
✗
Vantagens:
✗
✗
✗
Flexibilidade.
O processo de build torna-se reproduzível, facilitando o trabalho de
recompilação, correção de problemas e adição de novas
funcionalidades.
Desvantagens:
✗
✗
Tempo extra para configurar a ferramenta.
É necessário conhecimento do funcionamento da ferramenta e de
mecanismos de compilação para adicionar novos pacotes se
necessário e corrigir possíveis erros de compilação.
Embedded
Labworks
FERRAMENTAS
✗
✗
✗
Buildroot, desenvolvido pela comunidade:
http://www.buildroot.net
PTXdist, desenvolvido pela empresa Pengutronix:
http://www.pengutronix.de/software/ptxdist/index_en.html
LTIB, desenvolvido principalmente pela Freescale:
http://www.ltib.org/
Embedded
Labworks
FERRAMENTAS (cont.)
✗
✗
✗
OpenEmbedded, mais flexível (e também mais complexo):
http://www.openembedded.org
Yocto, evolução do OpenEmbedded:
http://www.yoctoproject.org/
Sistemas comerciais (MontaVista, WindRiver, Timesys).
Embedded
Labworks
LTIB
✗
✗
✗
✗
LTIB (Linux Target Image Builder) é uma ferramenta usada para
desenvolver e liberar BSPs (Board Support Packages).
http://ltib.org/
Projeto inicialmente patrocionado pela Freescale, suporta gerar
imagens para ARM, PPC e Coldfire.
Permite gerar imagens do bootloader, kernel e rootfs.
Usa o sistema de pacotes RPM, e possui em torno de 200
aplicações/bibliotecas disponíveis.
Embedded
Labworks
BUILDROOT
✗
✗
✗
Desenvolvido pelos mesmos mantenedores da uClibc.
Possibilita gerar o toolchain, o bootloader, o kernel e o rootfs com
muitas bibliotecas e aplicações disponíveis.
Mais de 700 aplicações e bibliotecas integradas, de utilitários
básicos à bibliotecas mais elaboradas como X.org, Qt, Gtk, Webkit,
Gstreamer, etc.
✗
Ótima solução para projetos pequenos e médios.
✗
Desde a versão 2009.02 um novo release é liberado a cada 3 meses.
Embedded
Labworks
CONFIGURANDO O BUILDROOT
✗
✗
Permite configurar, dentre outras opções:
✗
Arquitetura e modelo da CPU.
✗
Toolchain.
✗
Bootloader.
✗
Kernel.
✗
Bibliotecas e aplicações.
✗
Tipos das imagens do rootfs (ext2, jffs2, etc).
Para configurar:
make menuconfig
Embedded
Labworks
CONFIGURANDO O BUILDROOT
Embedded
Labworks
COMPILANDO O BUILDROOT
✗
Configuração também fica armazenada em um arquivo .config.
✗
Para compilar:
make ✗
No final do processo de compilação, as imagens estarão
disponíveis no diretório abaixo:
ls output/images/
rootfs.ext2 rootfs.jffs2 uboot.bin uImage
Embedded
Labworks
LABORATÓRIO
Gerando um sistema Linux do zero com o Buildroot
Embedded
Labworks
Linux Embarcado
Bibliotecas e aplicações
Embedded
Labworks
BIBLIOTECAS E APLICAÇÕES
✗
✗
✗
✗
Uma das grandes vantagens do Linux é a enorme quantidade de
bibliotecas e aplicações disponíveis que podem ser usadas
livremente no seu projeto.
Estas bibliotecas e aplicações são normalmente disponibilizadas e
distribuídas gratuitamente, e graças à sua natureza open-source,
podem ser analisadas e modificadas de acordo com seu projeto.
Entretanto, o uso eficiente destes componentes nem sempre é fácil.
Você precisa encontrar e escolher o componente mais apropriado,
compilar e integrar ao seu projeto.
Embedded
Labworks
PROCURANDO COMPONENTES
✗
✗
Procurar em sites que hospedam projetos de software livre:
http://www.freshmeat.net
http://directory.fsf.org
http://sourceforge.net
http://code.google.com/hosting
https://github.com
Pesquisar outros produtos com Linux embarcado, e identificar seus
componentes.
✗
Perguntar à comunidade (fóruns, listas de discussão, etc).
✗
Pesquisar no Google ou em outros sites de busca.
Embedded
Labworks
ESCOLHENDO COMPONENTES
✗
Ao escolher um componente open source para seu projeto, você precisa
levar em consideração:
✗
✗
✗
✗
Requisitos técnicos: o componente deve satisfazer os requisitos técnicos
do seu projeto. Mas não esqueça também de que você mesmo pode
implementar estas melhorias! E depois compartilhar!
Atividade do projeto: o projeto deve ser ativo, releases frequentes, fórum
movimentado. É importante ter a garantia de manutenção e suporte.
Qualidade do componente: seu uso em diversos sistemas e uma
comunidade ativa em geral significam uma qualidade relativamente boa.
Licença: a licença pode ser um impeditivo para o uso de determinado
componente no seu produto.
Embedded
Labworks
Linux Embarcado
Pacotes open source
Embedded
Labworks
LINGUAGENS DE SCRIPT
✗
Interpretadores das mais comuns linguagens de script estão
disponíveis:
✗
Shell script
✗
Python
✗
Perl
✗
Lua
✗
Ruby
✗
TCL
✗
PHP
Embedded
Labworks
EDITORES DE TEXTO
✗
vi: editor de texto em Linux embarcado mais usado.
✗
nano: ótimo editor para os iniciantes.
✗
uemacs: um emacs de tamanho reduzido.
Embedded
Labworks
FERRAMENTAS DE REDE
✗
dropbear: implementação de um cliente e servidor SSH. Bom para
ter acesso remoto seguro e transferir arquivos.
✗
dnsmasq: servidor DNS e DHCP.
✗
iptables: ferramentas userspace para gerenciar o firewall.
✗
netsnmp: implementação do protocolo SNMP.
✗
openssl: biblioteca para conexões SLL e TLS.
✗
vsftpd: servidor SFTP.
Embedded
Labworks
SERVIDORES WEB
✗
✗
✗
✗
Busybox http server: servidor HTTP do Busybox, com suporte à CGI e
autenticação, ocupando apenas 9K de tamanho. Não suporta SSL.
Boa: servidor HTTP simples e rápido. Trabalha com apenas uma thread de
execução, multiplexando o processamento de conexões simultâneas. Sem
suporte à controle de acesso e SSL.
thttpd: servidor HTTP simples, rápido e portável, com suporte à CGI e
autenticação. Sem suporte nativo à SSL.
lighttpd: servidor HTTP mais completo, ótimo para gerenciar altas cargas,
rápido e seguro, com suporte à controle de acesso, CGI e SSL.
Embedded
Labworks
MULTIMEDIA
✗
✗
Gstreamer: framework multimídia, permite codificar e decodificar
diversos containers e formatos multimídia. Suporta codecs de hardware
através de plugins.
FFmpeg: ferramenta completa para gravar, converter e tocar mídias.
Implementa a libavcodec, uma das mais usadas e famosas bibliotecas de
áudio e vídeo da atualidade.
✗
Mplayer: player multimídia (usa a libavcodec).
✗
Alsalib: biblioteca associada com o sistema de som no Linux.
✗
Outras bibliotecas e codecs como flac, libogg, libtheora, libvorbis, libmad,
libsndfile, speex, etc.
Embedded
Labworks
BANCO DE DADOS
✗
SQLite: uma pequena biblioteca em C que implementa um
gerenciador de banco de dados leve que pode ser embarcado no
seu projeto.
✗
É ”a escolha” de banco de dados em Linux embarcado.
✗
Pode ser usado como uma biblioteca normal.
✗
Pode ser até compilada estaticamente com uma aplicação
proprietária, já que o SQLite é liberado sob domínio público.
Embedded
Labworks
OUTRAS BIBLIOTECAS
✗
Bibliotecas de compressão/descompressão.
✗
Bibliotecas de criptografia.
✗
Bibliotecas de manipulação do hardware.
✗
Bibliotecas de rede.
✗
Bibliotecas para manipular arquivos XML.
✗
Bibliotecas gráficas (veremos em detalhes mais adiante).
✗
Etc!
Embedded
Labworks
Linux Embarcado
Licenças
Embedded
Labworks
LICENÇAS
✗
✗
Todo software sob a licença de software livre dá à todos os
usuários 4 liberdades básicas:
✗
Liberdade de usar.
✗
Liberdade de estudar.
✗
Liberdade de copiar.
✗
Liberdade de modificar e distribuir cópias modificadas.
Veja o link abaixo para uma definição completa de software livre:
http://www.gnu.org/philosophy/free-sw.html
Embedded
Labworks
LICENÇAS (cont.)
✗
✗
✗
Licenças de software livre possuem basicamente duas categorias:
✗
Licenças copyleft.
✗
Licenças non-copyleft.
Quando você modifica e distribui um software sob licença copyleft,
você precisa liberá-lo sob a mesma licença original.
✗
Mesma liberdade à novos usuários.
✗
Incentivo para você contribuir de volta à comunidade.
Licenças non-copyleft não tem estes requisitos, e versões modificadas
podem ser mantidas proprietárias, sendo necessário apenas manter a
atribuição de autoria do projeto ao autor original.
Embedded
Labworks
GPL
✗
✗
✗
GNU General Public Licence.
Cobre mais da metade dos projetos de software livre, incluindo o
U-Boot, o Linux, o Busybox e muitas aplicações.
É uma licença copyleft:
✗
✗
Trabalhos derivados precisam ser liberados sob a mesma licença.
Programas linkados com uma biblioteca GPL também precisam ser
liberados sob a GPL.
Embedded
Labworks
GPL (cont.)
✗
Boa parte dos programas é coberta pela GPLv2.
✗
Alguns programas estão migrando para a GPLv3.
✗
Principal diferença: o usuário deve ser capaz de rodar versões
modificadas do programa no dispositivo.
Embedded
Labworks
LGPL
✗
GNU Lesser General Public Licence.
✗
Cobre ~10% dos projetos de software livre.
✗
É uma licença copyleft:
✗
✗
✗
✗
Trabalhos derivados precisam ser liberados sob a mesma licença.
Mas programas linkados com uma biblioteca LGPL não precisam ser
liberados pela LGPL e podem ser mantidos proprietários.
Entretanto, o usuário precisa ter a possibilidade de atualizar a biblioteca
independentemente do programa, portanto, a linkagem precisa ser
dinâmica.
Licença usada nas maioria das bibliotecas.
Embedded
Labworks
LICENÇAS NON-COPYLEFT
✗
✗
Versões modificadas de um software sob licença non-copyleft
podem ser mantidas proprietárias, desde que você atribua a
autoria da versão original.
Existe uma grande família de licenças non-copyleft relativamente
similares em suas características, dentre elas:
✗
Apache Licence
✗
BSD Licence
✗
MIT Licence
✗
X11 Licence
✗
Artistic Licence
Embedded
Labworks
LICENÇAS (EXEMPLOS)
✗
Você modificou o Linux, o Busybox, o U-Boot ou outro software GPL:
✗
✗
Você precisa liberar o software com as modificações realizadas sob
a mesma licença, e estar pronto para distribuir o código-fonte para
seus clientes.
Você modificou uma biblioteca qualquer sob a licença LGPL:
✗
Você precisa liberar as versões modificadas sob a mesma licença.
Embedded
Labworks
LICENÇAS (EXEMPLOS)
✗
Você criou uma aplicação que utiliza uma biblioteca LGPL:
✗
✗
Você pode manter sua aplicação proprietária, mas precisa linkar
dinamicamente com a biblioteca.
Você fez modificações em um software non-copyleft:
✗
Você pode manter suas modificações proprietárias, mas precisa
manter o crédito aos autores.
Embedded
Labworks
APLICANDO LICENÇAS
✗
Não existe uma regra única para aplicar licenças em software open
source, já que cada licença possui sua própria “receita de bolo”. De
qualquer forma, um projeto open source possui normalmente:
✗
✗
✗
Uma indicação da licença utilizada e uma cópia completa desta
licença no site do projeto.
Uma cópia completa da licença utilizada no diretório principal dos
fontes do projeto. Normalmente este arquivo é nomeado como
LICENCE, LICENCE.TXT, COPYRIGHT ou COPYING.
Um descritivo da licença utilizada no cabeçalho de cada
arquivo-fonte do projeto. O conteúdo deste descritivo depende da
licença utilizada.
Embedded
Labworks
LABORATÓRIO
Identificando e analisando licenças open source
Embedded
Labworks
Linux Embarcado
Cross-compilando bibliotecas e aplicações
Embedded
Labworks
COMO CROSS-COMPILAR?
✗
✗
✗
Basicamente, temos duas soluções:
✗
Adaptar o pacote ao seu build system.
✗
Compilar manualmente.
O processo de adaptação do pacote ao build system é dependente do build
system utilizado. Por exemplo, para compilar um pacote dentro do Buildroot,
os procedimentos estão disponíveis no manual do Buildroot:
http://buildroot.uclibc.org/downloads/manual/manual.html
Para compilar manualmente, você precisa:
✗
Toolchain.
✗
Conhecer o mecanismo de compilação do pacote.
Embedded
Labworks
MECANISMOS DE COMPILAÇÃO
✗
Todo software open-source possui um sistema de build ou
mecanismo de compilação. Dentre eles, podemos destacar:
✗
✗
✗
✗
Makefile simples: é necessário ler e entender o que alterar para
cross-compilar o componente.
Autotools: um dos mais utilizados, iremos estudar em mais detalhes.
Cmake: Mais novo e mais simples que o autotools, usado em projetos
grandes como o KDE.
Qmake: Criado pela Trolltech para ser usado no Qt.
Embedded
Labworks
MAKE
✗
✗
✗
O make é uma ferramenta bastante usada para compilar
programas e bibliotecas.
http://www.gnu.org/software/make/
Ele interpreta arquivos Makefile, que contém os comandos a
serem executados durante o processo de compilação.
Para compilar um programa ou biblioteca baseado em makefiles,
basta digitar o comando abaixo (considerando-se que você tenha
um arquivo Makefile no diretório corrente):
make
Embedded
Labworks
MAKEFILE (EXEMPLO)
TOOLCHAIN:=/opt/labs/ex/09/buildroot/output/host/usr/bin/
CROSS_COMPILE:=armlinux
PATH:=${TOOLCHAIN}:${PATH} all: ${CROSS_COMPILE}gcc teste.c o teste
clean: rm Rf *.o teste
Embedded
Labworks
LABORATÓRIO
Desenvolvendo uma aplicação baseada em Makefile
Embedded
Labworks
AUTOTOOLS
✗
✗
Autotools é o nome dado ao sistema de build do projeto GNU, que
contém um conjunto de ferramentas para auxiliar na compilação de
uma aplicação ou biblioteca.
Ele tem basicamente os seguintes objetivos:
✗
✗
✗
Ser um sistema de build universal e multiplataforma.
Analisar e verificar se a plataforma possui os requisitos necessários
para compilar o pacote (biblioteca ou aplicação).
Configurar a aplicação, habilitando ou desabilitando funcionalidades
antes da compilação.
Embedded
Labworks
AUTOTOOLS (cont.)
✗
O Autotools é composto pelas seguintes ferramentas:
✗
✗
✗
✗
Autoconf: ferramenta responsável por gerar os scripts de
configuração.
Automake: ferramenta responsável por gerar os makefiles.
Libtool: ferramenta responsável por compilar e criar de forma
portável as bibliotecas da aplicação.
Para compilar um software baseado em autotools, normalmente
usamos os comandos abaixo:
./configure
make
make install
Embedded
Labworks
CROSS-COMPILANDO COM AUTOTOOLS
✗
✗
✗
✗
Para cross-compilar um software baseado em autotools, você
precisará prestar atenção em alguns detalhes adicionais.
No script de configuração, você precisa indicar o host (onde irá
executar o software) com a opção --host.
Dependendo do pacote, você precisará indicar o nome das
ferramentas de compilação do toolchain, setando as variáveis de
ambiente AR, AS, LD, CC, GCC, CPP, CXX.
Você precisa indicar onde irá instalar o software usando a variável
DESTDIR, que deve estar apontando para o diretório onde se
encontra o rootfs do seu sistema.
Embedded
Labworks
AUTOTOOLS (EXEMPLO)
# configurando o toolchain
export PATH=/usr/local/armlinux/bin:$PATH
export CC=armlinuxgcc
# configurando a aplicação
./configure host=armlinux
# compilando
make
# instalando
make DESTDIR=/home/<user>/work/rootfs install
Embedded
Labworks
LABORATÓRIO
Cross-compilando um software baseado em autotools
Embedded
Labworks
Linux Embarcado
Integrando componentes
Embedded
Labworks
INTEGRANDO COMPONENTES
✗
✗
✗
✗
Na integração de componentes open source com seu projeto, às vezes é
necessário realizar algumas modificações para fazê-lo funcionar, otimizar
o uso de espaço em disco, corrigir algum bug, etc.
Precisamos saber documentar as alterações realizadas em pacotes
open-source, porque quando atualizarmos este pacote para uma nova
versão, será necessário aplicar as alterações realizadas no pacote
original.
Precisamos de um mecanismo para distribuir estas alterações, e também
para contribuir de volta com a comunidade.
Como a comunidade de software livre é muito grande, precisamos de uma
linguagem comum.
Embedded
Labworks
PATCHES
✗
✗
✗
Como então documentar as alterações realizadas em projetos
open-source? Através de patches!
Um patch descreve basicamente as diferenças entre um ou mais
arquivos de determinado diretório ou projeto.
Um patch pode ser gerado automaticamente por uma ferramenta
de controle de versão (svn, git, mercurial), ou pode ser gerado
manualmente através da ferramenta diff:
diff rau prjorig prjalt > prj.patch
Embedded
Labworks
EXEMPLO DE PATCH
diff rau netcat/src/netcat.c netcat2/src/netcat.c
netcat/src/netcat.c 20111001 12:03:55.000000000 +++ netcat2/src/netcat.c 20120312 12:06:01.830816531 @@ 445,7 +445,7 @@
exit(EXIT_FAILURE);
}
debug_dv("Arguments parsing complete! Total"); + printf("Linha adicionada\n");
#if 0
/* pure debugging code */
c = 0;
Embedded
Labworks
APLICANDO PATCHES
✗
✗
Com o arquivo de patch temos documentado as alterações
realizadas no projeto original.
Para aplicar o patch, basta entrar no diretório do projeto original e
executar a ferramenta patch:
cd prjorig/
patch p1 < ../prj.patch
Embedded
Labworks
LABORATÓRIO
Criando e aplicando patches
Embedded
Labworks
Linux Embarcado
Bibliotecas gráficas
Embedded
Labworks
CAMADA DE VÍDEO NO LINUX
Aplicação
Aplicação
Toolkit Gráfico
(Qt, Gtk)
Aplicação
User
Aplicação
Biblioteca
(SDL, DirectFB)
Toolkit
Gráfico (Qt)
Framebuffer driver comum
/dev/fbX
Framebuffer
driver
Framebuffer
driver
Controladora
VGA
Controladora
LCD
Servidor Gráfico
(X server)
Acesso
direto
à memória
/dev/mem
Kernel
Hardware
Embedded
Labworks
CAMADA INPUT NO LINUX
Aplicação
Biblioteca
gráfica
Toolkit
gráfico
Servidor
gráfico
User
Input event driver (/dev/input/eventX)
Input core
Input driver
Input driver
Input driver
Input driver
Input driver
Serio
USB HID
SPI
I2C
GPIO
Teclado ou
mouse PS2
Teclado ou
Mouse USB
Controladora
Touchscreen
Acelerômetro
Joystick
Kernel
Hardware
Embedded
Labworks
SDL
✗
✗
✗
SDL (Simple Directmedia Layer) é uma biblioteca multimídia para
acesso de baixo nível em dispositivos de entrada (teclado, mouse,
joystick, etc) e saída (vídeo, áudio, etc).
http://www.libsdl.org
Suporta aceleração de hardware 3D via OpenGL e acesso ao
framebuffer para gráficos 2D.
Usada basicamente para desenvolvimento de aplicações que
desejam acessar diretamente o hardware. Exemplos: jogos, mídia
players, etc.
Embedded
Labworks
JOGO CIVILIZATION USANDO SDL
Embedded
Labworks
DIRECTFB
✗
✗
✗
✗
Biblioteca de baixo nível para trabalhar com interface gráfica.
http://www.directfb.org
Pode ser utilizada para desenvolvimento de UI em aplicações
simples, ou como uma camada de baixo nível para bibliotecas
gráficas de mais alto nível.
Manipula eventos de entrada como mouse, teclado, joystick, etc.
Capacidade de trabalhar com aceleradores gráficos em diferentes
hardwares.
Embedded
Labworks
MEDIACENTER USANDO DIRECTFB
Embedded
Labworks
X.ORG KDRIVE
✗
✗
✗
✗
Kdrive (antes Tiny-X) é a implementação do servidor X para
sistemas embarcados.
http://www.x.org
Também trabalha diretamente sobre o framebuffer.
Suporte total ao protocolo X11, e permite o uso de qualquer
aplicação ou biblioteca baseada no X11.
O uso é feito normalmente com um Toolkit rodando por cima (Qt,
Gtk, EFL, WxEmbedded, etc).
Embedded
Labworks
DESKTOP USANDO KDRIVE
Embedded
Labworks
Linux Embarcado
Toolkits gráficos
Embedded
Labworks
GTK
✗
Famoso toolkit usado no Gnome, disponibilizando uma API baseada
em widgets para o desenvolvimento de aplicações gráficas.
http://www.gtk.org
✗
Pode usar o servidor X ou o DirectFB como backend gráfico.
✗
Não inclui um sistema de janelas.
✗
Em desktop é comum o Gnome como sistema de janelas. Em
sistemas embarcados, uma possibilidade é o Matchbox.
Embedded
Labworks
EXEMPLOS DE USO DO GTK
OpenMoko
Maemo
Interface
proprietária
Embedded
Labworks
Qt
✗
✗
Famoso toolkit usado no KDE, também disponibilizando uma API
baseada em widgets para o desenvolvimento de aplicações
gráficas.
http://qt-project.org/
Já inclui um sistema de janelas, e fornece um framework completo
de desenvolvimento para trabalhar com estrutura de dados, thread,
networking, banco de dados, etc.
✗
Implementação em C++.
✗
Trabalha direto no framebuffer ou em cima do X11 ou DirectFB.
Embedded
Labworks
EXEMPLOS DE USO DO QT
Express GPS
OpenMoko
Netflix Player
Embedded
Labworks
LABORATÓRIO
Desenvolvendo uma aplicação em Qt
Embedded
Labworks
Linux Embarcado
Debugging
Embedded
Labworks
GDB
✗
✗
✗
O GDB (GNU Debugger) é o debugger padrão do projeto GNU,
disponível para diversas arquiteturas.
http://www.gnu.org/software/gdb/
Interface via console, mas com frontends disponíveis (Eclipse,
DDD, GDB/Insight, Kdbg, etc).
Pode ser usado para diversas tarefas, incluindo controlar a
execução de um programa, colocar breakpoints, mudar o estado de
variáveis ou fazer um dump da memória.
Embedded
Labworks
DEBUG REMOTO
✗
✗
✗
Problema 1: os fontes estão na máquina de desenvolvimento e o binário
está rodando na máquina alvo.
Problema 2: A máquina-alvo não tem recursos para instalar o gdb
completo e aplicações com símbolos de debugging.
A solução: gdb client na máquina de desenvolvimento e gdb server na
máquina alvo.
Embedded
Labworks
ARQUITETURA GDB
Host
Target
ARCHlinuxgdb
gdbserver
Conexão
Serial ou
Ethernet
Binários e bibliotecas
com símbolos de
debugging
Binários e bibliotecas
sem símbolos de
debugging
Embedded
Labworks
LABORATÓRIO
Debugging com GDB
Embedded
Labworks
Linux Embarcado
Desenvolvimento de aplicações
Embedded
Labworks
DESENVOLVENDO APLICAÇÕES
✗
✗
✗
✗
Um sistema Linux embarcado é um sistema Linux normal, apenas
com um conjunto menor e mais enxuto de componentes.
Em termos de desenvolvimento de aplicações, é o mesmo processo
comparado ao desenvolvimento para desktop, o que inclusive facilita
os testes.
Você pode reusar aplicações e bibliotecas sem nenhuma adaptação
na maioria das vezes.
Mas sempre leve em conta a limitação de recursos do seu
equipamento (capacidade de processamento, memória e
armazenamento).
Embedded
Labworks
LINGUAGEM DE PROGRAMAÇÃO
✗
✗
✗
✗
A linguagem padrão para desenvolvimento de aplicações no nível do
sistema é a linguagem C. A biblioteca C padrão esta sempre presente em
sistemas Linux.
C++ pode ser usada para o desenvolvimento de aplicações maiores. A
biblioteca C++ precisa normalmente ser adicionada ao sistema.
Java também é uma possibilidade, mas leve em consideração o consumo
de recursos do dispositivo.
Linguagens de script são muito úteis em determinadas tarefas, e ajudam
em aumentar a velocidade do desenvolvimento, mas requerem um
interpretador que também consome recursos de memória e
processamento.
Embedded
Labworks
AMBIENTES DE DESENVOLVIMENTO
✗
✗
✗
Eclipse: Uma IDE completa baseada em plugins, ideal para
desenvolver outras IDEs. Roda em cima de uma JVM. Diversas
empresas de sistemas embarcados tem usado a plataforma
Eclipse para desenvolver IDEs para seus produtos. Ex: MontaVista
DevRocket, TimeSys TimeStorm, Windriver Workbench, TI Code
Composer, Freescale Codewarrior, etc.
Kdevelop: uma IDE completa. Roda nativamente. Suporta diversas
linguagens incluindo C, C++ e Java.
Outras opções: Anjuta, Netbeans, vim, emacs, etc.
Embedded
Labworks
CONTROLE DE VERSÃO
✗
✗
✗
✗
CVS: Foi bastante popular, mas hoje não é mais usado em novos
projetos.
Subversion: Também chamado de SVN, criado como substituto do
CVS, removendo diversas limitações e com melhor performance.
Git: Sistema de controle de versão distribuído, permite ter cópias
locais e remotas. Desenvolvido por uma equipe comandada por
Linus e hoje é o padrão para novos projetos open source.
Mercurial: Trabalha da mesma forma que o Git, e é uma opção
para sistemas de controle de versão distribuídos.
Embedded
Labworks
LABORATÓRIO
Configurando e usando o Eclipse
Embedded
Labworks
Linux Embarcado
Ferramentas de análise
Embedded
Labworks
VALGRIND
✗
✗
✗
O Valgring é um framework de instrumentação para se criar
ferramentas de análise dinâmica de aplicações.
http://valgrind.org/
Atualmente, o Valgrind fornece ferramentas de análise de memória
e profiling de aplicações.
Um dos principais usos do Valgring é na análise de alocação
dinâmica de memória e detecção de memory leak nas aplicações.
Embedded
Labworks
APLICAÇÃO COM BUG
int txData(char *data)
{
unsigned char *ptr = NULL, *buf = NULL;
int size = strlen(data);
if ((ptr = buf = (unsigned char*)malloc(size + 3)) == NULL)
return(1);
*ptr++ = STX;
strncpy(ptr, data, size);
ptr += size;
*ptr++ = ETX;
if (txSerial(buf, size + 3) == 1)
return(2);
free(buf);
return 0;
}
Embedded
Labworks
TESTANDO COM VALGRIND
valgrind ./leak
==3811== Memcheck, a memory error detector
==3811== Copyright (C) 20022009, and GNU GPL, by Julian Seward et al.
==3811== Using Valgrind3.6.0.SVNDebian and LibVEX; rerun with h for copyright info
==3811== Command: ./leak
==3811==
Erro ao enviar mensagem!
==3811==
==3811== HEAP SUMMARY:
==3811== in use at exit: 13 bytes in 1 blocks
==3811== total heap usage: 1 allocs, 0 frees, 13 bytes allocated
==3811==
==3811== LEAK SUMMARY:
==3811== definitely lost: 13 bytes in 1 blocks
==3811== indirectly lost: 0 bytes in 0 blocks
==3811== possibly lost: 0 bytes in 0 blocks
==3811== still reachable: 0 bytes in 0 blocks
==3811== suppressed: 0 bytes in 0 blocks
==3811== Rerun with leakcheck=full to see details of leaked memory
==3811==
==3811== For counts of detected and suppressed errors, rerun with: v
==3811== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 8)
Embedded
Labworks
STRACE
✗
✗
✗
O strace (system calls tracer) permite capturar todas as chamadas
de sistema realizadas pela sua aplicação.
http://sourceforge.net/projects/strace/
Bastante útil para debugar uma aplicação que fecha sem exibir
nenhuma mensagem de erro, ou então para fazer engenharia
reversa em uma aplicação a qual você tenha somente o binário.
Disponível em sistemas GNU/Linux, e pode ser compilada para sua
plataforma alvo.
Embedded
Labworks
EXEMPLO STRACE
strace cat Makefile
execve("/bin/cat", ["cat", "Makefile"], [/* 38 vars */]) = 0
brk(0) = 0x98b4000
access("/etc/ld.so.nohwcap", F_OK) = 1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 1, 0) = access("/etc/ld.so.preload", R_OK) = 1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=111585, ...}) = 0
mmap2(NULL, 111585, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f69000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = 1 ENOENT (No such file or directory)
open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0755, st_size=1442180, ...}) = 0
mprotect(0xb7f62000, 4096, PROT_NONE) = 0
mmap2(0xb7f63000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15c) = 0xb7f63000
mmap2(0xb7f66000, 9840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 1, 0) = 0xb7f66000
close(3) = 0
...
Embedded
Labworks
LTRACE
✗
✗
O ltrace (library calls tracer) permite capturar todas as chamadas
de bibliotecas realizadas e sinais recebidos pela sua aplicação.
http://freshmeat.net/projects/ltrace/
Complementa o uso do strace, que não exibe as chamadas de
biblioteca.
Embedded
Labworks
EXEMPLO LTRACE
ltrace nedit index.html
sscanf(0x8274af1, 0x8132618, 0x8248640, 0xbfaadfe8, 0) = 1
sprintf("const 0", "const %d", 0) = 7
strcmp("startScan", "const 0") = 1
strcmp("ScanDistance", "const 0") = 1
strcmp("const 200", "const 0") = 1
strcmp("$list_dialog_button", "const 0") = 1
strcmp("$shell_cmd_status", "const 0") = 1
strcmp("$read_status", "const 0") = 1
strcmp("$search_end", "const 0") = 1
strcmp("$string_dialog_button", "const 0") = 1
strcmp("$rangeset_list", "const 0") = 1
strcmp("$calltip_ID", "const 0") = 1
...
Embedded
Labworks
SUMÁRIO LTRACE
ltrace c cat /etc/resolv.conf % time seconds usecs/call calls function

22.10 0.000795 795 1 setlocale
8.51 0.000306 153 2 read
7.81 0.000281 281 1 write
7.65 0.000275 137 2 __fxstat
6.84 0.000246 61 4 __freading
6.31 0.000227 113 2 fclose
4.39 0.000158 158 1 open
4.06 0.000146 146 1 close
3.92 0.000141 141 1 posix_fadvise
3.59 0.000129 64 2 fileno
3.56 0.000128 64 2 __fpending
...

100.00 0.003597 29 total
Embedded
Labworks
LABORATÓRIO
Usando ferramentas de análise
Embedded
Labworks
Linux Embarcado
E agora?
Embedded
Labworks
RECURSOS ONLINE
✗
✗
✗
✗
Site do kernel Linux:
Linux kernel mailing list:
http://www.tux.org/lkml
Acompanhar as mudanças nas novas versões do kernel:
http://wiki.kernelnewbies.org/LinuxChanges
Notícias e novidades sobre o desenvolvimento do kernel:
http://lwn.net
Embedded
Labworks
RECURSOS ONLINE (cont.)
✗
✗
✗
✗
Linux Foundation (notícias, blog e vídeos):
http://linuxfoundation.org
Free electrons (documentos e vídeos):
http://free-electrons.com
Revista eletrônica sobre Linux:
http://www.linuxjournal.com/
Notícias sobre Linux e software livre (brasileiro):
http://br-linux.org
Embedded
Labworks
RECURSOS ONLINE (cont.)
✗
✗
✗
Portal Embarcados:
http://embarcados.com.br
Grupo sis_embarcados:
https://groups.google.com/group/sis_embarcados
Blog do Sergio Prado:
http://sergioprado.org
Embedded
Labworks
LIVRO SOFTWARE LIVRE
The Cathedral & The Bazaar
Eric S. Raymond
Embedded
Labworks
LIVROS DESENVOLVIMENTO DE SOFTWARE
The Linux programming interface
Michael Kerrisk
The art of UNIX Programming
Eric S. Raymond
Embedded
Labworks
LIVROS LINUX EMBARCADO
Embedded Linux Primer
Christopher Hallinan
Building Embedded Linux Systems
Karim Yaghmour & others
Embedded
Labworks
LIVROS LINUX KERNEL
Linux Kernel in a Nutshell
Greg Kroah-Hartman
Linux Kernel Development
Robert Love
Embedded
Labworks
LIVROS LINUX DEVICE DRIVERS
Essential Linux Device Drivers
Sreekrishnan Venkateswaran
Linux Device Drivers
Jonathan Corbet & others
OBRIGADO!
E-mail
Website
[email protected]
http://e-labworks.com
Embedded Labworks
Por Sergio Prado. São Paulo, Novembro de 2012
® Copyright Embedded Labworks 2004-2013. All rights reserved.