Ausführen von Linux 4.9 auf Cortex-M4 STM32F4 (29I-DISC1)

Question

Ich verbringe ein paar Tage versuchen zu verstehen, aber ich stecke fest. Ich bekomme nicht mehr als eine "Start Kernel ..." Meldung nach Eingabe von 'bootm 8100000' auf meiner STM32F429I-DISC1 Karte.

Bevor ich upboot von 2011 bis 2016 update Es war ein "Starting Kernel ..." + UNHANDED EXCEPTION HARDFAULT, aber jetzt habe ich nur die Meldung "Starting Kernel ...".

MCU ist ein stm32F429, 2MB Flash + ext. 8 MB RAM.

Flash-Start Adr ist 0x08000000 (uboot adr) und ich legte meinen Kernel auf dem Beginn der zweiten Flash-Bank bei 0x08100000.

Start Externe 8MB RAM ist 0xD0000000

u-boot-2016,11 ziemlich gut auf dieser Platine zu laufen scheint, bdi mir geben:

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 

Dies ist, wie ich den Kernel bauen:

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

Und das ist die vollständige Ausgabe von bootm Befehl:

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

Mit den ‚robutest‘/‚emcraft‘ kernel/Configakten bekam ich das gleiche Protokoll, es sei denn, der Entry Point richtiger scheint, weil es 08100001.

Auf der robutest/emcraft Kernel Ich habe versucht, das aktivieren LCD-Bildschirm des Boards, aber nichts passiert.

In meinem ganzen Test aktiviere ich die Kernel-Konfiguration "early printk" und "DEBUG_LL_xxx".

Dies ist ein Link zu meiner CONFIG-Datei: http://pastebin.com/gBNYx3Gs

PS: Ich habe einige versuchen, mit uCLinux emcraft/robutest zu finden, um zu versuchen, was los ist, aber mein Hauptziel ist es Linux 4.9 zu laufen.

Danke fürs Lesen !!!

EDIT: Ich habe versucht, die dtb "auf die alte Weise" passieren, aber mit dem gleichen Ergebnis:

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

Ich bin verzweifelt, alle Ideen sind willkommen: '(

EDIT2: I versucht, den Kernel mit u-boot zu dekomprimieren, ist es das gleiche:

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: ich habe den Speicher/USART1 Adresse im dtb geprüft, und es ist in Ordnung, warum ich keine Nachricht des Kernels haben

01.235.164.?

Edit4: Mit 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 ... 

ich mit unterschiedlichen Einstiegspunkten versucht, 08060000, 08060040 und 08060041.

Answer 1

ich gefunden habe!

Dank Alexander, der Trick für die UART funktioniert wie ein Charme! Dank dir, das erste Mal versuche ich den Kernel in einem Embedded System zu hacken und ich habe so viele Dinge dank dir gelernt.

Für diejenigen, die dieses Problem haben, war es für mich das XIP_PHYS_ADDR! Vergessen Sie nicht die 64 Bytes Header !!

Ich blinkte den XIP-Kernel @ 0x08060000 so das XIP_PHYS_ADDR (und der Boot-Eintrag BTW) ist es 0x08060040 !!!!

Danke nochmal Alexander !!

Answer 2

Ich hatte das gleiche Problem, aber der Grund war ein anderer. Das Problem war in eines der u-boot structure field, die die size des uncompressed linux kernel. Die u-boot speichern, wird dieses Feld nicht mit der unkomprimierten Größe bevölkert, dass die linux kernel verwendet später seine stack, um die Größe, damit das System in einen undefinierten Zustand versetzt.

Sobald u-boot druckt die Starting kernel... Nachricht, sollte die nächste Nachricht Uncompressing Linux... done, booting the kernel sein, nachdem u-boot ein SMM Handler überträgt für die Kernel Übernahme der Ausführung, und vielleicht die kernel ist für dieses Feld suchen. Wenn Sie auf einem x86 basiertes System arbeiten, würde die Dekomprimierung in den folgenden Dateiverzeichnissen sein:

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

Die Lösung ist hier das neueste u-boot foun zu verwenden: https://github.com/andy-shev/u-boot

Wenn Sie jedoch Verwenden Sie einen benutzerdefinierten U-Boot, müssen Sie nach diesem Feld suchen.