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
