public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Wolfgang Wegner <wolfgang@leila.ping.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] still weird problems (linker/debug?) on MCF5445x
Date: Tue, 2 Mar 2010 17:05:13 +0100	[thread overview]
Message-ID: <20100302160513.GF23389@leila.ping.de> (raw)

Hi list,

I had some strange problems in the beginning resulting from bad memory
setup. I fixed the memory setup and now have a linux kernel running
including the user space on top of U-Boot [so would think that the memory
setup should really be OK now], but still have some very weird problems
in U-Boot.
As I really have no clue what might be going wrong I am here again to
ask if anybody has a hint for me.

The behaviour:
When adding code to some functions, the function and sometimes even
completely unrelated other parts of U-Boot fail. The "failure" is a
simple lockup, as I could not yet debug it further. Most of the times
I can "cure" this by adding some code (printf, writing to HW register, ...)
to the failing function - if I figure out which function fails...
(e.g. when adding code to my misc_init_r I had to add some printf()
at the beginning of console_setfile to make U-Boot get past console_setfile
at all.)

While trying to debug this I am running into a somewhat strange
problem with the symbol table relocation for debugging. I added a
printf to board_init_r like this:
	printf("gd->reloc_off: 0x%08x\n", gd->reloc_off);
giving me:
	gd->reloc_off: 0x07d84000
my TEXT_BASE is 0x40020000, so I set this in my .gdbinit:
	define ram
        	symbol-file
        	add-symbol-file u-boot 0x47da4000
	end

Now in the debugger I do:
	(gdb) ram
	add symbol table from file "u-boot" at
        	.text_addr = 0x47da4000
	(gdb) b board_init_r
	Breakpoint 1 at 0x47da4672: file board.c, line 422.

but the breakpoint is never reached. I tried printing the function
pointer from the code:
	printf("%s@%p\n", __FUNCTION__, &board_init_r);
resulting in:
	board_init_r at 47da466e
The disassembly shows:
	4002066e <board_init_r>:
	4002066e:       4e56 ffc0       linkw %fp,#-64
	40020672:       202d 0014       movel %a5@(20),%d0
	40020676:       48d7 3c3c       moveml %d2-%d5/%a2-%a5,%sp@

and in the debugger I can see:
	(gdb) print /x *0x47da466e
	$1 = 0x4e56ffc0

Can anybody give a hint what I might be doing wrong in debugging (I seem
to remember I already could debug after relocation, and really do not
know I would have changed anything except the symbol table offfset in
between), and what could cause such strange behaviour from U-Boot when
changing the code?

Regards,
Wolfgang

             reply	other threads:[~2010-03-02 16:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-02 16:05 Wolfgang Wegner [this message]
2010-03-02 16:30 ` [U-Boot] still weird problems (linker/debug?) on MCF5445x Wolfgang Denk
2010-03-02 16:42   ` Wolfgang Wegner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100302160513.GF23389@leila.ping.de \
    --to=wolfgang@leila.ping.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox