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