Цитата(vvj @ Oct 25 2005, 20:32)

Цитата(yuriypro @ Mar 21 2005, 15:38)

В У-Буте есть mkimage, который делает из имиджа ядра то, что потребно лоадеру.

Интересная утилита этот mkimage - из 5ти вариантов сгенерированного им образа для uBoot'а, грузиться только один. Смотрю - а он к одному и тому же исходному zImage может добавить разные header'ы! При одинаковых параметрах и иходном зипованом бинарнике! Что он туда и время пишет? А большинство сгенерированных образов или виснут при их вызове (uBoot'ом) или перегружают проц (очевидно exeption). Повезло ещё что первые образы были удачные, ведь поначалу на подправленый мной kernel грешил.
Попробовал взять mkimage от версии (uBoot'а) 1.3 для linux'а, пока юзаю 1.1 для cygwin'а - таже фигня.
Может кто сталкивался?
Ещё интересная вещь - когда uBoot распаковывает образ, обращает на себя внимание сообщение насчёт Bad gzipped data:

Код

...
## Booting image at 20008000 ...
  Image Name:  
  Image Type:   ARM Linux Kernel Image (gzip compressed)
  Data Size:    810360 Bytes = 791.4 kB
  Load Address: 20008000
  Entry Point:  20008000
  Verifying Checksum ... OK
  Uncompressing Kernel Image ... Error: Bad gzipped data
GUNZIP ERROR - must RESET board to recover
OK
No initrd
## Transferring control to Linux (at address 20008000) ...

Starting kernel ...

Uncompressing Linux...................................................... done, booting the kernel.

Linux version 2.6.13.3 (root@linux) (gcc version 3.4.1) #1...

Это не смертельно? А то kernel вроде работоспособен

А почему у Вас сам скомпрессированный имидж лежит по тому же адресу, куда он должен грузиться?

По идее, адрес, где скомпрессированный имидж лежит, и адрес куда он затем после распаковки грузится должны быть разные. А иначе Вы рискуете запортить свой скомпрессированный имидж.

Нормальная ситуация, когда скомпрессированный имидж лежит, например, во флешке, а u-Boot его затем из флешки распаковывает и грузит в SDRAM.

Hercules.

Сам пока не задумывался - до размещения linux'а во Flash дело не дошло. Пользовался инструкциями из документа "AT91RM9200DK U-Boot Developper Manual" :
и

Цитата(vvj @ Oct 26 2005, 11:28)

Цитата(Hercules @ Oct 26 2005, 10:04)

А почему у Вас сам скомпрессированный имидж лежит по тому же адресу, куда он должен грузиться?Hercules.

Сам пока не задумывался - до размещения linux'а во Flash дело не дошло. Пользовался инструкциями из документа "AT91RM9200DK U-Boot Developper Manual" :

Код

($U-BOOT-PATH)/tools > ./mkimage -A arm -O linux -T kernel -C gzip -a
0x20008000 -e 0x20008000 -d linux.bin.gz uImage /tftpboot/

и

Код

Uboot> tftp 20008000 uImage
Uboot> tftp 21100000 ramdisk
Uboot> setenv bootargs root=/dev/ram rw initrd=0x21100000,
60000000 ramdisk_size=15360 console=ttyS0,115200 mem=32M
Uboot> saveenv
Uboot> bootm 20008000 21100000

Вы немного неправильно делаете (у Вас неправильно указан адрес, куда нужно грузить скомпрессированное ядро linux-а). Нужно где-то так:

т.е. мы грузим скомпрессированное ядро linux-а по адресу 0x21000000, а ramdisk по адресу 0x21100000. Затем распаковывается и запускается ядро linux-а (команда bootm). Причем ядро после распаковки будет лежать начиная с адреса 0x20008000 и туда же будет передано управление т.к. "Load Address" так же был установлен на 0x20008000 (судя по той информации, что Вы привели "($U-BOOT-PATH)/tools > ./mkimage ..."). Указывать в команде bootm еще и адрес, где у нас лежит ramdisk не нужно, так как его распаковывать будет ядро linux-а (ему будет передана информация о том где лежит ramdisk в аргументах (bootargs)).

Командой setenv вы устанавливаете переменную bootargs в нужное значение. А затем командой saveenv Вы сохраняете все свое окружение во флэшку. При последующей загрузки u-Boot-а все сохраненные переменные будут востановлены. Т.е. до тех пор пока Вы сами не удалите переменную bootargs (например, командой setenv bootargs без указания значения переменной или сотрете тот сектор флешки, где у Вас располагаются переменные окружения) все последующие запуски linux-а можно делать так:

т.е. уже не нужно вы полнять команды:


Вот в кратце вроде все. Пробуйте.
Hercules

PS. Надеюсь у Вас на tftp сервере, с которого осуществляется загрузка, скомпрессированное ядро лежит именно под именем uImage, а RAM диск под именем ramdisk.

Благодарю за исчерпывающий ответ, извиняюсь за то, что я привёл оригинальную выдержку из документа, где работают с DevKit'ом. У меня же в "раме", "всего" 16 метров. Сам использую скрипт для bootcmd:

а то уже снится стали эти "tftp 20008000 uImage tftp .."

Идею я понял, спасибо. Однако тогда не пойму как оно сейчас работает - ведь распаковывающийся образ, из-за бОльшего размера перетирает пакованный по тому же адресу uImage "быстрее"?

И вот ещё: что надо чтоб "пингануть" этот кастрированный Linux? Должен ли он это по умолчанию делать или добавить какой модуль надо? А то он кроме ls и cd других команд (типа ifconfig) не признаёт. Я понимаю, что это по идее отдельные апликации, но сам пока не знаю как делать тот самый rootfs. Пользуюсь одолженным.

ЗЫ: и кто бы подсказал что это за число магическое: 60000000?

ЗЫ2:
Товарищ Hercules! Не работает Ваша теория: проверено несколько раз по 8ми и 10ти метровому адресу

Я хоть и не Hercules, но присоединюсь:

Может у Вас просто память (SDRAM) шалит?
И во-вторых, можно для начала вообще не сжимать ядро (с помощью mkimage), а делать plain image, и потом уже (для записи во флешку) делать zImage и его уже обрабатывать mkimage. Мне показалось что zImage разкручивается быстрее...

PS Посмотрел более ранние сообщения, у вас похоже ядро сжато дважды? Сначала u-boot рапортует про gzipped image, потом видим Uncompressing linux??? Это же двойное время на распаковку!

Убрал параметр -C gzip из mkimage, всё равно (uBoot) пытается его распаковать:

SDRAM впорядке. Если сазданный mkimage'ом образ виснет, то он виснет ВСЕГДА (раз пять подряд пробовал). Тогда делаю с того же(!) zImage'а ещё раз uImage пока не получу работающий образ. И этот образ грузится ВСЕГДА.
Короче этот mkimage клепает разные образы с одного и того же исходника!

Попробуйте c ключом -С none

Семён Семёныч! Не дочитал я документ однако!

Но всё же избавление от повторной зиповки, не помогло избежать проблем с появлением виснущих образов

А можно глупый вопрос?
Судя по:

Цитата(vvj @ Oct 26 2005, 21:48)

Код

Starting kernel ...
Uncompressing Linux...................................................... done, booting the kernel.
Linux version 2.6.13.3 (root@linux) (gcc version 3.4.1) #1...

и

Цитата(vvj @ Oct 26 2005, 21:48)

Код

($U-BOOT-PATH)/tools > ./mkimage -A arm -O linux -T kernel -C gzip -a 0x20008000 -e 0x20008000 -d linux.bin.gz uImage /tftpboot/

Вы вначале собираете ядро Linux-а версии 2.6.13.3, а затем при помощи mkimage получаете готовый имидж для u-Boot-а.
А почему Вы сразу при сборке ядра не получаете готовый имидж для u-Boot-а? Это можно сделать так:
make uImage
В ядре 2.4 такой возможности не было и действительно приходилось вначале собирать ядро, а затем самому получать имидж для u-Boot-а, а в ядре 2.6 уже есть (ядро 2.5 я не собирал, поэтому не знаю можно там сразу получить uImage или нет).

Вот нашел у себя книжечку. Может пригодиться. Правда там все расказывается на примере ядра 2.4, а не 2.6, но все равно можно почитать.

Убрал аттач. Содержимое книги лежит в закромах по адресу /pub/DOC/Books/OS/Unix_linux/linux_embedded/oreilly.building.embedded.linux.systems

Читаю читаю, спасибо.

Так ведь тёмный я, не в въехал пока как ему при этом параметры "-e 20008000" и "-a 20008000" передавать.
ЗЫ: есть там правда в папке arch/arm/boot файл .uImage.cmd с узнаваемыми параметрами, но по сообщению "mkimage" command not found (при make uImage) понятно что это просто шелскрипт и сделает он тоже что и я.

Заговор имени компакт флеша на AT91RM9200DK. Вот уж сколько времени я пытаюсь запустить компакт флеш на плате, схемотехника которой сильно похожа на субж. В майл листе посвященном данной теме проносятся какие-то обрывки информации о том, что данная плата имеет баг в этом отношении. Кто либо может подсказать или связать с человеком обладающим информацией по данной проблеме или запустившим компакт флеш любым способом под линух 2.6. Заранее благодарен.

Немного не по теме, но правильно ли я понимаю, что У-Буту нету разницы, по какому USART я подключусь (в смысле, я хочу по RXD3, TXD3)? Я так понял, что это конфигурируется вначале?