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 <[email protected]> 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 > [email protected] > https://lists.denx.de/listinfo/u-boot > -- *M*axim *S*loyko _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
