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

Question

I spend a few days trying to understand but I'm stuck. I get no more than a "Starting kernel..." message after entering 'bootm 8100000' on my STM32F429I-DISC1 board.

Before I update uboot from 2011 to 2016 It was a "Starting Kernel..." + UNHANDED EXCEPTION HARDFAULT, but now I have just the "Starting Kernel..." message.

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

Flash start addr is 0x08000000 (uboot addr) and I put my kernel on the start of the 2nd flash bank at 0x08100000.

Start of External 8MB RAM is 0xD0000000

u-boot-2016.11 seems to run pretty well on that 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 build the kernel:

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

And this is the complete output of 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 ...

With the 'robutest'/'emcraft' kernel/config files I got the same log, unless the Entry Point seems more correct because it's 08100001.

On the robutest/emcraft kernel I tried to activate the LCD screen of the board, but nothing happen.

In all my test I activate kernel config "early printk" and "DEBUG_LL_xxx" stuff.

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

PS: I made some try with uCLinux emcraft/robutest to try to find what's going on, but my main goal is to run Linux 4.9.

Thanks for reading me!!!

EDIT: I tried to pass the dtb "the old way", 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'm desperate, any ideas is welcome :'(

EDIT2: I tried to uncompress the kernel with u-boot, it's 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/USART1 address in the dtb, and it's ok. Why I have no message of the kernel?

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.

Vories

Stack Overflow is a site for programming and development questions. This question appears to be off-topic because it is not about programming or development. See What topics can I ask about here in the Help Center. Perhaps Super User or Unix & Linux Stack Exchange would be a better place to ask. Also see Where do I post questions about Dev Ops? – Kiruna

@Kiruna We are talking about software dev., even if it's for embedded device. Can you tell me how can I set the output UART ? I though this connection was done by the dtb. – Vories

Answer 1

I found!

Thanks alexander, the trick for the UART WORKS like a charm!!!! Thanks to you, First time I try to hack the kernel in an embedded system and I've learnt so many things thanks to you.

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

I was flashing the XIP kernel @ 0x08060000 so the XIP_PHYS_ADDR (and the boot entry btw) it's 0x08060040!!!!

Thank you again alexander !!

Vories

BTW I don't know why the "normal" kernel I decompress into RAM and them boot don't works..... but I'll see that later, I have more RAM now :) The loss due to the XIP it's about 500ko of ROM, make me save 2Mo of RAM. I don't really need a lot of RAM, but we never know and it's works now :) – Vories

Glad to see, you did it! Good luck with hacking! – Zoubek

Do you have any knowledge on VFS ramdisk? :P unix.stackexchange.com/questions/333037/… – Vories

Answer 2

I have had faced the same issue but the reason was a different one. The issue was in one of the u-boot structure field that stores the size of the uncompressed linux kernel. The u-boot is not populating this field with the uncompressed size, that the linux kernel uses later to resize its stack, thus putting the system into an undefined state.

Once u-boot prints the Starting kernel... message, the next message should be Uncompressing Linux... done, booting the kernel after u-boot transfers a SMM Handler for the kernel to take-over the execution, and maybe the kernel is looking for this field. If you are working on a x86 based system,the uncompression would 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 in here: https://github.com/andy-shev/u-boot

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

Mountie

Thanks for the add, could help someone :) – Vories