Вопрос: за что боролись ? И к чему тогда все эти пляски с проводами и переходниками...

Ладно, придется искать причины этих неприятностей. Для этого посмотрим на структуру разделов, который создаются в памяти устройства. И на их содержимое.

И нужный нам раздел нашёлся: маленький, но гордый и важный. Размер раздела всего 16 Mb, при этом в него записывается целиком файл размером 130 Кб, в котором значащих данных всего примерно 5 Кбайт, остальное - пустое место.

Он потому и сделан как отдельный раздел, что в нем хранится информация, необходимая для правильной работы загрузчика U-Boot.

Итак, мы смотрим раздел Env. Его название - не что иное, как сокращение от слова Environment, что означает "окружение" или "cреда". Это защищенное хранилище переменых среды (или переменных окружения), которыми пользуется загрузчик U-Boot, копируя эти переменные в оперативную память и выполняя записанные в этих переменных команды и настраивая систему. Переменные среды в исходном виде представляют собой массив обычных текстовых строк, разделенных нулевыми байтами. В таком виде они хранятся в файле env.fex, входящем в состав образа прошивки, в таком же виде они записываются в одноименный раздел env в хранилище устройства.

В таблице разделов GPT раздел ENV описан так:

• Partition Type GUID (GUID типа раздела) = ebd0a0a2-b9e5-4433-780c-68b6b72699c7
• Unique Partition GUID (GUID раздела) = 0a805564-1466-47a4-a353fca9272b8e46
• Starting LBA 98304 (N блока первого сектора раздела) = 0x3000000
• Ending LBA 131071 (N блока последнего сектора раздела) = 0x4000000
• Attributes ( атрибуты раздела) = 0000000000020008 [0]
• Partition Name (имя раздела) = env
• Partition Size (размер раздела): блоков = 32768 (0x8000), 16 Мбайт
• Время создания раздела 27.03.2020 15:17:10

В этот раздел ENV при установке прошивки на устройство записывается содержимое файла env.fex, имеющегося в образе прошивки XXX.img. Этот файл можно извлечь из образа утилитой imgrepacker.exe, запустив её в окне консоли (или в командной строке) Windows.

Кроме того, его можно скопировать командой dd непосредственно из памяти устройства, сохранив в файл:

Анализ содержимого файла env.fex показывает, что в нем содержится 26 строк:

• 1) earlyprintk=sunxi-uart,0x05000000
• 2) initcall_debug=0
• 3) console=ttyS0,115200
• 4) nand_root=/dev/nand0p4
• 5) mmc_root=/dev/mmcblk0p4
• 6) init=/init
• 7) loglevel=8
• 8) selinux=0
• 9) cma=64M
• 10) mac=
• 11) wifi_mac=
• 12) bt_mac=
• 13) specialstr=
• 14) hx_flag=
• 15) keybox_list=hdcpkey,widevine
• 16) setargs_nand=setenv bootargs earlyprintk= initcall_debug= console= loglevel= root= init= partitions= cma= snum= mac_addr= wifi_mac= bt_mac= selinux= specialstr= hx_flag= gpt=1
• 17) setargs_mmc=setenv bootargs earlyprintk= initcall_debug= console= loglevel= root= rootwait init= partitions= cma= snum= mac_addr= wifi_mac= bt_mac= selinux= specialstr= hx_flag= gpt=1
• 18) boot_normal=sunxi_flash read 45000000 boot;bootm 45000000
• 19) boot_recovery=sunxi_flash read 45000000 recovery;bootm 45000000
• 20) boot_fastboot=fastboot
• 21) recovery_key_value_max=0x13
• 22) recovery_key_value_min=0x10
• 23) fastboot_key_value_max=0x8
• 24) fastboot_key_value_min=0x2
• 25) bootdelay=0
• 26) bootcmd=run setargs_nand boot_normal

Сейчас мы не будем исследовать смысл и назначение каждой строки. Нас интересут толко две из них, а именно 7-я и 25-я. Эти две строки - источник всех бед, описанных выше. Поэтому нужно внести в них исправления.

Строка bootdelay=0 (ждать 0 секунд) сообщает загрузчику U-Boot, что он должен не ждать нажатия каких-либо кнопок (от слова - совсем), а сразу переходить к исполнению команд, содержащихся в переменной bootcmd, т.е. запускать загрузку ядра системы. Поэтому необходимо заменить 0 на любое не очень большое целое число, например сделать bootdelay=5.

С таким значением U-Boot будет обязан ждать 5 секунд, отображая обратный отсчет, как при запуске космической ракеты. И мы всегда успеем нажать на клавиатуре кнопку остановки (или просто будем держать клавишу пробела нажатым в момент подачи питания или рестарта).

Пробел предпочтителен по двум причинам:

Итак, с одной проблемой мы справились. Ура !

Теперь переходим ко второй проблеме.

Строка loglevel=N, где N - число от 1 до 8, устанавливает уровень важности выводимых в терминал сообщений: 1 - самые критичные ошибки, 2 - менее критичные и т.д., а 8 - вообще все сообщения, включая ошибки, предупреждения и прочий словесный мусор.

В исходном файле переменных окружения установлено значение loglevel=8, поэтому этот спам обеспечен и он бесконечен.

Ну вот, включаем антиспам и ставим значение loglevel=2. Теперь при нормальном включении и загрузке системы никаких лишних сообщений не будет или будут сообщения о фатальных или критических ошибках (а если что-то совсем пошло не так, то просто пойдет дым...).

Но пока это всё теория, и возникает вопрос: как практически отредактировать этот файл и что с ним делать дальше.

Для редактирования есть разные возможности.

Например, использовать продвинутый HEX-редактор. Единственная с ним сложность: правильно вычислить контрольную сумму CRC32 и записать её в файл (это первые четыре байта в самом начале файла).

Поэтому был написан простенький скрипт , который делает эту процедуру автоматически, быстро и надёжно.

Для проверки правильности сделанных изменений достаточно сравнить исходный файл с изменённым с помощью консольной команды (мы используем Windows):

 fc /b env.fex env.img > diff.txt  

здесь

Отличаться должны 6 байтов: первые 4 - это контрольная сумма, и ещё два байта 38 -> 32 и 30 -> 35

Например, так:

  00000000: F5 73
  00000001: 2B BB
  00000002: 97 CA
  00000003: 95 AE
  00000090: 38 32
  00000496: 30 35

Ну хорошо, теперь у нас имеется откорректированный файл env.img. Что дальше ?

Кстати, этот файл (для приставки Transpeed на H616) можно забрать по ссылке ниже. После скачивания извлечь из zip-архива файл env.img. Сравните его со своим указанной выше командой. Если отличия только в 6 байтах ( и 38->32, 30->35), то этим файлом можно воспользоватся в готовом виде.