Treinamento Linux embarcado

3,031 views

Published on

Slides do treinamento de Linux embarcado da Labworks.

Published in: Technology

Treinamento Linux embarcado

  1. 1. Embedded Labworks Por Sergio Prado. São Paulo, Junho de 2016 ® Copyright Embedded Labworks 2004-2016. All rights reserved. Linux embarcado
  2. 2. 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
  3. 3. Embedded Labworks SOBRE O INSTRUTOR ✗ Sergio Prado tem 20 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 sobre Linux e sistemas embarcados: http://sergioprado.org
  4. 4. Embedded Labworks AGENDA DO TREINAMENTO ✗ DIA 1: Introdução e arquitetura de sistemas com Linux embarcado, toolchain, bootloader e kernel. ✗ DIA 2: Rootfs, módulos do kernel, sistemas de arquivo e ferramentas de build de sistema. ✗ DIA 3: Desenvolvimento de aplicações, licenças de software, aplicações gráficas, ferramentas de desenvolvimento, depuração de sistemas Linux.
  5. 5. Embedded Labworks PRÉ-REQUISITOS ✗ Usuário nível básico de distribuições GNU/Linux. ✗ Terminal de comandos do Linux (ls, cp, cat, grep, find, vi, etc). ✗ Conhecimentos básicos em linguagem C/C++. ✗ Conhecimento básicos de hardware e sistemas embarcados (GPIO, PWM, I2C, SPI, etc).
  6. 6. Embedded Labworks AMBIENTE DE LABORATÓRIO /opt/labs/ Ambiente de laboratório dl/ Aplicações e pacotes open­source Que serão usados durante as atividades de laboratório docs/ Documentação guides/ Guias de consulta (shell, vi, etc)   hardware/ Documentação do hardware   training/ Slides e atividades de laboratório.   videos/ Vídeos ex/ Exercícios de laboratório tools/ Ferramentas de uso geral
  7. 7. Embedded Labworks ORIENTAÇÕES GERAIS ✗ Pergunte... ✗ Expresse seu ponto de vista... ✗ Troque experiências... ✗ Ajude... ✗ Participe!
  8. 8. Embedded Labworks Linux embarcado Introdução à Linux embarcado
  9. 9. 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.
  10. 10. 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).”
  11. 11. Embedded Labworks 23 ANOS DEPOIS
  12. 12. Embedded Labworks VÍDEO (OS 20 ANOS DO LINUX)
  13. 13. 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.
  14. 14. Embedded Labworks PRINCIPAIS CARACTERÍSTICAS ✗ Código aberto e livre de royalties. ✗ Portabilidade para mais de 28 arquiteturas! ✗ Escalabilidade: o mesmo kernel roda em relógios, em celulares e em servidores da bolsa de valores! ✗ Estabilidade: capaz de rodar por muito tempo sem precisar de um único reboot. ✗ Recursos ”infinitos” disponíveis na Internet.
  15. 15. 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!
  16. 16. 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!
  17. 17. 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!
  18. 18. 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 aberto é de boa qualidade, portanto tome cuidado. Procure sempre aqueles mais usados em outros projetos e com uma comunidade mais ativa.
  19. 19. 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. ✗ Em muitos casos o suporte é melhor comparado ao suporte prestado por empresas comerciais, mas você precisa saber como usar corretamente o suporte da comunidade. ✗ Permite você resolver os problemas mais rapidamente!
  20. 20. 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!
  21. 21. Embedded Labworks Linux embarcado Arquitetura básica
  22. 22. Embedded Labworks ARQUITETURA BÁSICA Hardware Bootloader Linux kernel Biblioteca C Biblioteca Biblioteca Aplicação Aplicação Toolchain
  23. 23. 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.
  24. 24. Embedded Labworks HARDWARE Hardware Bootloader Linux kernel Biblioteca C Biblioteca Biblioteca Aplicação Aplicação Toolchain
  25. 25. Embedded Labworks HARDWARE
  26. 26. Embedded Labworks CPU ✗ Suporta mais de 30 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/ ✗ 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).
  27. 27. Embedded Labworks MEMÓRIA RAM E ARMAZENAMENTO ✗ Um sistema Linux bem básico pode funcionar com 8MB de RAM (ou até menos!), mas o ideal para começar é em torno de 32MB. ✗ Suporta armazenamento em memória flash NAND e NOR, disco rígido, cartão SD/MMC, etc. ✗ Um sistema bem básico pode funcionar com 2M de armazenamento (ou até menos!).
  28. 28. 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).
  29. 29. 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 (bootloader e kernel) é melhor: maior qualidade e novas versões disponíveis. ✗ A diferença entre uma plataforma suportada na árvore oficial 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!
  30. 30. Embedded Labworks TOOLCHAIN Hardware Bootloader Linux kernel Biblioteca C Biblioteca Biblioteca Aplicação Aplicação Toolchain
  31. 31. 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.
  32. 32. Embedded Labworks TOOLCHAIN (cont.) Binário x86 x86 Binário ARM ARM Código-fonte x86 Toolchain nativo Cross-compiling toolchain Host Target
  33. 33. Embedded Labworks COMPONENTES DO TOOLCHAIN ✗ Compilador (gcc). ✗ Assembler e Linker (binutils). ✗ Standard C Library (glibc, uclibc, dietlibc, etc).
  34. 34. Embedded Labworks TOOLCHAINS PRONTOS ✗ Linaro (ARM): https://wiki.linaro.org/WorkingGroups/ToolChain ✗ Sourcery Codebench (ARM, MIPS, PPC): http://sourcery.mentor.com/public/gnu_toolchain ✗ Scratchbox (ARM e x86): http://www.scratchbox.org/ ✗ Linux/MIPS: http://www.linux-mips.org/wiki/Toolchains
  35. 35. Embedded Labworks FERRAMENTAS OPEN SOURCE ✗ Crosstool-ng: http://crosstool-ng.org/ ✗ Buildroot: http://buildroot.uclibc.org/ ✗ Yocto Project: https://www.yoctoproject.org/
  36. 36. Embedded Labworks SISTEMA LINUX EMBARCADO Hardware Bootloader Linux kernel Biblioteca C Biblioteca Biblioteca Aplicação Aplicação Toolchain
  37. 37. Embedded Labworks SISTEMA LINUX EMBARCADO (NA FLASH) Bootloader Kernel Rootfs Memória flash
  38. 38. Embedded Labworks BOOTLOADER Hardware Bootloader Linux kernel Biblioteca C Biblioteca Biblioteca Aplicação Aplicação Toolchain
  39. 39. Embedded Labworks BOOTLOADER ✗ O bootloader tem basicamente duas responsabilidades: ✗ Inicializar o hardware. ✗ Carregar e executar o sistema operacional. ✗ Mas normalmente o bootloader provê outras funcionalidades para facilitar o desenvolvimento do sistema.
  40. 40. Embedded Labworks FUNCIONALIDADES DO BOOTLOADER ✗ Passagem de parâmetros para o kernel. ✗ Ler e escrever em dispositivos de armazenamento (memória flash, cartão SD, etc). ✗ Boot pela rede. ✗ Rotinas de diagnóstico de hardware.
  41. 41. Embedded Labworks PRINCIPAIS BOOTLOADERS ✗ x86: ✗ LILO ✗ Grub ✗ Syslinux ✗ ARM, MIPS, PPC e outras arquiteturas: ✗ U-Boot ✗ Barebox ✗ Redboot
  42. 42. Embedded Labworks KERNEL Hardware Bootloader Linux kernel Biblioteca C Biblioteca Biblioteca Aplicação Aplicação Toolchain
  43. 43. 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.
  44. 44. Embedded Labworks CARACTERÍSTICAS DO KERNEL ✗ Gerenciar a execução dos processos e controlar o 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 de módulos do kernel.
  45. 45. Embedded Labworks EXEMPLO DE SYSTEM CALL
  46. 46. Embedded Labworks ROOTFS Hardware Bootloader Linux kernel Biblioteca C Biblioteca Biblioteca Aplicação Aplicação Toolchain
  47. 47. Embedded Labworks COMPONENTES BÁSICOS ✗ Biblioteca do sistema (uClibc, glibc, eglibc, dietlibc, musl, etc). ✗ Mecanismo de inicialização. ✗ Bibliotecas e aplicações.
  48. 48. 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).
  49. 49. Embedded Labworks BUSYBOX ✗ Pacote que 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. ✗ É considerado o canivete suíço de sistemas embarcados com Linux!
  50. 50. Embedded Labworks BUSYBOX – TUDO ISSO EM ~1MB! 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
  51. 51. Embedded Labworks SISTEMA LINUX “Desenvolver um sistema Linux embarcado é como brincar de Lego!”
  52. 52. 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. ✗ Compilar bibliotecas e aplicações, e gerar a imagem final do rootfs.
  53. 53. Embedded Labworks ALGUNS BUILD SYSTEMS ✗ Proprietários: ✗ Monta Vista. ✗ Wind River. ✗ TimeSys. ✗ Open source: ✗ Buildroot. ✗ LTIB. ✗ Poky (Yocto Project). ✗ OpenEmbedded.
  54. 54. 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!
  55. 55. Embedded Labworks VAMOS COMEÇAR?
  56. 56. Embedded Labworks Linux embarcado Ambiente de desenvolvimento
  57. 57. 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!
  58. 58. Embedded Labworks QUE DISTRIBUIÇÃO USAR?
  59. 59. 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). Host Target Serial Ethernet
  60. 60. Embedded Labworks NOSSA PRINCIPAL FERRAMENTA!
  61. 61. 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
  62. 62. 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). ✗ Unix-Linux-Command-Reference.pdf (referência de comandos Linux).
  63. 63. Embedded Labworks Linux embarcado Toradex Colibri i.MX6DL
  64. 64. Embedded Labworks COLIBRI IMX6DL ✗ System-on-module (SOM) da Toradex. ✗ Baseado no SOC i.MX6 DualLite da NXP, um ARM Cortex-A9 rodando a até 996MHz. ✗ 512MB de memória RAM. ✗ 4GB de armazenamento interno (eMMC NAND Flash). ✗ Conector no padrão SODIMM200 (memória DDR1).
  65. 65. Embedded Labworks PLACA BASE VIOLA ✗ Placa base compatível com todos os módulos Colibri da Toradex. ✗ 2 conectores USB Host e 1 conector Ethernet. ✗ 1 conector de cartão SD. ✗ Interface RGB para display LCD. ✗ Barramento de 50 pinos que exporta o acesso à diversas interfaces de I/O do SOC (I2C, SPI, UART, GPIO, etc). ✗ Alimentação externa com uma fonte de 5V/2A.
  66. 66. Embedded Labworks PLACA DE EXPANSÃO IPÊ ✗ Placa desenvolvida pela Toradex Brasil. ✗ 2 chaves, 1 botão e 3 leds conectados a GPIOs. ✗ 1 led e 1 buzzer conectados a canais PWM. ✗ 1 porta serial para console. ✗ 1 resistor dependente de luz (LDR) e um trimpot conectados a canais A/D. ✗ 1 acelerômetro MMA8653. ✗ 1 expansor de GPIOs MCP23S08 conectado a um display de 7 segmentos.
  67. 67. Embedded Labworks REFERÊNCIAS E DOCUMENTAÇÃO ✗ A documentação do hardware está disponível no ambiente de laboratório do treinamento em /opt/labs/docs/hardware: ✗ SOC_imx6sdl_datasheet.pdf: datasheet do SOC. ✗ SOM_colibri_imx6_datasheet.pdf: datasheet do SOM. ✗ BASE_BOARD_viola_datasheet.pdf: datasheet da placa base. ✗ EXT_BOARD_ipe_esquemático.pdf: esquemático da placa de expansão. ✗ Recursos na internet: http://www.toradex.com/ https://www.toradex.com/community/ http://community.nxp.com
  68. 68. Embedded Labworks LABORATÓRIO Conectando e testando o target
  69. 69. Embedded Labworks Linux embarcado Toolchain
  70. 70. 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.
  71. 71. 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.
  72. 72. Embedded Labworks TIPOS DE TOOLCHAIN (cont.) Binário x86 x86 Binário ARM ARM Código-fonte x86 Toolchain nativo Cross-compiling toolchain Host Target
  73. 73. Embedded Labworks COMPONENTES DO TOOLCHAIN Compilador (GCC) Binutils Headers do kernel Debugger (GDB) Biblioteca C padrão Toolchain
  74. 74. 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.
  75. 75. 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.
  76. 76. 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, musl, etc. Kernel Biblioteca C Aplicações
  77. 77. 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.
  78. 78. 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! ✗ Comunidade de desenvolvimento do projeto bem ativa. ✗ Usada em grande parte do dispositivos de consumo com Linux embarcado.
  79. 79. Embedded Labworks COMPARANDO GLIBC E UCLIBC Comparação realizada em uma arquitetura ARM
  80. 80. 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.
  81. 81. Embedded Labworks KERNEL HEADERS (EXEMPLOS) ✗ Números das chamadas de sistema em <asm/unistd.h>: ✗ Definições de constantes em <asm­generic/fcntl.h>: ✗ Estruturas de dados em <asm/stat.h>: #define __NR_exit                 1 #define __NR_fork                 2 #define __NR_read                 3 #define O_RDWR          00000002 struct stat {         unsigned long  st_dev;         unsigned long  st_ino;  [...] };
  82. 82. Embedded Labworks USANDO TOOLCHAINS ✗ Existem basicamente duas soluções para trabalhar com toolchains: 1. Usar um toolchain pronto, fornecido por uma empresa ou pela comunidade. 2. Usar uma ferramenta para configurar e gerar um toolchain customizado, de acordo com as suas necessidades.
  83. 83. 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
  84. 84. Embedded Labworks INSTALANDO E USANDO ✗ Basta seguir o procedimento do fornecedor da solução. ✗ Normalmente, estes são os passos: ✗ Baixar e descompactar o 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: PREFIX­gcc teste.c ­o teste ✗ O PREFIX depende da configuração do toolchain, e permite diferenciar toolchains nativos de toolchains para compilação cruzada.
  85. 85. Embedded Labworks LABORATÓRIO Usando um toolchain pré-compilado
  86. 86. Embedded Labworks GERANDO SEU PRÓPRIO TOOLCHAIN ✗ Gerar um toolchain manualmente é uma tarefa difícil e dolorosa! ✗ É necessário estar familiarizado com o gcc. ✗ Muitos componentes para configurar e compilar. ✗ Existem depêndencias entre as versões dos componentes. ✗ Algumas plataformas necessitam que sejam aplicados patches em alguns componentes antes de compilar. ✗ Ótimo site para os aventureiros: http://www.linuxfromscratch.org/
  87. 87. 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.
  88. 88. Embedded Labworks ALGUMAS FERRAMENTAS ✗ Crosstool-ng (suporta glibc, uClibc, eglibc): http://crosstool-ng.org/ ✗ Buildroot (sistema de build): http://www.buildroot.net ✗ Poky/Yocto Project (sistema de build): https://www.yoctoproject.org
  89. 89. Embedded Labworks CROSSTOOL-NG ✗ O crosstool-ng é a principal ferramenta de código-aberto específica para a criação de toolchains. http://crosstool-ng.org/ ✗ Capaz de gerar toolchains para diferentes arquiteturas de hardware, incluindo x86, x86-64, MPIS, ARM e PPC. ✗ Capaz de gerar toolchains bare metal e com suporte ao kernel Linux. ✗ Possui a mesma interface de configuração do kernel Linux.
  90. 90. Embedded Labworks CROSSTOOL-NG (cont.)
  91. 91. Embedded Labworks LABORATÓRIO Compilando seu próprio toolchain
  92. 92. Embedded Labworks Linux embarcado Bootloader
  93. 93. Embedded Labworks BOOTLOADER ✗ O bootloader é o código responsável por: ✗ Inicializar o hardware (CPU, GPIO, controladora de RAM, etc). ✗ Carregar outro binário (normalmente o sistema operacional) de um dispositivo de armazenamento para a RAM. ✗ Passar o controle da CPU para este binário.
  94. 94. Embedded Labworks FUNCIONALIDADES DO BOOTLOADER ✗ Além destas funcionalidades básicas, a maioria dos bootloaders possui uma linha de comandos com diversas funcionalidades, dentre elas: ✗ Manipulação das memórias RAM e flash. ✗ Comunicação via rede e serial. ✗ Rotinas de diagnóstico de hardware. ✗ Suporte à variáveis de ambiente e execução de scripts. ✗ Passagem de parâmetros para o sistema operacional.
  95. 95. Embedded Labworks BOOTLOADERS NO X86 ✗ 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, carregar para a memória e executar. BIOS em ROM Estágio 2 do disco Estágio 1 512 bytes do disco SO do disco
  96. 96. 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. http://www.syslinux.org/
  97. 97. Embedded Labworks BOOT EM ARM O SoC tem um código de boot em uma ROM interna, responsável por carregar um bootloader de 1o. estágio (SPL) para uma memória RAM interna (SRAM ou IRAM). O SPL (Secundary Program Loader) é responsável por inicializar o hardware (CPU, DRAM, GPIOs, etc) e carregar um bootloader de 2o. estágio para a RAM. É um bootloader mais completo e normalmente suporta sistemas de arquivo, interface USB e protocolo TCP/IP. Responsável por carregar e executar o kernel Linux. É executado da memória RAM e assume o controle do sistema (a partir daqui, o bootloader não existe mais). ROM Code SPL Bootloader Linux Kernel
  98. 98. Embedded Labworks i.MX28 (FREESCALE) 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). Inicializa alguns dispositivos de hardware (rede, USB, etc). Carrega a imagem do kernel na RAM e passa o controle para ele. Roda da RAM. Assume o controle do sistema (a partir daqui, o bootloader não existe mais). ROM Code Bootlets U-Boot Linux Kernel
  99. 99. Embedded Labworks OMAP3530/AM35x (TI) Procura por imagens de boot na NAND, UART, USB e MMC, e carrega para a SRAM (64KB). Um GPIO pode mudar a ordem da busca. Roda da SRAM. Inicializa a controladora da SDRAM, NAND ou MMC, e carrega o bootloader de 2o. estágio para a RAM. Roda da RAM. Inicializa alguns dispositivos de hardware (rede, USB, etc). Carrega a imagem do kernel na RAM e passa o controle para ele. Roda da RAM. Assume o controle do sistema (a partir daqui, o bootloader não existe mais). ROM Code X-Loader U-Boot Linux Kernel
  100. 100. Embedded Labworks LPC3250 (NXP) 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. Roda da RAM. Inicializa alguns dispositivos de hardware (rede, USB, etc). Carrega a imagem do kernel na RAM e passa o controle para ele. Roda da RAM. Assume o controle do sistema (a partir daqui, o bootloader não existe mais). ROM Code Kickstart/S1L U-Boot Linux Kernel
  101. 101. Embedded Labworks AT91 (ATMEL) Procura por imagens de boot em diversos dispositivos de armazenamento, e carrega para a SRAM (4KB). Roda da SRAM. Inicializa a controladora da DRAM e carrega o bootloader de 2o. estágio para a RAM. Roda da RAM. Inicializa alguns dispositivos de hardware (rede, USB, etc). Carrega a imagem do kernel na RAM e passa o controle para ele. Roda da RAM. Assume o controle do sistema (a partir daqui, o bootloader não existe mais). ROM Code AT91Bootstrap U-Boot Linux Kernel
  102. 102. Embedded Labworks i.MX5/i.MX6 (FREESCALE) Código de boot em ROM é iniciado no reset. Lê o registrador BOOT_MODE ou um conjunto de GPIOs para determinar o dispositivo de boot (NOR/NAND, cartão SD/MMC, SATA, etc). Uma versão mínima do U-Boot que irá inicializar o hardware (clock, SDRAM, etc) e carregar o U-Boot completo para a RAM. Inicializa alguns dispositivos de hardware (rede, USB, etc). Carrega a imagem do kernel na RAM e passa o controle para ele. Roda da RAM. Assume o controle do sistema (a partir daqui, o bootloader não existe mais). ROM Code U-Boot SPL U-Boot Linux Kernel
  103. 103. Embedded Labworks A31 (ALLWINNER) Código de boot em ROM é iniciado no reset. Verifica as interfaces de boot suportadas (NAND, SD Card, USB) para carregar o SPL para a memória RAM interna do chip. Uma versão mínima do U-Boot que irá inicializar o hardware (clock, SDRAM, etc) e carregar o U-Boot completo para a RAM. Inicializa alguns dispositivos de hardware (rede, USB, etc). Carrega a imagem do kernel na RAM e passa o controle para ele. Roda da RAM. Assume o controle do sistema (a partir daqui, o bootloader não existe mais). ROM Code U-Boot SPL U-Boot Linux Kernel
  104. 104. Embedded Labworks BOOTLOADERS EM LINUX EMBARCADO ✗ O bootloader de 1o. estágio (SPL) é totalmente dependente do hardware e cada plataforma pode ter o seu. Nosso foco é no bootloader de 2o. estágio. ✗ Existem alguns bootloaders de código-aberto que suportam o kernel Linux. Os dois mais conhecidos e utilizados são: ✗ U-Boot: bastante popular em ARM, mas também usado em outras arquiteturas como MIPS, PPC e até x86. http://www.denx.de/wiki/U-Boot ✗ Barebox: sucessor do U-Boot, código melhor estruturado e desenvolvimento ativo, mas ainda com pouco suporte a hardware. http://www.barebox.org
  105. 105. Embedded Labworks U-BOOT ✗ Bootloader open-source (GPLv2) mais utilizado atualmente. http://www.denx.de/wiki/U-Boot ✗ 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
  106. 106. 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).
  107. 107. Embedded Labworks FUNCIONALIDADES DO U-BOOT (cont.) ✗ Boot por interfaces SD/MMC ou USB. ✗ Entende sistemas de arquivo (fat, ext2/3, ubifs, jffs2, cramfs, etc). ✗ Configuração por variáveis de ambiente e suporte à scripts. ✗ Executa código bare-metal. ✗ Carrega e executa imagens do kernel Linux.
  108. 108. 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: http://www.denx.de/wiki/U-Boot ✗ 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.
  109. 109. 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_config> pelo nome da sua plataforma de desenvolvimento no U-Boot. Por exemplo, para configurar o U-Boot para o módulo Colibri i.MX6 da Toradex: $ make colibri_imx6_defconfig
  110. 110. 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=arm­linux­ ✗ No final, será gerada a imagem do U-Boot para ser gravada no target.
  111. 111. Embedded Labworks GRAVANDO O U-BOOT ✗ O processo de gravação do U-Boot pode ser feito de diferentes formas, dependendo do target: ✗ Se o target puder iniciar por uma mídia removível (cartão SD, pendrive, HD, etc), basta conectar o dispositivo removível na sua máquina de desenvolvimento e gravar. ✗ Se o dispositivo usar memória flash, podem existir algumas opções: ✗ O bootloader de 1o. estágio pode fornecer um mecanismo de escrita na flash. ✗ A CPU pode fornecer um monitor de boot que se comunica via serial ou USB. ✗ JTAG.
  112. 112. Embedded Labworks LABORATÓRIO Compilando e gravando o U-Boot
  113. 113. Embedded Labworks Linux embarcado Kernel Linux
  114. 114. Embedded Labworks VISÃO GERAL Biblioteca C Hardware Biblioteca Biblioteca Aplicação User space Kernel AplicaçãoAplicação Chamadas de sistema Notificação de eventos Exportação de informações Gerenciamento do hardware Notificação de eventos
  115. 115. 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.
  116. 116. Embedded Labworks COLABORAÇÃO
  117. 117. Embedded Labworks ESTATÍSTICAS ✗ Algumas estatísticas da versão 3.9: ✗ 69 dias de desenvolvimento. ✗ 11.910 commits. ✗ 608.436 linhas adicionadas. ✗ 338.439 linhas removidas. ✗ Aproximadamente 7 commits por hora. ✗ Aproximadamente 10 linhas alteradas por minuto!
  118. 118. Embedded Labworks ARQUITETURA
  119. 119. 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.
  120. 120. Embedded Labworks GERENCIAMENTO DE PROCESSOS (cont.) ✗ Trade-off entre capacidade de processamento e tempo de resposta (latência). ✗ O Linux é um sistema multitasking preemptivo. ✗ Possui o conceito de classes de escalonamento, onde cada classe possui um algoritmo 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).
  121. 121. 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).
  122. 122. 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.
  123. 123. 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. ✗ SWAP: se faltar memória física, possibilita salvar e recuperar páginas de memória do disco. ✗ Proteção: cada processo só enxerga seu espaço de endereçamento, onde um acesso inválido gera uma exceção (segmentation fault). ✗ Compartilhamento: os processos podem compartilhar memória (código, dados, etc), usado por exemplo em mecanismos de IPC. ✗ Memory mapping: possibilidade de mapear um arquivo físico em memória.
  124. 124. 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.
  125. 125. 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
  126. 126. 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.
  127. 127. 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.
  128. 128. 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. ✗ Em 2015, a versão mudou para 4.0.
  129. 129. 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
  130. 130. Embedded Labworks FONTES DO KERNEL ✗ A versão oficial do código-fonte do kernel liberada por Linus Torvalds encontra-se em: http://www.kernel.org ✗ Baixando os fontes por http: $ wget http://www.kernel.org/pub/linux/kernel/v3.0/linux­3.12.tar.bz2 $ tar xjfv linux­3.12.tar.bz2 ✗ Baixando os fontes pelo git: $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
  131. 131. 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. ✗ Portanto, consulte a documentação da sua plataforma para saber como e onde baixar os fontes do Linux.
  132. 132. Embedded Labworks FONTES DO KERNEL (cont.) $ ls linux/ arch     Documentation  ipc          Makefile        scripts block    drivers        Kbuild       mm              security certs    firmware       Kconfig      net             sound COPYING  fs             kernel       README          tools CREDITS  include        lib          REPORTING­BUGS  usr crypto   init           MAINTAINERS  samples         virt
  133. 133. 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 núcleo do kernel é bem pequeno!
  134. 134. Embedded Labworks TAMANHO DOS FONTES DO KERNEL (cont.) Linux 2.6.39
  135. 135. 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.
  136. 136. Embedded Labworks LICENÇA (cont.) ✗ Mas e os módulos do kernel? ✗ 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 de código fechado são ruins. Veja “Kernel Driver Statement” no link abaixo: http://j.mp/fbyuuH ✗ Sob um ponto de vista legal, cada driver é provavelmente um caso diferente. Ex: Nvidia. ✗ É realmente útil manter um driver proprietário?
  137. 137. 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.
  138. 138. Embedded Labworks CONFIGURANDO O KERNEL ✗ O kernel possui centenas de drivers de dispositivo, diversos protocolos de rede e muitos outros itens de configuração. ✗ Mas o kernel é bem modular, a maioria das opções podem ser habilitadas ou desabilitadas conforme a necessidade. ✗ O processo de configuração serve para você configurar o kernel para ser compilado para o seu sistema e plataforma de hardware. ✗ 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).
  139. 139. 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
  140. 140. Embedded Labworks make xconfig
  141. 141. Embedded Labworks make gconfig
  142. 142. Embedded Labworks make nconfig
  143. 143. Embedded Labworks make menuconfig
  144. 144. 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 é incluído na imagem final do kernel. Ele deve ser adicionado ao sistema de arquivos e pode ser carregado dinamicamente (em tempo de execução), conforme a necessidade.
  145. 145. 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 (built­in)→ <M>   Opção habilitada (módulo)→ ✗ Números inteiros. Ex: (17) Kernel log buffer size ✗ Strings. Ex: (iso8859­1) Default iocharset for FAT
  146. 146. Embedded Labworks DEPENDÊNCIAS ✗ Na configuração do kernel, podem existir dependências entre funcionalidades: ✗ Exemplo 1: o driver de um dispositivo I2C só pode ser habilitado se o barramento I2C for habilitado. ✗ Exemplo 2: o framework de porta serial do kernel (serial core) é habilitado automaticamente quando um driver de UART é habilitado.
  147. 147. 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 no comando abaixo: $ make menuconfig ✗ 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.
  148. 148. 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 o kernel Linux para uma plataforma específica. Por exemplo, para carregar a configuração padrão do módulo Colibri i.MX6 da Toradex: $ make ARCH=arm colibri_imx6_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
  149. 149. 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.
  150. 150. Embedded Labworks COMPILANDO O KERNEL ✗ Depois de configurado, para compilar nativamente basta executar: $ make ✗ Não precisa de previlégios de root! ✗ Para compilar de forma cruzada, você precisa indicar a arquitetura e o prefixo do toolchain: $ make ARCH=arm CROSS_COMPILE=arm­linux­ ✗ O comando acima irá gerar uma imagem genérica para ARM. Se você quiser gerar uma imagem específica, deve adicionar ao fim do comando o nome da imagem. Exemplo para gerar uma imagem para o U-Boot: $ make ARCH=arm CROSS_COMPILE=arm­linux­ uImage
  151. 151. 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 é inicializável, mas pode ser usada para depuração. ✗ 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).
  152. 152. Embedded Labworks INSTALANDO O KERNEL ✗ Para instalar o kernel, basta executar o comando abaixo: $ make INSTALL_PATH=<install_dir> install ✗ Este comando irá instalar os seguintes arquivos no diretório passado (ou no diretório /boot por padrão): ✗ 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).
  153. 153. Embedded Labworks DEVICE TREE ✗ Muitas plataformas possuem dispositivos de hardware que não podem ser identificados dinamicamente pelo kernel. ✗ Nestes casos, é necessário um mecanismo para comunicar ao kernel informações sobre os dispositivos de hardware presentes no sistema. ✗ A forma antiga de resolver este problema era descrevendo o hardware através de estruturas de dados, o que deixava o código- fonte do kernel mais confuso e difícil de manter. ✗ Atualmente, a maioria das plataformas (incluindo ARM) suportam o mecanismo de device tree.
  154. 154. Embedded Labworks DEVICE TREE (cont.) ✗ O device tree é uma estrutura de dados capaz de descrever a topologia e a configuração do hardware presente no sistema. ✗ Na prática, o device tree é um arquivo texto com extensão .dts que descreve hierarquicamente o hardware através de nós e propriedades. ✗ Atualmente, o device tree é suportado por diversas arquiteturas, incluindo ARM, PowerPC, OpenRISC, ARC e Microblaze.
  155. 155. Embedded Labworks LISTAGEM DEVICE TREE ✗ Cada placa possui um arquivo de especificação do device tree, disponível no código-fonte do kernel em arch/arm/boot/dts: $ ls arch/arm/boot/dts/ aks­cdu.dts alphascale­asm9260­devkit.dts alpine­db.dts am335x­baltos­ir5221.dts am335x­base0033.dts am335x­boneblack.dts am335x­bone.dts am335x­bonegreen.dts am335x­chiliboard.dts [...]
  156. 156. Embedded Labworks COMPILANDO O DEVICE TREE ✗ Uma ferramenta chamada Device Tree Compiler (dtc), disponível em scripts/dtc/, é responsável por compilar o device tree. ✗ Para compilar o device tree de todas as placas habilitadas na configuração do kernel: $ make ARCH=arm CROSS_COMPILE=arm­linux­ dtbs ✗ Para compilar o device tree de uma placa específica: $ make ARCH=arm CROSS_COMPILE=arm­linux­ imx6dl­colibri­ipe.dtb ✗ Os arquivos DTB são gerados em arch/arm/boot/dts.
  157. 157. Embedded Labworks BOOT COM DEVICE TREE ✗ Durante o processo de boot, o bootloader é o responsável por passar o DTB para o kernel. ✗ Exemplo para o U-Boot: > bootm ${loadaddr} ­ ${fdt_addr} ✗ Caso o bootloader não seja capaz de passar o DTB para o kernel, é possível indicar ao kernel que o DTB está integrado à sua imagem habilitando a opção CONFIG_ARM_APPENDED_DTB, e depois gerando uma imagem com o DTB integrado: $ cat zImage board.dtb > zImage_dtb
  158. 158. Embedded Labworks LIMPANDO A COMPILAÇÃO ✗ 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
  159. 159. 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 (kernel command line). ✗ A linha de comandos do kernel pode ser passada de duas formas: ✗ Pelo bootloader. ✗ Hardcoded na configuração do kernel, através da opção CONFIG_CMDLINE. ✗ Esta linha de comandos é uma string com diversas opções no formato chave=valor.
  160. 160. 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 nos fontes do kernel em: Documentation/kernel-parameters.txt
  161. 161. Embedded Labworks LABORATÓRIO Compilando e gravando o kernel Linux
  162. 162. Embedded Labworks Linux embarcado Rootfs
  163. 163. 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.
  164. 164. 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!
  165. 165. 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.
  166. 166. 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.
  167. 167. 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 ✗ Listando o conteúdo do pendrive: $ ls /mnt/usbkey docs prog.c picture.png movie.avi ✗ Desmontando o dispositivo USB: $ umount /mnt/usbkey
  168. 168. 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.
  169. 169. Embedded Labworks SISTEMA DE ARQUIVO ROOT (cont.) ✗ Se você não passar a opção root na linha de comandos, 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 ...
  170. 170. 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.
  171. 171. 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
  172. 172. 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
  173. 173. 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). ✗ 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. Host Servidor NFS Target Cliente NFS
  174. 174. 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)
  175. 175. 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).
  176. 176. 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.
  177. 177. Embedded Labworks DIRETÓRIOS MAIS IMPORTANTES /bin Programas básicos /sbin Aplicações de administração do sistema /boot Imagens de boot (bootloader, kernel, etc) /etc Arquivos de configuração /home Diretório de arquivos dos usuários /root Home do usuário root /lib Bibliotecas básicas do sistema /media Ponto de montagem para mídias removíveis /mnt Ponto de montagem para mídias estáticas
  178. 178. Embedded Labworks DIRETÓRIOS MAIS IMPORTANTES (cont.) /dev Arquivos de dispositivo /sys Ponto de montagem do sistema de arquivo virtual sysfs /proc Ponto de montagem do sistema de Arquivo virtual ”proc” /tmp Arquivos temporários /usr Aplicações e dados dos usuários    /usr/bin Aplicações básicas do usuário    /usr/lib Bibliotecas do usuário    /usr/sbin Aplicações de administração do usuário  /var Arquivos de dados (logs, banco de dados, arquivos temporários, etc)
  179. 179. Embedded Labworks ARQUIVOS DE DISPOSITIVO ✗ Um conceito muito importante vindo 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.
  180. 180. Embedded Labworks INFORMAÇÕES DOS DISPOSITIVOS ✗ Internamente, cada arquivo de dispositivo está 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.
  181. 181. Embedded Labworks EXEMPLOS ✗ Exemplos de arquivos de dispositivo: $ ls ­la /dev/ttyS* /dev/sda1 brw­rw­­­­ 1 root disk    8,  1 2012­01­25 06:54 /dev/sda1 crw­rw­­­­ 1 root dialout 4, 64 2012­01­25 06:54 /dev/ttyS0 crw­rw­­­­ 1 root dialout 4, 65 2012­01­25 06:54 /dev/ttyS1 crw­rw­­­­ 1 root dialout 4, 66 2012­01­25 06:54 /dev/ttyS2 crw­rw­­­­ 1 root dialout 4, 67 2012­01­25 06:54 /dev/ttyS3 ✗ Escrevendo ”Hello” na porta serial: int fd; fd = open(“/dev/ttyS0”, O_RDWR); write(fd, “Hello”, 5); close(fd);
  182. 182. 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égios de root): $ mknod /dev/<device> [c|b] major minor ✗ Para sistemas mais complexos, existem mecanismos para adicionar e remover arquivos de dispositivo dinamicamente: ✗ udev ✗ mdev ✗ devtmpfs
  183. 183. Embedded Labworks PROCFS ✗ O sistema de arquivo virtual procfs 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 procfs também possibilita ajustar parâmetros do kernel em tempo de execução. ✗ Muitas aplicações, como os comandos ps e top, utilizam o /proc para exibirem informações dos processos em execução.
  184. 184. Embedded Labworks PROCFS (cont.) ✗ Montando o procfs: $ mount ­t proc none /proc ✗ Mais informações na documentação do kernel: Documentation/filesystems/proc.txt
  185. 185. Embedded Labworks 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.
  186. 186. Embedded Labworks SYSFS (cont.) ✗ Montando o sysfs: $ mount ­t sysfs none /sys ✗ Mais informações na documentação do kernel: Documentation/filesystems/sysfs.txt
  187. 187. 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. ✗ O processo init pode ser passado como parâmetro na linha de comandos do kernel: init=/sbin/init ✗ Se o parâmetro init não for passado, o kernel tenta executar os seguintes binários, nesta ordem: /sbin/init, /etc/init, /bin/init e /bin/sh.
  188. 188. 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.
  189. 189. Embedded Labworks VISÃO GERAL DO BOOT Bootloader Carrega o kernel para a RAM e inicia init Inicia outros serviços e aplicações Kernel Monta o rootfs indicado por ”root=” Inicia a aplicação ”init” Shell Outras aplicações Rootfs
  190. 190. 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.
  191. 191. 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/.
  192. 192. Embedded Labworks /etc/inittab # Startup the system null::sysinit:/bin/mount ­t proc proc /proc null::sysinit:/bin/mount ­t sysfs sysfs /sys # 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 3­finger salute ::ctrlaltdel:/sbin/reboot # Stuff to do before rebooting null::shutdown:/usr/bin/killall syslogd
  193. 193. 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
  194. 194. Embedded Labworks /etc/init.d/ $ ls ­l init.d/ total 8 ­rwxr­xr­x 1 root root  408 2011­08­31 08:44 rcS ­rwxr­xr­x 1 root root  478 2011­09­08 15:02 S01logging ­rwxr­xr­x 1 root root 1365 2011­08­31 08:44 S20urandom ­rwxr­xr­x 1 root root  282 2011­08­31 08:44 S40network ­rwxr­xr­x 1 root root 1092 2011­09­08 16:05 S50dropbear ­rwxr­xr­x 1 root root   73 2011­09­13 14:50 S60leds
  195. 195. 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/
  196. 196. 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
  197. 197. Embedded Labworks LABORATÓRIO Criando um rootfs e testando com o NFS
  198. 198. Embedded Labworks Linux embarcado Módulos do kernel
  199. 199. 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 núcleo do kernel roda em kernelspace (gerenciamento de memória e processos). O restante roda em userspace, incluindo sistemas de arquivos, device drivers, protocolos de rede, etc!
  200. 200. Embedded Labworks MONOLÍTICO X MICROKERNEL
  201. 201. 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 facilmente 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.
  202. 202. Embedded Labworks VANTAGENS DOS MÓDULOS ✗ Módulos tornam fácil o desenvolvimento do kernel (ex: device drivers) sem precisar reiniciar o target. ✗ Ajuda a manter a imagem do kernel bem pequena. ✗ Só ocupa memória enquanto estiver carregado. ✗ O tempo de boot do kernel fica menor. ✗ Cuidado: módulos rodam em kernel space. Uma vez carregados, eles tem total controle do sistema! Por isso só podem ser carregados como root.
  203. 203. Embedded Labworks COMPILANDO OS MÓDULOS ✗ Para compilar os módulos, basta executar: $ make modules ✗ Para compilar os módulos de forma cruzada, não esqueça de indicar a arquitetura e o prefixo do toolchain: $ make ARCH=arm CROSS_COMPILE=arm­linux­ modules
  204. 204. 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, podemos usar o parâmetro INSTALL_MOD_PATH no comando de instalação: $ make ARCH=<arch> INSTALL_MOD_PATH=<dir> modules_install
  205. 205. 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 ficam descritas no arquivo /lib/modules/<kernel­version>/modules.dep. ✗ Este arquivo é gerado automaticamente quando você instala os módulos, através de uma ferramenta chamada depmod.
  206. 206. 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>
  207. 207. 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>
  208. 208. 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
  209. 209. Embedded Labworks PASSANDO PARÂMETROS ✗ Passando um parâmetro via linha de comando: $ modprobe <module> param=value ✗ Passando um parâmetro via arquivo de configuração (/etc/modprobe.conf ou /etc/modprobe.d/): options <module> param=value ✗ Passando um parâmetro via linha de comandos do kernel: <module>.param=value
  210. 210. Embedded Labworks LABORATÓRIO Trabalhando com módulos do kernel
  211. 211. Embedded Labworks Linux embarcado Tipos de sistemas de arquivo
  212. 212. 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 tipos de sistemas de arquivo? ✗ Performance. ✗ Segurança. ✗ Economia de espaço em disco. ✗ Uso em diferentes tipos de dispositivo de armazenamento.
  213. 213. 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: ✗ Memórias flash trabalham em blocos e para serem escritas precisam ser apagadas antes. Exemplo: flash NAND. ✗ 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. ✗ Por este motivo, vamos estudar estes dois sub-sistemas separadamente.
  214. 214. 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
  215. 215. Embedded Labworks SISTEMAS DE ARQUIVO TRADICIONAIS ✗ Existem sistemas de arquivo específicos para dispositivos de bloco. ✗ Um dos primeiros foi o tradicional sistema de arquivos 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).
  216. 216. 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.
  217. 217. 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. Escreve uma entrada no journal Escreve no arquivo Aplicação Escreve no arquivoUser space Kernel space Limpa entrada no journal
  218. 218. Embedded Labworks JOURNALING (cont.) ✗ 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. Reboot Journal vazio? Executa journal Sistema de arquivo OK Sim Descarta entradas incompletas no journal Não
  219. 219. 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á está em uso por algumas distribuições Linux. ✗ 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.
  220. 220. Embedded Labworks QUAL ESCOLHER? ✗ Na prática, você usará 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. Mas isso pode depender das características da sua aplicação e do dispositivo de armazenamento. ✗ 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.
  221. 221. Embedded Labworks SISTEMAS DE ARQUIVO COMPRIMIDOS ✗ Sistemas embarcados possuem normalmente poucos recursos de armazenamento. Por este motivo, você pode querer usar um sistema de arquivo que comprima os dados, deixando o tamanho da imagem do sistema de arquivo menor, e ocupando menos espaço no dispositivo de armazenamento. ✗ 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.
  222. 222. 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).
  223. 223. 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 a 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).
  224. 224. 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. ✗ São nestes casos que usamos sistemas de arquivo voláteis.
  225. 225. 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.
  226. 226. 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
  227. 227. Embedded Labworks MISTURANDO TUDO ✗ 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 ext4 para leitura e escrita de dados do usuário e de configuração. ✗ Dados temporários em RAM com o tmpfs. squashfs rootfs comprimido ext4 dados e configuração tmpfs dados voláteis RAMDispositivodeBloco
  228. 228. 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!
  229. 229. 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.
  230. 230. 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.
  231. 231. 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.
  232. 232. Embedded Labworks MTD (MEMORY TECHNOLOGY DEVICES) MTD Chip drivers Interface com o sistema de arquivos NOR flash MTD User modules Hardware DiskOnChip flash RAM chips ROM chipsNAND flash Block device Virtual memory Virtual devices jffs2 Char device Block deviceRead-only block device yaffs2ubifs
  233. 233. 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.
  234. 234. 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.
  235. 235. 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/
  236. 236. 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.
  237. 237. 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.
  238. 238. 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.
  239. 239. 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. ✗ Principal desvantagem é o overhead de metadados, por isso sua utilização é aconselhada apenas em memórias flash maiores (acima de 32M). ✗ Com a capacidade das memórias flash aumentando cada vez mais, tem se tornado o sistema de arquivo padrão para dispositivos MTD.
  240. 240. 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 o 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).
  241. 241. Embedded Labworks ESCOLHENDO O SISTEMA DE ARQUIVO Dados Voláteis? Somente Leitura? Dispositivo Tem flash? tmpfs squashfs ubifs ou jffs2 ext2 ou ext4 ext4 Sim Sim Sim Não NãoNão MTD Bloco
  242. 242. Embedded Labworks LABORATÓRIO Iniciando o rootfs de um dispositivo de bloco
  243. 243. Embedded Labworks Linux embarcado Build system
  244. 244. Embedded Labworks O DESAFIO: INTEGRAR TUDO ISSO Hardware Bootloader Linux kernel Biblioteca C Biblioteca Biblioteca Aplicação Aplicação Toolchain
  245. 245. Embedded Labworks O DESAFIO: INTEGRAR TUDO ISSO (cont.) u-boot.bin zImage rootfs.img

×