Sistemas Operativos Linux em Computadores ARM

[Nosferatu Arucard]

A recente expansão do mundo da informática (smartphones, tables e afins) beneficiou em larga medida uma arquitectura de processador que estava até mesmo entre 5 a 10 anos atrás relegada a um canto obscuro: a arquitectura ARM. Este processador não é compatível de todo com a dominante arquitectura x86 (e x64 da AMD/Intel), mas o seu baixo consumo de energia e baixo custo de patentes permitiu que com a expansão do mercado dos computadores embebidos torna-se uma oportunidade única para os CPU ARM ganharam espaço para o uso mainstream, podendo até chegar a ser utilizado em computadores pessoais.

Estamos em 2015, e verifica-se que a maioria dos smartphones e tablets de entrada de gama são dominados pelo ARM. E os tablets de topo e sub-portáteis tendem a ser máquinas x86, embora existam excepções.
Computadores pessoais com ARM e com sistema aberto já existem, mas regra geral na forma de placas como o Rapsberry Pi e o Arduino. De fábrica ainda não conheço PC com processadores ARM, embora a tecnologia exista para isso (Um Tegra K1 ou X1 daria teoricamente um bom Desktop compacto). Mas existem, por encomenda, servidores que utilizam processadores com arquitectura ARM, se bem que sejam sistemas criados para fins restritos.

Além disso por vezes surgem notícias contraditórias como o velho boato do Mac Air com processador ARM, ou  lançamento por partes do Governo da Federação Russa em subsidiar o lançamento de computadores desktop com processadores ARM (O Beikal 8-core, se bem que tenham CPU mais modestos à venda). De qualquer forma, os primeiros protótipos e máquinas à venda usavam o Ubuntu 12.04 LTS e só depois migraram para a versão 14.04 LTS. 

Independentemente destas permissivas, o facto dos computadores Linux com ARM (e mais por causa da arquitectura) terem uma quota de mercado restrita deve-se principalmente a três factores:
1. Muito software comercial, científico e industrial que requer cálculos matemáticos exigentes brilham em processadores CISC, e a optimização para x86 (ou x64) é avassaladora. Até o problema dos ports de software x86 para ARM a nível comercial é muito menos compensadora do que o extinto mercado para PowerPC, quanto mais o problema de portar software de Windows para Linux! 
2. Tirando os softwares open-source que são compilados para ARM em 99% dos casos sem incidentes, mais 0,9% com alguns ajustes, restando menos de 0,1% com rotinas em assembly x86 ou bibliotecas dependentes de estruturas de registos de CPU CISC para resolver.
(Fui eu que consegui portar o PeaZip para ARM  , exigindo a substituição de cinco linhas de código assembly para stubs em Pascal.)
Um computador ARM nasce literalmente sem software nativo de referência para a sua arquitectura  (Tirando as aplicações para Android e iOS evidentemente). Se num computador x86 o Wine quebra a dependência do software Windows para sistemas Linux, mudar de arquitectura de processador o problema é radicalmente diferente.
3. O facto do ARM ser associado a dispositivos portáteis de consumo ganha um estigma que prejudica a sua penetração no mercado mais profissional.

Por minha experiência eu tenho um tablet com arquitectura ARM (Tegra 3): o ASUS Transformer Infinity equipado com o sistema Android. Posteriormente, o lançamento de softwares de virtualização que permitiram correr o Debian sem desbloquear o aparelho permitiu experimentar e usar os mesmos softwares open-source (  Firefox, LibreOffice ...) que o meu PC Intel 
Mas o problema surge quando existe algum software até portado para Linux, mas cujo código-fonte não é livremente distribuído, e normalmente significa que os computadores ARM estão fora do baralho. 
E se for disponível somente para Windows, então depois um problema duplo bem espinhoso...

Isso não significa que a comunidade open-source não arranjasse soluções que atenuassem o problema, pois para aliviar o salto de arquitecturas seria necessário o uso de emuladores, uma solução já antiga mas considerada de último recurso devido aos elevados consumos de recursos que acarreta. Emular um sistema completo x86 a nível de hardware (mesmo alto nível), gasta demasiados ciclos de processamento aos processadores RISC para garantir um desempenho acima de medíocre. A componente ocupada na tradução das instruções x86 para ARM fica afogada por outras que exigem a emulação de dispositivos I/O, discos virtuais, rede virtual e outros componentes. Normalmente isso é útil na situação inversa, quando se criam devkits para testar componentes de software, mas para uso intensivo e regular estava fora de questão.
Uma solução mais aceitável saiu com o autor do Qemu (que podia emular sistemas de hardware completos), para criar uma versão que habilita-se a execução directa de executáveis Linux em sistemas operativos Linux cujas arquitecturas fossem diferentes. Desta forma, eliminava-se a emulação de um sistema x86 completo para emular somente uma CPU x86 por tradução dinâmica de instruções, capturando as chamadas de sistema do kernel Linux e enviando as equivalentes ao kernel nativo. Desta forma o programa x86 vivia com um processo do Linux ARM, e tinha acesso directo (via uma mistura de bibliotecas x86 (user mode) e ARM (kernel mode)) aos mesmos ficheiros e recursos de hardware. Isto reduzia a compatibilidade para programas que operem exclusivamente sem acesso directo ao hardware, mas a performance subia finalmente para valores aceitáveis, o que tornava o uso regular de programas x86 em máquinas ARM finalmente possíveis. O programa ficou conhecido como Qemu User Mode por esse motivo.
Felizmente o Wine funciona com a abordagem minimalista do Qemu User Mode, mas determinadas funções avançadas com o som ou a aceleração gráfica 3D podem não funcionar ou exigir bibliotecas de bridging desenhadas para esse fim. (A biblioteca glshim já permite aceleração OpenGL para jogos 3D em máquinas ARM, embora o seu objectivo inicial fosse emular as funções do OpenGL com máquinas com drivers OpenGL ES). 

O uso mais recorrente do Qemu User Mode para além de brincar com o Wine em máquinas ARM é o uso de utilitários de linhas de comando que só existem para x86, e desta forma compressores como o rar iniciam em menos de um segundo com o uso desse emulador sem gastar uma miríade de recursos para carregar uma máquina x86 completa (que bem podia levar 10 minutos a arrancar totalmente!).
Programas que usam gráficos, exige que a variável DISPLAY do X11 deve ser prefixada antes do comando do emulador e do executável x86, caso contrário o programa falha ao acusar a ausência de um servidor X! 

Voltando à Russia, mal os primeiros computadores ARM foram lançados no mercado, ainda a nível experimental, não admira que o primeiro software comercial fosse precisamente um emulador para correr os programas x86 nas novas máquinas!  Trata-se do Exagear Desktop que opera de forma similar ao Qemu User Mode, embora existam algumas diferenças: O emulador foi implementado como um módulo de kernel, de modo a que a execução dos binários x86 e ARM ocorra sem necessidade de prefixar comandos especiais, e depois a implementação foi muito optimizada para os processadores ARM mais avançados, enquanto o QEMU corre nos ARM mais antigos, e isto torna o ExaGear mais rápido nos cálculos de virgula flutuante que os ARM recentes implementaram de forma mais ou menos directa.
No entanto, uma versão reduzida do ExaGear complementada com uma mini-distro Linux com o Wine 1.6.2 foi lançado no Google Play para ganhar espaço de mercado, apresentando como uma alternativa viável para correr jogos do Windows antigos em tablets Android com processadores ARM, incluindo gráficos e som. O loader da aplicação esconde o arranque do mini-Linux até arrancar a janela da aplicação, o que demora pelo menos entre 20 a 60 segundos...
De qualquer forma o fabricante do software russo recomenda a instalação do Wine para correr os programas Windows nas suas máquinas ARM... (a ironia...)

Em relação à minha experiência, posso mostrar como é "fácil"  correr programas Linux que existem somente para x86 num computador Linux ARM (Tegra 3):
Primeiro deve-se abrir o Terminal e acrescentar a arquitectura i386 ao apt-get:

$ sudo dpkg --add-architecture i386
$ sudo apt-get update && sudo apt-get upgrade
$ sudo apt-get install qemu-user

Instala-se um programa simples como o compressor rar:
$ sudo apt-get install rar:i386
Para executá-lo, basta aplicar:
$ qemu-i386 /usr/bin/rar

Um exemplo mais complicado seria correr um programa como o FTool usado por um parente próximo para cálculos de estruturas.
Transfere-se directamente do site, e queixa-se da falta de componentes, para este caso basta instalar as bibliotecas necessárias...
$ sudo apt-get install libgtk2.0-0:i386 libxmu6:i386
Que automaticamente transfere as bibliotecas referentes ao libx11 para arquitectura x86 necessárias para o servidor X (nativo ARM) consiga  carregar o programa x86.

Pulando para a directoria correcta do FTool, o programa incompatível irá funcionar com este comando:
$ DISPLAY=$DISPLAY qemu-i386 Ftool

Durante 60 segundos rolam mensagens de avisos e erros relativos a tradução da API entre bibliotecas ARM e x86, depois aparece em menos de 10 segundos o programa FTool e este corre até sem grandes problemas de desempenho, pois durante este minuto de espera o emulador fez a tradução dinâmica do toolkit GTK2+ e do executável para macro-código que fosse executado directamente pelo processador ARM!
Já o encerramento do programa é instantâneo, mas exige fechar o Terminal para matar threads penduradas a meio.

Com isso foi recriado os problemas mais comuns de um computador Linux com arquitectura ARM.

[Sergio Benjamim]

computadores embebidos

google translate? Acho que seria sistema embarcado, não?

Computadores pessoais com ARM e com sistema aberto já existem, mas regra geral na forma de placas como o Rapsberry Pi e o Arduino.

Arduino é uma plataforma de prototipagem eletrônica, no caso do mais conhecido Arduino UNO vem com um microcontrolador AVR 8-bit ATmega328P (que não é ARM), não dá nem para comparar com esses computadores single-board como raspberry pi, odroid, cubieboard e tantos outros, as características de hardware, proposta e foco são diferentes. Você quis comparar o Arduino TRE com essas placas talvez? O Arduino Due vem com microcontrolador baseado em ARM, mas é microcontrolador, não processador (SoC) usado nessas single-boards.

[Nosferatu Arucard]

Desculpe pelo lapso, confundi o Arduino com uma placa fabricada pela Texas Instruments. Mas de resto as suas reparações estão bem fundamentadas. 

[Sergio Benjamim]

Você tem alguma dessas plaquinhas Nosferatu? Eu adquiri recentemente um Odroid U3 e um Odroid C1. Usando Lubuntu 14.04 neles

Vem com Chromium, Firefox, Gimp, LibreOffice, XBMC (Kodi), e mais alguns programas. O Lubuntu é uma versão customizada na verdade, pela Hardkernel, vem com algumas modificações para poder funcionar nessas placas (kernel, driver de vídeo Mali). Instalei o RetroArch neles, não testei muito no C1 mas no U3 deu para jogar bastante coisa hehe.

[Nosferatu Arucard]

Tenho um amigo que usa uma Rapsberry Pi, portanto já conheço a experiência de trabalhar nestas máquinas.
Utilização a sério é num tablet com Tegra 3 com o Debian Wheezy que juntamente com um teclado com touchpad e ecrã táctil torna um laptop agradável de usar.