2016-12-25 3 views
4

Я провожу несколько дней, пытаясь понять, но я застрял. Я получаю сообщение «Начиная ядро ​​...» после ввода «bootm 8100000» на моей плате STM32F429I-DISC1.Запуск Linux 4.9 на Cortex-M4 STM32F4 (29I-DISC1)

Перед тем, как обновить uboot с 2011 по 2016 год, это было «Начальное ядро ​​...» + НЕПРАВИЛЬНОЕ ИСКЛЮЧЕНИЕ HARDFAULT, но теперь у меня есть только сообщение «Starting Kernel ...».

MCU - это stm32F429, 2MB Flash + ext. 8 МБ оперативной памяти.

флэш-старт адр является 0x08000000 (UBoot адр), и я кладу ядро ​​на начало 2-го флэш-банка на 0x08100000.

Начало внешних 8MB RAM является 0xD0000000

U-Boot-2016,11, кажется, бежит очень хорошо на этой доске, BDI дать мне:

U-Boot > bdi 
arch_number = 0x00000000 
boot_params = 0xD0000100 
DRAM bank = 0x00000000 
-> start = 0xD0000000 
-> size  = 0x00800000 
current eth = unknown 
ip_addr  = <NULL> 
baudrate = 115200 bps 
relocaddr = 0xD07D6000 
reloc off = 0xC87D6000 
irq_sp  = 0xD05D3EE0 
sp start = 0xD05D3ED0 
Early malloc usage: e0/400 

Это, как я построить ядро:

make CROSS_COMPILE=arm-none-eabi- ARCH=arm uImage LOADADDR=08100000 -B 

И это полный вывод команды bootm:

U-Boot > bootm 8100000 
## Booting kernel from Legacy Image at 08100000 ... 
    Image Name: Linux-4.9.0 
    Image Type: ARM Linux Kernel Image (uncompressed) 
    Data Size: 839872 Bytes = 820.2 KiB 
    Load Address: 08100000 
    Entry Point: 08100000 
    Verifying Checksum ... OK 
    Loading Kernel Image ... OK 

Starting kernel ... 

С «robutest» конфигурационные файлы/«emcraft» ядра/я получил тот же журнал, если точка входа не кажется более правильным, потому что это 08100001.

На robutest ядро ​​/ emcraft Я попытался активировать ЖК-экран платы, но ничего не происходит.

Во всем моем тесте я активирую конфигурацию ядра «ранний printk» и «DEBUG_LL_xxx».

Это ссылка на мой файл .config: http://pastebin.com/gBNYx3Gs

PS: Я сделал некоторые пытаются с uCLinux emcraft/robutest, чтобы попытаться найти то, что происходит, но моя главная цель состоит в том, чтобы запустить Linux 4.9.

Спасибо, что прочитал меня !!!

EDIT: Я пытался передать DTB "по-старому", но с тем же результатом:

U-Boot > bootm 08100000 - 08040000                    
## Booting kernel from Legacy Image at 08100000 ...               
    Image Name: Linux-4.9.0                     
    Image Type: ARM Linux Kernel Image (uncompressed)               
    Data Size: 805744 Bytes = 786.9 KiB                  
    Load Address: 08100000                      
    Entry Point: 08100000                      
    Verifying Checksum ... OK                     
## Flattened Device Tree blob at 08040000                  
    Booting using the fdt blob at 0x8040000                  
    Loading Kernel Image ... OK                     
    Loading Device Tree to d05ce000, end d05d2a9f ... OK              

Starting kernel ...                       

Я отчаянно, любые идеи можно только приветствовать: '(

EDIT2: Я пытался распаковывать ядро ​​с U-Boot, это то же самое:

U-Boot > bootm 8100000 - 8040000 
## Booting kernel from Legacy Image at 08100000 ... 
    Image Name: uImage 
    Image Type: ARM Linux Kernel Image (gzip compressed) 
    Data Size: 940696 Bytes = 918.6 KiB 
    Load Address: d0008000 
    Entry Point: d0008001 
    Verifying Checksum ... OK 
## Flattened Device Tree blob at 08040000 
    Booting using the fdt blob at 0x8040000 
    Uncompressing Kernel Image ... OK 
    Loading Device Tree to d05ce000, end d05d2a9f ... OK 

Starting kernel ... 

EDIT3: Я проверил память/USART1 адрес в DTB, и это нормально, почему у меня нет никакого сообщения ядра

.?

EDIT4: С uxipImage:

U-Boot > bootm 08060000 - 08040000 
## Booting kernel from Legacy Image at 08060000 ... 
    Image Name: uxipImage 
    Image Type: ARM Linux Kernel Image (uncompressed) 
    Data Size: 1497396 Bytes = 1.4 MiB 
    Load Address: 08060000 
    Entry Point: 08060041 
    Verifying Checksum ... OK 
## Flattened Device Tree blob at 08040000 
    Booting using the fdt blob at 0x8040000 
    Loading Kernel Image ... OK 
    Loading Device Tree to d05ce000, end d05d2a9f ... OK 

Starting kernel ... 

Я попытался с различными точками входа, 08060000, 08060040 и 08060041.

+1

Stack Overflow - это сайт для вопросов программирования и разработки. Этот вопрос кажется вне темы, потому что речь идет не о программировании или разработке. См. [Какие темы можно задать здесь] (http://stackoverflow.com/help/on-topic) в Справочном центре. Возможно, лучше сказать [Суперпользователь] (http://superuser.com/) или [Unix & Linux Stack Exchange] (http://unix.stackexchange.com/). Также см. [Где я пишу вопросы о Dev Ops?] (Http://meta.stackexchange.com/q/134306) – jww

+1

@jww Мы говорим о программном обеспечении, даже если это для встроенного устройства. Можете ли вы рассказать мне, как установить выходной UART? Я, хотя это соединение было выполнено с помощью dtb. – user2629409

ответ

3

я нашел!

Спасибо alexander, трюк для UART WORKS, как шарм !!!! Благодаря вам, в первый раз я пытаюсь взломать ядро ​​во встроенной системе, и благодаря этому я узнал так много всего.

Для тех, у кого будет эта проблема, для меня это был XIP_PHYS_ADDR! Не забывайте заголовок 64 байта!

Я прошивал ядро ​​XIP @ 0x08060000, так что XIP_PHYS_ADDR (и загрузочная запись) это 0x08060040 !!!!

Еще раз спасибо alexander !!

+1

BTW Я не знаю, почему «нормальное» ядро ​​распаковываю в оперативную память и их загрузка не работает ..... но я увижу, что позже у меня теперь больше оперативной памяти :) Потери, вызванные XIP это около 500ko ROM, заставьте меня сохранить 2MO ОЗУ. Мне не нужно много оперативной памяти, но мы никогда не знаем, и сейчас это работает :) – user2629409

+2

Рад видеть, вы сделали это! Удачи вам в взломе! – alexander

+1

Есть ли у вас какие-либо знания о ramdisk VFS? : P http://unix.stackexchange.com/questions/333037/uclinux-linux-4-9-nommu-vfs-cannot-open-root-device-null – user2629409

1

У меня была такая же проблема, но причина была другая. Проблема была в одном из u-boot structure field, который хранит sizeuncompressed linux kernel.. u-boot не заполняет это поле несжатым размером, который linux kernel использует позже, чтобы изменить размер его stack, тем самым переведя систему в неопределенное состояние.

После u-boot печатает Starting kernel... сообщения, следующее сообщение должно быть Uncompressing Linux... done, booting the kernel после U-Boot передает SMM Handler для ядра приемки исполнения, и, возможно, kernel ищет для этого поля. Если вы работаете на системе x86 основы, то распаковка будет в следующих каталогах файлов:

arch/x86/boot/uncompressed/head_32.S 
arch/x86/boot/uncompressed/piggy.S 

Решения использовать последнюю U-Boot foun здесь: https://github.com/andy-shev/u-boot

Однако, если вы используют пользовательский u-boot, вам нужно искать это поле.

+0

Спасибо за добавление, может помочь кому-то :) – user2629409

Смежные вопросы