Running Linux 4.9 on the Cortex-M4 STM32F4 (29I-DISC1)

Question

I spend a few days trying to figure it out, but I'm stuck. I received no more than the message "Starting kernel ..." after entering "bootm 8100000" on my STM32F429I-DISC1 board.

Before updating uboot from 2011 to 2016, it was the "Initial kernel ..." + WRONG EXCLUSION of HARDFAULT, but now I only have the message "Starting Kernel ...".

MCU is stm32F429, 2MB Flash + ext. 8 MB of RAM.

Flash start addr 0x08000000 (uboot addr), and I put my kernel at the beginning of the second bank of flash memory at 0x08100000 .

Start of external 8 MB of RAM 0xD0000000

u-boot-2016.11 seems to work very well on this board, bdi give me:

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 

This is how I create the kernel:

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

And this is the full output of the bootm command:

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

Using the "robutest" / "emcraft" kernel / configuration files, I got the same log, if only the entry point seems more correct, because it is 08100001.

In the robutest / emcraft core, I tried to activate the LCD screen of the board, but nothing happens.

Throughout my testing, I will activate the early print and DEBUG_LL_xxx kernel configurations.

This is the link to my .config file: http://pastebin.com/gBNYx3Gs

PS: I tried using uCLinux emcraft / robutest to try to find what is happening, but my main goal is to run Linux 4.9.

Thanks for reading me !!!

EDIT: I tried passing dtb the "old path", but with the same result:

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

I am desperate, any ideas are welcome: '(

EDIT2: I tried unpacking the kernel using u-boot, this is the same:

 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: I checked the memory address / USART 1 in dtb and that is fine. Why don't I have a kernel message?

EDIT4: With 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 ... 

I tried with different entry points, 08060000, 08060040 and 08060041.

Answer 1

I found!

Thank you, Alexander, a trick for UART WORKS, like a charm !!!! Thanks to you, the first time I am trying to crack the kernel in an embedded system, and thanks to this I learned so much.

For those who have this problem, for me it was XIP_PHYS_ADDR! Don't forget the 64 byte header!

I flashed the core of XIP @ 0x08060000, so XIP_PHYS_ADDR (and boot record btw) is 0x08060040 !!!!

Thanks again alexander !!

Answer 2

I ran into the same problem, but the reason was different. The problem was in one of the u-boot structure field , which stores size uncompressed linux kernel. . u-boot does not fill this field with an uncompressed size, which linux kernel uses later to resize the stack , thus putting the system in an undefined state.

As soon as u-boot prints the message Starting kernel... , the next message should be Uncompressing Linux... done, booting the kernel after u-boot transfers the SMM Handler so that the kernel intercepts execution, and possibly kernel looking for this field. If you are working with an x86 based system, then compression will be in the following file directories:

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

The solution is to use the latest u-boot foun here: https://github.com/andy-shev/u-boot

However, if you are using custom u-boot, you need to look for this field.