Назад | Перейти на главную страницу

Загрузка с помощью tftp U-Boot случайно истекает

У меня есть кастомная плата с TI OMAP SoC. Я пытаюсь загрузить uImage с Linux-машины через tftp U-Boot. Он терпит неудачу с тайм-аутами (большинство попыток превышает лимит таймаута, и очень редко он проходит) на некоторых, но успешен на других. Однако любая другая комбинация, не связанная с U-Boot, безупречна. Даже если рассматриваемая плата загрузила ядро. Сравнение сетевых настроек (включая sysctl) не дало существенной разницы между обслуживающими машинами, на которых работает Linux.

Были взяты следующие тесты:

Результаты следующие:

  1. u-boot <-> i686-pae Linux
Using DaVinci-EMAC device
TFTP from server 192.168.100.254; our IP address is 192.168.100.88
Filename 'uImage'.
Load address: 0xc0700000
Loading: ############T ###############################T ##########T ############
              #######T ################################################T ##########
              ##########################T #######################################
              ###########################T ######################################
              ################################T #################################
    #################################################################
              ########T #########################################################
              ##################
              11.7 KiB/s
done
Bytes transferred = 2418464 (24e720 hex)

Соответствующий дамп трафика можно найти здесь: http://pastebin.com/hBBwe9bL

  1. u-boot <-> i686-pae Linux kvm guest
Using DaVinci-EMAC device
TFTP from server 192.168.100.112; our IP address is 192.168.100.88
Filename 'uImage'.
Load address: 0xc0700000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
          ##################
          795.9 KiB/s
done
Bytes transferred = 2418464 (24e720 hex)

Соответствующий дамп трафика можно найти здесь: http://pastebin.com/ZXYdpmSe

  1. u-boot <-> x86_64 windows 7
Using DaVinci-EMAC device
TFTP from server 192.168.100.86; our IP address is 192.168.100.88
Filename 'uImage'.
Load address: 0xc0700000
Loading: #################################################################
#################################################################
          ###################################
          173.8 KiB/s
done
Bytes transferred = 2418464 (24e720 hex)

Соответствующий дамп трафика можно найти здесь: http://pastebin.com/UWFEZjTz

На данный момент я понятия не имею, что может вызвать тайм-ауты для u-boot, и у меня больше нет подсказок, как решить эту проблему. Любая помощь очень ценится.

Это определенно имеет какое-то отношение к сетевому стеку U-Boot, но я считаю, что это правильное место, чтобы задать этот вопрос.

Я прочитал эту статью: http://www.denx.de/wiki/view/DULG/TFTPTimeoutОднако то, что там описано, не имеет отношения к моей ситуации, поскольку результаты не зависят от переключения между ними.

Что я уже пробовал: tftpd / tftpd-hpa; tftpblocksize=512; ядро x86_64 linux (tftp сервер); изменение настроек порта коммутатора на не aneg, а явное full-дуплекс; так же как half-; добавление / удаление переключателей между ними; изменение MTU на обслуживающей машине; сборка последней версии U-Boot из исходников; изменяющийся IP-адрес сервера в пределах /24; изменение sysctl сеть. настройки памяти; отправил сообщение в список рассылки U-Boot, но не получил ответа; сделал статический arp для U-Boot MAC.

Как показали дальнейшие эксперименты, проблема в этом конкретном случае заключалась в том, что u-boot терял входящие пакеты по совпадению с --- NetLoop timeout handler set и --- NetLoop timeout, что, как я полагаю, вызвано либо реализацией драйвера Mac в u-boot, либо самой сетевой обработкой u-boot. Этому может способствовать высокая частота пакетов в секунду восходящего коммутатора Cisco из-за быстрой обработки пакетов.

Успешная передача с хоста Windows проявляется в том факте, что выбранная реализация tftp имеет таймауты меньше, чем у u-boot, и, как следствие, повторная отправка пакетов снова, которые были захвачены u-boot в пределах отведенного времени.

Тесты также показывают, что настройка #define TIMEOUT 8000UL во время компиляции или tftptimeout 1000 во время выполнения дайте серверу tftp достаточно времени для повторной передачи потерянного пакета, что позволит продолжить передачу. Это именно то, что наблюдается при загрузке с хоста Windows.

Дополнительное тестирование показало, что настройка восходящего порта коммутатора (не тот же порт, обращенный к u-boot с рассматриваемой платой) до 10 Мбит / с полудуплекс решает проблему передачи, однако это значительно снижает доступную полосу пропускания.

Эта проблема:

  1. Возможности ставок на доске явно медленнее, чем у хоста. Тогда клиент TFTP после отправки ACK N может немедленно получить пакет данных N + 1, когда плата, вероятно, еще не может принять пакет (т.е. нет полнодуплексного режима).

  2. После пропущенного пакета обе стороны переходят в режим ожидания тайм-аута.

Дела, которые необходимо сделать:

  1. Попробуйте провести тест в очень легкой сети или, что еще лучше, при прямом подключении
  2. Если ваша ссылка составляет 1 ГБ / 100 МБ, попробуйте, если возможно, медленнее.
  3. Попробуйте установить меньшее время ожидания на «стороне сервера»; это заставит сервер ждать меньше времени перед повторной отправкой пропущенного пакета, вероятно, избегая таймаута клиента.
  4. Если у вас есть TFTP-сервер, способный управлять «задержкой между пакетами», увеличьте ее.

Если у вас все еще возникают проблемы, попробуйте захватить трафик с помощью Wireshark и проанализировать последовательность тайм-аута трафика.