Этот сайт лучше всего просматривать в современном браузере с включённым JavaScript.

Angstrom для контрольной платы S9k (Часть 1)

Minerflash

Заводская прошивка для контрольных плат Antminer S9k по умолчанию загружается из NAND в оперативную память, после чего монтируется для дальнейшей работы в систему. Но по завершению работы контрольной платы корень файловой системы удаляется из ОЗУ, а при следующей загрузки заново загружается из флеш-памяти в ОЗУ.
По этому все модификации в корне системы не сохраняются и каждый раз прошивка загружается с чистого образа.
Но если мы хотим установить что либо или удалить в прошивке, чтобы изменения сохранилось в памяти?
Тут следует переделать вид загрузки, что я и сделал.

devicetree.dtb Нажмите чтобы развернуть devicetree.dtb Нажмите чтобы скрыть

Первым делом я разобрал devicetree.dtb. Как это сделать?

Далее распакуем devicetree.dtb:

Получившейся файл devicetree.dts открываем любым текстовым редактором, например sublime:

Как видим по умолчанию в devicetree.dtb размечалось 6 разделов на NAND под различные области данных:

BOOT.bin-env-dts-kernel (Начало: 0 Размер: 2800000) - mtd0 раздел с загрузчиком, системными переменными, деревом устройств и ядром.

ramfs (Начало: 2800000 Размер: 2000000) - mtd1 раздел с основным образом файловой системы, который монтировался из под оперативной памяти.

configs (Начало: 4800000 Размер: 800000) - mtd2 раздел, монтируется в систему как каталог /config, хранит конфиги с настройками сети, MAC-адреса, настройки майнера, ключ SSH, настройки хоста и пр. При размонтировании содержимое раздела сохраняются в NAND.

reserve (Начало: 5000000 Размер: 1000000) - mtd3 раздел. ??????

ramfs-bak (Начало: 6000000 Размер: 2000000) - mtd4 раздел, хранит копию файловой системы, при длительном нажатии на кнопку Recovery на контрольной плате, содержимое этого раздела переписывается в mtd1, что приводит к заводским настройкам файловой системы.

reserve1 (Начало: 8000000 Размер: 8000000) - mtd5 раздел. Большой радел, который монтируется в систему как каталог /nvdata. В этом каталоге хранятся логи работы системы и майнера. Причём на весь период работы. Логи складываются в каталоги с датой. Логи могут записываться на период нескольких лет работы асика. Этот раздел так же, как и mtd2 сохраняется в NAND при размонтировании.

Мне же не надо столько много разделов, достаточно 2:

Редактирую дерево разделов:

BOOT.bin-env-dts-kernel (Начало: 0 Размер: 800000) - mtd0 раздел с загрузчиком, системными переменными, деревом устройств и ядром, как и было, только изменил размер с 2800000 на 800000 (с 40 Мб на 8 Мб)

rootfs (Начало: 800000 Размер: F780000) - mtd1 раздел с основным образом файловой системы. Размер раздела 247,5 Мб. Большой раздел для нашей будущей файловой системы.

После изменения дерева разделов компилируем devicetree обратно в dtb формат:

С деревом устройств разобрались.

Далее я хочу монтировать не образ диска в ОЗУ, а разворачивать полноценную файловую систему из NAND с возможностью сохранения данных при выключении контрольной платы. Метод загрузки позаимствуем с прошивки от Antminer S9 / T9+.

Но возникает проблема, что переменные U-Boot не хранятся отдельным файлом в памяти, а интегрированы в сам boot.bin. Здесь придётся редактировать boot.bin HEX редактором. Я использую отличную программу HxD Editor. Открываем boot.bin и ищем область с системными переменными:

boot.bin Нажмите чтобы развернуть boot.bin Нажмите чтобы скрыть

Далее ищем начало области переменных:

И конец. Зажимаем Shift и указываем конец.

Копируем область, создаём новый файл и вставляем всё туда:

Важно отметить, что размер данных составляет 0x0000136F (4975 Байт).
Ищем начало и конец переменных отвечающих за загрузку из под NAND и SD-карты:

Копируем и вставляем для удобства в текстовой редактор.

Редактируем записи, не затрагивая название переменных (nandboot и nandboot_sd) и символа переноса строки (�):

Как видно, загрузка с NAND и SD-карты буден идентичная. Т.е. даже при вставленной карте прошивка будет загружаться из образа mtd1, а саму SD карту мы будем использовать, как дополнительное хранилище данных.

Теперь возвращаем редактированные строки обратно в бинарник:

Как видим, размер области сократился c 4975 байт до 0x00001203 (4611 байт) на целых 364 байта.

Необходимо компенсировать этот пробел, иначе мы нарушим смещения бинарника, что приведёт к отказу контрольной платы загружаться с таким boot.bin. Создадим стоку в новом файле. Например переменную null=FFFFFFFF и наполним её символами FF пока не наберётся 364 байта в сумме (последний байт должен быть 00):

Далее копируем всё и вставляем перед нашими новыми переменными:

Проверяем, чтобы размер области стал как прежде:

Теперь копируем всё и вставляем в сам бинарник boot.bin:

Переменные подправили, осталось изменить метод загрузки. Ищем в бинарном файле boot.bin область с bootargs:

Выделяем строку с памятью 240 Мб.

Создадим отдельный файл и напишем там строку:

Скопируем эту строку и вставим в бинарник boot.bin:

Как видим, строка больше предыдущей на 14 байт и весь бинарный код сместился вперёд.
Исправим это: выделим произвольные 14 байт из следующей строки (она при загрузке не участвует):

И просто удалим эти лишние байты клавишей delete:

Теперь можно сохранить наш boot.bin в отдельную папку:

На этом приготовление загрузчика завершено.

У нас есть измененное дерево устройств devicetree.dtb и загрузчик boot.bin, само ядро uImage мы оставляем без изменений. Положим это всё в отдельную папку.

Осталось приготовить образ для загрузки из NAND в систему на контрольной плате.

root Нажмите чтобы развернуть root Нажмите чтобы скрыть

Здесь особо разворачивать тему не буду. Про развёртывание образов были темы на форуме.
В коротком пересказе это делается так:
Берём образ для контрольных плат S9k uramdisk.image.gz и под ОС Linux монтируем его в систему.
Далее берём образ для контрольных плат S9 angstrom_rootfs.jffs2 и тоже монтируем с систему.
Далее находясь в каталоге root образа от S9 удаляем всё содержимое. Затем командой cp -r копируем всё из каталога root от S9k в каталог root S9. Затем собираем образ для S9, образ для S9k отмонтируем.
В конечном итоге мы имеем образ angstrom_rootfs.jffs2 содержащий внутри каталоги и файлы из образа uramdisk.image.gz.
Сам образ angstrom_rootfs.jffs2 переименуем просто в root.

Поместим образ к нашим файлам прошивки:

Подготовка SD Нажмите чтобы развернуть Подготовка SD Нажмите чтобы скрыть

Подготовка SD-карты:
Берём SD-карту и форматируем её в FAT-32.
Помещаем в корень карты 4 файла прошивки: boot.bin, devicetree.dtb, uImage и сам образ root.

Прошивка Нажмите чтобы развернуть Прошивка Нажмите чтобы скрыть

Прошивка контрольной платы.
Итак, вставляем флешку в контрольную плату, подключаем к контрольке usb-uart переходник, открываем терминал, настраиваем. Указываем порт и скорость 115200. Далее подключаем питание и во время загрузки контрольной платы прерываем загрузку, нажимая в терминале Enter

Проверяем целостность NAND командой nand bad

Видим 4 блока, занятых системной разметкой. Кроме них нет больше плохих блоков, что значит - память в хорошем состоянии. Поверим, видит ли контролька SD-карту командой mmc info

Видим, что контролька видит флешку, в моём случае это 1Gb (951 Mb), значит можно пробовать загрузить boot.bin в память ОЗУ. Вводим команду fatload mmc 0 1000000 boot.bin

Видим, что 2752048 байт успешно скопировались в ОЗУ за 198 миллисекунды.
Можно спокойно форматировать NAND. Для этого вводим nand erase.chip

Видим, что NAND отформатировалась успешно, 4 системных блока игнорируются.
Можем записать boot.bin из ОЗУ в NAND: nand write 1000000 0 300000

Видим, что 3145728 байт успешно записались в NAND. (2752048 байт сам файл boot.bin и 393680 байт пустой области) Под boot.bin я разметил 3 мегабайта, чтобы было с небольшим запасом. Теперь запишем ядро в NAND:
Скачаем его в ОЗУ командой fatload mmc 0 2000000 uImage и после запишем его в нанд: nand write 2000000 300000 400000

Ядро записано, запишем дерево устройств: fatload mmc 0 3000000 devicetree.dtb и nand write 3000000 700000 100000

С загрузочной областью разобрались. Таблица выглядит так:

boot.bin 0-300000 (size: 300000)
uImage 300000-700000 (size: 400000)
devicetree.dtb 700000-800000 (size: 100000)

Сразу можно снять дамп загрузчика и сохранить его на флешку в виде файла boot
Этом файлом будет удобно прошивать последующие контрольные платы:
Считываем область NAND в ОЗУ командой nand read 2000000 0 800000 и сохраняем на флешку: save mmc 0 2000000 boot 800000

Осталось сохранить в NAND образ файловой системы.
Считываем образ в ОЗУ и запишем в NAND: fatload mmc 0 4000000 root и nand write 4000000 800000 200000
Можно вытаскивать флешку и выключать питание контрольной платы.

Подключаем флешку к компьютеру. Создаём папку firmware и data. В папку firmware помещаем получившийся дамп загрузчика boot, а так же образ файловой системы root. Папку data оставляем пустой. Её можно будет смонтировать из под контрольной платы и использовать для хранения файлов.

Возвращаем флешку в контрольную плату и подаём питание.
Хоть флешка и установлена, но загрузка идёт из под nand, переменные отработали успешно.

При загрузке видим, что создано 2 MTD раздела. Отредактированное дерево устройств devicetree.dtb тоже отработало успешно.

Файловая система jffs2 смонтировалась успешно. Редактирование bootargs в boot.bin отработало.

Директория data на флешке смонтировалась в систему.
Angstrom загрузился. Можно работать.

Подведём итоги: в этой статье мы узнали, как можно править дерево устройств devicetree.dtb, как править бинарники в HEX редакторе, чтобы они не теряли рабочее состояние. Повторили навыки прошивки контрольных плат через u-boot. Поняли, как можно собирать образ из одной системы в другую. Ну и наконец, получили контрольную плату с готовой ОС Angstrom Linux.
В следующих статьях мы посмотрим, как запустить на этой плате python, как установить дополнительные модули и используем контрольную плату в качестве сервера с базой данных.

Готовая прошивка:

Материал подготовил: @Vinogradov
Копирование и распространение с разрешения автора.

Astranome

Minerflash sudo apt install device-tree-compeler

apt install device-tree-compiler

Astranome

Если можно прервать загрузку девайс3 и ядра , то из консоли Убута можно вывалить в консоль весь ~~энвиронмент~~ environment и изменить, например, бутаргс :
editenv bootargs
а потом сохранить изменения:
saveenv
Для распаковки BOOT.bin используется тот же инструмент, что и для упаковки -- bootgen (вроде, не помню точно)

Astranome

установка bootgen:
apt-get install bootgen-xlnx

( можно прямо на рабочей системе подмонтировать sd card:
root@arm:~# mount /dev/mmcblk0p1 /boot )

переходим в каталог с BOOT.bin :
cd /boot
и читаем, что внутри:

root@arm:/boot# bootgen -read BOOT.bin

****** Xilinx Bootgen v2020.2
**** Build date : May 27 2021-14:58:44
** Copyright 1986-2020 Xilinx, Inc. All Rights Reserved.

BOOT HEADER

boot_vectors (0x00) : 0xeafffffeeafffffeeafffffeeafffffeeafffffeeafffffeeafffffeeafffffe
width_detection (0x20) : 0xaa995566
image_id (0x24) : 0x584c4e58
encryption_keystore (0x28) : 0x00000000
header_version (0x2c) : 0x01010000
fsbl_sourceoffset (0x30) : 0x00001700
fsbl_length (0x34) : 0x00018010
fsbl_load_address (0x38) : 0x00000000
fsbl_exec_address (0x3C) : 0x00000000
fsbl_total_length (0x40) : 0x00018010
qspi_config-word (0x44) : 0x00000001
checksum (0x48) : 0xfc164520
iht_offset (0x98) : 0x000008c0

pht_offset (0x9c) : 0x00000c80

IMAGE HEADER TABLE

version (0x00) : 0x01020000 total_images (0x04) : 0x00000003
pht_offset (0x08) : 0x00000c80 ih_offset (0x0c) : 0x00000900

hdr_ac_offset (0x10) : 0x00000000

IMAGE HEADER (FSBL24dec.elf)

next_ih(W) (0x00) : 0x00000250
next_pht(W) (0x04) : 0x00000320
total_partitions (0x08) : 0x00000000
total_partitions (0x0c) : 0x00000001

name (0x10) : FSBL24dec.elf

IMAGE HEADER (system_wrapper.bit)

next_ih(W) (0x00) : 0x00000260
next_pht(W) (0x04) : 0x00000330
total_partitions (0x08) : 0x00000000
total_partitions (0x0c) : 0x00000001

name (0x10) : system_wrapper.bit

IMAGE HEADER (u-boot.elf)

next_ih(W) (0x00) : 0x00000000
next_pht(W) (0x04) : 0x00000340
total_partitions (0x08) : 0x00000000
total_partitions (0x0c) : 0x00000001

name (0x10) : u-boot.elf

PARTITION HEADER TABLE (FSBL24dec.elf.0)

encrypted_length (0x00) : 0x00006004 unencrypted_length (0x04) : 0x00006004
total_length (0x08) : 0x00006004 load_addr (0x0c) : 0x00000000
exec_addr (0x10) : 0x00000000 partition_offset (0x14) : 0x000005c0
attributes (0x18) : 0x00000010 section_count (0x1C) : 0x00000001
checksum_offset (0x20) : 0x00000000 iht_offset (0x24) : 0x00000240
ac_offset (0x28) : 0x00000000 checksum (0x3c) : 0xfffed7e2
attribute list -
trustzone [non-secure] el [el-0]
exec_state [aarch-32] dest_device [none]

encryption [no] core [none]

PARTITION HEADER TABLE (system_wrapper.bit.0)

encrypted_length (0x00) : 0x0007f2e8 unencrypted_length (0x04) : 0x0007f2e8
total_length (0x08) : 0x0007f2e8 load_addr (0x0c) : 0x00000000
exec_addr (0x10) : 0x00000000 partition_offset (0x14) : 0x000065d0
attributes (0x18) : 0x00000020 section_count (0x1C) : 0x00000001
checksum_offset (0x20) : 0x00000000 iht_offset (0x24) : 0x00000250
ac_offset (0x28) : 0x00000000 checksum (0x3c) : 0xffe7bf06
attribute list -
trustzone [non-secure] el [el-0]
exec_state [el-0] dest_device [none]

encryption [no] core [none]

PARTITION HEADER TABLE (u-boot.elf.0)

encrypted_length (0x00) : 0x0001caeb unencrypted_length (0x04) : 0x0001caeb
total_length (0x08) : 0x0001caeb load_addr (0x0c) : 0x04000000
exec_addr (0x10) : 0x04000000 partition_offset (0x14) : 0x000858c0
attributes (0x18) : 0x00000010 section_count (0x1C) : 0x00000001
checksum_offset (0x20) : 0x00000000 iht_offset (0x24) : 0x00000260
ac_offset (0x28) : 0x00000000 checksum (0x3c) : 0xf7f2440d
attribute list -
trustzone [non-secure] el [el-0]
exec_state [aarch-32] dest_device [none]

encryption [no] core [none]

root@arm:/boot#

Astranome

BOOT.bin чуть больше старого, 20 блоков вместо прежнего 19 блоков. Что надо сделать, чтобы он загружался? Изменить команду "-erase BOOT.bin -"
flash_erase /dev/mtd0 0x0 0x80 ?