Тут надо просто всё очень тщательно проверить, и должно заработать:
1) Переменные окружения u-Boot-а
командой printenv (на предмет, что наш IP не занят другими компами в сети, что серверный IP указан правильно, т.е. действительно соответствует IP-адресу компа, на котором Linux установлен, что адрес гейта (роутера) тоже установлен правильно (хотя и не знаю, на что это по идее влияет), что адреса все из правильной подсети и т.д. - В вашем случае нужно убедиться, что 192.168.1.3 не занят никем в вашей сети, что IP Linux-машины 192.168.1.124 - командой ifconfig).
2) То, что inetd сервер правильно сконфигурирован на вашей PC-шке (/etc/inetd.conf). Я писал как он должен быть сконфигурирован.
3) То, что у вас запущен на PC-шке этот самый inetd. Это он запускает tftp сервер когда приходит соответствующий входящий запрос.
4) Если вы изменяли конфигурацию при запущенном inetd, надо его остановить (например, командой kill -9 PID) где PID - это ID процесса inetd, выдаваемый командой ps. И запустить снова, чтоб конфигурация новая вступила в силу.
5) Странно, что у вас U-Boot не имеет реализованной команду ping. Но в любом случае, надо еще проверить, что ethernet-соединение одноплатного комьютера с сетью хорошее, что лампочки на сетевом разъеме тиона загораются, когда пытаетесь что-то получить.
6) Еще надо убедиться, что у вас действительно есть файл uImage там, где вы задали tftp серверу его искать (но судя по тому, что у вас не пишет
"host 192.168.1.124 is alive", значит он не может соединиться с сетью вообще).
7) Я бы еще проверил бы работоспособность ethernet-a на тионе: загрузил бы плату, с помощью ifconfig задал бы аппаратный адрес 81:82:83:84:85:86 и какой-нибудь незанятый IP, и пропинговал бы с этой платы Linux-машину и роутер...

Короче говоря - нужно произвести стандартный набор процедур (пооткрывать крышку капота, попинать колёса...) и должно всё заработать - нету там чего-то такого суперсекретного. Попробуйте исключить все описанные здесь причины...
Могу прислать свой образ U-Boot-а, в нём есть ping.

Прошьёте его через dd.

Только я не даю гарантий, что с компом ничего не случится! Если он сдохнет совсем - реанимировать его можно будет только J-TAG-ом!!!

В общем коннект появился, сам не знаю как :)
Дальше происходит вот такая бяка:

$ tftpboot A0000000 uImage
dm9000 i/o: 0x8000000, id: 0x90000a46
MAC: 80:81:82:83:84:85
operating at 100M full duplex mode
TFTP from server 192.168.1.124; our IP address is 192.168.1.3
Filename ''uImage''
Load address: 0xa0000000
Loading: *T T T T T T T T T T
Retry count exceeded; starting again
checksum bad
checksum bad
TFTP from server 192.168.1.124; our IP address is 192.168.1.3
Filename ''uImage''
Load address: 0xa0000000
Loading: *T T T T T T T T T T

и так далее.

Timur, в общем с постройкой образов всё получилось. Пытаюсь теперь разобраться с прошивкой тиона через uBoot. Во-первых, я так и не понял через какой же шнур физически происходит загрузка образов на Тион. С одной стороны tftp по сетевому интерфейсу коннектится, с другой стороны, консоль у нас по серийному порту работает. Переменные окружения в U-Boot''е указал, на компьютере поставил tftp, коннекта нет. Собственно, я даже не понимаю, откуда ему взяться, если мы на хост-компьютере ставим только tftp. Там не надо в настройках сети что-то менять? На ping мой U-Boot вообще отвечает, что знать не знает такой команды)) А на команду например
tftpboot A0000000 uImage
отвечает, что не может установить соединение и затем бесконечно идёт процесс "Loading:"

Насколько я помню, у меня всегда была путаница с этими -p0 или -p1. Это зависит от того, где находится патч и где находится каталог, который мы хотим пропатчить по отношению к самому патчу (хотим мы патчить то, что в каталоге или то, что рядом с каталогом - типа того).
Самый лучший способ научиться патчить - это самому на простеньких файлах и каталогах diff-ом сгенерировать файл разницы, а потом пропатчив, убедиться, что сходится.
вот здесь написано очень хорошо про это: http://www.ylsoftware.com/news/243

Timur, почему-то патч не хотел налагаться с параметром -p0, говорил выдывал следующее:
spark@spark-desktop:~/Proj/linux/linux-2.6.22$ patch -p0 < ../linux-2.6.22.19_tion270_svn700_200907291855/linux-2.6.22.19_tion270_svn700.patch
can''t find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: kernel/exit.c
|===================================================================
|--- a/kernel/exit.c (.../tags/vanilla) (revision 700)
|+++ b/kernel/exit.c (.../trunk) (revision 700)
--------------------------
File to patch:

И так далее, для каждого файла. Если продублировать ему путь к файлу, то он нормально пропатчивается и переходит к следующему, снова спрашивает файл... и т.д.
Автоматом наложился только с -p1. Чем это можно объяснить?

Да, тулчейн построился, пробую собрать ядро.

Рад, что всё получилось и спасибо, что поделились, может будет ещё кому-нибудь полезно.

Выпала еще одна ошибка:

В функции ‘open’,
включённом из ‘collect_execute’ в /home/spark/Proj/OSELAS.Toolchain-1.1.1/build-cross/gcc-4.0.4/gcc/collect2.c:1580:
/usr/include/bits/fcntl2.h:51: ошибка: call to ‘__open_missing_mode’ declared with attribute error: open with O_CREAT in second argument needs 3 arguments
make[2]: *** [collect2.o] Ошибка 1
make[2]: *** Ожидание завершения заданий...
ranlib libbackend.a
make[2]: Выход из каталога `/home/spark/Proj/OSELAS.Toolchain-1.1.1/build-cross/gcc-4.0.4-first-build/gcc''
make[1]: *** [all-gcc] Ошибка 2
make[1]: Выход из каталога `/home/spark/Proj/OSELAS.Toolchain-1.1.1/build-cross/gcc-4.0.4-first-build''
make: *** [/home/spark/Proj/OSELAS.Toolchain-1.1.1/state/cross-gcc-first.compile] Ошибка 2

Руководствуясь этим:
http://bugs.gentoo.org/attachment.cgi?id=180181
отредактировал collect.c, пошло дальше, покамест строится

Действительно, не установлен. Процесс пошёл вроде, спасибо.

Думаю, что вы не установили пакет build-essential (как пакеты устанавливать, наверно знаете - через Synaptic либо sudo apt-get install имя_пакета).

Ещё посоветовал бы вам установить англоязычную Ubuntu - это сильно облегчает потом решение проблем, т.к. переводить сообщения об ошибках с русского на английский и потом гуглить - можно легко не найти, а если сразу на английском сообщения - то обычно находится всё без проблем гуглом и решается. (К сожалению, русскоязычное Linux-community еще не настолько развито, чтоб можно было найти описание подобных ошибок на русском языке).

Timur, пробовал собрать toolchain, запнулся на следующем этапе:

spark@spark-desktop:~/Proj/OSELAS.Toolchain-1.1.1$ ptxdist go

touch depend.out

------------------------------
target: cross-binutils.extract
------------------------------

extract: archive=/home/spark/Proj/OSELAS.Toolchain-1.1.1/src/binutils-2.17.tar.bz2
extract: dest=/home/spark/Proj/OSELAS.Toolchain-1.1.1/build-cross
PATCHIN: packet=binutils-2.17
PATCHIN: dir=/home/spark/Proj/OSELAS.Toolchain-1.1.1/build-cross/binutils-2.17
PATCHIN: using series file /home/spark/Proj/OSELAS.Toolchain-1.1.1/patches/binutils-2.17/generic/series
~/Proj/OSELAS.Toolchain-1.1.1/build-cross/binutils-2.17 ~/Proj/OSELAS.Toolchain-1.1.1
applying /home/spark/Proj/OSELAS.Toolchain-1.1.1/patches/binutils-2.17/generic/tc-arm.diff
/home/spark/Proj/ptxdist/lib/ptxdist-1.0.2/scripts/apply_patch_series.sh: line 86: patch: команда не найдена
make: *** [/home/spark/Proj/OSELAS.Toolchain-1.1.1/state/cross-binutils.extract] Ошибка 1

error: a command in the pipe returned 2, bailing out

Не подскажете, в чём дело?

Страничку, описывающую построение ядра, перевёл на CSS. Цвета щас не фонтан, но зато меняются одним махом.

Пока так, разберусь, как использовать CSS, тогда сделаю по-другому. Вроде сейчас же (серый текст на темно синем фоне) уже вполне читабельно...

Интересная тема сайта, только сочетания шрифта и фона - "вырвиглаз". Черное на белом будет смотреться лучше.

Дал ссылку на эту страничку вконтакте и в LJ.
Есть замечания по дизайну у некоторых. Кому не лень, скажите, что в дизайне по-вашему не правильно. Я исправлю. Пишите прямо в гостевой, пожалуйста.