[U-Boot] OMAP3/devkit8000 division/multiplication function problems

Simon Schwarz simonschwarzcor at googlemail.com
Tue Jun 14 16:08:49 CEST 2011


(Sorry forgot the ML on CC - resend)
Hi Graeme,

2011/6/14 Graeme Russ <graeme.russ at 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


More information about the U-Boot mailing list