kexec on mips - anyone has it working?

kexec on mips - anyone has it working?

[Tomasz Chmielewski]

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?



-- 
Tomasz Chmielewski
http://wpkg.org

Re: kexec on mips - anyone has it working?

[Nicolas Schichan]

[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]

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

-- 
Nicolas Schichan

[-- Attachment #2: Type: text/html, Size: 2716 bytes --]

Re: kexec on mips - anyone has it working?

[Tomasz Chmielewski]

Nicolas Schichan schrieb:

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


-- 
Tomasz Chmielewski
http://wpkg.org

Re: kexec on mips - anyone has it working?

[Nicolas Schichan]

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,

-- 
Nicolas Schichan

Re: kexec on mips - anyone has it working?

[Nicolas Schichan]

On Tuesday 27 May 2008 14:40:21 you wrote:
> > 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?


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:

--- linux/arch/mips/kernel/machine_kexec.c	(revision 8056)
+++ linux/arch/mips/kernel/machine_kexec.c	(working copy)
@@ -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)();
 }



-- 
Nicolas Schichan

Re: kexec on mips - anyone has it working?

[Tomasz Chmielewski]

Nicolas Schichan schrieb:
> On Tuesday 27 May 2008 14:40:21 you wrote:
>>> 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?
> 
> 
> machine_kexec.c is 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.


-- 
Tomasz Chmielewski
http://wpkg.org

Re: kexec on mips - anyone has it working?

[Simon Horman]

On Tue, May 27, 2008 at 08:14:11PM +0200, Tomasz Chmielewski wrote:
> Nicolas Schichan schrieb:
> > On Tuesday 27 May 2008 14:40:21 you wrote:
> >>> 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?
> > 
> > 
> > machine_kexec.c is 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.

-- 
Horms

Re: kexec on mips - anyone has it working?

[Nicolas Schichan]

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  has
CONFIG_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,

-- 
Nicolas Schichan

Re: kexec on mips - anyone has it working?

[Tomasz Chmielewski]

Nicolas Schichan schrieb:
> 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? ;)


> However,  could   you  kexec   a  kernel  from   a  kernel   that  has
> CONFIG_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." ?

I'll try that later today and will post the results.


> 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


> how much RAM do you have
> on the board ?

It has 32 MB RAM; some ~11 MB is used before I load another kernel.


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


-- 
Tomasz Chmielewski
http://wpkg.org

Re: kexec on mips - anyone has it working?

[Tomasz Chmielewski]

Nicolas Schichan schrieb:
> 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  has
> CONFIG_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.

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 (root@localhost.localdomain)
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: 512
net_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$
(...)


-- 
Tomasz Chmielewski
http://wpkg.org

Re: kexec on mips - anyone has it working?

[Maciej W. Rozycki]

On Thu, 29 May 2008, Tomasz Chmielewski wrote:

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

 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

Re: kexec on mips - anyone has it working?

[Nicolas Schichan]

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,

-- 
Nicolas Schichan

Re: kexec on mips - anyone has it working?

[Tomasz Chmielewski]

Nicolas Schichan schrieb:
> 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" ?

# 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 RWE 
0x2000
   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

-- 
Tomasz Chmielewski
http://wpkg.org

Re: kexec on mips - anyone has it working?

[Nicolas Schichan]

On Friday 30 May 2008 13:39:16 Tomasz Chmielewski wrote:

Hello,

> Nicolas Schichan schrieb:
> > 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" ?
>
> # uname -m
> mips
> # readelf -l vmlinux
>
> Elf file type is EXEC (Executable file)
> Entry point 0x80251b50

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() ?

Index: linux/arch/mips/kernel/machine_kexec.c
===================================================================
--- linux/arch/mips/kernel/machine_kexec.c	(revision 8056)
+++ linux/arch/mips/kernel/machine_kexec.c	(working copy)
@@ -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,

-- 
Nicolas Schichan

Re: kexec on mips - anyone has it working?

[Tomasz Chmielewski]

Nicolas Schichan schrieb:
> On Friday 30 May 2008 13:39:16 Tomasz Chmielewski wrote:
> 
> Hello,
> 
>> Nicolas Schichan schrieb:
>>> 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" ?
>> # uname -m
>> mips
>> # readelf -l vmlinux
>>
>> Elf file type is EXEC (Executable file)
>> Entry point 0x80251b50
> 
> 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() ?
> 
> Index: linux/arch/mips/kernel/machine_kexec.c
> ===================================================================
> --- linux/arch/mips/kernel/machine_kexec.c	(revision 8056)
> +++ linux/arch/mips/kernel/machine_kexec.c	(working copy)
> @@ -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'



-- 
Tomasz Chmielewski
http://wpkg.org

Re: kexec on mips - anyone has it working?

[Nicolas Schichan]

On Tuesday 01 July 2008 19:53:17 Tomasz Chmielewski wrote:
> > Index: linux/arch/mips/kernel/machine_kexec.c
> > ===================================================================
> > --- linux/arch/mips/kernel/machine_kexec.c	(revision 8056)
> > +++ linux/arch/mips/kernel/machine_kexec.c	(working copy)
> > @@ -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'

-Werror is missing from my kernel cflags.

Try this one, %lx will accept unsigned long parameters without warnings:

Index: linux/arch/mips/kernel/machine_kexec.c
===================================================================
--- linux/arch/mips/kernel/machine_kexec.c	(revision 8056)
+++ linux/arch/mips/kernel/machine_kexec.c	(working copy)
@@ -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,


-- 
Nicolas Schichan

Re: kexec on mips - anyone has it working?

[Tomasz Chmielewski]

Nicolas Schichan schrieb:

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



-- 
Tomasz Chmielewski
http://wpkg.org

Re: kexec on mips - anyone has it working?

[Tomasz Chmielewski]

Nicolas Schichan schrieb:

(...)

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


-- 
Tomasz Chmielewski
http://wpkg.org

Re: kexec on mips - anyone has it working?

[wurststulle]

is there any solution for this, i have the same problem

mangoo wrote:
> 
> Nicolas Schichan schrieb:
> 
>> +	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 ...
> 
> 
> 
> -- 
> Tomasz Chmielewski
> http://wpkg.org
> 
> 
> 

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

Re: kexec on mips - anyone has it working?

[Arnaud Patard]

wurststulle <wurststulle@gmail.com> writes:

Hi,

> 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

[1] http://people.mandriva.com/~apatard/kexec_mips.patch

Re: kexec on mips - anyone has it working?

[wurststulle]

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!


Arnaud Patard wrote:
> 
> wurststulle <wurststulle@gmail.com> writes:
> 
> Hi,
> 
>> 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
> 
> [1] http://people.mandriva.com/~apatard/kexec_mips.patch
> 
> 
> 

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

Re: kexec on mips - anyone has it working?

[Arnaud Patard]

wurststulle <wurststulle@gmail.com> writes:

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

oops. Adding BOOTMEM_DEFAULT as 3rd parameter should cure the problem I
think.


Arnaud