Да, виснет если даже сам uImage второй раз послать и на тот же или любой другой адрес... У меня в uboot там ещё доступна загрузка по y-modem и по какому-то kermit, я юзаю minicom и уже сто раз отправлял файлы через этот minicom, но u-boot просто не видит что я хочу послать по kermit, а если по y-modem то minicom выдает ошибку даже если никаких файлов ни через что не передавалось до этого... Пробую ещё вариант с NFS, но пока выдает unable to mount, хотя NFS сервер пашет...

В общем, попробовал я с NFS грузануть... и тоже не работает!!! Где можно раздобыть наипоследнийший u-boot с поддержкой edb9302? Может в новых версиях эти проблемы устранили?
Однако если ядро грузить по tftp (один раз он срабатывает к счастью) а корневую файловую систему через NFS брать то всё прекрасно монтируется и система заводится и работает отлично. Этим я пока ограничусь, но не теряя надежды оживить и все другие возможные способы загрузки системы...
ЗЫ Оффтоп: юзаю nfs-kernel-server и он почему-то очень долго ищется nfs-клиентом... Так же замечал на своем десктопном Linux что на фтп оно заходит очень очень долго, думает о чем-то, хотя на тот же фтп виндовый комп заходит слёту за мгновение... Можно ли ускорить в Linux скорости коннектов?

А если с RedBoot'ом новым попробовать?

Столкнулся со следующей проблемой... Ядро версии 2.6.24-rc8 прекрасно собирается и работает, однако для него не удается собрать модуль ядра. Для начала я пытаюсь собрать простейший модуль hello world, который содержит всего пару printk и успешно собирается для моего десктопного Linux (debian-40r3-i386). Не поленился и запустил на своей платке ядро 2.6.20.4 и оно хроршо работает и этот же модуль прекрасно собирается и устанавливается. Но для 2.6.24-rc8 выдает тучу непонятных ошибок. Изменился ли как-нибудь процесс сборки модулей ядра для самых последних версий ядра, начиная с 2.6.24?

Чтобы не засорять форум текстами, выкладываю текстовый файл:  error.txt ( 3.03 килобайт ) Кол-во скачиваний: 279

В начале успешная сборка для 2.6.20.4, затем то что для 2.6.24, далее скриптик который собирает, в нем я меняю лишь только каталог KDIR с исходниками ядра...

Есть вопрос: SPI под каким майором регистрируется? Про i2c знаю, что 89

У меня PHY KSZ8721BL. Для процессора EP93xx - ядра версии 2.6.24, 2.6.25 и самая свежатина 2.6.27 - отлично собирается, создается uImage, загружается по TFTP, запускается. Но PHY насколько я понимаю не определяется...
Это регрессия, или надо что-то дополнительное сконфигурировать, чтобы возобновить поддержку KSZ8721BL?

Проверьте, правильно ли выставлена частота MDC (2.5MHz).

Сори, но где это смотреть?.. Осциллографа нет... Или копать исходники? Но в каком файле? Поиск по папке с 2.6.27 по ключевому слову 8721 не позволил найти файлы, относящиеся к данному типу PHY... Может решили почистить от "ненужных" драйверов? Вроде интерфейс у таких PHY стандартный, однако где смотреть код, относящийся к нему пока не нашел. Но с удовольствием бы покопался и попробовал бы решить проблему...

Копать исходники в сторону \kernel\linux-2.6.2x\drivers\net\arm\ep93xx_eth.c, phy_init().

У них стоит HCLK/8, т.е. 12.5MHz @ 100MHz HCLK.

Ядро 2.6.27, этой функции нет, они переделали на новомодную структуру модуля c platform_driver... Она называется static int ep93xx_eth_probe(struct platform_device *pdev)

т.е. на 2.5 МГц они уже исправили (100М/40 = 2.5M)...
Остается непонятной причина неработоспособности... А главное - пути решения...

Тогда это не PHY. А MAC-адрес они там откуда берут?

А хз...
Я сравнил с кодом рабочего драйвера из 2.6.20 (кстати, сильно отличаются) там есть:

т.е. там как раз 12.5 МГц и работает - попробую исправить и проверить...

Куда исправить - на 12.5MHz? Так не поможет.

Проверьте, что дело вообще доходит до вызова ep93xx_eth_probe.

Действительно, не помогло... Вставил в probe такое: printk(KERN_EMERG "ep93xx_eth_probe\n");
Это гарантирует что сообщение будет выведено если до него дойдет дело... Проверил лог загрузки... Действительно, ep93xx_eth_probe даже не вызывается!

Тогда ковыряйте конфиги... Да, а что такого хорошего в 2.6.27?