[oe-issues] [Bug 2969] New: Kexec Cmdline support for arm kernels
bugzilla-daemon at tinman.treke.net
bugzilla-daemon at tinman.treke.net
Mon Sep 10 05:21:56 UTC 2007
http://bugs.openembedded.org/show_bug.cgi?id=2969
Summary: Kexec Cmdline support for arm kernels
Product: Openembedded
Version: Angstrom
Platform: Other
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: Distributions
AssignedTo: openembedded-issues at lists.openembedded.org
ReportedBy: hvontres at gmail.com
Created an attachment (id=2202)
--> (http://bugs.openembedded.org/attachment.cgi?id=2202)
Main patch
This bug has patches for adding cmdline support to arm kernels. These patches
were made by mwester and have been tested by me on a poodle for linux-rp
2.6.17,2.6.21 and 2.6.22.
The patch consists of three parts:
1)80-kexec-atags.patch: This is the main patch. It adds the capability for
kexec to manipulate the atags list
2) kexec-ksysfs_2.6.21.patch: This patch provides a crude interface to the
above patch through sysfs. I have adapted it to 2.6.17, 2.6.21 and 2.6.22
3) poodle-bootparams.patch: This patch adds a fake atags list for poodle to get
around the crappy sharp bootloader. Other zaurus models would need similar
patches.
Here is a copy of the emails from mwester about these patches:
Forwarded Conversation
Subject: Re: arm kexec commandline support
------------------------
From: Mike (mwester) <mwester at dls.net>
To: thommycheck at gmx.de, hvontres at gmail.com
Cc: "Mike (mwester)" <mwester at dls.net>
Date: Mon, Jul 9, 2007 at 9:46 AM
Attachments: 81-kexec-cmdline.patch, 80-kexec-atags.patch
- Show quoted text -
Gentlemen,
(context: I found a thread on arm kexec commandline support on the OE
archives that didn't seem to garner much enthusiasm or comment. I also
conversed briefly with someone regarding kexec commandline support on the
#oe channel some time ago - I suspect that was probably Thomas.)
I encountered a similar problem as did Henry when using the patch; in my
case the issue was that the ATAGs address was hard-coded to a non-existant
address, as the ixp4xx systems I work with use 0x00000100 instead.
Upon fixing that, I discovered that the ixp4xx systems will then begin to
reboot, but if the commandline (and other startup information) is not
hardcoded, the system crashes as well. The problem was traced to the need
to pass in the memory information in the form of atags as well.
To get to the point, after a lot of digging, the attached patches work (on
kernel 2.6.21 -- very minor changes in ksysfs.c require tweaks for use on
2.6.22). The first, 80-kexec-atags.patch, is designed simply to preserve
whatever information the bootloader passes into the device for kexec use --
the second, 81-kexec-cmdline.patch, uses the original patch's approach of
using ksysfs to permit the commandline atag to be modified.
The first of the two patches I think is reasonably acceptable in terms of
style and completeness, and may even be able (at some point) to be sent
upstream. The second (modifications to the ksysfs.c file) are clearly not
acceptable upstream -- it really exists at this point in time as a means to
test the first patch. This is working on a number of ixp4xx machines
running SlugOS (the NSLU2 and the DSM-G600).
I wonder if you might take a look at this and comment, please? Is this
reworked patch something that might be more general, and work on the
machines you are using as well? I don't want to send this to the OE list
before getting some feedback from those who originally worked on this -
thanks!
Regards,
Mike (mwester)
mailto: mwester at dls.net
--------
From: Hans Henry von Tresckow <hvontres at gmail.com >
To: "Mike (mwester)" <mwester at dls.net>
Cc: thommycheck at gmx.de
Date: Tue, Jul 24, 2007 at 10:13 PM
I tried your patch on poodle, but so far I have not been able to actually
change the cmdline...:( But at least it doesn't break anythng either...:) Sorry
it took me so long to get back to this, but between work, the house and two
small kids, fiddling with OE kinda takes a back seat.
[Quoted text hidden]
--------
From: Thomas Kunze < thommycheck at gmx.de>
To: mwester at dls.net
Cc: Hans Henry von Tresckow <hvontres at gmail.com >
Date: Fri, Jul 27, 2007 at 2:44 PM
- Show quoted text -
Hans Henry von Tresckow wrote:
> I tried your patch on poodle, but so far I have not been able to
> actually change the cmdline...:( But at least it doesn't break anythng
> either...:)
This is also true for me. Sorry that it took so long to answer but I was
quite busy lately.
Regards,
Thomas (thesing)
--------
From: Thomas Kunze < thommycheck at gmx.de>
To: "Mike (mwester)" <mwester at dls.net>
Cc: Hans Henry von Tresckow < hvontres at gmail.com>
Date: Sat, Jul 28, 2007 at 6:03 AM
Hi,
I looked further into this. It seems that atm collie doesn't use
bootparams during startup. (There ist no .boot_params in machine
description.) "cat /sys/kernel/kexec_boot_params" gives only zeros. So
maybe fallback on 0xc0000100 then and only include the cmdline tag in
the atag list?
Regards,
Thomas
--------
From: Mike (mwester) <mwester at dls.net>
To: Thomas Kunze <thommycheck at gmx.de>
Cc: Hans Henry von Tresckow <hvontres at gmail.com>
Date: Mon, Aug 6, 2007 at 9:23 PM
Attachments: poodle-bootparams.patch, collie-bootparams.patch,
kexec-ksysfs.patch, 80-kexec-atags.patch
- Show quoted text -
Sorry for the long delay. I have re-assembled my build environment, and
took a long look at this problem.
Your analysis is correct; the root cause is the absense of any .boot_params
at all.
My first thought was to re-instate the l-a-k atags patch (the one that
accepts atags from the boot-loader in R2), and pass the atag list in that
fashion. However, that doesn't change the fact that we still need an area
of memory to store the atags in for the new kernel -- and it was earlier
observed in this email thread that R2 is ignored by the current kernel
anyway. So, it seems that the simplest solution is to add the
".boot_params" to collie and poodle -- even though the bootloader may not
actually put anything there, this solution is simple and it ensures that the
area of memory is in the correct place, and avoids some complicated code in
setup.c.
The quick-and-dirty ksysfs code in the original patchset also has a problem,
in that it assumes the existance of at least an empty atags list. This is
not the case for these devices, as they have no bootloader information. The
fix there is also simple -- if the existing in-kernel buffer copied from the
.boot_params area does not start with a valid CORE tag, an empty set is
created.
I lack either a poodle or a collie to test with -- and all my machines have
bootloaders that initialize ATAGS, so I'm not in a position to test the
ksysfs.c change. It may not work.
Attached are the patches.
Regards,
Mike Westerhof
mailto:mwester at dls.net
[Quoted text hidden]
--------
From: Hans Henry von Tresckow <hvontres at gmail.com>
To: "Mike (mwester)" <mwester at dls.net>
Cc: Thomas Kunze < thommycheck at gmx.de>
Date: Wed, Aug 8, 2007 at 8:43 AM
Mike,
Thanks for the help. I tested this on my poodle last night, but I got a
segfault during kexec -e. How did you deterimine that 0xa0000100 was the
correct location for the fake tags list? I would like to take a look a this
some more when I get home, but I am still a relative kernel newbie, so I could
use some pointers. Thanks,
Henry
[Quoted text hidden]
--------
From: Hans Henry von Tresckow <hvontres at gmail.com>
To: "Mike (mwester)" <mwester at dls.net >
Cc: Thomas Kunze <thommycheck at gmx.de>
Date: Fri, Aug 10, 2007 at 7:14 AM
Mike,
I looked into this a bit further, and it looks like the adding the
poodle-bootparams.patch causes the kernel to hang during or after uncompressing
the image. Any ideas what I should look at to try to fix this?
[Quoted text hidden]
--------
From: Mike (mwester) < mwester at dls.net>
To: Hans Henry von Tresckow <hvontres at gmail.com>
Cc: Thomas Kunze < thommycheck at gmx.de>
Date: Sun, Aug 12, 2007 at 8:08 AM
After looking at the code, there are a few possibilities. The first is that
perhaps the address is not a good one. Based on a quick look at the
poodle.c source, it seemed to me that on that machine, 0xa0000000 is the
start of the RAM (physical). ATAGs must be near the beginning of the RAM (I
think in the first 16Kbytes, or so), and traditionally the bootparams are
passed at START+0x100 -- but maybe I picked a wrong address.
The other possibility is that perhaps there is data at that location that is
being misinterpreted as boot parameters. It seems unlikely that random data
might match the signature for valid ATAGs, but I've not looked at the
old-style bootparams; perhaps random data may be interpreted as such. There
is also the possibility that the bootloader is actually writing valid boot
parameters, but the poodle code is deliberately ignoring them for some
reason -- in that case, this patch would be defeating this purpose.
Lacking a poodle to test with, I can only guess. I will prepare a debugging
patch, and see if that will shed any light on the behavior. Hopefully I'll
be able to do that later today.
Regards,
Mike (mwester)
----- Original Message -----
From: "Hans Henry von Tresckow" < hvontres at gmail.com>
To: "Mike (mwester)" <mwester at dls.net>
[Quoted text hidden]
--------
From: Hans Henry von Tresckow <hvontres at gmail.com >
To: "Mike (mwester)" <mwester at dls.net>
Cc: Thomas Kunze <thommycheck at gmx.de >
Date: Mon, Aug 13, 2007 at 10:43 AM
Thanks for the input. I think you might want to run these patches by rpurdie as
well, since he is the main kernel guru on the Zaurus side of things. IIRC, the
standard sharp bootloader does not play well with 2.6 kernels.
[Quoted text hidden]
--------
From: Mike (mwester) <mwester at dls.net>
To: Hans Henry von Tresckow <hvontres at gmail.com>
Cc: Thomas Kunze < thommycheck at gmx.de>
Date: Mon, Aug 13, 2007 at 12:20 PM
----- Original Message -----
From: "Hans Henry von Tresckow" < hvontres at gmail.com>
To: "Mike (mwester)" <mwester at dls.net>
Cc: "Thomas Kunze" < thommycheck at gmx.de>
Sent: Monday, August 13, 2007 12:43 PM
Subject: Re: arm kexec commandline support
> Thanks for the input. I think you might want to run these patches by
rpurdie
> as well, since he is the main kernel guru on the Zaurus side of things.
> IIRC, the standard sharp bootloader does not play well with 2.6 kernels.
Hmmm.... That last statement might make the difference. That would explain
much, and offers a new twist to the solution. In that case, we would need a
mechanism to cause the kernel to ignore the bootloader .bootparams, but
process the ones from kexec.
Let me rethink what I was going to do. One solution would be to parse the
ATAGs and examine them for the "signature" of the bootloader vs kexec --
tricky, and like all heuristics, prone to failure. :-) However, I feel
that there is a very simple solution to do the above, but it is just out of
reach of my brain at this moment...
Mike (mwester)
--------
From: Mike (mwester) < mwester at dls.net>
To: Hans Henry von Tresckow <hvontres at gmail.com>
Cc: Thomas Kunze < thommycheck at gmx.de>
Date: Wed, Aug 15, 2007 at 8:36 PM
Henry,
Can you perform a quick test for me, to see if I'm heading in the correct
direction? If you can edit the patched kernel sources, the file
arch/arm/mach-pxa/poodle.c, and around line #409 or so, you'll find this
line that the last patch I emailed applied:
.boot_params = 0xa0000100, /* fake boot params loc for kexec */
Please change that value to be 0xa0000200 instead, recompile, and see if
the resulting kernel boots...
This change should make the kernel look for ATAGs somewhere other than
where the bootloader placed any information. If this results in a booting
kernel, this might be the easiest solution -- it retains the kexec/command
line functionality while ignoring the boot parameters from the bootloader.
If it doesn't fix the booting kernel, then there's something else wrong, and
I'll put my efforts to trying to figure that out instead.
Thanks!
Mike (mwester)
----- Original Message -----
From: "Hans Henry von Tresckow" < hvontres at gmail.com>
To: "Mike (mwester)" <mwester at dls.net>
Cc: "Thomas Kunze" < thommycheck at gmx.de>
Sent: Monday, August 13, 2007 12:43 PM
[Quoted text hidden]
--------
From: Hans Henry von Tresckow <hvontres at gmail.com>
To: "Mike (mwester)" < mwester at dls.net>
Cc: Thomas Kunze <thommycheck at gmx.de>
Date: Wed, Aug 15, 2007 at 11:05 PM
It boots :)
[Quoted text hidden]
--------
From: Mike (mwester) <mwester at dls.net>
To: Hans Henry von Tresckow <hvontres at gmail.com>
Cc: Thomas Kunze <thommycheck at gmx.de>
Date: Thu, Aug 16, 2007 at 7:35 AM
Excellent! That would indicate that the boot failures are indeed caused by
some sort of conflict between the kernel and the bootloader's parameters.
Did you check to see if kexec now works as well, and if the basic kexec
works, can you also try changing the command line?
Thanks,
Mike
----- Original Message -----
From: "Hans Henry von Tresckow" < hvontres at gmail.com>
To: "Mike (mwester)" <mwester at dls.net>
Cc: "Thomas Kunze" < thommycheck at gmx.de>
[Quoted text hidden]
--------
From: Hans Henry von Tresckow <hvontres at gmail.com>
To: "Mike (mwester)" <mwester at dls.net >
Cc: Thomas Kunze <thommycheck at gmx.de>
Date: Fri, Aug 17, 2007 at 12:48 AM
Yay....it works :) I was able to get it to boot from flash, and change the
cmdline to boot from SD. I'd suggest putting the patches up on the mailing list
to get some feedback from the other guys as well.
Thanks a lot for all your help on this. :)
Henry
--
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the Openembedded-issues
mailing list