(Sorry forgot the ML on CC - resend) Hi Graeme, 2011/6/14 Graeme Russ <graeme.r...@gmail.com>: > Hi Simon, > > On 14/06/11 18:52, Simon Schwarz wrote: >> Hi List, >> >> as some may know I'am working on an SPL for the devkit8000. >> Now I have a problem with the UART init where I hope someone on the >> list can help. > > Are you working with a latest version of U-Boot? Do you have additional > modifications not yet posted/committed?
I based my modifications on commit 5d1ee00b1fe1180503f6dfc10e87a6c6e74778f3. Its about a month old. I have some modifications - as it is a SPL it's mainly the Makefile which is pulling all the parts from the main u-boot together. I also modified the SDRC but this code isn't executed at the stage where the problem happens. I adapted also some code from http://patchwork.ozlabs.org/patch/95641/ (Mostly this was: void preloader_console_init(void)). > >> >> My problem is in drivers/serial/serial.c with the function >> calc_divisor. With my defines this function is essentially just this: >> return (CONFIG_SYS_NS16550_CLK + (gd->baudrate * (MODE_X_DIV / 2))) / >> (MODE_X_DIV * gd->baudrate); >> >> (Where MODE_X_DIV=16) >> >> If i try to execute this line (with the step instruction of >> gdb/openOCD) the debugger just does not return and I have to use >> Strg+c to get a prompt. > > Have you tried returning a hard-coded value? yep, a hard-coded value works. It then has the same problem at: serial_out(CONFIG_SYS_NS16550_IER, &com_port->ier); (drivers/serial/ns16550.c:33) > >> >> Then the PC is 0x4020ffd4 (upper region of SRAM) and the CPSR is 0x600001d7 >> >> I think I have some problem with the division/multiplication functions >> as there is nothing else in this line which may cause trouble (returns >> and function calls worked before). > > The problem may actually be related to gd access. I have had a heap (no pun > intended) of trouble getting gd access right in the past. Is this the first > access to gd? It's the first (read-)access to gd but... > >> >> U-boot is running in SRAM no SDRAM init yet. > > If this is indeed the first access to gd, you need to look at the location > of gd in SRAM and make sure it not being clobbered ... I already did this and gd seems to be ok - I can't see any problems with gdb. > >> >> Has someone an idea where I can start looking? Maybe a known pitfall >> for beginners? More information needed? > > Try adding another temporary variable to gd (ulong temp for example) and in > calc_divisor do: > > ulong temp = gd->temp; > gd->temp = 1; > > and step through I will try that. > > I'm sure that if I am wrong, somebody else here will be of further assistance > > Regards, > > Graeme > Thank you Graeme! I have some starting points now - but i don't think the problem is with gd (was also my first suggestion here). Regards Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
