kexec on mips - anyone has it working?
Subsystems (3)
I'm trying to use kexec on a ASUS WL-500gP router (BCM47XX, little endian MIPS) with a 2.6.25.4 kernel with some additional changes from OpenWRT.
Unfortunately, it doesn't work for me - when I load a new kernel and try to execute it, it just says "Bye" and the router is dead:
# kexec -l vmlinux # kexec -e (...) Bye
I signalled the issue before in the past, with a 2.6.23.1 kernel:
http://lists.infradead.org/pipermail/kexec/2008-February/001315.html
Ideas? Ways to debug it?
Signature · 7 lines
Tomasz Chmielewski http://wpkg.org _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
Quoted 13 lines · On Tuesday 27 May 2008 10:51:01 you wrote:
I'm trying to use kexec on a ASUS WL-500gP router (BCM47XX, little endian MIPS) with a 2.6.25.4 kernel with some additional changes from OpenWRT.
Unfortunately, it doesn't work for me - when I load a new kernel and try to execute it, it just says "Bye" and the router is dead:
# kexec -l vmlinux # kexec -e (...) Bye
Quoted 6 lines
I signalled the issue before in the past, with a 2.6.23.1 kernel:
http://lists.infradead.org/pipermail/kexec/2008-February/001315.html
Ideas? Ways to debug it?
I am using a 2.6.20 kernel on a 32bit mips platform and it is working fine. however I am using this userland code (make CROSS=$(your cross-compiler prefix) to compile it) :
http://chac.le-poulpe.net/~nico/kexec.tar.gz
Could you try to add the following line in machine_kexec.c, just before jumping to the trampoline:
change_c0_config(CONF_CM_CMASK, CONF_CM_UNCACHED);
This disables caching on KSEG0, but I would be suprised to find the bcm47xx in the list of machines for which this line could be a "one way ticket to hell" :)
(Well I still have my doubts regarding the issue of not flushing the instruction cache completely before jumping to the new kernel in the trampoline code).
Regards,
Signature · 1 line
Nicolas Schichan
Quoted 4 lines · On Tuesday 27 May 2008 14:05:54 Nicolas Schichan wrote:
I am using a 2.6.20 kernel on a 32bit mips platform and it is working fine. however I am using this userland code (make CROSS=$(your cross-compiler prefix) to compile it) :
I can confirm it also works on our little-endian boards. the kexec-code between 2.6.25 and our tree is the same (I backported some patches).
I will give a try to the official userland stuff.
Btw, sorry for the mess caused by the HTML attachement in the previous mail.
Regards,
Signature · 1 line
Nicolas Schichan
Quoted 9 lines · Nicolas Schichan
Quoted 1 line
Ideas? Ways to debug it?
I am using a 2.6.20 kernel on a 32bit mips platform and it is working fine. however I am using this userland code (make CROSS=$(your cross-compiler prefix) to compile it) :
http://chac.le-poulpe.net/~nico/kexec.tar.gz
Could you try to add the following line in
machine_kexec.c, just before jumping to the trampoline:change_c0_config(CONF_CM_CMASK, CONF_CM_UNCACHED);
And machine_kexec.c file is in where? It's not in the above one, it's not in kexec-tools-testing-20080324?
Signature · 2 lines
Tomasz Chmielewski http://wpkg.org
Quoted 7 lines · On Tuesday 27 May 2008 14:40:21 you wrote:
Quoted 4 lines
Could you try to add the following line in
machine_kexec.c, just before jumping to the trampoline:change_c0_config(CONF_CM_CMASK, CONF_CM_UNCACHED);And
machine_kexec.cfile is in where? It's not in the above one, it's not in kexec-tools-testing-20080324?
machine_kexec.c is in the kernel not in the kexec userland tools.
it's in arch/mips/kernel/machine_kexec.c, just apply the following patch:
arch/mips/kernel/machine_kexec.c +1 -0
@@ -81,5 +81,6 @@printk ("Will call new kernel at %08lx\n" , image->start);printk ("Bye ...\n" );__flush_cache_all (); +change_c0_config (CONF_CM_CMASK ,CONF_CM_UNCACHED ); ((noretfun_t ) reboot_code_buffer)(); }
Signature · 1 line
Nicolas Schichan
Quoted 10 lines · Nicolas Schichan
Quoted 6 lines · On Tuesday 27 May 2008 14:40:21 you wrote:
Quoted 4 lines
Could you try to add the following line in
machine_kexec.c, just before jumping to the trampoline:change_c0_config(CONF_CM_CMASK, CONF_CM_UNCACHED);And
machine_kexec.cfile is in where? It's not in the above one, it's not in kexec-tools-testing-20080324?
machine_kexec.cis in the kernel not in the kexec userland tools.
Aah, I see.
Anyway, it doesn't work - with or without this slight change in machine_kexec.c, with kexec compiled from the sources in the link you gave or with kexec-tools-testing-20080324, it just doesn't work on BCM43XX with OpenWRT patches. At least on Asus WL-500gP.
Signature · 2 lines
Tomasz Chmielewski http://wpkg.org
Quoted 10 lines · Tomasz Chmielewski
Quoted 9 lines · Nicolas Schichan
Quoted 6 lines · On Tuesday 27 May 2008 14:40:21 you wrote:
Quoted 4 lines
Could you try to add the following line in
machine_kexec.c, just before jumping to the trampoline:change_c0_config(CONF_CM_CMASK, CONF_CM_UNCACHED);And
machine_kexec.cfile is in where? It's not in the above one, it's not in kexec-tools-testing-20080324?
Quoted 8 lines
Quoted 1 line
machine_kexec.cis in the kernel not in the kexec userland tools.Aah, I see.
Anyway, it doesn't work - with or without this slight change in
machine_kexec.c, with kexec compiled from the sources in the link you gave or with kexec-tools-testing-20080324, it just doesn't work on BCM43XX with OpenWRT patches. At least on Asus WL-500gP.
Hi,
MIPS support was merged into kexec-tools-testing-20080324. However, as far as I could tell it only supports one of the many boot protocols that are used by various MIPS machines.
If things aren't working for a particular peice of hardware, I would start by looking into what boot protocol the kernel uses on that machine, and making sure that kexec-tools understands it.
As always if there are any patches for MIPS for kexec-tools, please send them to me and this list.
Signature · 7 lines
Horms _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
Quoted 10 lines · Nicolas Schichan
Quoted 6 lines · On Tuesday 27 May 2008 20:14:11 you wrote:
Aah, I see.
Anyway, it doesn't work - with or without this slight change in
machine_kexec.c, with kexec compiled from the sources in the link you gave or with kexec-tools-testing-20080324, it just doesn't work on BCM43XX with OpenWRT patches. At least on Asus WL-500gP.I'm not familiar with broadcom CPU names, but isn't BCM43XX supposed to be a Wifi chipset ? :)
Well, yeah, indeed the device is sold as a wireless router. But it can perfectly run Debian, so it should run kexec as well, shouldn't it? ;)
Quoted 7 lines
However, could you kexec a kernel from a kernel that has
CONFIG_MIPS_UNCACHEDset (under "Kernel hacking", "run uncached")? this will slow down the kernel that does the kexec, but if this works, then it is most probably a cache problem.Could you also indicate the last lines of kernel messages just before the "Bye." ?
I'll try that later today and will post the results.
Quoted 1 line
Are you trying to kexec a big kernel image ?
Hmm, is it big? It's the same kernel I booted:
# ls -l vmlinux -rwxr-xr-x 1 root root 3868065 May 26 23:30 vmlinux
Quoted 2 lines
how much RAM do you have
on the board ?
It has 32 MB RAM; some ~11 MB is used before I load another kernel.
Quoted 2 lines
are there some hardware that could have a hard time to be re-probed by the kexeced linux kernel ?
The kexeced kernel is the same one I booted, so no.
Signature · 7 lines
Tomasz Chmielewski http://wpkg.org _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
Quoted 8 lines · Nicolas Schichan
Quoted 6 lines · On Tuesday 27 May 2008 20:14:11 you wrote:
Aah, I see.
Anyway, it doesn't work - with or without this slight change in
machine_kexec.c, with kexec compiled from the sources in the link you gave or with kexec-tools-testing-20080324, it just doesn't work on BCM43XX with OpenWRT patches. At least on Asus WL-500gP.
Quoted 7 lines
I'm not familiar with broadcom CPU names, but isn't BCM43XX supposed to be a Wifi chipset ? :)
However, could you kexec a kernel from a kernel that has
CONFIG_MIPS_UNCACHEDset (under "Kernel hacking", "run uncached")? this will slow down the kernel that does the kexec, but if this works, then it is most probably a cache problem.
I guess I'm not that lucky. Either CONFIG_MIPS_UNCACHED slowed the device down so much that it didn't boot, or it didn't boot. Hey, isn't it the same? So either BCM43XX doesn't work very well with certain kernel options enabled/disabled, or OpenWRT patches still lack some features to make ASUS WL-500gP properly (added openwrt-devel to CC:).
Without CONFIG_MIPS_UNCACHED it boots just fine.
Here is what is displayed when doing "kexec -e" (using kexec-tools-testing-20080324):
# kexec -e b44: eth0: powering down PHY Starting new kernel Will call new kernel at 00305000 Bye ...
Below, a full bootup up to the point where it freezes with CONFIG_MIPS_UNCACHED enabled (every message is printed very fast, up until the last "usbcore", where nothing else shows up):
CFE version 1.0.37 for BCM947XX (32bit,SP,LE)
Build Date: �| 10�� 12 22:21:19 CST 2006 ([email protected]) Copyright (C) 2000,2001,2002,2003 Broadcom Corporation.
Initializing Arena
Initializing Devices.
et0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 3.90.7.0
rndis0: Broadcom USB RNDIS Network Adapter (P-t-P) CPU type 0x29006: 264MHz
Total memory: 33554432 KBytes
Total memory used by CFE: 0x80800000 - 0x8089AF40 (634688) Initialized Data: 0x808313D0 - 0x80833790 (9152) BSS Area: 0x80833790 - 0x80834F40 (6064) Local Heap: 0x80834F40 - 0x80898F40 (409600) Stack Area: 0x80898F40 - 0x8089AF40 (8192) Text (code) segment: 0x80800000 - 0x808313D0 (201680) Boot area (physical): 0x0089B000 - 0x008DB000 Relocation Factor: I:00000000 - D:00000000
Device eth0: hwaddr 00-0E-A6-F1-ED-3C, ipaddr 192.168.1.1, mask 255.255.255.0
gateway not set, nameserver not set
Null Rescue Flag.
Loader:raw Filesys:raw Dev:flash0.os File: Options:(null)
Loading: .. 3768 bytes read
Entry at 0x80001000
Closing network.
Starting program at 0x80001000
Linux version 2.6.25.4 (build@dom) (gcc version 4.1.2) #5 Thu May 29 21:45:46 CEST 2008
console [early0] enabled
CPU revision is: 00029006 (Broadcom BCM3302)
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x03, vendor 0x4243)
ssb: Core 1 found: Fast Ethernet (cc 0x806, rev 0x06, vendor 0x4243)
ssb: Core 2 found: Fast Ethernet (cc 0x806, rev 0x06, vendor 0x4243)
ssb: Core 3 found: USB 1.1 Hostdev (cc 0x808, rev 0x03, vendor 0x4243)
ssb: Core 4 found: PCI (cc 0x804, rev 0x08, vendor 0x4243)
ssb: Core 5 found: MIPS 3302 (cc 0x816, rev 0x03, vendor 0x4243)
ssb: Core 6 found: V90 (cc 0x807, rev 0x02, vendor 0x4243)
ssb: Core 7 found: IPSEC (cc 0x80B, rev 0x00, vendor 0x4243)
ssb: Core 8 found: MEMC SDRAM (cc 0x80F, rev 0x02, vendor 0x4243)
ssb: Initializing MIPS core...
ssb: set_irq: core 0x0806, irq 2 => 2
ssb: set_irq: core 0x0806, irq 3 => 3
ssb: set_irq: core 0x0804, irq 0 => 4
ssb: Sonics Silicon Backplane found at address 0x18000000 Serial init done.
Determined physical RAM map:
memory: 02000000 @ 00000000 (usable)
Initrd not found or empty - disabling initrd
Zone PFN ranges:
Normal 0 -> 8192
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 8192
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128 Kernel command line: root=/dev/sda1 rootdelay=10 console=ttyS0,115200 Primary instruction cache 16kB, VIPT, 2-way, linesize 16 bytes. Primary data cache 16kB, 2-way, VIPT, cache aliases, linesize 16 bytes Synthesized clear page handler (26 instructions).
Synthesized copy page handler (46 instructions).
PID hash table entries: 128 (order: 7, 512 bytes)
console handover: boot [early0] -> real [ttyS0]
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 29376k/32768k available (2409k kernel code, 3392k reserved, 392k data, 144k init, 0k highmem)
Mount-cache hash table entries: 512net_namespace: 440 bytes
NET: Registered protocol family 16
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
With CONFIG_MIPS_UNCACHED disabled, it continues like here:
ssb: PCIcore in host mode found
Registering a PCI bus after boot
PCI: Fixing up bridge 0000:00:00.0
PCI: Fixing up device 0000:00:00.0
PCI: Fixing latency timer of device 0000:00:00.0 to 168
PCI: Enabling device 0000:00:02.0 (0000 -> 0002)
PCI: Fixing up device 0000:00:02.0
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243)
ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09, vendor 0x4243)
ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243)
ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243)
ssb: Sonics Silicon Backplane found on PCI device 0000:00:02.0
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 1024 (order: 1, 8192 bytes) TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024) TCP reno registered
detected lzma initramfs
initramfs: LZMA lc=1,lp=2,pb=2,origSize=512
squashfs: version 3.0 (2006/03/15) Phillip Lougher Registering mini_fo version $Id$
(...)
Signature · 9 lines
Tomasz Chmielewski http://wpkg.org _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
Quoted 6 lines · On Tuesday 27 May 2008 20:14:11 you wrote:
Aah, I see.
Anyway, it doesn't work - with or without this slight change in
machine_kexec.c, with kexec compiled from the sources in the link you gave or with kexec-tools-testing-20080324, it just doesn't work on BCM43XX with OpenWRT patches. At least on Asus WL-500gP.
I'm not familiar with broadcom CPU names, but isn't BCM43XX supposed to be a Wifi chipset ? :)
However, could you kexec a kernel from a kernel that hasCONFIG_MIPS_UNCACHED set (under "Kernel hacking", "run uncached")? this will slow down the kernel that does the kexec, but if this works, then it is most probably a cache problem.
Could you also indicate the last lines of kernel messages just before the "Bye." ?
Are you trying to kexec a big kernel image ? how much RAM do you have on the board ? are there some hardware that could have a hard time to be re-probed by the kexeced linux kernel ?
Regards,
Signature · 1 line
Nicolas Schichan
Quoted 5 lines · Tomasz Chmielewski
I guess I'm not that lucky. Either
CONFIG_MIPS_UNCACHEDslowed the device down so much that it didn't boot, or it didn't boot. Hey, isn't it the same? So either BCM43XX doesn't work very well with certain kernel options enabled/disabled, or OpenWRT patches still lack some features to make ASUS WL-500gP properly (added openwrt-devel to CC:).
LL/SC are undefined on uncached memory. Implementers are free to keep
the instructions working the same way as on cached memory, but are not required to do so and your chip may be an example. Of course the reason of the hang you see may be different, but this is one plausible explanation. I wouldn't trust a kernel running with CONFIG_MIPS_UNCACHED enabled -- it is merely a debugging hack.
Maciej
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Quoted 4 lines · On Thursday 29 May 2008 22:15:47 Tomasz Chmielewski wrote:
# kexec -e b44: eth0: powering down PHY Starting new kernel Will call new kernel at 00305000
The calling address of the kernel looks quite wrong, it should clearly be inside the KSEG0 zone. could you please indicate the output of the command "mips-linux-readelf -l vmlinux" ?
Regards,
Signature · 7 lines
Nicolas Schichan _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
Quoted 9 lines · Nicolas Schichan
Quoted 4 lines · On Thursday 29 May 2008 22:15:47 Tomasz Chmielewski wrote:
# kexec -e b44: eth0: powering down PHY Starting new kernel Will call new kernel at 00305000The calling address of the kernel looks quite wrong, it should clearly be inside the KSEG0 zone. could you please indicate the output of the command "mips-linux-readelf -l vmlinux" ?
# uname -m mips # readelf -l vmlinux
Elf file type is EXEC (Executable file) Entry point 0x80251b50
There are 2 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x001000 0x80001000 0x80001000 0x2dd07a 0x303250 RWE0x2000
NOTE 0x000000 0x00000000 0x00000000 0x00000 0x00000 R 0x4
Section to Segment mapping:
Segment Sections...
00 .text __ex_table __dbe_table .rodata .pci_fixup __ksymtab__ksymtab_gpl __ksymtab_strings __param .data .data.cacheline_aligned .init.text .init.data .init.setup .initcall.init .con_initcall.init .exit.text .init.ramfs .bss
01
Signature · 7 lines
Tomasz Chmielewski http://wpkg.org _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
On Friday 30 May 2008 13:39:16 Tomasz Chmielewski wrote:
Hello,
Quoted 8 lines
Quoted 6 lines · Nicolas Schichan
Quoted 1 line · On Thursday 29 May 2008 22:15:47 Tomasz Chmielewski wrote:
Will call new kernel at 00305000
The calling address of the kernel looks quite wrong, it should clearly be inside the KSEG0 zone. could you please indicate the output of the command "mips-linux-readelf -l vmlinux" ?
Quoted 6 lines
# uname -m mips # readelf -l vmlinuxElf file type is EXEC (Executable file)
Entry point0x80251b50
This is quite surprising. The jump address that kexec will use is
cleary not what I expected. I would have expected it to be the Entry point address given by readelf.
could you try the following patch to make sure that the kimage* structure is not corrupted by the code in machine_kexec() ?
arch/mips/kernel/machine_kexec.c +2 -0
@@ -49,6 +49,8 @@unsigned long entry;unsigned long *ptr; +printk ("image->start = %p" , image->start); + reboot_code_buffer = (unsigned long )page_address (image->control_code_page);
Regards,
Signature · 1 line
Nicolas Schichan
Quoted 29 lines · Nicolas Schichan
On Friday 30 May 2008 13:39:16 Tomasz Chmielewski wrote:
Hello,
Quoted 6 lines
Quoted 5 lines · Nicolas Schichan
Quoted 1 line · On Thursday 29 May 2008 22:15:47 Tomasz Chmielewski wrote:
Will call new kernel at 00305000
The calling address of the kernel looks quite wrong, it should clearly be inside the KSEG0 zone. could you please indicate the output of the command "mips-linux-readelf -l vmlinux" ?
Quoted 6 lines
# uname -m mips # readelf -l vmlinuxElf file type is EXEC (Executable file)
Entry point0x80251b50This is quite surprising. The jump address that kexec will use is
cleary not what I expected. I would have expected it to be the Entry point address given by readelf.could you try the following patch to make sure that the kimage* structure is not corrupted by the code in
machine_kexec()?Index:
linux/arch/mips/kernel/machine_kexec.c
===================================================================
arch/mips/kernel/machine_kexec.c line 55
Quoted 7 lines
arch/mips/kernel/machine_kexec.c +2
-0@@ -49,6 +49,8 @@unsigned long entry;unsigned long *ptr; +printk ("image->start = %p" , image->start); + reboot_code_buffer = (unsigned long )page_address (image->control_code_page);
Umm?
CC arch/mips/kernel/machine_kexec.o
cc1: warnings being treated as errors arch/mips/kernel/machine_kexec.c: In function 'machine_kexec':arch/mips/kernel/machine_kexec.c:52: warning: format '%p' expects type 'void *', but argument 2 has type 'long unsigned int' make[6]: *** [arch/mips/kernel/machine_kexec.o] Error 1 make[5]: *** [arch/mips/kernel] Error 2
make[5]: Leaving directory `/home/tch-data/openwrt/11612/build_dir/linux-brcm47xx/linux-2.6.25.9'
Signature · 7 lines
Tomasz Chmielewski http://wpkg.org _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
Quoted 15 lines · On Tuesday 01 July 2008 19:53:17 Tomasz Chmielewski wrote:
arch/mips/kernel/machine_kexec.c line 55
Quoted 12 lines
Index:
linux/arch/mips/kernel/machine_kexec.c
===================================================================arch/mips/kernel/machine_kexec.c +2
-0@@ -49,6 +49,8 @@unsigned long entry;unsigned long *ptr; +printk ("image->start = %p" , image->start); + reboot_code_buffer = (unsigned long )page_address (image->control_code_page);Umm?
Quoted 9 lines
CC
arch/mips/kernel/machine_kexec.o
cc1: warnings being treated as errorsarch/mips/kernel/machine_kexec.c: In function 'machine_kexec':arch/mips/kernel/machine_kexec.c:52: warning: format '%p' expects type 'void *', but argument 2 has type 'long unsigned int' make[6]: *** [arch/mips/kernel/machine_kexec.o] Error 1 make[5]: *** [arch/mips/kernel] Error 2
make[5]: Leaving directory `/home/tch-data/openwrt/11612/build_dir/linux-brcm47xx/linux-2.6.25.9'
-Werror is missing from my kernel cflags.
Try this one, %lx will accept unsigned long parameters without warnings:
arch/mips/kernel/machine_kexec.c +2 -0
@@ -49,6 +49,8 @@unsigned long entry;unsigned long *ptr; +printk ("image->start = %lx" , image->start); + reboot_code_buffer = (unsigned long )page_address (image->control_code_page);
Regards,
Signature · 7 lines
Nicolas Schichan _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
arch/mips/kernel/machine_kexec.c line 55
Quoted 4 lines · Nicolas Schichan
arch/mips/kernel/machine_kexec.c +2
-0+printk ("image->start = %lx" , image->start); + reboot_code_buffer = (unsigned long )page_address (image->control_code_page);
# kexec -e b44: eth0: powering down PHY Starting new kernel image->start = 304000Will call new kernel at 00304000 Bye ...
Signature · 7 lines
Tomasz Chmielewski http://wpkg.org _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
Nicolas Schichan schrieb:
(...)
arch/mips/kernel/machine_kexec.c line 53
Quoted 2 lines
arch/mips/kernel/machine_kexec.c +2
-0+printk ("image->start = %lx" , image->start); +
And this is what happens if I use your "util.c for kexec-userland" - why does it use a different address?
# /root/kexec-test/kexec -r Starting new kernel image->start = 802520d0Will call new kernel at 802520d0 Bye ...
Signature · 8 lines
Tomasz Chmielewski http://wpkg.org _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
is there any solution for this, i have the same problem
Quoted 22 lines · mangoo
arch/mips/kernel/machine_kexec.c line 55
Quoted 4 lines · Nicolas Schichan
arch/mips/kernel/machine_kexec.c +2
-0+printk ("image->start = %lx" , image->start); + reboot_code_buffer = (unsigned long )page_address (image->control_code_page);# kexec -e b44: eth0: powering down PHY Starting new kernel image->start = 304000Will call new kernel at 00304000 Bye ...Signature · 2 lines
Tomasz Chmielewski http://wpkg.org
Signature · 2 lines
View this message in context: http://www.nabble.com/kexec-on-mips---anyone-has-it-working--tp17485898p22148789.html Sent from the linux-mips main mailing list archive at Nabble.com.
wurststulle <[email protected]> writes:
Hi,
Quoted 1 line
is there any solution for this, i have the same problem
What's your exact problem ? It hangs right after saying 'Bye...' ? Some monthes ago, I played with the patch from M. Syrchin [ sorry, I don't remember if it was on linux-mips or on the kexec list ]. I've made on it a small modification (compare the machine_kexec_prepare function in my version [1] and the original function) and it was somewhat working on Qemu and on my box. It was not perfect but at least with a very minimal test system, it was working. Maybe you can try it and see if it works for you too. Depending on your platform, you may have to define machine specific hooks too.
Regards,
Arnaud
hi, thank you for the patch, but there is a mistake, that i can not fix:
+#ifdef CONFIG_CRASH_DUMP
+ if (crashk_res.start != crashk_res.end)
+ reserve_bootmem(crashk_res.start,
+ crashk_res.end - crashk_res.start + 1);
+#endif
the function reserve_bootmem need i think three arguments. while compiling this error occurs:
arch/mips/kernel/setup.c: In function 'arch_mem_init':arch/mips/kernel/setup.c:493: error: too few arguments to function 'reserve_bootmem'
make[6]: *** [arch/mips/kernel/setup.o] Error 1
thanks!
Quoted 24 lines · Arnaud Patard
wurststulle <[email protected]> writes:
Hi,
Quoted 1 line
is there any solution for this, i have the same problem
What's your exact problem ? It hangs right after saying 'Bye...' ? Some monthes ago, I played with the patch from M. Syrchin [ sorry, I don't remember if it was on linux-mips or on the kexec list ]. I've made on it a small modification (compare the
machine_kexec_preparefunction in my version [1] and the original function) and it was somewhat working on Qemu and on my box. It was not perfect but at least with a very minimal test system, it was working. Maybe you can try it and see if it works for you too. Depending on your platform, you may have to define machine specific hooks too.Regards,
Arnaud
Signature · 2 lines
View this message in context: http://www.nabble.com/kexec-on-mips---anyone-has-it-working--tp17485898p22167417.html Sent from the linux-mips main mailing list archive at Nabble.com.
Quoted 8 lines · wurststulle
hi, thank you for the patch, but there is a mistake, that i can not fix:
(quoted diff) +5
-0+#ifdef CONFIG_CRASH_DUMP + if (crashk_res.start != crashk_res.end) + reserve_bootmem(crashk_res.start, + crashk_res.end - crashk_res.start + 1); +#endif
Quoted 6 lines
the function
reserve_bootmemneed i think three arguments. while compiling this error occurs:
arch/mips/kernel/setup.c: In function 'arch_mem_init':arch/mips/kernel/setup.c:493: error: too few arguments to function 'reserve_bootmem'
oops. Adding BOOTMEM_DEFAULT as 3rd parameter should cure the problem I think.
Arnaud