kexec 2.0.2 MIPS
Maxim Uvarov
muvarov at gmail.com
Wed Jan 25 01:35:42 EST 2012
2012/1/24 Simon Horman <horms at verge.net.au>:
> Hi,
>
> sorry for the extensive delay in responding to this.
> I am now back from Christmas, New Year, holidays and
> attending LCA 2012.
>
> On Fri, Dec 16, 2011 at 05:27:31AM +0000, ANDY KENNEDY wrote:
>> Simon/All,
>>
>> After two months, I'm back working on this again. After 3 hours
>> tonight, I have the final result of what you told me to do. Looks like,
>> based on the comment:
>>
>> - remove kexec/arch/mips/mips-setup-simple.S which prepares cmdline for
>> new kernel, it is better to move this work to kernel code. BTW this code was
>> compilable only on o32 because of t4 is not defined on 64-64 or n32 MIPS ABIs.
>>
>> The problem is that my 2.6.36.2 apparently doesn't have whatever Maxim
>> is talking about. Therefore, the newer versions must not be backwards
>> compatible. Perhaps this is okay with you guys. If so, I'll just make
>> sure to include a patch to BuildRoot that clearly states that the v2.0.1
>> is the only version that works with *some* versions of MIPS. If you
>> guys were expecting this to be backwards compatible, I'll gladly work
>> with you to test whatever you need checked out. Just let me know.
>
> It is not apparent to me that the kernel code Maxim makes mention of
> exists in any released kernel. I think that the best option at this
> stage would be to revert that portion of his change.
>
> Maxim, do you have any thoughts on this?
>
Yes, kernel patches were not accepted and looks like stuck linux-mips@
queue forever.
Reverting this patches it ok for me especially if somebody going to
work on them. As I remember
the was problem with supporting all mips ABIs (o32, n32, 32-64). It's
mostly related to asm purgatory
code. It will be nice if somebody can synchronize kernel and user land
parts and make mips kexec code
board independent. I think at this time it should be much easy since
mips supports device tree.
Maxim.
> Andy, could you prepare a patch to do that?
> At the very least it ought to be useful to you.
>
>> There are build errors that I would like (if it hasn't already) to
>> be fixed
>> 1) in purgatory/Makefile, Near line 71
>>
>> $(PURGATORY): LDFLAGS=$($(ARCH)_PURGATORY_EXTRA_CFLAGS)\
>> --no-undefined -nostartfiles -nostdlib -nodefaultlibs \
>> -e purgatory_start -r
>>
>>
>> The newer gcc's don't like --no-undefined. I think a fix is
>> -Wl,--no-undefined.
>
> Thanks, there is a fix for that in git and 2.0.3.
>
>> 2) In the newer version of the kexec/arch/mips/Makefile, there is
>> a -Werror in the CFLAGS. This causes the build to fail if using a
>> newer version of gcc, as many more warnings are available.
>
> Thanks, there is a fix for that in git and 2.0.3.
>
> Due to some quirks in the kexec build system
> -Werror was effecting all architectures.
>
>> Now, here is the result of the bisect:
>>
>> root at akennedy_lin:~/src/kexec/kexec-tools# git bisect good
>> 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17 is the first bad commit
>> commit 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17
>> Author: Maxim Uvarov <muvarov at gmail.com>
>> Date: Wed Mar 3 14:05:53 2010 +0300
>>
>> some kexec MIPS improvements
>>
>> - using simple mips* ) in configure.ac to make it compilable on mips2
>> and mips64
>> - remove kexec/arch/mips/mips-setup-simple.S which prepares cmdline for
>> new kernel, it is better to move this work to kernel code. BTW this code was
>> compilable only on o32 because of t4 is not defined on 64-64 or n32 MIPS ABIs.
>> - simple put cmdline as string, kernel code should catch cmdline like this
>>
>> int board_kexec_prepare(struct kimage *image)
>> {
>> int i;
>> char *bootloader = "kexec";
>> board_boot_desc_ptr->argc = 0;
>> for(i=0;i<image->nr_segments;i++)
>> {
>> printk("segment %d
>> if (!strncmp(bootloader, (char*)image->segment[i].buf,
>> strlen(bootloader)))
>> {
>> /*
>> * convert command line string to array
>> * of parameters (as bootloader does).
>> */
>> int argc = 0, offt;
>> char *str = (char *)image->segment[i].buf;
>> char *ptr = strchr(str, ' ');
>> while (ptr && (ARGV_MAX_ARGS > argc)) {
>> *ptr = '\0';
>> if (ptr[1] != ' ') {
>> offt = (int)(ptr - str + 1);
>> boot_desc_ptr->argv[argc] =
>> image->segment[i].mem + offt;
>> argc++;
>> }
>> ptr = strchr(ptr + 1, ' ');
>> }
>> boot_desc_ptr->argc = argc;
>> break;
>> }
>> }
>> Keep it as string make code simple and more readable.
>>
>> - add crashdump support
>> - do not redefine syscalls numbers if they defined in system
>> remove fixups for /proc/iomem. If your board provides wrong /proc/iomem please
>> fix kernel, or at least you local version of kexec. No need to support it in
>> main line. At least add option --fake-iomem
>> - some minor fixes
>>
>> Signed-off-by: Maxim Uvarov <muvarov at gmail.com>
>> Signed-off-by: Simon Horman <horms at verge.net.au>
>>
>> :100644 100644 a911f8ad03c5321faeba93069924fa79aceeba9c 88d2e0bb2479ecd956d0ec31c571d2472fef7721 M configure.ac
>> :040000 040000 4dcef15024daa7ccc62bd6983e127cb87f036c5d 69204c980286b2e08308d4a10eb2bf2775d9d962 M kexec
>>
>> Andy
>>
>> > -----Original Message-----
>> > From: ANDY KENNEDY
>> > Sent: Thursday, September 29, 2011 1:07 PM
>> > To: 'Simon Horman'
>> > Cc: kexec at lists.infradead.org; Matt Evans; Maxim Uvarov
>> > Subject: RE: kexec 2.0.2 MIPS
>> >
>> > > My bad, yes the idea is to check between 2.0.1 and 2.0.2.
>> > > I will explain git bisect further down. However, it looking at
>> > the
>> > > logs
>> > > it strikes me that there was only one significant MIPS change
>> > > between
>> > > 2.0.1 and 2.0.2. So that seems like a likely culprit.
>> > >
>> > > Could you try the following?
>> > >
>> > > $ git clone git://github.com/horms/kexec-tools.git
>> > > $ cd kexec-tools
>> > > $ git checkout 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17^
>> >
>> > Works.
>> >
>> > >
>> > > Build and see if it works. If so could you then try?
>> > >
>> > > $ git checkout 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17
>> >
>> > Works.
>> >
>> > >
>> > > Build and see if it works. If it does not then
>> > > revision 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17 starts to smell
>> > > a lot like the cause of the problem you have observed.
>> > >
>> > >
>> > > Git Bisect
>> > > ----------
>> > >
>> > > A git bisection works by doing a binary search over a set of
>> > > commits
>> > > in order to (hopefully) isolate which commit introduces a
>> > > regression.
>> > >
>> > > To this, the git commands are something along these lines:
>> > >
>> > > $ git clone git://github.com/horms/kexec-tools.git
>> > > $ cd kexec-tools
>> > > $ git checkout v2.0.1
>> >
>> > root at akennedy_lin:~/src/kexec/kexec-tools# git checkout v2.0.1
>> > error: pathspec 'v2.0.1' did not match any file(s) known to git.
>> > (yes, I run as root. Have since 1994, so, please no holy wars.)
>> >
>> > >
>> > > Build and confirm that it does work
>> > >
>> > > $ git checkout v2.0.2
>> > >
>> > > Build and confirm that it does not work.
>> > >
>> > > Now we actually start the bisect
>> > >
>> > > $ git bisect start
>> > > $ git bisect bad v2.0.2
>> > > $ git bisect good v2.0.1
>> > >
>> > > Git should now select a revision between v2.0.1 and v2.0.2
>> > > Test it and see if it works or not. If it does run
>> > >
>> > > $ git bisect good
>> > > If not run
>> > >
>> > > $ git bisect bad
>> > >
>> > > Git will now select another revision for you to test...
>> >
>> > I have some time right now to test, so, when you can get
>> > back to me I'll be able to continue.
>>
>> _______________________________________________
>> kexec mailing list
>> kexec at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
>>
--
Best regards,
Maxim Uvarov
More information about the kexec
mailing list