| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This reverts commit e35aa29fb40b37bf86d980b2e19af5e01c2d2549.
This patch is based on the commit 49320340f705694e387d794f7f19d407ad9baefa
"kexec: lengthen the kernel command line image"
Since the latter commit has been reverted due to its useless, this
patch should be reverted too.
Besides, This patch also changed a kernel restriction of max segments
from 16 to 70. Though kexec-tools could have more segments, more than 16,
the kexec_load syscall will still fail for the kernel side has a restriction
of 16.
Cc: Cliff Wickman <cpw@sgi.com>
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The crash kernel is not able to find its root device if that device is not
on PCI 0.
This is because it is booted with the command line option memmap=exactmap
which currently clears the e820 table and does not restore reserved spaces.
This works for a device on PCI 0 because ACPI falls back to a legacy mode.
But the error message " [Firmware Bug]: PCI: MMCONFIG at
[mem 0x80000000-0x80cfffff] not reserved in ACPI motherboard resources"
is written to the log even in this functioning case.
It fails for some devices on UV2, and only for UV2, because SGI seems to
be the only manufacturer currently using the extended PCI(>0).
The fix is simple, as long as the command line is long enough to include
all the reserved spaces.
The command line may have to be lengthened. See
[PATCH] kexec: lengthen the kernel command line image
Signed-off-by: Cliff Wickman <cpw@sgi.com>
[ horms@verge.net.au: Manually applied due to conflicts ]
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
While trying to port kexec cleanly to klibc,
came across this syscall usage for reboot(2).
Calling reboot directly simplifies the code.
Signed-off-by: maximilian attems <max@stro.at>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
These 2 "uncommon" include pathes are the first stumbling blocks
to build kexec-tools against klibc.
Of course more is needed, but this is a first step.
On the klibc step there is still stuff needed, but
it is already possible with hacks as Oppenembedded shows.
Signed-off-by: maximilian attems <max@stro.at>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
I got the following warning when I compiled kexec-tools on ppc64,
In file included from kexec/arch/ppc64/kexec-ppc64.c:32:
kexec/arch/ppc64/../../kexec-syscall.h:118:1: warning: "KEXEC_ARCH_NATIVE" redefined
kexec/arch/ppc64/../../kexec-syscall.h:115:1: warning: this is the location of the previous definition
This is due to that ppc64 defines bot __powerpc64__ and __powerpc__,
this patch fixes that warning.
Signed-off-by: WANG Cong <amwang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Trivial but sometimes it is sometimes multi-arch code wants to know.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
|
|
- 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>
|
|
To support memory backup/restore an option named
--load-preserve-context is added to kexec. When it is specified
toggether with --mem-max, most segments for crash dump support are
loaded, and the memory range between mem_min to mem_max which has no
segments loaded are loaded as backup segments. To support jump back
from kexeced, options named --load-jump-back-helper and --entry are
added to load a helper image with specified entry to jump back.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Hello,
I hope this is the correct list to which to send these patches.
Comments are very welcome.
Thanks,
Edgar
From: Edgar E. Iglesias <edgar.iglesias@axis.com>
Add a CRISv32 port. Initially only the elf filetype is supported.
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@axis.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The released toolchain had an old list of syscalls (kexec_load was missing)
so I had to add a fallback definition:
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Jamey Sharp <jamey@thetovacompany.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
[ Reposted with correct linux-mips address ]
Hi,
this patch switches the mips support in kexec-tools around a little bit.
All the files and directories containing "mipsel" have been renamed
to contain "mips" instead.
This is kind of consistent with the way that ARCH=mips in the kernel
works for both big and little endian.
After a small amount of tweaking, which is also included in this patch, the
code compiles and works fine for big endian mips as well as small endian
mips. All you need to do is compile using an appropriate compiler.
That is to say, kexec-tools's build system doesn't need to
be told about which endienness the code is being compiled for.
I have added kept mipsel as a supported "architecture" via ./configure,
though its just an alias for mips now. This is consistent with how
other architectures such as sh are treated. But I'm happy to remove
mipsel from ./configure if the mips people want that.
I tested this patch using qemu and the 2.6.24.3 tag of the mips-2.6 git
tree compiled for the qemu machine type for both big and little endian.
The qemu machine type has subsequently been removed, and kexec-tools
needs some work in order to function with qemu - as far as I understand
the way the boot parameters are passed needs to be fixed, likely
in purgatory. However, this is not related to the changes
introduced in this patch.
I intend to merge this patch into kexec-tools-testing if
no alarm bells are sounded.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Hello,
We developed a patch to port kexec-tools to mips arch and included support for
command line passing through elf boot notes.
We did it for a customer of ours on a specific platform derived from toshiba
tx4938 (so we think it should work at least for tx4938 evaluation board also).
We would like to contribute it in case somebody else needs it or wants to
improve it.
This patch works for us but the assembler part in particular, should be
considered as a starting point because my assembly knowledge is not too deep.
As this is the first time I submit a patch I tried to guess reading tpp.txt if
this is the right way to submit. Please let me know about any mistakes I may
have made.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add ARM support to kexec including commandline support through ATAGs.
The kernel syscall support has already been merged and kernel ATAG
exporting is queued for 2.6.25 (its optional for kexec).
Based on work by various people, notably Uli Luckas <u.luckas@road.de>
for adding ATAG support.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Horms <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Patch found on
http://eggplant.ddo.jp/www/download/debian26/source/kexec-tools/kexec-tools_1.101-2sh.diff.gz
According to Paul Mundt <lethal@linux-sh.org> it was originally by
kogiidena <kogiidena@eggplant.ddo.jp>
Signed-off-by: Simon Horman <horms@verge.net.au>
Acked-by: Magnus Damm <magnus.damm@gmail.com>
|
|
o In some cases, the number of segments on kexec load exceeds
the existing cap of 8. This patch increases the KEXEC_MAX_SEGMENTS
from 8 to 16.
Signed-off-by: Rachita Kothiyal <rachita@in.ibm.com>
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
--===============39718348520004598==
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi Milton,
first of all thanks for looking at the patches.
> 1) When patching the command line, you read the string from the
> optarg. While you clear the area in the kernel looking at
> COMMAND_LINE_SIZE, you do not limit the length that you copy into
> the kernel by this amount. This would seem like a buffer-overflow
> situation that could easily be trapped.
Yes, you're right. The kernel image could be damaged. Fixed.
> 2) I noticed your ramdisk code is quite similar in function to
> slurp_file in kexec/kexec.c. I realize this is probably a new
> function.
Fixed as well :)
> 3) Your elf-rel loading seem to not be implemented, but your probe
> returns 0 just like the image loader.
I think you're talking about the function machine_verify_elf_rel().
Unlike the probe functions this one should return 0 on error,
shouldn't it?
> 4) You seem to have several addresses hard-coded into the kexec-s390.h
> file. This would seem to limit the image you are loading, including
> any panic crash kernel options using the current scheme. I don't
> know your abi to know what other issues you might have with a more
> generic kexec to image interface. (It appears you setup your image
> to load as if it were from 0 but skipping IMAGE_READ_OFFSET bytes.
The hard coded addresses are part of the kernel abi. Nothing needs to
be changed here. Skipping the first 64k of the kernel image is ok too,
since you usually would only find a loader routine there which would
load the rest of the kernel image into ram and then start it.
If you are really interested you might have a look at
arch/s390/kernel/head.S in the kernel sources :)
Also we do not plan to use the kdump feature. It doesn't make too
much sense for the s390 architecture since we have already other
mechanisms which allow to reliably dump complete memory and register
contents at any given state of the system.
The patch below should be better (still against 1.101). Guess I will
come up with an improved kernel patch too.
Thanks,
Heiko
diffstat:
configure | 5 -
kexec/arch/s390/Makefile | 6 +
kexec/arch/s390/include/arch/options.h | 11 ++
kexec/arch/s390/kexec-elf-rel-s390.c | 23 +++++
kexec/arch/s390/kexec-image.c | 137 +++++++++++++++++++++++++++++++++
kexec/arch/s390/kexec-s390.c | 104 +++++++++++++++++++++++++
kexec/arch/s390/kexec-s390.h | 25 ++++++
kexec/kexec-syscall.h | 7 +
purgatory/arch/s390/Makefile | 7 +
purgatory/arch/s390/include/limits.h | 54 +++++++++++++
purgatory/arch/s390/include/stdint.h | 24 +++++
11 files changed, 402 insertions(+), 1 deletion(-)
|
|
- Initial import into git
- initial nbi image formage support
- ppc32 initial register setting fixes.
- gzipped multiboot file support
|
