Хотя я и не sasamy :), но разве от альтернативы кому то плохо бывает?
К тому же, если взглянуть в исходники bootstrap, Atmel сама имела/имеет планы сделать из своего загрузчика "полноценный", вплоть до распаковки ядра (не знаю, на что они расчитывали при 4К).

да не бывает, конечно. только польза..

я спрашивал потому, что действительно не понимаю, или не вижу чего-то.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Отредактированно alexey123 27.01.2009 г. в 11:11:30

Цитата

sasamy, идея и реализация понятна. Непонятна цель:)
чем насолил uboot?
1. ядро по TFTP записывать/обновлять быстрее, чем по xmodem
2. можно память тестировать (nm), писать в порты, и вообще - руками щупать периферию процесора..
3. место жрет на dataflash? впаять 8М и забыть

в конечном устройстве нет нужды перешивать ядра и отлаживаться? это до той поры, пока устройство не окажется в ремонте (у вас на столе). а возиться с ним всяко удобнее имея uboot...

где недостаток от его присутствия?

Недостаток один - все что умеет uboot работает ТОЛЬКО на локальной консоли... а это как раз и не нужно (для моих целей)... Избавится от ненужной функциональности - правильно, поддерживаю sasamy...

Запущенный в производство девайс должен безусловно работать... Если он работает - то доступен по сети и перешьет себя сам при необходимости через MTD, если не работает - отправляется в помойку без суда и следствия... никто никаких мозгов щупать и играться с TFTP не будет... больше 3 минут на каждый - прямой убыток... ЧТО здесь будет делать uboot - я не понимаю....

Можно поставить кучу всего ненужного и оплатить это... только ЗАЧЕМ ?
К тому же разница всего в 1$, даже при мелкосерийном производстве превращается в тысячи, которые я предпочитаю получить в виде премии...

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Отредактированно repairman 27.01.2009 г. в 11:59:01

Цитата

Хотел дописать чтобы можно было указать адрес в ram по которому производить запись и последующий запуск - но никак не могу уложиться в 4 кбайта - это предел sram для кода на этом этапе загрузки. Я собирал старым тулчайном который 2007q - более новый 2008q генерирует слишком большой бинарник и он не влазит в 4 кбайта.

Попробуй этим собрать...
http://repairman.smtp.ru/armv5l-linux-uclibc.tar.bz2

Заодно узнаем, работает ли оптимизация под armv5te / arm926ej-s при сборке тулчейна....

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Отредактированно repairman 27.01.2009 г. в 13:05:53

>>если не работает - отправляется в помойку без суда и следствия...

ну дай-то бог!
вы не из NOKIA ?:)

Цитата

1. ядро по TFTP записывать/обновлять быстрее, чем по xmodem
2. можно память тестировать (nm), писать в порты, и вообще - руками щупать периферию процесора..
3. место жрет на dataflash? впаять 8М и забыть

1) u-boot по xmodem залетает в ram за несколько секунд - так что если он нужен - вообще ноу проблем :) Реализовать загрузку по определенному адресу - вопрос времени, я просто спать хотел :) Если вы посмотрите на исходники ставшего уже монстриком u-boot - весь его функционал наращивается за счет переноса кода ядра linux - так какой смысл перед linux грузить еще один кастрированный linux ??? Не проще сразу нормальный грузить ?
2) см 1:) - все это можно делать и в linux причем с большим успехом, единственное - тестирование памяти не получится, при желании опять же заливается u-boot или свой нормальный тестер, вам в любом случае нужен будет терминал для просмотра результата, а вот сеть далеко не всегда работает ;)
3) repairman прав - это дома можно перепаять и не обращать внимание на разницу в 1$ - на практике даже резисторы стараются при smd монтаже одних номиналов делать чтобы затраты снизить - а тут целый доллар :)

2repairman - проверю - счас докачается тулчайн, только дело не в нем :) от оптимизации в данном случае нет никакого толка - в загрузчике не используются библиотеки C. Все зависит от версии компилятора - наколько он умеет генерировать оптимальный код.

Основная цель была - знакомство с архитектурой ARM.

Цитата

Попробуй этим собрать...

Собрал - работает и код получился короче на 68 байт :) Думаю сейчас мне хватит места чтобы доделать загрузку по выборочному адресу. Если и другое все заработает - буду пользоваться этим тулчайном. Спасибо.

1) смысл кастрированного linux - в загрузке некастрированного linux, и ничего больше. изменяя bootstrap вы волей-неволей тащите в него (своими руками и головой) функционал из uboot . загрузка по адресу, xmodem... и TFTP не за горами:)
+как патчить такой код? а ну как ошибка всплывет в xmodem ? (всплывет не у вас на плате, а у соседа)
резюме: bootstrap и u-boot (в том виде, каком они есть) обсуждается, дебагится и патчится всем миром в google. надо только увидеть проблему. свой код - ты обсуждаешь, дебагишь и патчишь сам.
2) в linux можно все делать с большим успехом. Но через толстую прослойку ОС (и драйверов) и с обязательной оглядкой на них. на мой ламерский взгляд - nm+*.pdf прозрачней devctl+DocBook. (в приведенной задаче - простая проверка оборудования).
3) тут трудно спорить, доллар правит миром. 8M на dataflash - это о себе любимом забота. потому как понадобится потом лишний мегабайт, и накроются тысячные премии :)

Цитата

а ну как ошибка всплывет в xmodem ?

Это вряд ли :) Код перенесен из проекта coreboot практически один в один. Функционал наращиваться больше не будет - предел по памяти... Патчить - кому надо пропатчит :) А может и еще доработает - в этом есть смысл open source.

Добавлю про 8М DataFlash, разница в стоимости не имела такого значения (когда определялся с размером монтируемых флешек), самое главное - у 8М нет so8 корпуса, тот который на подобии QFN (только хуже от того что с боков корпуса нет метализации) монтировать ОЧЕНЬ неприятно ну а в QFP копрусе слишком много места занимать будет (для своей скромной функции).