Як уже згадувалося раніше, на жаль, не існує єдиного стандарту для прошивки систем ARM. Навіть поведінка різних систем, які використовують однакову прошивку, може сильно відрізнятися. Це пояснюється тим фактом, що значна частина пристроїв, які використовують архітектуру ARM, є вбудованими системами, для яких виробники зазвичай створюють окремо налаштовані версії прошивок з латками для конкретних пристроїв. На жаль, виробники досить рідко надсилають свої зміни та розширення розробникам основних прошивок, тому їхні зміни не інтегруються в новіші версії оригінального мікропрограмного забезпечення.

Як наслідок, навіть нещодавно продані системи часто використовують прошивку, яка основана на модифікованій виробником версії, основний код якої значно розвинувся за цей час та пропонує додаткові функції або в певних аспектах поводиться інакше. На додаток до цього, найменування вбудованих пристроїв не узгоджується між різними виробниками для однакових версій прошивки, тому майже неможливо надати корисні інструкції для систем на основі ARM, незалежні від продукту.

Debian надає образи U-Boot для різних систем armhf, які можуть завантажувати свій U-Boot із SD-картки з .../images/u-boot/ . Збірки U-Boot є у двох форматах: необроблені компоненти U-Boot та образи, готові одразу для запису на SD-картку. Необроблені компоненти U-Boot надаються для досвідчених користувачів; загалом рекомендується використовувати один із готових образів SD-карти. Вони мають назву <system-type>.sdcard.img.gz та можуть бути записані на картку, наприклад, з

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

Як і з усіма образами, пам'ятайте, що запис образу на SD-картку стирає увесь попередній вміст картки!

Якщо Debian надає образ U-Boot для Вашої системи, радимо користуватися ним, а не наданим образом від постачальника U-Boot, оскільки версія від Debian зазвичай новіша та має більше можливостей.

MAC-адреса кожного інтерфейсу ethernet зазвичай має бути глобально унікальною і технічно вона має бути унікальною в межах свого broadcast домену. Для цього виробник зазвичай виділяє блок MAC-адрес із централізовано керованого пулу (за який потрібно сплачувати плату) та попередньо налаштовує одну з цих адрес для кожного проданого товару.

У випадку з платами для розробки виробник для уникнення сплати цих зборів може не надавати ці глобальні унікальні адреси. У таких випадках користувачі самі повинні визначити MAC-адреси для своїх систем. Якщо MAC-адреса не визначена для інтерфейсу ethernet, деякі мережеві драйвери генерують випадкову MAC-адресу, яка може змінюватися під час кожного завантаження, і якщо це станеться, доступ до мережі буде можливим, навіть якщо користувач не встановив адресу вручну, але, наприклад, призначення напівстатичних IP-адрес через DHCP на основі MAC-адреси клієнта з запитом, може не працювати надійно.

Щоб уникнути конфліктів з існуючими офіційно призначеними MAC-адресами, існує пул адрес, який зарезервовано для так званих «локально адміністрованих» адрес. Він визначається значенням двох конкретних бітів у першому байті адреси (стаття «MAC-адреса» в англомовній Вікіпедії дає гарне пояснення). На практиці це означає, що напр. будь-яка адреса, яка починається з шістнадцяткового ca (наприклад, ca:ff:ee:12:34:56), може використовуватися як локально адміністрована адреса.

У системах, які використовують U-Boot як мікропрограму системи, MAC-адресу Ethernet розміщують у змінній середовища «ethaddr». Його можна перевірити в командному рядку U-Boot за допомогою команди «printenv ethaddr» і встановити за допомогою команди «setenv ethaddr ca:ff:ee:12:34:56» . Після встановлення значення команда «saveenv» робить призначення постійним.

У деяких системах зі старішими версіями U-Boot можуть виникнути проблеми з правильним переміщенням ядра Linux, початкового RAM-диска та blob дерева пристроїв у пам’яті під час процесу завантаження. У цьому випадку U-Boot показує повідомлення «Запуск ядра...», але після цього система зависає без подальшого виведення. Ці проблеми вирішено в новіших версіях U-Boot, починаючи з версії 2014.07.

Якщо система спочатку використовувала версію U-Boot, старішу за v2014.07, і її пізніше було оновлено до новішої версії, проблема може виникнути навіть після оновлення U-Boot. Оновлення U-Boot зазвичай не змінює існуючі змінні середовища U-Boot, а для виправлення потрібно встановити додаткову змінну середовища (bootm_size), яку U-Boot робить автоматично лише під час нових установок без наявних даних середовища. Можна вручну встановити значення bootm_size до нового значення за замовчуванням U-Boot, виконавши команду «env default bootm_size; saveenv» у запиті U-Boot.

Іншою можливістю обійти проблеми, пов’язані з переміщенням, є виконання команди «setenv fdt_high ffffffff; setenv initrd_high 0xffffffff; saveenv» у запиті U-Boot, щоб повністю вимкнути переміщення початкового ramdisk і blob дерева пристроїв.