Debugging on MIPS.

[ANDY KENNEDY]

I got *I hope* the tip from @ ~midnight US Central time:

git clone git://github.com/horms/kexec-tools.git

My issue (in case you have forgotten -- it has been a few months) is
that since version 2.0.1 (a couple steps after that), I cannot use
kexec on my MIPS core with 2.6.36.1.  I get nothing.  I've done a bit of
poking around and I can make the kernel boot, however, command line
parameters are missing.

Comparing 2.0.1 with the tip and looking at kexec_load (via adding in
printf's just before the syscall), I see that entry = 0x0,
nr_segments = 2, (didn't print the segments), and the flags = 0x0.

Running the same command with the tip, I get:

entry = 0x1042d0, nr_segments = 2, flags = 0x00080000.

Interestingly, my bootloader determines that the entry point of this
kernel is 0x104290, but sets this address as a virtual.  So, following
that lead, just before the syscall:

entry += 0x80000000;

Boom, the kernel boots.  I get a kernel panic, however, since it cannot
find my RFS.

Further annoyances are that I changed the #if 0 to 1 around the
following code:

#if 0
        fprintf(stdout, "kexec_load: entry = %p flags = %lx\n", 
                info.entry, info.kexec_flags);
        print_segments(stdout, &info);
#endif

Which would have given me all sorts of cool stuff.  Problem is that it
will only output:

kexec_load: entry = 0x1042d0 flags = 80000
nr_segments = 2 
segment[0].buf   = 0x2b1a6008 
segment[0].bufsz = 377b5c 
segment[0].mem   = 0x100000 
segment[0].m

Even more curious is that after the call to my_load, I can printf()
exactly 16 chars before we lock hard.

Testing this information a bit further on the system, I see that at the
top of my_load, before the memset, I can printf() about 1500 chars
before the lockup.

Something is probing destructively.  Any ideas where I should look?

Thanks,
Andy