summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'baserock/tiagogomes/armv8l64' into baserock/morphbaserock/morphTiago Gomes2015-02-1278-1432/+4296
|\
| * Add missing macrosbaserock/tiagogomes/armv8l64Tiago Gomes2015-02-112-0/+11
| | | | | | | | | | Those were copied from the scripts/recordmcount.c file of the Linux repository.
| * Add arm64 kexec supportGeoff Levand2015-02-1116-2/+1490
| | | | | | | | Signed-off-by: Geoff Levand <geoff@infradead.org>
| * kexec: Add common device tree routinesGeoff Levand2015-02-113-0/+153
| | | | | | | | Signed-off-by: Geoff Levand <geoff@infradead.org>
| * kexec/fs2dt: Fix sorting of device treeAnton Blanchard2014-11-131-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit b02d735bf252 ('ppc64 kdump device_tree sort') added code to sort device tree properties, but it had a few issues. A compare routine needs to return -1 and 1. The special case for sorting properties with unit addresses only returned 1 and ignored the opposite case, which screwed up the sorting. We were missing a few more things: - Need to check both basenames are the same length - Need to check both basenames match I noticed this when looking at the NUMA topology after a kexec, and it had shifted. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Simon Horman <horms@verge.net.au>
| * kexec: distribute kexec/arch/m68k/bootinfo.hAndreas Schwab2014-10-141-0/+1
| | | | | | | | | | Signed-off-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Simon Horman <horms@verge.net.au>
| * kexec-tools 2.0.8.gitSimon Horman2014-10-141-1/+1
| | | | | | | | | | | | | | | | Add .git to version so it doesn't look like a release. This is just so when people build code from git it can be identified as such from the version string. Signed-off-by: Simon Horman <horms@verge.net.au>
| * kexec-tools 2.0.8v2.0.8Simon Horman2014-10-081-1/+1
| | | | | | | | Signed-off-by: Simon Horman <horms@verge.net.au>
| * kexec-tools 2.0.8-rc1v2.0.8-rc1Simon Horman2014-10-011-1/+1
| | | | | | | | Signed-off-by: Simon Horman <horms@verge.net.au>
| * Return error code in case of invalid command line optionVivek Goyal2014-09-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | Currently kexec returns success even if an invalid command line option is encountered. Kexec currently prints usage message and then returns 0. That's not right. It is an error and error code 1 should be returned. Due to this wrapper script thinks that kdump succeeded but that's not the case. Signed-off-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * ppc64/kdump: Fix ELF header endianessLaurent Dufour2014-09-011-0/+4
| | | | | | | | | | | | | | | | | | | | | | The ELF header created among the loading of the kdump kernel should be flagged using the current endianess and not always as big endian. Without this patch the data exposed in /proc/vmcore are not readable when running in LE mode. Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * kexec: Provide an option to use new kexec system callVivek Goyal2014-08-274-4/+257
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hi, This is v2 of the patch. Since v1, I moved syscall implemented check littler earlier in the function as per the feedback. Now a new kexec syscall (kexec_file_load()) has been merged in upstream kernel. This system call takes file descriptors of kernel and initramfs as input (as opposed to list of segments to be loaded). This new system call allows for signature verification of the kernel being loaded. One use of signature verification of kernel is secureboot systems where we want to allow kexec into a kernel only if it is validly signed by a key system trusts. This patch provides and option --kexec-file-syscall (-s), to force use of new system call for kexec. Default is to continue to use old syscall. Currently only bzImage64 on x86_64 can be loaded using this system call. As kernel adds support for more arches and for more image types, kexec-tools can be modified accordingly. Signed-off-by: Vivek Goyal <vgoyal@redhat.com> Acked-by: Baoquan He <bhe@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * kexec: align the extended size of dtbLiu Hua2014-07-241-1/+1
| | | | | | | | | | | | | | | | | | | | When loading dtb on arm platform, we may need change strings in dtb in function setup_dtb_prop. If length of new string is larger than that of the old one. We should extend the dtb by "FDT_TAGALIGN"ed size. If not, kexec may fail to load the capture kernel. Signed-off-by: Liu Hua <sdu.liu@huawei.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * kexec/ppc64: disabling exception handling when building the purgatoryLaurent Dufour2014-07-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Some Linux distributions would like to turn on the GCC exception handling by default. As this option introduces symbols in the built code that are defined in a separate shared library, this is not a good idea to have such an option activated when building the purgatory. This patch forces the exception handling to be turned off when building the purgatory on ppc64 BE and LE. Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * kexec/ppc64: move to device tree version 17Laurent Dufour2014-06-171-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Kernel commit e6a6928c3ea1d0195ed75a091e345696b916c09b changed the way the device tree is processed in the kernel. Now version 2 is no more supported. This patch move the version of the device tree generated in ppc64 environment from 2 to 17, allowing to kexec kernel 3.16. In addition, automates the define of NEED_STRUCTURE_BLOCK_EXTRA_PAD which should not be set for DT version 16 and above. Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * kexec-tools 2.0.7.gitSimon Horman2014-06-171-1/+1
| | | | | | | | | | | | | | | | Add .git to version so it doesn't look like a release. This is just so when people build code from git it can be identified as such from the version string. Signed-off-by: Simon Horman <horms@verge.net.au>
| * kexec-tools 2.0.7v2.0.7Simon Horman2014-06-091-1/+1
| | | | | | | | Signed-off-by: Simon Horman <horms@verge.net.au>
| * kexec: ARM: add LPAE supportLiu Hua2014-06-061-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | For 32-bit ARM systems with CONFIG_ARM_LPAE=y, when kexec utility loads the crash kernel. 32-bit elf header is not enough if the physical address exceeds 4G. This patch checkes whether the largest physical address of the system exceeds 4G. If so, kexec creates 64-bit elf header.Otherwise it creates 32-bit elf header. Signed-off-by: Wei Jitao <weijitao@huawei.com> Signed-off-by: Liu Hua <sdu.liu@huawei.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * kexec: iomem: accept u64 parameters for callbacksLiu Hua2014-06-063-8/+8
| | | | | | | | | | | | | | | | | | | | Since "start" and "end" in kexec_iomem_for_each_line are unsigned long long, this patch makes "callback"s accept unsigned-long-long-type parameters. Signed-off-by: Wei Jitao <weijitao@huawei.com> Signed-off-by: Liu Hua <sdu.liu@huawei.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * Fix mistaken check of stat(2) return valueTakao Indoh2014-06-051-1/+1
| | | | | | | | | | | | | | | | | | | | get_crash_notes_per_cpu() should return -1 if return value of stat(2) is zero (on success). Signed-off-by: Takao Indoh <indou.takao@jp.fujitsu.com> Reviewed-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Acked-by: WANG Chao <chaowang@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * Enumerate all /sys/devices/system/cpu/cpuN when they are discontiguousTakao Indoh2014-06-051-1/+4
| | | | | | | | | | | | | | | | | | | | | | There is a case that the number of /sys/devices/system/cpu/cpuN is not contiguous, for example after cpu hot removing. This patch fixes so that all /sys/devices/system/cpu/cpuN is handled when they are discontiguous. Signed-off-by: Takao Indoh <indou.takao@jp.fujitsu.com> Reviewed-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Acked-by: WANG Chao <chaowang@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * kdump: pass acpi_rsdp to 2nd kernel if kernel does not export efi runtime mapsDave Young2014-05-301-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | If kernel does not export efi runtime maps it means 1:1 mapping does not work or user explictly boot with efi=old_map. In this case efi setup code will failback to noefi boot, but for kdump case we still need pass extra acpi_rsdp cmdline. Thus adding a check in kdump path. Signed-off-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * kexec-tools: add --page-offset option for ARMWang Nan2014-05-303-2/+26
| | | | | | | | | | | | | | | | When KALLSYMS is disabled or /proc is not mounted, this patch allows --page-offset cmdline option for user to setup correct page_offset. Signed-off-by: Wang Nan <wangnan0@huawei.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * kexec-tools: detect page_offset dynamicallyWang Nan2014-05-302-2/+51
| | | | | | | | | | | | | | | | | | ARM kernel can be compiled with CONFIG_VMSPLIT_1G, CONFIG_VMSPLIT_2G or CONFIG_VMSPLIT_3G. This patch dynamically detects PAGE_OFFSET according to _stext symbol from /proc/kallsyms. Signed-off-by: Wang Nan <wangnan0@huawei.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * kexec-tools 2.0.7-rc1v2.0.7-rc1Simon Horman2014-05-281-1/+1
| | | | | | | | Signed-off-by: Simon Horman <horms@verge.net.au>
| * kexec-tools: usage text fixDave Young2014-05-281-1/+1
| | | | | | | | | | | | | | | | There's one more '-' in arch_usage, thus s/pass--memmap-cmdline/pass-memmap-cmdline Signed-off-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * kexec-tools: add noefi arch cmdline optionDave Young2014-05-286-2/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For kernel boot with efi=old_map or some quirked machines like SGI UV they use old ioremap instead of 1:1 mapping. But kexec efi support depends on the 1:1 mapping thus we need to switch to use the old way There's a kernel patch for exporting the efi flags so we can check the memory mapping method. But user may want to explictly disable efi boot for unknown reasons. So here add a new arch option '--noefi' for this case. Signed-off-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * vmcore-dmesg: Handle struct log to struct printk_log renamingVivek Goyal2014-05-261-15/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | vmcore-dmesg has been failing for me for quite some time as struct log was renamed to struct printk_log. 62e32ac printk: rename struct log to struct printk_log This patch has been sitting in mailing list for quite some time. It is time to repost the patch. I took original patch of Lubomir and modified a bit to take care of concern of hardcoded string length. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Signed-off-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * x86, cleanup: remove cmdline_add_memmap_acpiWANG Chao2014-05-221-31/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | In kdump path, now we store all the 2nd kernel memory ranges in memmap_p. We could use just cmdline_add_memmap() to add all types of memory ranges to 2nd kernel cmdline. So clean up here, merge cmdline_add_memmap_acpi() into cmdline_add_memmap(). Signed-off-by: WANG Chao <chaowang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * kexec/ppc64: Handle reserved memory ranges exported by OPAL firmware.Mahesh Salgaonkar2014-05-151-0/+44
| | | | | | | | | | | | | | | | | | | | OPAL based system exports reserved memory ranges through /proc/device-tree for the regions that are reserved by OPAL firmware. Traverse /proc/device-tree/reserved-ranges and add them to exclude_ranges[] and reserve them. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * kexec/ppc64: Fix up ELF header and dt for PowerNV platform.Mahesh Salgaonkar2014-05-155-1/+79
| | | | | | | | | | | | | | | | | | On PowerNV platform, OPAL region is overlapped with crashkernel, need to create ELF Program header for the overlapped memory. The changes are similar to the way RTAS region was handled. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * zImage-arm: init modified_cmdline with zeroWang Nan2014-05-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch memset modified_cmdline after it alloced. Without this patch, the header of command line always contains random value like following example: kernel: 0x765fd008 kernel_size: 0x23b610 memory range: [0x60000000 - 0x6fffffff] (256M) memory range: [0x78000000 - 0x9fffffff] (640M) ... kernel command line: "°¥氥䐶# elfcorehdr=0x77f00000 mem=130048K" Signed-off-by: Wang Nan <wangnan0@huawei.com> Cc: Geng Hui <hui.geng@huawei.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * cleanup duplicate codeWANG Chao2014-05-111-1/+0
| | | | | | | | | | | | | | | | I accidentally add one duplicate line. Now remove it. Signed-off-by: WANG Chao <chaowang@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * zImage-arm: bugfix: kernel offset must be 0x8000Wang Nan2014-05-111-8/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixs a problem introduced by commit e5d6a55 which make ARM kexec fails. Due to that commit, kernel is loaded at a dynamically offset: it computes extra_size using size of dtb, and load zImage at base + extra_size. When dtb size small (for example, 0x3000 bytes), kernel will be loaded at address like 0x60003000. For ARM zImage such address is incorrect. In kernel code arch/arm/boot/compressed/head.S, zImage builds a temporary page table at (pc & 0xf8000000) + TEXT_OFFSET - 0x4000. The related instructions sequence is: mov r4, pc and r4, r4, #0xf8000000 add r4, r4, #TEXT_OFFSET @ (TEXT_OFFSET == 0x8000 on most platforms) call cache_on ... call __armv7_mmu_cache_on ... call __setup_mmu sub r3, r4, #16384 @ Page directory size r3 becomes page table pointer. When kernel is loaded at 0x60003000, page table is still built at 0x60004000, which destroys kernel. This patch make extra_size a fix value (0x8000) to avoid the failure. For the problem commit e5d6a55 tries solve, this patch uses locate_holes() to find a place can hold initrd and dtb. Change from v1: - Coding style enhancements. Signed-off-by: Wang Nan <wangnan0@huawei.com> Tested-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * condition check fixWANG Chao2014-05-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | In commit 91f5b9c ("kdump: pass e820 reserved region to 2nd kernel via e820 table or setup_data"), I made a wrong condition check. We should only add cmdline for a memory range if --pass-memmap-cmdline and the range type isn't RANGE_RESERVED. Signed-off-by: WANG Chao <chaowang@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * zImage-arm: get rid of static offsetDaniel Mack2014-05-021-11/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code in arch/arm/kexec-zImage-arm.c currently enforces a hard limit on the maximum size a dtb blob can occupy. This limit is set to 32k, which is quite low for device tree blobs nowadays. Get rid of this assumption, and calculate the added size dynamically. For this, we need to slurp in the dtb file earlier in order to determine its size, because the memory hole allocation for 'base' takes this size into account. For ATAGs, we keep the current value of 32k, which should in fact be enough. With this change in place, the 'DTB too large!' error message can go away. Successfully tested on a AM335x board. Signed-off-by: Daniel Mack <zonque@gmail.com> [s.neumann@raumfeld.com: Fix ATAGs case] Reported-and-tested-by: Sven Neumann <s.neumann@raumfeld.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * kdump: pass e820 reserved region to 2nd kernel via e820 table or setup_dataWANG Chao2014-04-291-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | e820 reserved region could be useful in 2nd kernel. For example, PCI mmconf (extended mode) requires reserved region otherwise it falls back to legacy mode. The following log is from Cliff Wickman <cpw@sgi.com>: PCI: MMCONFIG for domain 1003 [bus 3f-3f] at [mem 0xff0ff00000-0xff0fffffff] (base 0xff0c000000) [Firmware Bug]: PCI: MMCONFIG at [mem 0x80000000-0x80cfffff] not reserved in ACPI motherboard resources PCI: not using MMCONFIG PCI devices on segment 1 (>0) can't fall back to legacy mode, thus kernel probing fails and device can't be found. We don't pass reserved region because these regions could be too much and eat up our very limited kernel command line resource in memmap=exactmap case. However now we use e820 map and setup_data to pass memory map to 2nd kernel and the number of reserved regions should not be a problem any more. Signed-off-by: WANG Chao <chaowang@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * ppc64/purgatory: Device tree values should be read/stored in Big EndianLaurent Dufour2014-04-291-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The purgatory code reads the device tree's version and stores if needed the currently running CPU number. These 2 values are stored in Big Endian format in the device tree and should be byte swapped when running in Little Endian mode. Without this fix, when running in SMP environment, kexec or kdump kernel may fail booting with the following message : Failed to identify boot CPU Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * Do not distribute generated files in the release tarballPaul Wise2014-04-251-1/+1
| | | | | | | | | | | | | | | | | | | | Generated files should always be built from source and never be present in VCS repositories and only autotools generated files should be in tarballs. This ensures that they get built as often as possible and bugs with that process are discovered early. Signed-off-by: Paul Wise <pabs3@bonedaddy.net> Signed-off-by: Simon Horman <horms@verge.net.au>
| * x86: Pass memory range via E820 for kdumpWANG Chao2014-04-233-53/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | command line size is restricted by kernel, sometimes memmap=exactmap has too many memory ranges to pass to cmdline. And also memmap=exactmap and kASLR doesn't work together. A better approach, to pass the memory ranges for crash kernel to boot into, is filling the memory ranges into E820. boot_params only got 128 slots for E820 map to fit in, when the number of memory map exceeds 128, use setup_data to pass the rest as extended E820 memory map. kexec boot could also benefit from setup_data in case E820 memory map exceeds 128. Now this new approach becomes default instead of memmap=exactmap. saved_max_pfn users can specify --pass-memmap-cmdline to use the exactmap approach. Signed-off-by: WANG Chao <chaowang@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Reviewed-by: Linn Crosetto <linn@hp.com> Acked-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * x86: add --pass-memmap-cmdline optionWANG Chao2014-04-234-0/+12
| | | | | | | | | | | | | | | | | | | | | | --pass-memmap-cmdline is used for pass memmap=exactmap cmdline for 2nd kernel. Later we will use this option to disable passing E820 memmap method but use the old exactmap method. Signed-off-by: WANG Chao <chaowang@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Acked-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * x86, cleanup: kexec memory range .end to be inclusiveWANG Chao2014-04-233-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Later kexec and kdump memory range will be mapped to E820entry. But currently kexec memory range .end field is exclusive while crash memory range is inclusive. Given the fact that the exported proc iomem and sysfs memmap are both inclusive, change kexec memory range .end to be inclusive. Later the unified memory range of both kexec and kdump can use the same E820 filling code. Signed-off-by: WANG Chao <chaowang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * x86, cleanup: Store crash memory ranges kexec_infoWANG Chao2014-04-232-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add two new members to kexec_info structure: struct memory_range *crash_range int nr_crash_ranges; crash_range contains the memory ranges used to boot 2nd kernel. nr_crash_ranges contains the count of the crash memory ranges. Signed-off-by: WANG Chao <chaowang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * x86, cleanup: use dbgprint_mem_range for memory range debuggingWANG Chao2014-04-231-23/+3
| | | | | | | | | | | | | | Signed-off-by: WANG Chao <chaowang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * x86, cleanup: increase CRASH_MAX_MEMMAP_NR up to 1024WANG Chao2014-04-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CRASH_MAX_MEMMAP_NR is used as the upper boundary of memmap_p. Originally memmap_p was used to store RANGE_RAM only. But now we changed it to store all the types of memory ranges for 2nd kernel, which includes RANGE_RAM, RANGE_ACPI, RANGE_ACPI_NVS (and RANGE_RESERVED in the future). Currently CRASH_MAX_MEMMAP_NR is defined (KEXEC_MAX_SEGMENTS + 2), which is not enough for memmap_p. It must be increased to a much higher value. I think 1024 is good enough for storing all memory ranges for 2nd kernel. So this patch increases CRASH_MAX_MEMMAP_NR to 1024. Signed-off-by: WANG Chao <chaowang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * x86, cleanup: add other types of memory range for 2nd kernel boot to memmap_pWANG Chao2014-04-231-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | In load_crashdump_segments(), memmap_p[] is used to contain RANGE_RAM memory range for booting 2nd kernel. Now adding types of RANGE_ACPI and RANGE_ACPI_NVS to memmap_p, so later we can pass all the types of memory range to 2nd kernel. These all types of memory ranges are all stored in memmap_p for later reference. Signed-off-by: WANG Chao <chaowang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * x86, cleanup: add_memmap() only do alignment check on RANGE_RAMWANG Chao2014-04-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | add_memmap() will also add memory range with type RANGE_ACPI and RANGE_ACPI_NVS (RANGE_RESERVED in the future) besides RANGE_RAM to memmap_p. Among these types of memory range, only RANGE_RAM needs to be aligned with certain alignment. RANGE_ACPI, RANGE_ACPI_NVS and RANGE_RESERVED doesn't have to be aligned. Signed-off-by: WANG Chao <chaowang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * x86, cleanup: add extra arguments to add_memmap() and delete_memmap()WANG Chao2014-04-231-9/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change will be used later: add_memmap(.., int *nr_memmap, .., int type); delete_memmap(.., int *nr_memmap, ..); memmap_p[] is statically allocated for a certain amount. It will be used later when mapping these memory maps to e820 map. It's convenient to keep track of the count of memmap_p (nr_memmap) in add_memmap and delete_memmap, because the counting has already been taken care of in these two functions. The original add_memmap() can only add memory range of RANGE_RAM type. For adding other types of memory range, add another argument for indicating the type. Signed-off-by: WANG Chao <chaowang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * kexec/fs2dt : Fix endianess issue with initrd base and sizeLaurent Dufour2014-04-141-4/+5
| | | | | | | | | | | | | | | | | | | | | | The initrd values exposed in the device tree of the kexeced kernel must be encoded in Big Endian format. Without this patch, kexeced LE kernel are expected to panic when dealing with the initrd image. Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
| * x86, cleanup: Add a funtion add_setup_data()WANG Chao2014-04-141-6/+20
| | | | | | | | | | | | | | | | add_setup_data() is used to add an instance to the single linked list of setup_data structure. Signed-off-by: WANG Chao <chaowang@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
View Lorry Controller Status