RE: kexec 2.0.2 MIPS

RE: kexec 2.0.2 MIPS

[ANDY KENNEDY]

Guys, sorry for the long lines on that last e-mail attempt.
I, unfortunately, have to use LookOut at work.  This is a
better formatted message:

Attempting to make kexec work for Mips32r2.  2.0.1 works, 2.0.2
doesn't.  Looking through the differences of the arch/mips folders
I find that there is a reference to an extern simple_setup_start.
In 2.0.1 this appears to be referencing asm code from the file
simple_setup_start.S, however, in 2.0.2 I cannot find the
referenced location.

Is this the reason that I cannot get a Linux kernel to boot using
2.0.2 using the same command line as the 2.0.1?

Thanks in advance for any help you can provide,
Andy Kennedy

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec 2.0.2 MIPS

[Simon Horman]

On Mon, Sep 19, 2011 at 08:14:21PM +0000, ANDY KENNEDY wrote:
> Guys, sorry for the long lines on that last e-mail attempt.
> I, unfortunately, have to use LookOut at work.  This is a
> better formatted message:
> 
> Attempting to make kexec work for Mips32r2.  2.0.1 works, 2.0.2
> doesn't.  Looking through the differences of the arch/mips folders
> I find that there is a reference to an extern simple_setup_start.
> In 2.0.1 this appears to be referencing asm code from the file
> simple_setup_start.S, however, in 2.0.2 I cannot find the
> referenced location.
> 
> Is this the reason that I cannot get a Linux kernel to boot using
> 2.0.2 using the same command line as the 2.0.1?

Hi Andy,

I'm a little unsure why it is that your platform broke between 2.0.1
and 2.0.2. And I'm even less sure what simple_setup_start is/was
(I don't see it in 2.0.1 or 2.0.2 or the current master branch).

However, I do have a few suggestions.

1. Is it possible for you to try the latest development tree?
   It is available at git://github.com/horms/kexec-tools.git while
   kernel.org is on holidays.

2. If that doesn't work is it possible for your to perform a git
   bisection between 2.0.2 and 2.0.3? I don't imagine that should
   take a great deal of time.

I have also CCed Matt Evans who made some of the few changes
that touched MIPS code between 2.0.2 and 2.0.3.


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: kexec 2.0.2 MIPS

[ANDY KENNEDY]

> > Attempting to make kexec work for Mips32r2.  2.0.1 works, 2.0.2
> > doesn't.  Looking through the differences of the arch/mips
> folders
> > I find that there is a reference to an extern simple_setup_start.
> > In 2.0.1 this appears to be referencing asm code from the file
> > simple_setup_start.S, however, in 2.0.2 I cannot find the
> > referenced location.
> >
> > Is this the reason that I cannot get a Linux kernel to boot using
> > 2.0.2 using the same command line as the 2.0.1?
> 
> Hi Andy,
> 
> I'm a little unsure why it is that your platform broke between
> 2.0.1
> and 2.0.2. And I'm even less sure what simple_setup_start is/was

Well, the reason you didn't see it is because I was apparently
smoking something that day.  The _real_ filename (in the 2.0.1
I just downloaded from you local store) was mips-setup-simple.S.
This file doesn't exist in 2.0.2.  I'll pull the latest and
test it.  If it works for me in mips I'll bump the version in
BuildRoot too.

BTW, the full path for that asm file is:
kexec-tools-2.0.1/kexec/arc/mips/mips-setup-simple.S

Unfortunately, I don't have much time (always the story, no?) as
I have a very important pre-release of what I'm doing with
kexec, so, forgive me if I don't get back to you with this for
a couple of days.

> (I don't see it in 2.0.1 or 2.0.2 or the current master branch).
> 
> However, I do have a few suggestions.
> 
> 1. Is it possible for you to try the latest development tree?
>    It is available at git://github.com/horms/kexec-tools.git while
>    kernel.org is on holidays.
> 
> 2. If that doesn't work is it possible for your to perform a git
>    bisection between 2.0.2 and 2.0.3? I don't imagine that should
>    take a great deal of time.
> 
> I have also CCed Matt Evans who made some of the few changes
> that touched MIPS code between 2.0.2 and 2.0.3.


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: kexec 2.0.2 MIPS

[ANDY KENNEDY]

> On Mon, Sep 19, 2011 at 08:14:21PM +0000, ANDY KENNEDY wrote:
> > Guys, sorry for the long lines on that last e-mail attempt.
> > I, unfortunately, have to use LookOut at work.  This is a
> > better formatted message:
> >
> > Attempting to make kexec work for Mips32r2.  2.0.1 works, 2.0.2
> > doesn't.  Looking through the differences of the arch/mips
> folders
> > I find that there is a reference to an extern simple_setup_start.
> > In 2.0.1 this appears to be referencing asm code from the file
> > simple_setup_start.S, however, in 2.0.2 I cannot find the
> > referenced location.
> >
> > Is this the reason that I cannot get a Linux kernel to boot using
> > 2.0.2 using the same command line as the 2.0.1?
> 
> Hi Andy,
> 
> I'm a little unsure why it is that your platform broke between
> 2.0.1
> and 2.0.2. And I'm even less sure what simple_setup_start is/was
> (I don't see it in 2.0.1 or 2.0.2 or the current master branch).
> 
> However, I do have a few suggestions.
> 
> 1. Is it possible for you to try the latest development tree?
>    It is available at git://github.com/horms/kexec-tools.git while
>    kernel.org is on holidays.

Eh, best way to get time is to claim you don't have it.

Done.  Doesn't work.  The only way I could get 2.0.1 to work was via
the following command:
kexec -l -f vmlinux # vmlinuz works too.
With this command, I get a Booted Linux system quickly.  With 2.0.2+,
however, I get blackness.  It never even kernel panics (I've left it
accidentally for 6 hours, no change).

So, I haven't dug into the WHY yet, but it is late and it probably
won't happen tonight.

If I get it to work with >2.0.1, I'll make a patch and send it in.

> 
> 2. If that doesn't work is it possible for your to perform a git
>    bisection between 2.0.2 and 2.0.3? I don't imagine that should
>    take a great deal of time.

Not a big git user, so I don't know what this would do for me.

However, since neither 2.0.2 NOR 2.0.3 work, shouldn't it be more
like 2.0.1 and 2.0.2?  Let me know what you want me to do (spoon
feed me the git command{,s}) and I'll try it.

> 
> I have also CCed Matt Evans who made some of the few changes
> that touched MIPS code between 2.0.2 and 2.0.3.


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec 2.0.2 MIPS

[Simon Horman]

On Wed, Sep 21, 2011 at 03:45:21AM +0000, ANDY KENNEDY wrote:
> > On Mon, Sep 19, 2011 at 08:14:21PM +0000, ANDY KENNEDY wrote:
> > > Guys, sorry for the long lines on that last e-mail attempt.
> > > I, unfortunately, have to use LookOut at work.  This is a
> > > better formatted message:
> > >
> > > Attempting to make kexec work for Mips32r2.  2.0.1 works, 2.0.2
> > > doesn't.  Looking through the differences of the arch/mips
> > folders
> > > I find that there is a reference to an extern simple_setup_start.
> > > In 2.0.1 this appears to be referencing asm code from the file
> > > simple_setup_start.S, however, in 2.0.2 I cannot find the
> > > referenced location.
> > >
> > > Is this the reason that I cannot get a Linux kernel to boot using
> > > 2.0.2 using the same command line as the 2.0.1?
> > 
> > Hi Andy,
> > 
> > I'm a little unsure why it is that your platform broke between
> > 2.0.1
> > and 2.0.2. And I'm even less sure what simple_setup_start is/was
> > (I don't see it in 2.0.1 or 2.0.2 or the current master branch).
> > 
> > However, I do have a few suggestions.
> > 
> > 1. Is it possible for you to try the latest development tree?
> >    It is available at git://github.com/horms/kexec-tools.git while
> >    kernel.org is on holidays.
> 
> Eh, best way to get time is to claim you don't have it.
> 
> Done.  Doesn't work.  The only way I could get 2.0.1 to work was via
> the following command:
> kexec -l -f vmlinux # vmlinuz works too.
> With this command, I get a Booted Linux system quickly.  With 2.0.2+,
> however, I get blackness.  It never even kernel panics (I've left it
> accidentally for 6 hours, no change).
> 
> So, I haven't dug into the WHY yet, but it is late and it probably
> won't happen tonight.
> 
> If I get it to work with >2.0.1, I'll make a patch and send it in.
> 
> > 
> > 2. If that doesn't work is it possible for your to perform a git
> >    bisection between 2.0.2 and 2.0.3? I don't imagine that should
> >    take a great deal of time.
> 
> Not a big git user, so I don't know what this would do for me.
> 
> However, since neither 2.0.2 NOR 2.0.3 work, shouldn't it be more
> like 2.0.1 and 2.0.2?  Let me know what you want me to do (spoon
> feed me the git command{,s}) and I'll try it.

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^

Build and see if it works. If so could you then try?

$ git checkout 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17

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

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...





_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: kexec 2.0.2 MIPS

[ANDY KENNEDY]

> $ git clone git://github.com/horms/kexec-tools.git
> $ cd kexec-tools
> $ git checkout 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17^

configure: creating ./config.status
config.status: creating Makefile
config.status: error: cannot find input file: `include/config.h.in'

Just to make sure I did this correctly:

# autoconf
# CC=${CROSS_COMPILE}gcc LDFLAGS=-static ./configure
<snip>
configure: creating ./config.status
config.status: creating Makefile
config.status: error: cannot find input file: `include/config.h.in'

> 
> Build and see if it works. If so could you then try?
> 
> $ git checkout 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17
> 
> 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
> 
> 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...
> 
> 
> 


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: kexec 2.0.2 MIPS

[ANDY KENNEDY]

> -----Original Message-----
> From: ANDY KENNEDY
> Sent: Thursday, September 29, 2011 11:03 AM
> To: 'Simon Horman'
> Cc: kexec@lists.infradead.org; Matt Evans; Maxim Uvarov
> Subject: RE: kexec 2.0.2 MIPS
> 
> > $ git clone git://github.com/horms/kexec-tools.git
> > $ cd kexec-tools
> > $ git checkout 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17^
> 
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: error: cannot find input file: `include/config.h.in'
> 
> Just to make sure I did this correctly:
> 
> # autoconf
> # CC=${CROSS_COMPILE}gcc LDFLAGS=-static ./configure
> <snip>
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: error: cannot find input file: `include/config.h.in'

RTFM ANDY!!!

Sorry, ./bootstrap works great ;)!!

> 
> >
> > Build and see if it works. If so could you then try?
> >
> > $ git checkout 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17
> >
> > 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
> >
> > 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...
> >
> >
> >


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: kexec 2.0.2 MIPS

[ANDY KENNEDY]

> 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@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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec 2.0.2 MIPS

[Simon Horman]

On Thu, Sep 29, 2011 at 06:03:42PM +0000, ANDY KENNEDY wrote:
> > 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@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.)

v2.0.1 and v2.0.2, as used in the git commands above and below,
are tags. For some reason when I pushed kexec-tools onto github
recently the tags were not pushed. I have pushed them manually now
and you should be able to fetch them using:

git fetch --tags

Otherwise, you can use 0de986976197056d0bf24456912778f1cbec05ef in place
of v2.0.1. And 7918271775078fc1c7b30dd84d026fa935a9f11f in place of v2.0.2.

> 
> > 
> > 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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: kexec 2.0.2 MIPS

[ANDY KENNEDY]

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.

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.

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.

Now, here is the result of the bisect:

root@akennedy_lin:~/src/kexec/kexec-tools# git bisect good
6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17 is the first bad commit
commit 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17
Author: Maxim Uvarov <muvarov@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@gmail.com>
    Signed-off-by: Simon Horman <horms@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@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@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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec 2.0.2 MIPS

[Simon Horman]

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?

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@akennedy_lin:~/src/kexec/kexec-tools# git bisect good
> 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17 is the first bad commit
> commit 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17
> Author: Maxim Uvarov <muvarov@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@gmail.com>
>     Signed-off-by: Simon Horman <horms@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@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@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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec 2.0.2 MIPS

[Maxim Uvarov]

2012/1/24 Simon Horman <horms@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@akennedy_lin:~/src/kexec/kexec-tools# git bisect good
>> 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17 is the first bad commit
>> commit 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17
>> Author: Maxim Uvarov <muvarov@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@gmail.com>
>>     Signed-off-by: Simon Horman <horms@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@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@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@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
>>



-- 
Best regards,
Maxim Uvarov

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec 2.0.2 MIPS

[Simon Horman]

On Tue, Jan 24, 2012 at 10:35:42PM -0800, Maxim Uvarov wrote:
> 2012/1/24 Simon Horman <horms@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.

Thanks Maxim.

Andy can you prepare a patch to revert the problematic portion
of the change?

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: kexec 2.0.2 MIPS

[ANDY KENNEDY]

> -----Original Message-----
> From: Simon Horman [mailto:horms@verge.net.au]
> Sent: Wednesday, January 25, 2012 12:57 AM
> To: Maxim Uvarov
> Cc: ANDY KENNEDY; kexec@lists.infradead.org; Matt Evans
> Subject: Re: kexec 2.0.2 MIPS
> 
> On Tue, Jan 24, 2012 at 10:35:42PM -0800, Maxim Uvarov wrote:
> > 2012/1/24 Simon Horman <horms@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.
> 
> Thanks Maxim.
> 
> Andy can you prepare a patch to revert the problematic portion
> of the change?

I'll do my best.  I don’t know when I'll be able to get to it, given
that I've had scope change on my project 3 times in the last week.

Andy
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: kexec 2.0.2 MIPS

[ANDY KENNEDY]

> -----Original Message-----
> From: kexec-bounces@lists.infradead.org [mailto:kexec-bounces@lists.infradead.org] On Behalf Of ANDY
> KENNEDY
> Sent: Wednesday, January 25, 2012 8:21 AM
> To: Simon Horman; Maxim Uvarov
> Cc: kexec@lists.infradead.org; Matt Evans
> Subject: RE: kexec 2.0.2 MIPS
> > -----Original Message-----
> > From: Simon Horman [mailto:horms@verge.net.au]
> > Sent: Wednesday, January 25, 2012 12:57 AM
> > To: Maxim Uvarov
> > Cc: ANDY KENNEDY; kexec@lists.infradead.org; Matt Evans
> > Subject: Re: kexec 2.0.2 MIPS
> >
> > On Tue, Jan 24, 2012 at 10:35:42PM -0800, Maxim Uvarov wrote:
> > > 2012/1/24 Simon Horman <horms@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.
> >
> > Thanks Maxim.
> >
> > Andy can you prepare a patch to revert the problematic portion
> > of the change?
> 
> I'll do my best.  I don’t know when I'll be able to get to it, given
> that I've had scope change on my project 3 times in the last week.

What a world.  Today I was told "Never mind" on that scope
change from yesterday.

I'll try to get to it this week or next ;).

Andy
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

kexec 2.0.2 MIPS

[ANDY KENNEDY]

Attempting to make kexec work for Mips32r2.  2.0.1 works, 2.0.2 doesn't.  Looking through the differences of the arch/mips folders I find that there is a reference to an extern simple_setup_start.  In 2.0.1 this appears to be referencing asm code from the file simple_setup_start.S, however, in 2.0.2 I cannot find the referenced location.

Is this the reason that I cannot get a Linux kernel to boot using 2.0.2 using the same command line as the 2.0.1?

Thanks in advance for any help you can provide,
Andy Kennedy

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec