Como ya se ha mencionado antes, lamentablemente no existe un estándar para el firmware del sistema en los sistemas ARM. Incluso puede ser bastante diferente el comportamiento de diferentes sistemas que utilizan nominalmente el mismo firmware. Esto se debe a que una gran parte de los dispositivos que utilizan la arquitectura ARM son sistemas embebidos, para los que los fabricantes suelen crear versiones de firmware muy personalizadas e incluyen parches específicos para cada dispositivo. Lamentablemente, los fabricantes no suelen enviar sus cambios y extensiones a los desarrolladores del firmware principal, por lo que sus cambios no se integran en las nuevas versiones del firmware original.

Como consecuencia, incluso los sistemas recién vendidos suelen utilizar un firmware basado en una versión modificada por el fabricante hace años, cuyo código base ha evolucionado mucho más entretanto y ofrece características adicionales o muestra un comportamiento diferente en ciertos aspectos. Además, el nombre de los dispositivos integrados no es consistente entre las diferentes versiones modificadas por el fabricante del mismo firmware, por lo que es casi imposible proporcionar instrucciones utilizables e independientes del producto para los sistemas basados en ARM.

Debian proporciona imágenes de U-Boot para varios sistemas armhf que pueden cargar su U-Boot desde una tarjeta SD en .../images/u-boot/ . Las compilaciones de U-Boot se ofrecen en dos formatos: componentes U-Boot en bruto y una imagen de tarjeta lista que puede escribirse fácilmente en una tarjeta SD. Los componentes U-Boot se ofrecen a los usuarios avanzados; la forma recomendada generalmente es utilizar una de las imágenes de tarjeta SD ya preparadas. Se denominan <system-type>.sdcard.img.gz y se pueden escribir en una tarjeta con

zcat <system-type>.sdcard.img.gz > /dev/SD_CARD_DEVICE

Como con todas las imágenes, ¡ten en cuenta que al escribir la imagen en una tarjeta SD se borra todo el contenido anterior de la tarjeta!

Si Debian proporciona una imagen de U-Boot para tu sistema, se recomienda que utilices esta imagen en lugar de la U-Boot proporcionada por el proveedor, ya que la versión de Debian suele ser más nueva y tiene más funciones.

Normalmente, la dirección MAC de cada interfaz ethernet debe ser única a nivel mundial, y técnicamente tiene que ser única dentro del dominio de difusión ethernet. Para conseguirlo, el fabricante suele asignar un bloque de direcciones MAC de un grupo de administración centralizada (por el que hay que pagar una cuota) y preconfigura una de estas direcciones en cada artículo vendido.

En el caso de las placas en desarrollo, a veces el fabricante quiere evitar el pago de estas tasas y, por tanto, no proporciona direcciones únicas globales. En estos casos los propios usuarios tienen que definir las direcciones MAC para sus sistemas. Cuando no se define una dirección MAC para una interfaz ethernet, algunos controladores de red generan una dirección MAC aleatoria que puede cambiar en cada arranque, y si esto sucede, el acceso a la red sería posible incluso cuando el usuario no ha establecido manualmente una dirección, pero, por ejemplo, no funcionaría de forma fiable la asignación de direcciones IP semiestáticas por DHCP basada en la dirección MAC del cliente solicitante obviamente.

Para evitar conflictos con las direcciones MAC existentes asignadas oficialmente, existe un conjunto de direcciones reservadas para las denominadas direcciones “administradas localmente” . Se define por el valor de dos bits específicos en el primer byte de la dirección (el artículo “Dirección MAC” en la Wikipedia en inglés ofrece una buena explicación). En la práctica, esto significa que, por ejemplo, cualquier dirección que empiece por ca en hexadecimal (como ca:ff:ee:12:34:56) se puede utilizar como dirección administrada localmente.

En los sistemas que utilizan U-Boot como firmware del sistema, la dirección MAC de ethernet se coloca en la variable de entorno “ethaddr”. Se puede comprobar en la línea de comando de U-Boot con la orden “printenv ethaddr” y se puede establecer con el comando “setenv ethaddr ca:ff:ee:12:34:56”. Después de establecer el valor, el comando “saveenv” hace que la asignación sea permanente.

Puede haber problemas con la reubicación correcta del kernel de Linux, en algunos sistemas con versiones antiguas de U-Boot, el ramdisk inicial y el blob del árbol de dispositivos en la memoria durante el proceso de arranque. En este caso, U-Boot muestra el mensaje “Starting kernel ...”, pero el sistema se congela después sin más resultados. Estos problemas se han solucionado con las nuevas versiones de U-Boot a partir de la v2014.07.

Si el sistema ha utilizado originalmente una versión de U-Boot anterior a la v2014.07 y se ha actualizado posteriormente a una versión más reciente, el problema podría seguir produciéndose incluso después de actualizar U-Boot. La actualización de U-Boot no suele modificar las variables de entorno de U-Boot existentes y la solución requiere que se establezca una variable de entorno adicional (bootm_size), lo que U-Boot hace automáticamente sólo en instalaciones nuevas sin datos de entorno existentes. Es posible establecer manualmente bootm_size al nuevo valor por defecto de U-Boot ejecutando el comando “env default bootm_size; saveenv” en el prompt de U-Boot.

Otra posibilidad para evitar los problemas relacionados con la reubicación es ejecutar el comando “setenv fdt_high ffffffff; setenv initrd_high 0xffffffff; saveenv” en el prompt de U-Boot para deshabilitar completamente la reubicación del ramdisk inicial y el device-tree blob.