[U-Boot] STM32F429 u-boot

[Maxim Sloyko]

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 at 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 at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>



-- 
*M*axim *S*loyko