вроде картина прояснилась - похоже собака порылась в dnsmasq

Код

/usb/sbin/dnsmasq --help
bla-bla-bla
--enable-tftp Enable integrated read-only TFTP server.
..

как вариант, заблокировать tftp через dnsmasq.conf и засетапить tftpd (apt-get install tftpd)

Цитата

С платы на Windows + tftpd32 передается нормально. С Windows на ВМ и обратно - тоже.

Пробовал при выключенном антивирусе - то же самое.
Плата напрямую соединяется с ПК (т.е. никаких роутеров, свичей и т.д. нет)

Сегодня/завтра проверю на другом компе с нативным линуксом, отпишусь, что и как.

Есть простое решение "влоб" - мне как-то нужна была венда с vmware (для imx233 утилита для прошивки mfgtool есть только для венды) я расшаривал общую директорию для обоих ОС, соответственно на гостевой Linux в эту директорию падали автоматом ядро и корневая после сборки а на хост системе (венда) я эту директорию прописал как корень для tftpd32. Как расшарить общую директорию описано например тут
http://www.vmware.com/support/ws4/doc/running_sharefold_ws.html
и тут
http://www.howtogeek.com/howto/ubuntu/how-to-share-folders-with-your-ubuntu-virtual-machine-guest/

Нужно мне это было не cтолько для доступа к tftp а больше для удобного переноса док и других данных между ОС.

как-то упустил начальный вопрос, попробовал..
для начала был изящно послан:

Код

U-Boot> run safe_boot

NAND read: device 0 offset 0x900000, size 0x700000
Skipping bad block 0x00980000
NAND read from offset fc0000 failed -74
6946816 bytes read: ERROR
Wrong Image Format for bootm command
ERROR: can't get kernel image!

изучил вывод printenv

Код

U-Boot> run safe_update
NAND write: device 0 offset 0x900000, size 0x700000
Skip bad block 0x00980000
7340032 bytes written: OK
bla-bla
# Booting kernel from Legacy Image at 70400000 ...
Welcome to SK-AT91SAM9G45!
System loaded in safe mode (rootfs in memory).

buildroot login: root

загрузился, далее посмотрел:

Код

cat /bin/install_rootfs

из него запускается

Код

cat /bin/copy_rootfs_to_nand

что и было проделано:

Код

# cd /mnt/nand/
# tftp -g -b 4096 -r rootfs.tgz 192.168.0.2
rootfs.tgz 100% |*******************************| 16504k --:--:-- ETA

есть вариант, что у вас битый блок в нанде в неудачном месте
пройдите скрипты по шагам, проконтролируйте ошибки

Странным является тот факт, что при скачивании rootfs.tgz с ВМ зависание всегда происходит на 17% и 2929к...
rootfs.tgz 17% |***** | 2929k - stalled

С нандом все в порядке (тьфу-тьфу-тьфу).
ФС восстановлена, но через Windows (как и писалось) =)

Кстати, раз уж вопрос зашел о битых блоках... Разве они никак автоматически не обходятся средствами линукса при выполнении операций с памятью?
Например, в U-boot команды nand read и nand write учитывают (по крайней мере, так сказано в хелпе) битые блоки.