Conforme já mencionado anteriormente, infelizmente não existe standard para o firmware de sistema nos sistemas ARM. Mesmo o comportamento de diferentes sistemas que normalmente utilizem o mesmo firmware pode ser bastante diferente. Isto resulta do facto que uma grande parte dos dispositivos que utilizam a arquitetura ARM são sistemas embebidos, para os quais os fabricantes utilizam versões de firmware altamente customizadas e que incluem patches específicos de dispositivos. Infelizmente os fabricantes muitas vezes não submetem as suas alterações e extensões de volta aos desenvolvedores de firmware mainline, por isso as suas alterações não são integradas em novas versões do firmware original.

Como resultado, mesmo sistemas recentemente vendidos muitas vezes utilizam um firmware que é baseado numa versão com anos modificada pelo fabricante cujo código mainline do firmware entretanto evoluiu imenso e oferece funcionalidades adicionais ou apresenta comportamento diferente em certos aspetos. Além disso, o nome de dispositivos onboard não é consistente entre diferentes versões modificadas pelo fabricante do mesmo firmware, e por isso é quase impossível disponibilizar instruções utilizáveis que sejam independentes de produto para sistemas baseados em ARM.

O endereço MAC de cada interface ethernet deve ser único globalmente, e tecnicamente tem que ser único dentro do domínio de broadcast ethernet. Para conseguir isto, o fabricante geralmente aloca um bloco de endereços MAC e partir de um conjunto administrado centralmente (para o qual é pago um valor) e pré-configurar um destes endereços em cada item vendido.

No caso de placas de desenvolvimento, por vezes o fabricante quer evitar pagar esses valores e por isso não disponibiliza um endereço globalmente único. Nesses casos os próprios utilizadores têm de definir os endereços MAC para os seus sistemas. Quando não está definido um endereço MAC para um interface ethernet, alguns controladores de rede geram um endereço MAC aleatório que pode ser alterado em cada arranque, mas se isso acontecer, o acesso à rede será possível mesmo que o utilizador não defina manualmente o endereço, mas e.g. atribuir endereços IP semi-estáticos por DHCP baseados em endereços MAC do cliente que requisita obviamente não irá funcionar corretamente.

Para evitar conflitos com endereços MAC atribuídos oficialmente, existe um conjunto de endereços que é reservado para os chamados endereços “administrados localmente”. É definido por um valor de dois bits específicos no primeiro byte do endereço (o artigo “MAC address” na Wikipedia em idioma Inglês dá uma boa explicação). Na prática isto significa que qualquer endereço começado pelo hexadecimal ca (tal como ca:ff:ee:12:34:56) pode ser utilizado como endereço administrado localmente.

Em sistemas que utilizem U-Boot como firmware de sistema, o endereço MAC é colocado na variável de ambiente “ethaddr”. Pode ser verificado na linha de comandos do U-Boot com o comando “printenv ethaddr” e pode ser definido com o comando “setenv ethaddr ca:ff:ee:12:34:56”. Após definir o valor, o comando “saveenv” torna a atribuição permanente.

Em alguns sistemas com versões mais antigas do U-Boot podem haver problemas com a correta relocação do kernel Linux, do ramdisk inicial e do blob de device-tree em memória durante o processo de arranque. Neste caso, o U-Boot mostra a mensagem “Starting kernel ...”, mas o sistema congela de seguida sem mais qualquer saída. Estes problemas foram resolvidos com novas versões do U-Boot a partir da v2014.07.

Se o sistema utilizou originalmente uma versão do U-Boot anterior à v2014.7 e foi posteriormente atualizado para uma versão mais recente, o problema pode ainda assim ocorrer mesmo após atualizar o U-Boot. A atualização do u-boot normalmente não altera as variáveis de ambiente existentes e a correção requer que seja definida uma variável de ambiente adicional (bootm_size), o que o U-Boot faz automaticamente apenas em novas instalações sem dados de ambiente. É possível definir manualmente bootm_size para a nova predefinição do U-Boot ao correr na linha de comandos o comando “env default bootm_size; saveenv”.

Outra possibilidade de contornar os problemas relacionados com a relocação é correr o seguinte comando na linha de comandos do U-Boot “setenv fdt_high ffffffff; setenv iitrd_high 0xffffffff; saveenv” para desabilitar completamente a relocação do ramdisk inicial e do blob device-tree.