[U-Boot] STM32F429 u-boot
Hi all,
I am bringing up u-boot on a new custom board with STM32F429 cpu. To start, I modified the stm32f429 discovery board files by adding the proper gpio, size and address for the external DRAM, also the dram timings and USART gpio pins used I use the "bare" gcc 5.4 toolchain from ARM from https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads
I am able to load u-boot in flash with openocd, and I am able to debug with a jtag adapter and gdb. I am able to step through the initial functions of u-boot, set breakpoints and examine memory. Until I hit strange things.
I can step into arch_cpu_init () at arch/arm/mach-stm32/stm32f4/soc.c, then into configure_clocks () at arch/arm/mach-stm32/stm32f4/clock.c . At that point, the clocks are setup by writing a few registers, and as soon as I leave this function, instead of returning to arch_cpu_init() I end up in mAlloc() in dlmalloc.c .
Anybody has some clue about what could be going on ? Any hint or suggestion on how to figure this out would be welcome.
Cheers,
Bruno
Anyway I can ask this on the list ? My message is still awaiting moderation or fell in the spam folder...
Hi all,
I am bringing up u-boot on a new custom board with STM32F429 cpu. To
start, I modified the stm32f429 discovery board files by adding the proper gpio, size and address for the external DRAM, also the dram timings and USART gpio pins used
I use the "bare" gcc 5.4 toolchain from ARM from
https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads
I am able to load u-boot in flash with openocd, and I am able to debug
with a jtag adapter and gdb. I am able to step through the initial functions of u-boot, set breakpoints and examine memory. Until I hit strange things.
I can step into arch_cpu_init () at arch/arm/mach-stm32/stm32f4/soc.c,
then into configure_clocks () at arch/arm/mach-stm32/stm32f4/clock.c . At that point, the clocks are setup by writing a few registers, and as soon as I leave this function, instead of returning to arch_cpu_init() I end up in mAlloc() in dlmalloc.c .
Anybody has some clue about what could be going on ? Any hint or
suggestion on how to figure this out would be welcome.
Cheers,
Bruno
Hi Bruno,
Your email did reach the mailing list, it's just looks like, unfortunately, nobody can help you with this at the moment.
Try Cc'ing or directly emailing somebody who works on U-Boot for STM32 SoCs, I definitely saw some patches recently.
On Sun, Mar 5, 2017 at 11:21 PM, bruno schwander bruno.schwander@gmail.com wrote:
Anyway I can ask this on the list ? My message is still awaiting moderation or fell in the spam folder...
Hi all,
I am bringing up u-boot on a new custom board with STM32F429 cpu. To
start, I modified the stm32f429 discovery board files by adding the proper gpio, size and address for the external DRAM, also the dram timings and USART gpio pins used
I use the "bare" gcc 5.4 toolchain from ARM from
https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads
I am able to load u-boot in flash with openocd, and I am able to debug
with a jtag adapter and gdb. I am able to step through the initial functions of u-boot, set breakpoints and examine memory. Until I hit strange things.
I can step into arch_cpu_init () at arch/arm/mach-stm32/stm32f4/soc.c,
then into configure_clocks () at arch/arm/mach-stm32/stm32f4/clock.c . At that point, the clocks are setup by writing a few registers, and as soon as I leave this function, instead of returning to arch_cpu_init() I end up in mAlloc() in dlmalloc.c .
Anybody has some clue about what could be going on ? Any hint or
suggestion on how to figure this out would be welcome.
Cheers,
Bruno
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
participants (2)
-
bruno schwander -
Maxim Sloyko