Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Линукс на ARM'e
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > GNU/OpenSource средства разработки
romez777
Приветствую,

портирую линукс на arm926 платформу (есть MMU). U-boot уже перенес - железо инициализируется, далее управление передается ядру (находится тут же на NOR флеше), и тут все и заканчивается:

Код
... здесь сообщения от Юбута
=> bootm
*  kernel: default image load address = 0x2c040000
## Booting kernel from Legacy Image at 2c040000 ...
   Image Name:   Linux-2.6.28-rc8
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    889640 Bytes = 868.8 kB
   Load Address: 10008000
   Entry Point:  10008000
   kernel data at 0x2c040040, len = 0x000d9328 (889640)
   Loading Kernel Image ... OK
OK
   kernel loaded at 0x10008000, end = 0x100e1328
## No init Ramdisk
   ramdisk start = 0x00000000, ramdisk end = 0x00000000
## Transferring control to Linux (at address 10008000) ...

Starting kernel ...

Uncompressing Lin........................................................ done, booting t


Именно так и печатает в серийную консоль: "ux" от linux'a кто-то откусил, а вместо "..." печатает кучу точек. Расследования дебагером показали, что падение происходит где-то в недрах $(linux)/arch/arm/kernel/head.S, предположительно в коде включения MMU:

Код
__turn_mmu_on:
    mov    r0, r0
    mcr    p15, 0, r0, c1, c0, 0        @ write control reg
    mrc    p15, 0, r3, c0, c0, 0        @ read id reg
    mov    r3, r3
    mov    r3, r3
    mov    pc, r13
ENDPROC(__turn_mmu_on)


Есть ли какие-то предположения, что стоит проверить?

Попутно такие вопросы:
1) обязательно ли бутлоадеру выполнять ремап перед передачей управления ядру?
2) сейчас просто пытаюсь грузить и отладить ядро, без RAM-диска. Это нормально, не может же от отсутствия ram-диска ядро падать в самом начале?

Буду признателен за советы!
amw
Цитата(romez777 @ Jan 12 2009, 13:50) *
Приветствую,

портирую линукс на arm926 платформу (есть MMU). U-boot уже перенес - железо инициализируется, далее управление передается ядру (находится тут же на NOR флеше), и тут все и заканчивается:

Код
... здесь сообщения от Юбута
=> bootm
*  kernel: default image load address = 0x2c040000
## Booting kernel from Legacy Image at 2c040000 ...
   Image Name:   Linux-2.6.28-rc8
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    889640 Bytes = 868.8 kB
   Load Address: 10008000
   Entry Point:  10008000
   kernel data at 0x2c040040, len = 0x000d9328 (889640)
   Loading Kernel Image ... OK
OK
   kernel loaded at 0x10008000, end = 0x100e1328
## No init Ramdisk
   ramdisk start = 0x00000000, ramdisk end = 0x00000000
## Transferring control to Linux (at address 10008000) ...

Starting kernel ...

Uncompressing Lin........................................................ done, booting t


Именно так и печатает в серийную консоль: "ux" от linux'a кто-то откусил, а вместо "..." печатает кучу точек. Расследования дебагером показали, что падение происходит где-то в недрах $(linux)/arch/arm/kernel/head.S, предположительно в коде включения MMU:

Код
__turn_mmu_on:
    mov    r0, r0
    mcr    p15, 0, r0, c1, c0, 0        @ write control reg
    mrc    p15, 0, r3, c0, c0, 0        @ read id reg
    mov    r3, r3
    mov    r3, r3
    mov    pc, r13
ENDPROC(__turn_mmu_on)


Есть ли какие-то предположения, что стоит проверить?

Попутно такие вопросы:
1) обязательно ли бутлоадеру выполнять ремап перед передачей управления ядру?
2) сейчас просто пытаюсь грузить и отладить ядро, без RAM-диска. Это нормально, не может же от отсутствия ram-диска ядро падать в самом начале?

Буду признателен за советы!

Т.к. это ядро, то пока отметем BE режим. Было такое "откусывание" в libc из-за того что многие функции (strlen и т.п) написаны были на ассемблере, и было типа так
Код
#ifdef ARM_EL
blah
blah
blah
#else
// TODO: Big Endian
#endif

А само копирование шло пословно (4 байта) и последние, невыровненные, пропадали из-зи неправильного анализа (не с того конца искались байты в слове).
Но возьмите на заметку.

Точек и должно быть много. Это типа проценты выполнения (протгресс бар, так сказать).
Откусывание может быть связано переполнением буффера или (скорее всего) несоответствия скоростей.

Какая версия ядра? 2.6.х? Если да, то консоль, по идее должна быть на initramfs. Не важно, что Вы ее не используете в явном виде, она всегда есть и консоль там должна быть. Дело в том, что после этого сообщения производится (в том числе) собственно настройка консоли в ядре. Строчка Uncompressing Linux .......... done. Booting the kernel. выводится в порт старыми настройками (оставшимися от u-boot).
Посмотрите в конфиге ядра чему равно CONFIG_CMDLINE и добавьте что-то типа
Код
CONFIG_CMDLINE="<что-тут-у-вас-было>console=ttyS0,115200n8"

Возможно консоль не на том порту. Разумеется, я тут предполагаю, что консоль на последовательном порту.

Из-за отсутствия RAM диска падать будет в самом конце типа так
VFS: not synching: Unable to mount rootfs

Ремап должен делаться u-boot. Возможно ошибаюсь.
romez777
Приветствую,

Цитата
Точек и должно быть много. Это типа проценты выполнения (протгресс бар, так сказать).

Если заглянуть в $(linux)/arch/arm/boot/compressed/misc.c, функция decompress_kernel, которая вызывается из $(linux)/arch/arm/boot/compressed/head.S, то точек должно быть три. Там дальше вызывается gunzip(), но в этой ф-ции ничего не печатается.

Ядро 2.6.28 из поставки тулкита ELDK-4.1 (www.denx.de). Консоль на последовательном поорту, CONFIG_CMDLINE="root=/dev/ram mem=16M console=ttyS0,115200n8"

Цитата
Строчка Uncompressing Linux .......... done. Booting the kernel. выводится в порт старыми настройками (оставшимися от u-boot).

т.е. несмотрят на то, что u-boot выставляет скорость и клок последовательного порта в регистры, линукс сделает это еще раз? Если да, то на каком этапе, и в каких файлах нужно прописать нужные значения? Предполагаю, что где-то в $(linux)/arch/arm/mach-<platform>/clock.[ch] ?
amw
Цитата(romez777 @ Jan 13 2009, 03:54) *
Приветствую,

Если заглянуть в $(linux)/arch/arm/boot/compressed/misc.c, функция decompress_kernel, которая вызывается из $(linux)/arch/arm/boot/compressed/head.S, то точек должно быть три. Там дальше вызывается gunzip(), но в этой ф-ции ничего не печатается.

Печатает.
Только не помню точно из какой функции. При большом образе, точки не влазят в одну строку.
Цитата
т.е. несмотрят на то, что u-boot выставляет скорость и клок последовательного порта в регистры, линукс сделает это еще раз? Если да, то на каком этапе, и в каких файлах нужно прописать нужные значения? Предполагаю, что где-то в $(linux)/arch/arm/mach-<platform>/clock.[ch] ?

Да. Возможно не совпадает частотат кварца. Возможно какие-то делители не правильно считаются.
Не знаю как в Вашем случае. В моем - плата на основе AT91SAM9260. Впаян кварц на 12МГц, а в ядре установлен 18.432МГц. Настройка (в моем случае) начинается с файла
linux/arch/arm/mach-at91/board-sam9260ek.c
Функция
static void __init ek_map_io(void)
Некоторые подробности можно найти в файле
linux/arch/arm/mach-at91/at91sam9260.c
Там указаны источники тактирования для периферии.

К сожалению, не могу сказать где файлы для Вашего процессора.

Ваше предположение о том, что "падение" происходит при настройке MMU мне кажется правильным. Сравните код в u-boot по этому поводу и в ядре. Возможно, задаются разные режимы. Возможно неправильно инициализируется таблица страниц.
К сожалению (или к счастью smile.gif ) я с такими случаями не сталкивался. Конкретно ничего посоветовать не могу.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.