Aprendendo Linux embarcado com Yocto Project e SoM (System ... · © 2018 Microchip Technology...

© 2018 Microchip Technology Incorporated. All Rights Reserved. Class Number + Prefix Slide 1

Aprendendo Linux embarcado com Yocto Project e SoM (System on Module) da Microchip

Sergio PradoEmbedded Labworks


Sobre este material

• Este material é disponibilizado sob a Licença Creative Commons BY-SA 3.0.http://creativecommons.org/licenses/by-sa/3.0/legalcode

• Os fontes deste material estão disponíveis em:https://sergioprado.org/palestras/masters2018

• Sinta-se livre para utilizar, compartilhar e adaptar este material às suas necessidades, lembrando-se sempre de respeitar a licença.

http://creativecommons.org/licenses/by-sa/3.0/legalcode

https://sergioprado.org/palestras/masters2018


Sobre o palestrante

• Sergio Prado tem mais de 20 anos de experiência em desenvolvimento de software para sistemas embarcados.

• É sócio da Embedded Labworks, onde atua com consultoria, treinamento e desenvolvimento de software para sistemas embarcados.http://e-labworks.com

• É ativo na comunidade de sistemas embarcados no Brasil, sendo um dos criadores do site Embarcados, administrador do grupo sis_embarcados no Google Groups, além de manter um blog pessoal sobre assuntos da área.http://sergioprado.org

• É colaborador de alguns projetos de software livre, incluindo o Buildroot e o kernel Linux.

http://e-labworks.com/

http://sergioprado.org/


Ambiente de exercícios

/opt/labs/ Ambiente de exercíciosdl/ Aplicações e pacotes open-source

utilizados durante os exercíciosdocs/ Documentação hardware/ Documentação do hardware hands-on/ Slides e exercícios do hands-onex/ Exercícios do hands-on respostas/ Respostas dos exercícios

sources/ Código-fonte


Agenda

1. Linux embarcado

2. Build systems e Yocto Project

3. Kernel Linux e device tree

4. SDK e desenvolvimento de aplicações


Agenda

1. Linux embarcado





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.


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)."


27 ANOS DEPOIS


Kernel Linux

• O Linux é um 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 outros componentes de software em sistemas embarcados.

http://www.kernel.org/


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.


Linux embarcado

Hardware

Bootloader

Linux kernel

Biblioteca C

Biblioteca Biblioteca

Aplicação Aplicação

Toolchain


Características

• Hardware: dispositivo de hardware, plataforma-alvo, target.

• Bootloader: responsável pela inicialização básica do hardware, 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 a camada de aplicações do usuário.

• Rootfs: sistema de arquivos principal.● Biblioteca C: API do sistema operacional, interface entre

o kernel e as aplicações.● Bibliotecas e aplicações do usuário.

• Toolchain: conjunto de ferramentas para manipular e gerar a imagens do sistema.


Hardware

Hardware

Bootloader

Linux kernel

Biblioteca C



Toolchain


Hardware típico


Características do hardware

• O kernel Linux suporta mais de 30 arquiteturas diferentes de 32/64 bits (x86, ia64, ARM, PPC, MIPS, SuperH, Blackfin, Coldfire, etc).

• Não foi feito para microcontroladores de 8/16 bits!

• Originalmente desenvolvimento para suportar sistemas com MMU (Memory Management Unit).

• Um sistema Linux bem básico pode funcionar com 8MB de RAM (ou até menos!), mas o ideal para começar é pelo menos 32MB.

• Um sistema bem básico pode funcionar com 2M de armazenamento (ou até menos!).


SAMA5D27 SOM1 Kit1

• Plataforma de avaliação para o SOM (System-On-Module) SAMA5D27, baseado no SIP (System-In-Package) SAMA5D27.

• Processador ARM Cortex-A5 rodando a até 500MHz com 128MB de RAM DDR2.

• Inclui suporte a display LCD, cartão SD, Ethernet, USB, CAN, mikroBUS, etc.

• Possui diversos periféricos, incluindo botões, leds e uma EEPROM de 256 bytes.


SAMA5D27 SOM1 Kit1 (cont.)

PowerUART

Reset Boot via SDCARDLed


Documentação

• A documentação do hardware está disponível no ambiente de exercícios em /opt/labs/docs/hardware:

samA5d2-sip-datasheet.pdf: datasheet do SIP.

sama5d27-som-datasheet.pdf: datasheet do SOM.

sama5d27-som1-ek1-user-guide.pdf: manual de usuário do kit de desenvolvimento.

• Recursos na Internet:https://www.microchip.com/DevelopmentTools/ProductDetails/atsama5d27-som1-ek1

http://www.at91.com/linux4sam/bin/view/Linux4SAM/Sama5d27Som1EKMainPage

https://www.microchip.com/DevelopmentTools/ProductDetails/atsama5d27-som1-ek1

http://www.at91.com/linux4sam/bin/view/Linux4SAM/Sama5d27Som1EKMainPage


Bootloader

Hardware

Bootloader

Linux kernel

Biblioteca C



Toolchain


Bootloader (cont.)

• O bootloader tem basicamente duas responsabilidades:

Inicializar o hardware.

Carregar e executar o sistema operacional.

• Normalmente o bootloader provê outras funcionalidades para facilitar o desenvolvimento do sistema, incluindo:

Fazer o boot pela rede ou pela porta serial.

Ler e escrever na memória flash.

Executar rotinas de diagnóstico de hardware.


Principais bootloaders

• x86:

LILO

Grub

Syslinux

• ARM, MIPS, PPC e outras arquiteturas:

U-Boot

Barebox

Redboot


U-Boot

• Bootloader open-source (GPLv2) mais utilizado atualmente, principalmente em ARM.

http://www.denx.de/wiki/U-Boot

• Suporta uma grande variedade de CPUs, incluindo PPC, ARM, MIPS, Coldfire, x86, etc.

• Documentação disponível no site do projeto.

http://www.denx.de/wiki/U-Boot/Documentation

http://www.denx.de/wiki/U-Boot

http://www.denx.de/wiki/U-Boot/Documentation


Kernel Linux

Hardware

Bootloader

Linux kernel

Biblioteca C



Toolchain


Arquitetura kernel Linux

Biblioteca C

Hardware

Biblioteca Biblioteca Aplicação Bibliotecas e aplicações

Kernel

AplicaçãoAplicação

Chamadas de sistema Notificação de eventosExportação de informações

Gerenciamento do hardware Notificação de eventos


Kernel Linux

• Os principais papéis do kernel envolvem gerenciar a execução dos processos e controlar o acesso à memória e aos dispositivos de hardware.

• Possui o conceito de classes de escalonamento, onde diferentes tipos de escalonadores de tarefas estão disponíveis para gerenciar a execução dos processos do sistema.

• Gerencia a memória através da MMU, possibilitando virtualizar o acesso à memória do sistema.

• A interface mais comum de acesso a hardware é implementada através de arquivos.


Kernel Linux (cont.)

• 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 acesso completo à 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.


Rootfs

Hardware

Bootloader

Linux kernel

Biblioteca C



Toolchain


Rootfs (cont.)

• Um sistema GNU/Linux precisa de um conjunto básico de bibliotecas e aplicações para funcionar, incluindo:

Uma biblioteca de sistema (glibc, uClibc-ng, musl, etc).

Um mecanismo de inicialização (systemd, sysvinit, upstart, etc).

Diversas bibliotecas e aplicações (bash, cat, echo, grep, sed, useradd, vi, getty, libusb, etc).

• Em sistemas com Linux embarcado é comum o uso do BusyBox, um projeto de código-aberto que implementa as principais ferramentas e comandos básicos de um sistema Linux.


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


Toolchain

Hardware

Bootloader

Linux kernel

Biblioteca C



Toolchain


O que é um toolchain?

• 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.


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 máquina de desenvolvimento mas gera código para a plataforma-alvo.


Tipos de toolchain (cont.)

Binário x86

x86

Binário ARM

ARM

Código-fonte

x86

Toolchain nativo Cross-compiling toolchainHost

Target


Sistema Linux embarcado

Bootloader

Kernel

Rootfs

Hardware

Código-fonteCross-compiling toolchain


Lab 1:Ambiente de desenvolvimento


Agenda

1. Linux embarcado





Linux embarcado

• Existem basicamente 3 soluções para desenvolver um sistema com Linux embarcado:

Usar uma distribuição pronta.

Gerar um sistema Linux manualmente.

Usar uma ferramenta de build para gerar um sistema Linux customizado.


Distribuição pronta

• Existem soluções de distribuição Linux comercializadas por empresas como a MontaVista, a WindRiver e a Timesys.

• Existem também diversas soluções abertas, incluindo Android, Debian, Ubuntu, Tizen, Angstrom, etc.

• Vantagens do uso de uma distribuição pronta:

Simplicidade de uso.

Facilidade na instalação de novos pacotes.

Framework de desenvolvimento pronto e funcional.


Distribuição pronta (cont.)

• Desvantagens no uso de uma distribuição pronta:

Falta flexibilidade (compatibilidade com a plataforma de hardware, mecanismo de inicialização, framework de desenvolvimento, etc).

Provavelmente não estará otimizado para o target, consumindo muitos recursos da máquina (CPU, memória, disco, etc).

Tempo de boot normalmente alto.

Dificuldade de atender aos requisitos de licença e distribuir código-fonte GPL e similares.

Requer tempo e experiência para customizar e adaptar o sistema às características do target.


Processo manual

• Gerar um sistema Linux manualmente permite um controle total sobre as ferramentas utilizadas para a geração do sistema, assim como a flexibilidade necessária para gerar uma distribuição Linux customizada para o target.

• Porém, gerar um sistema Linux completo manualmente é uma atividade extremamente trabalhosa, demorada, difícil de reproduzir e suscetível a erros.

• Para os mais aventureiros:

http://www.linuxfromscratch.org/

http://www.linuxfromscratch.org/


Sistemas de build

• Um sistema de build permite gerar um sistema Linux completo e customizado para o target.

• Ele possui um conjunto de ferramentas que automatizam o processo de geração de todos os componentes do sistema (toolchain, bootloader, kernel, rootfs).

• Normalmente já contém um conjunto grande de pacotes configurados para serem habilitados e utilizados pelo seu sistema.

• E facilita o trabalho de estender e adicionar novos pacotes se necessário.


Sistemas de build (cont.)

• Um sistema de build possui duas grandes vantagens:

Facilidade e flexibilidade na geração de um sistema Linux customizado.

O processo de build torna-se reproduzível, facilitando o trabalho de recompilação, correção de problemas e adição de novas funcionalidades.


Ferramentas

• Buildroot, desenvolvido pela comunidade.

http://www.buildroot.net

• OpenWRT, sistema de build com foco em roteadores.

http://www.openwrt.org/

• PTXdist, desenvolvido pela empresa Pengutronix.

http://www.pengutronix.de/software/ptxdist/index_en.html

http://www.buildroot.net/

http://www.openwrt.org/

http://www.pengutronix.de/software/ptxdist/index_en.html


Ferramentas (cont.)

• OpenEmbedded, mais flexível (e também mais complexo):

http://www.openembedded.org

• Poky (baseado no OpenEmbedded, sistema de build de referência usado pelo Yocto Project):

http://www.yoctoproject.org/

http://www.openembedded.org/

http://www.yoctoproject.org/


O que é o Yocto Project?

• Projeto colaborativo que provê um conjunto de ferramentas para auxiliar na criação de distribuições Linux customizadas para dispositivos embarcados.

https://www.yoctoproject.org

• Fundado em 2010 por diversas empresas da área de tecnologia, fabricantes de hardware e fornecedores de solução de software para Linux embarcado.

• Gerenciado por um membro da Linux Foundation, garantindo a independência do projeto com qualquer membro da organização.

https://www.yoctoproject.org/


Projetos

• Alguns dos projetos que formam o Yocto Project:

Openembedded Core

BitBake

Poky

Matchbox

AutoBuilder

Toaster

• Uma lista dos projetos está disponível no link abaixo:

https://www.yoctoproject.org/tools-resources/projects

https://www.yoctoproject.org/tools-resources/projects


Histórico

Portage (Gentoo)

BitBake

OpenZaurus

OpenEmbedded

Poky

Yocto Project


Características

• Extremamente configurável e flexível na geração de sistemas Linux.

• Milhares de pacotes de software pré-configurados e disponíveis para compilação cruzada.

• Provê facilidades para manter e estender o sistema através da implementação de camadas.

• Suportado pelos fabricantes das principais arquiteturas de hardware (Intel, ARM, MIPS, PowerPC, etc), servindo de padrão para o desenvolvimento de BSPs e imagens de demonstração.


Características (cont.)

• Suporte à geração de sistemas Linux multiplataforma, sendo trivial mudar a geração de uma imagem inteira para uma plataforma diferente.

• Suporte ao gerenciamento de pacotes de software (rpm, deb, ipk), possibilitando o desenvolvimento de distribuições Linux.

• Permite geração de ferramentas de desenvolvimento como SDKs e emuladores.

• Filtro por licenças (Ex: sistema sem GPLv3).

• Comunidade bastante ativa.


Arquitetura básica

Fonte: https://www.yoctoproject.org

https://www.yoctoproject.org/


Conceitos

• Tarefa (task): Etapa executada pelo sistema de compilação (fetch, patch, configure, compile, package, etc).

• Receita (recipe): conjunto de tarefas para compilar determinado software (.bb, .bbappend).

• Classes (classes): herança e encapsulamento da lógica para a execução de tarefas comuns entre as receitas (.bbclass).

• Pacote (package): resultado do processamento da receita de um componente de software, agregado em algum formato popular de empacotamento (.ipk, .deb, .rpm).


Conceitos (cont.)

• Camada (layer): Conjunto de receitas, classes e arquivos de configuração que podem ser agregados ao sistema de compilação de forma a estendê-lo (distro, BSP, software).

• Máquina (machine): Plataforma de hardware alvo da distribuição a ser gerada, implementada através de uma camada de BSP.

• Imagem (image): imagem final do rootfs do sistema gerado para determinada máquina, implementado através de uma receita de imagem.

• Distribuição (distro): Regras e políticas de geração da imagem do sistema.


Máquina de desenvolvimento

• Para trabalhar com o Yocto Project, é recomendado o uso de uma máquina GNU/Linux com uma das seguintes distribuições: Ubuntu, Fedora, openSUSE, CentOS ou Debian.

• É necessário uma máquina com boa capacidade de processamento (ex: Intel Core i7) e com bastante espaço em disco.

• Alguns pré-requisitos de software: gcc, make, git 1.8.3.1+, python 3.4+, tar 1.24+.

• Consulte o guia de início rápido do Yocto Project para instruções mais completas sobre como preparar a máquina de desenvolvimento.


Código-fonte

• O código-fonte do Yocto Project é composto pelo repositório do Poky e por diversos outros repositórios que fornecem ferramentas e camadas adicionais para construir uma distribuição Linux customizada.

• O repositório do Poky é versionado com o git e pode ser clonado conforme abaixo:$ git clone -b rocko git://git.yoctoproject.org/poky.git

• O parâmetro -b possibilita clonar um branch específico do repositório, neste exemplo o release Rocko do Yocto Project.


Código-fonte (cont.)

$ ls poky/bitbake meta-selftest README.LSBdocumentation meta-skeleton README.pokyLICENSE meta-yocto-bsp README.qemumeta oe-init-build-env scriptsmeta-poky README.hardware


Inicializando o ambiente

• O repositório do Poky contém a base do Yocto Project, incluindo as camadas com os metadados necessários para compilar uma distribuição customizada para emuladores e BSPs de referência.

• Para compilar, o primeiro passo é executar o script oe-init-build-env para que o ambiente de compilação seja configurado:$ source poky/oe-init-build-env

• Por padrão, será criado um diretório chamado build. Opcionalmente, você pode passar o nome do diretório de compilação:$ source poky/oe-init-build-env build_dir


Diretório de build

• Todo o processo de compilação irá acontecer dentro do diretório de build.

• Por padrão, o diretório de build será criado com alguns arquivos de configuração, incluindo:

conf/bblayers.conf: configuração das camadas que serão utilizadas na distribuição Linux a ser gerada.

conf/local.conf: variáveis de configuração locais do ambiente de compilação.


bblayers.conf

# POKY_BBLAYERS_CONF_VERSION is increased each time# build/conf/bblayers.conf changes incompatiblyPOKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"BBFILES ?= ""

BBLAYERS ?= " \ ${TOPDIR}/../sources/poky/meta \ ${TOPDIR}/../sources/poky/meta-poky \ "


local.conf

• O arquivo local.conf contém algumas das principais variáveis que serão utilizadas durante o processo de build.

• A variável MACHINE permite configurar para qual plataforma de hardware o sistema será gerado.MACHINE ?= "sama5d27-som1-ek-sd"

• A distribuição a ser gerada pode ser configurada na variável DISTRO.DISTRO ?= "poky-atmel"


local.conf (cont.)

• A variável PACKAGE_CLASSES possibilita configurar os formatos de empacotamento habilitados.PACKAGE_CLASSES ?= "package_ipk"

• A variável CORE_IMAGE_EXTRA_INSTALL pode ser usada para definir pacotes adicionais para incluir na imagem.CORE_IMAGE_EXTRA_INSTALL += "openssh"

• O manual de referência do Yocto Project contém uma lista das principais variáveis disponíveis.


Gerando uma imagem

• Com os arquivos bblayers.conf e local.conf configurados, é só iniciar o processo de compilação:$ bitbake core-image-minimal

• O comando acima irá processar a receita core-image-minimal.bb, que irá gerar uma imagem mínima para ser executada no target (selecionado pela variável MACHINE).

• Por padrão, todo o processo de build acontecerá no diretório tmp/, dentro do diretório de build.

• As imagens do sistema gerado estarão disponíveis em tmp/deploy/images/<machine>/.


Diretório de saída

$ tree -L 1 tmp/tmp/├── abi_version├── buildstats├── cache├── deploy├── hosttools├── log├── pkgdata├── saved_tmpdir├── sstate-control├── stamps├── sysroots├── sysroots-components├── sysroots-uninative├── work└── work-shared


Imagens

$ ls tmp/deploy/images/sama5d27-som1-ek-sd/at91bootstrap.binat91bootstrap-sama5d27_som1_ek.binat91-sama5d27_som1_ek.dtbBOOT.BINcore-image-minimal-sama5d27-som1-ek-sd.wicmodules--4.9+git0+29796588eb-r0-sama5d27-som1-ek-sd-20180917102156.tgzmodules-sama5d27-som1-ek-sd.tgzsama5d27_som1_ek-sdboot-uboot-3.8.10.binu-boot.binu-boot-sama5d27-som1-ek-sd.binu-boot-sama5d27-som1-ek-sd-v2017.03-at91+gitAUTOINC+59f2026221-r0.binzImagezImage--4.9+git0+29796588eb-r0-at91-sama5d27_som1_ek-20180917102156.dtbzImage--4.9+git0+29796588eb-r0-at91-sama5d27_som1_ek_pda4-20180917102156.dtbzImage--4.9+git0+29796588eb-r0-at91-sama5d27_som1_ek_pda7-20180917102156.dtbzImage--4.9+git0+29796588eb-r0-at91-sama5d27_som1_ek_pda7b-20180917102156.dtbzImage--4.9+git0+29796588eb-r0-sama5d27-som1-ek-sd-20180917102156.binzImage-at91-sama5d27_som1_ek.dtbzImage-sama5d27-som1-ek-sd.bin


Lab 2:Yocto Project


Agenda

1. Linux embarcado





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 e a maioria das opções podem ser habilitadas ou desabilitadas conforme a necessidade.

• O processo de configuração serve para configurar o kernel para ser compilado para o seu sistema e plataforma de hardware.

• O conjunto de opções que você irá habilitar depende:

Das características do hardware (device drivers, etc).

Das funcionalidades do software (protocolos de rede, sistemas de arquivo, etc).


Configurando o kernel (cont.)

• 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


make xconfig


make gconfig


make nconfig


make menuconfig


Configurando o kernel

• O kernel é um binário único, resultado do processo de linkagem de todos os arquivos-objeto das funcionalidades habilitadas, 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.


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


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, é necessário especificar a arquitetura:$ make ARCH=arm menuconfig

• Ao invés de passar a variável ARCH na chamada do make, é possível também definí-la como variável de ambiente ou alterar o arquivo Makefile do diretório principal do kernel.


Arquivos de configuração

• 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 configuração do kernel Linux para uma plataforma específica. Por exemplo, para carregar a configuração padrão do kit de desenvolvimento SAMA5D27-SOM1-EK1:$ make ARCH=arm sama5_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


Compilando o kernel

• Depois de configurado, para compilar o kernel nativamente basta executar:$ make

• Para compilar de forma cruzada, é necessário indicar a arquitetura e o prefixo do toolchain:$ make ARCH=arm CROSS_COMPILE=arm-linux-

• O comando acima irá compilar os módulos habilitados e gerar a imagem final do kernel. Se você quiser gerar apenas a imagem final, basta adicionar o nome da imagem no final do comando.$ make ARCH=arm CROSS_COMPILE=arm-linux- zImage


Compilando o kernel (cont.)

• Ao fim do processo de compilação do kernel, serão geradas as seguintes imagens:

vmlinux: imagem do kernel no formato ELF, que não é inicializável, mas pode ser usada para debugging.

*.ko: módulos do kernel, dentro de seus respectivos diretórios.

Em arch/<arch>/boot/:

Image: imagem final do kernel, inicializável e descomprimida.

*Image: imagem inicializável e comprimida do kernel (bzImage para x86, zImage para ARM, etc).

uImage: imagem do kernel para o U-Boot (opcional).


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.


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.


Device tree (cont.)

• 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.dtsalphascale-asm9260-devkit.dtsalpine-db.dtsam335x-baltos-ir5221.dtsam335x-base0033.dtsam335x-boneblack.dtsam335x-bone.dtsam335x-bonegreen.dtsam335x-chiliboard.dts[...]


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- at91-sama5d27_som1_ek.dtb

• Os arquivos DTB são gerados em arch/arm/boot/dts.


Boot com device tree

• Durante o processo de boot, o bootloader é responsável por passar o DTB para o kernel.

• Para isso, ele irá copiar o device tree para a memória e passar para o kernel o endereço de memória onde o device tree foi carregado.

• No boot, o kernel irá fazer o parser do device tree, identificar os dispositivos de hardware registrados e carregar os device drivers correspondentes.


Sintaxe do device tree

/ { node@0 { string-property = "string"; string-list-property = "first string", "second string"; byte-string-property = [0x01 0x21 0x76];

child-node@0 { first-child-property; second-child-property = <1>; reference-to-something = <&node1>; };

child-node@1 { }; };

node1: node@1 { empty-property; cell-property = <1 2 3 4>; };};


Descrevendo o hardware

• Começando no nó-raiz do device tree, temos:

model: informação descritiva sobre o modelo do hardware.

compatible: string utilizada para o kernel identificar o hardware e instanciar o código de inicialização correspondente.

cpus: descreve as CPUs presentes no sistema.

memory: descreve a quantidade e o endereço inicial da memória RAM.

chosen: usado para passar a linha de comandos do kernel.

aliases: permite definir apelidos para determinados nós.

Nós adicionais descrevendo os barramentos e dispositivos do hardware.


Exemplo device tree

/ { model = "Embedded Labworks Super Board"; compatible = "labworks,sama5d2-labworks", "atmel,sama5d2";

memory { reg = <0x10000000 0x80000000>; };

cpus { cpu@1 { compatible = "arm,cortex-a5"; device_type = "cpu"; reg = <1>; }; };

aliases { portA = &gpio1; portB = &gpio2; };

[...]


Exemplo device tree (cont.)

uart6: serial@200 {compatible = "atmel,at91sam9260-usart";reg = <0x200 0x200>;interrupts = <23 IRQ_TYPE_LEVEL_HIGH 7>;clocks = <&flx4_clk>;clock-names = "usart";atmel,fifo-size = <32>;status = "disabled";

};


Exemplo device tree (cont.)

i2c0: i2c@f8028000 {pinctrl-names = "default";pinctrl-0 = <&pinctrl_i2c0_default>;status = "okay";

at24@50 {compatible = "24c02";reg = <0x50>;pagesize = <8>;

};};


Organização do device tree

• O device tree é dividido em vários arquivos para tornar seu código mais modular e reutilizável.

• O código-fonte final do device tree tem extensão .dts (cada placa tem o seu arquivo .dts).

• O código comum do device tree que pode ser compartilhado com outras placas é implementado em arquivos com extensão .dtsi.

• Estes arquivos são incluídos via diretiva #include e processados através de um mecanismo de overlay.


at91-sama5d27_som1_ek.dts

#include "at91-sama5d27_som1_ek_common.dtsi"

/ {model = "Atmel SAMA5D27 SOM1 EK";compatible = "atmel,sama5d27-som1-ek",

"atmel,sama5d27-som1", "atmel,sama5d27", "atmel,sama5d2", "atmel,sama5";};

&uart3 { status = "okay";};


at91-sama5d27_som1_ek_common.dtsi

uart3: serial@fc008000 {atmel,use-dma-rx;atmel,use-dma-tx;pinctrl-names = "default";pinctrl-0 = <&pinctrl_uart3_default>;status = "disabled";

};


Resultado

uart3: serial@fc008000 {atmel,use-dma-rx;atmel,use-dma-tx;pinctrl-names = "default";pinctrl-0 = <&pinctrl_uart3_default>;status = "ok";

};


Device tree binding

• A string compatible e as propriedades de um nó são definidas e documentadas em um arquivo chamado device tree binding.

• É o arquivo de descrição do binding que define como um determinado nó do device tree será tratado pelo kernel.

• Todos os bindings são documentados no código-fonte do kernel em Documentation/devicetree/bindings.


Device tree binding (cont.)

/* Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt */

Microchip MCP2308/MCP23S08/MCP23017/MCP23S17 driver

Required properties:- compatible : Should be - "microchip,mcp23s08" for 8 GPIO SPI version[...]

Required device specific properties (only for SPI chips):- mcp,spi-present-mask (DEPRECATED)[...]

Optional properties:- #interrupt-cells : Should be two.[...]

Example I2C (with interrupt):gpiom1: gpio@20 { compatible = "microchip,mcp23017"; gpio-controller; #gpio-cells = <2>; reg = <0x20>;

interrupt-parent = <&gpio1>; interrupts = <17 IRQ_TYPE_LEVEL_LOW>; interrupt-controller; #interrupt-cells=<2>;};


Lab 3:Kernel Linux e device tree


Agenda

1. Linux embarcado





SDK

• Um SDK (Software Development Kit) é um conjunto de ferramentas que possibilitam o desenvolvimento de aplicações para um determinado target (plataforma de hardware, sistema operacional, ambiente de execução, etc).

• É composto por um conjunto de componentes, incluindo:

Toolchain (compilador, linker, debugger, etc).

Sysroot (bibliotecas e arquivos de cabeçalho).


Toolchain

• Sendo host a plataforma de desenvolvimento e target a plataforma-alvo, existem basicamente quatro tipos de toolchain:

Native toolchain: roda no host e gera código para o host.

Cross-native: roda no target e gera código para o target.

Cross-compiling toolchain: roda o host e gera código para o target.

Canadian toolchain: mesmo que cross-compiling toolchain, porém o host que gerou o toolchain é diferente do host que irá executar o toolchain.

• Apesar do cross-native ser uma opção para o desenvolvimento em Linux embarcado, o mais comum é o uso de um cross-compiling toolchain.


Sysroot

• O sysroot é um diretório que contém as bibliotecas e arquivos de cabeçalho necessários para compilar e gerar os binários que serão executados no target.

• É normalmente baseado no rootfs da imagem gerada para o target.


Yocto Project e SDK

• O Yocto Project é capaz de gerar um SDK para o desenvolvimento de aplicações.

• O SDK gerado é autocontido e pode ser instalado em qualquer máquina de desenvolvimento com a mesma arquitetura de hardware do host que gerou o SDK.

• Os dois principais mecanismos de geração de SDK do Yocto Project são:

meta-toolchain: SDK genérico sem o sysroot.

populate_sdk: SDK completo com o sysroot para o desenvolvimento de aplicações.


meta-toolchain

• Um SDK genérico pode ser gerado processando a receita meta-toolchain.$ bitbake meta-toolchain

• Ao final do processo de compilação, um script de instalação do SDK estará disponível em tmp/deploy/sdk.

• Ao executar o script, o toolchain é instalado por padrão em /opt/<distro>/<release>.

• Pode ser usado para o desenvolvimento de aplicações bare-metal como o bootloader ou o kernel Linux.


populate_sdk

• Um SDK completo com o sysroot baseado na imagem do rootfs pode ser gerado processando a tarefa populate_sdk da receita da imagem:$ bitbake <image> -c populate_sdk

• Ao final do processo de compilação, o script de instalação do SDK estará disponível em tmp/deploy/sdk.

• Ao executar o script, o toolchain é instalado por padrão em /opt/<distro>/<release>.

• Este é o melhor mecanismo para gerar e distribuir um SDK para o desenvolvimento de aplicações baseado em uma determinada imagem para o target.


Instalando o SDK

$ cd tmp/deploy/sdk/

$ ./poky-glibc-x86_64-labworks-image-training-cortexa9hf-neon-toolchain-2.1.1.shPoky (Yocto Project Reference Distro) SDK installer version 2.1.1Enter target directory for SDK (default: /opt/poky/2.1.1): You are about to install the SDK to "/opt/poky/2.1.1". Proceed[Y/n]? Extracting SDK...doneSetting it up...doneSDK has been successfully set up and is ready to be used.

$ ls /opt/poky/2.1.1/environment-setup-cortexa9hf-neon-poky-linux-gnueabisite-config-cortexa9hf-neon-poky-linux-gnueabisysrootsversion-cortexa9hf-neon-poky-linux-gnueabi


Usando o SDK

• Para utilizar o SDK, basta carregar o script de configuração do ambiente:$ source /opt/poky/2.1.1/environment-setup-cortexa9hf-neon-poky-linux-gnueabi

• Diversas variáveis serão criadas no ambiente de desenvolvimento (CC, CFLAGS, CXX, LD, LDFLAGS, etc).

• Para compilar uma aplicação em C, podemos utilizar a variável CC:$ $CC teste.c -o teste

• Abra o script de configuração do ambiente para verificar a lista completa de variáveis criadas.


Acesso a hardware no Linux

• Em sistemas Unix como o Linux, 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, close, etc).

• Este conceito se aplica também a dispositivos de hardware, cujo acesso é feito através de operações em arquivos.

• A única exceção são os dispositivos de rede, cujo acesso é feito através da API de sockets do kernel.


Acesso a hardware no Linux

/dev/ttyS0

Virtual Filesystem

Aplicação

Device driver

read() write()

User space

Kernel space

read() write()


Arquivos de acesso ao hw

• O Linux possui duas principais abstrações de arquivos para acesso a dispositivos de hardware, que são exportados por padrão nos diretórios /dev e /sys.

• No /dev são exportados os arquivos de dispositivo, uma abstração para trocar dados com dispositivos de hardware (porta serial, placa de som, mouse, teclado, display, memória flash, etc).

• No /sys são exportados os arquivos do sysfs, uma abstração para ler e controlar o estado de dispositivos de hardware (leds, sensores, bateria, gpios, etc).


Arquivos no /dev

# ls -la /devbrw-rw---- 1 root disk 8, 1 2012-01-25 06:54 /dev/sda1crw-rw---- 1 root dialout 4, 64 2012-01-25 06:54 /dev/ttyS0crw-rw---- 1 root input 13, 64 2012-01-25 06:54 /dev/input/event0crw------- 1 root root 251, 0 2012-01-25 06:54 /dev/rtc0crw-rw---- 1 root audio 116, 3 2012-01-25 06:54 /dev/snd/pcmC0D0p[...]


Arquivos no /sys

# ls /sys/class/ata_device drm mdio_bus ppp thermalata_link extcon mei printer tpmata_port firmware mem pwm ttybacklight gpio memstick_host rapidio_port usbmiscbdi graphics misc regulator vcblock hidraw mmc_host rfkill video4linuxbluetooth hwmon nd rtc virtio-portsbsg i2c-adapter net scsi_device vtconsoledevcoredump i2c-dev pci_bus scsi_disk watchdogdevfreq ieee80211 phy scsi_generic wmidevfreq-event input powercap scsi_hostdma iommu power_supply sounddmi leds ppdev spi_master


Principais interfaces

• Porta serial RS232/RS485, conversor USB/Serial, etc./dev/tty*

• Mouse, teclado, touchscreen, joystick, botão, etc./dev/input/*

• Monitores, displays LCD, etc./dev/fb*

• Codecs de áudio, placas de som, etc./dev/snd/*


Principais interfaces (cont.)

• Discos SATA, armazenamento USB, etc./dev/sd*

• Memórias flash NOR e NAND./dev/mtd*, /dev/mtdblock*

• Sensores internos do sistema (temperatura, corrente, etc)./sys/class/hwmon/hwmon*/

• Conversor A/D e D/A, acelerômetro, sensor de luz, sensor de proximidade, compasso, giroscópio, magnetômetro, etc./sys/bus/iio/devices/*, /dev/iio*



• Controladores de GPIO, expansor de I/O, shift register, etc./sys/class/gpio/*

• Leds./sys/class/leds/*

• Watchdogs./dev/watchdog*

• Relógios de tempo real./dev/rtc*, /sys/class/rtc/rtc*/



• Controladores de PWM./sys/class/pwm/*

• Bateria, fontes de alimentação, etc./sys/class/power_supply/*.

• Porta paralela./dev/lp*

• Gerenciamento do clock da CPU./sys/devices/system/cpu/cpu*/cpufreq/


API de arquivos

• Para acessar estes arquivos de interface com o hardware, uma aplicação em linguagem C/C++ pode utilizar a API de acesso a arquivos do Linux, que inclui as funções abaixo:

int open(const char *pathname, int flags);ssize_t read(int fd, void *buf, size_t count);ssize_t write(int fd, const void *buf, size_t count);off_t lseek(int fd, off_t offset, int whence);int close(int fd);


open()

• A função open() permite abrir um arquivo para leitura e escrita.

• O parâmetro pathname indica o caminho completo do nome do arquivo e o parâmetro flags permite definir o modo de acesso ao arquivo (O_RDONLY, O_WRONLY, O_RDWR, etc).

• Em caso de sucesso, a função retorna o descritor do arquivo, que deverá ser usado para referenciar o arquivo em futuras chamadas.

• Mais informações na página de manual:$ man 2 open

int open(const char *pathname, int flags);


read()

• A função read() lê dados de um arquivo.

• O descritor do arquivo deve ser passado no parâmetro fd, a variável buf é um ponteiro para retornar os dados lidos, e a variável count indica a quantidade máxima de bytes para serem lidos.

• Em caso de sucesso, a função retorna a quantidade de bytes lidos (que pode ser menor que o valor requisitado em count) ou 0 no caso de fim de arquivo.

• Mais informações na página de manual:$ man 2 read

ssize_t read(int fd, void *buf, size_t count);


write()

• A função write() escreve em um arquivo.

• O descritor do arquivo deve ser passado no parâmetro fd, a variável buf é um ponteiro com os dados a serem escritos, e a variável count indica a quantidade de bytes para escrever.

• Em caso de sucesso, a função retorna a quantidade de bytes escritos (que pode ser menor que o valor requisitado em count).

• Mais informações na página de manual:$ man 2 write

ssize_t write(int fd, const void *buf, size_t count);


lseek()

• A função lseek() permite alterar o offset do arquivo, um ponteiro para o local da próxima leitura ou escrita no arquivo.

• O descritor do arquivo deve ser passado no parâmetro fd, a variável offset permite definir o novo valor do offset (em bytes), e o parâmetro whence permite definir o endereço base para configurar o offset (SEEK_SET, SEEK_CUR, SEEK_END).

• A função retorna o novo offset (em bytes) do arquivo.

• Mais informações na página de manual:$ man 2 lseek

off_t lseek(int fd, off_t offset, int whence);


close()

• A função close() fecha um arquivo aberto.

• O descritor do arquivo para fechar deve ser passado no parâmetro fd.

• A função retorna 0 no caso de sucesso, ou -1 se acontecer algum erro.

• Quando um processo é encerrado, todos seus arquivos abertos são fechados automaticamente.

• Mais informações na página de manual:$ man 2 close

int close(int fd);


Exemplo: acessando arquivos

int main(int argc, const char *argv[]){ const char *msg = "Hodor!\n"; char buf[16]; int fd;

memset(buf, 0, sizeof(buf));

fd = open("/tmp/got", O_RDWR | O_CREAT | O_TRUNC); if (fd == -1) exit(1);

write(fd, msg, strlen(msg));

lseek(fd, 0, SEEK_SET);

if (read(fd, buf, sizeof(buf) - 1) > 0) printf("Read = %s\n", buf);

close(fd);

return 0;}


Lab 4:Aplicações em linguagem C/C++


Dúvidas?

Sergio PradoEmbedded [email protected]

mailto:[email protected]

Date post:	24-May-2020
Category:	Documents
Upload:	others
View:	6 times
Download:	0 times

Aprendendo Linux embarcado com Yocto Project e SoM (System ... · © 2018 Microchip Technology...

Documents