[Hercules 0]

В У-Буте есть 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 вроде работоспособен :smile3046:

<{POST_SNAPBACK}>

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

## Booting image at 20008000 ...
  ...
  Load Address: 20008000
  ...

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

 

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

 

Hercules.

[vvj 0]

А почему у Вас сам скомпрессированный имидж лежит по тому же адресу, куда он должен грузиться?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

[Hercules 0]

А почему у Вас сам скомпрессированный имидж лежит по тому же адресу, куда он должен грузиться?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

<{POST_SNAPBACK}>

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

Uboot> tftp 21000000 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 21000000

т.е. мы грузим скомпрессированное ядро 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-а можно делать так:

Uboot> tftp 21000000 uImage
Uboot> tftp 21100000 ramdisk
Uboot> bootm 21000000

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

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

 

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

Hercules

 

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

[vvj 0]

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

Uboot> printenv
bootdelay=3
baudrate=115200
ethaddr=12:34:56:78:9A:BC
bootargs=root=/dev/ram0 rw initrd=0x20410000,3145728 mem=16M console=ttyS0,115200
filesize=dcf68
ipaddr=10.0.3.2
serverip=10.0.3.1
flashit=tftp 20008000 uImage; tftp 20410000 root.cramfs; bootm 20008000
bootcmd=run flashit

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

 

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

 

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

 

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

setenv bootargs root=/dev/ram rw initrd=0x21100000,60000000 ramdisk_size=15360 console=ttyS0,115200 mem=32M

ЗЫ2:

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

Uboot> tftp 20800000 uImage
...
Uboot> tftp 20410000 root.cramfs
...
Uboot> bootm 20800000 ## Booting image at 20800000 ...
  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 ...<прим:ПОВИС>

[RRRR 0]

ЗЫ2:

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

Uboot> tftp 20800000 uImage
...
Uboot> tftp 20410000 root.cramfs
...
Uboot> bootm 20800000 ## Booting image at 20800000 ...
  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 ...<прим:ПОВИС>

<{POST_SNAPBACK}>

 

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

 

Может у Вас просто память (SDRAM) шалит?

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

 

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

[vvj 0]

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

## 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.

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

Короче этот mkimage клепает разные образы с одного и того же исходника!

[RRRR 0]

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

<{POST_SNAPBACK}>

 

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

[vvj 0]

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

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

 

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

[Hercules 0]

А можно глупый вопрос?

Судя по:

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

<{POST_SNAPBACK}>

и

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

<{POST_SNAPBACK}>

Вы вначале собираете ядро Linux-а версии 2.6.13.3, а затем при помощи mkimage получаете готовый имидж для u-Boot-а.

А почему Вы сразу при сборке ядра не получаете готовый имидж для u-Boot-а? Это можно сделать так:

make uImage

В ядре 2.4 такой возможности не было и действительно приходилось вначале собирать ядро, а затем самому получать имидж для u-Boot-а, а в ядре 2.6 уже есть (ядро 2.5 я не собирал, поэтому не знаю можно там сразу получить uImage или нет).

[Hercules 0]

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

 

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

[vvj 0]

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

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

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

Так ведь тёмный я, не в въехал пока как ему при этом параметры "-e 20008000" и "-a 20008000" передавать.

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

[d__ 0]

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

[Dimchansky 0]

Я использую U-Boot (http://u-boot.sourceforge.net/). Его же пользуют и атмеловцы. Есть и другие лоадеры, но мне и с этим нормально. Адрес рамдиска передается через параметр ядра. В У-Буте есть mkimage, который делает из имиджа ядра то, что потребно лоадеру.

 

По-поводу загрузки есть в кернеле: linux/Documentation/arm/Booting

 

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