Восстановление контроллера Matrix

[Ilya J.]

Сообщение от Gel

Посмотрел, все на месте.

Уточните, в 249 версии смотрели? Там еще нет этого исправления.

[Gel]

Сообщение от Ilya J.

Уточните, в 249 версии смотрели? Там еще нет этого исправления.

Да, смотрел в 249.

Подкиньте идею разработчикам, что настройки временно можно сохранять в RAM-диск, а не на eMMC.

Тогда процедура упрощается -- можно после сохранения, но перед выгрузкой root.tgz форматнуть eMMC, как надо и не заморачиваться, есть ли что-то на eMMC.

Т.е. я бы сделал такой алгоритм под ваши требования:

1. Сохранить настройки на RAM-диске (если получится).
2. Форматирование весь eMMC, как он должен быть, все три раздела.
3. Сохранить настройки из RAM-диска на eMMC
4. Загрузить root.tgz на eMMC
5. Выполнить распаковку, установку, восстановление настроек (если получилось сохранить ранее).


Добавлено через 27 минут


Посмотрел, там файлы настроек-то в сумме меньше килобайта.

Ради этого килобайта делать "многостадийное форматирование", сначала одну часть диска форматнем, потом другую -- это ерунда какая-то.

Слишком сложно без причины.

Надо проще делать.

[Gel]

В продолжение темы Trim 5 не переводится в режим программирования.

У меня тоже возникла ошибка форматирования, стал разбираться, что там могло пойти не так.

Мои симптомы были следующие. Был переход в режим форматирования, загружался загрузчик первой стадии, запускался, пытался загрузить загрузчик второй стадии и на этом все.







Вот, как выглядит проблема со стороны контроллера:

U-Boot SPL 2013.10-svn118115 (Jul 05 2021 - 14:29:56)
Set dpll freq to 400MHz
mtrx platform(): true
Trying to enable RTC32K...
RTC32K enabled.
SDRAM init (400MHz)
sleep 5s
Switch to 1GHz
Using default environment

usb_ether
using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
MAC 40:2e:71:f8:99:16
HOST MAC de:ad:be:af:00:00
RNDIS ready
musb-hdrc: peripheral reset irq lost!
high speed config #2: 2 mA, Ethernet Gadget, using RNDIS
USB RNDIS network up!
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
Using usb_ether device
TFTP from server 192.168.111.1; our IP address is 192.168.111.2
Filename 'u-boot-restore.img'.
Load address: 0x807fffc0
Loading: T T T
TFTP error: 'Timeout' (0)
Starting again

using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
MAC 40:2e:71:f8:99:16
HOST MAC de:ad:be:af:00:00
RNDIS ready
high speed config #2: 2 mA, Ethernet Gadget, using RNDIS
USB RNDIS network up!

Сразу забегая вперед и не томя, нашел, что проблему можно решить правкой файла "C:\Program Files (x86)\SMLogix\tftp.ini".

Параметр "blksize=65464" можно заменить на "blksize=512" или "blksize=1372".

С параметром "blksize=512" обновление у меня заняло 5 минут, а с параметром "blksize=1372" обновление длилось 3 минуты 42 секунды.

Что могло пойти не так

Оттрассировав TFTP-запросы SPL-загрузчика заметил, что контроллер предлагает передавать файл u-boot-restore.img блоками по 1468 байт, а TFTP-сервер с настройками по умолчанию этому и не сопротивляется.



Параметры сетевого интерфейса со стороны Windows дают настройку MTU в 1404 байт.

>netsh interface ipv4 show subinterfaces

   MTU  Состояние определения носителя   Вх. байт  Исх. байт  Интерфейс
------  ---------------  ---------  ---------  -------------
  1404                1       8851      22766  Ethernet 9

Это означает, что передача файла блоками 1468 байт требует MTU, равную 1468 + 4 + 28 = 1500 байт. В противном случае, происходит фрагментация пакета.

В итоге, в лучшем случае это приводит к неэффективной (более длительной) передаче данных, а в худшем, передача просто не работает. Есть предположение (не стал глубоко копать), что SPL-загрузчик, имеющий упрощенный IP-стек, просто не понимает фрагментированные пакеты.

В итоге обновление завершается по таймауту с ошибкой, т.к. загрузчик не "получает" данные.

В решении выше, значение "blksize=1372" получается, как 1372 = 1404 - 28 - 4. Специально проверил, если поставить большее значение, "blksize=1373", то загрузка не происходит.

[Gel]

Не удалось выяснить, кто или что испортило MTU для сетевого USB-адаптера.

Сбросил сетевые настройки в Windows на значение по умолчанию командой из административной консоли:

netsh interface ipv4 reset

После этого MTU вернулось к значению 1500.

[Arsie]

Сообщение от Gel

Не удалось выяснить, кто или что испортило MTU для сетевого USB-адаптера.

Сбросил сетевые настройки в Windows на значение по умолчанию командой из административной консоли:

netsh interface ipv4 reset

После этого MTU вернулось к значению 1500.

Отличное исследование!