Building 64 bit kernel on Cobalt

Last working Kernel was 2.6.19 series.

Some changes from 2.6.19 and the 2.6.20 make it impossible to build a 64 bit kernel to boot on the cobalt. Ya, I know why, building a N32 actually but need a 64 bit kernel in order to do that. Anyone got any suggestions. Looking through the difference between the kernels to figure this out, but it's like looking for a needle in a haystack. Any suggestions as to a starting point?

Try git-bisect to track down the changeset that broke things.

Ralf

We got it nailed down to arch/mips/kernel /setup.c. But we have not isolated which change is actually causing it.

We do know that reverting back to the 2.6.19.x arch/mips/kernel /setup.c will fix the issue. We will continue to dwindle it down until we come up with the offender.

Here's what we isolated it to.

The problem looks like this

inflate: decompressing
elf64: 00080000 - 0037701f (ffffffff.80326000) (ffffffff.80000000)
elf64: ffffffff.80080000 (80080000) 2957446t + 151450t
net: interface down

If we apply the patch that's attached we can boot all the way up, but we do get some errors. I'm hoping one of these errors might shed the light on what the actual issue is.

VFS: Mounted root (nfs filesystem) readonly.
Unhandled kernel unaligned access[#1]:
Cpu 0

$ 0   : 0000000000000000 ffffffff802adc60 0000000000000000 0000000000000000
$ 4   : ffffffff80089eec ffffffffde020000 ffffffff8008c588 0000000000000000
$ 8   : 0000000000561024 996bffffff40b050 0000000000000000 000000000000f6f8
$12   : ffffffff94004ce0 000000001000001e 0000000000000000 ffffffff80300000
$16   : 9800000000387df0 ffffffff80326000 0000000000000000 00067ffffff80326
$20   : 00067ffffff80326 000000000000002d fffffffffffffbff 67ffffff80353000
$24   : 0000000000000010 ffffffff801768d8
$28   : 9800000000384000 9800000000387dc0 67ffffff80326000 ffffffff80081e28
Hi    : 0000000000000000
Lo    : 0000000000000000
epc   : ffffffff80089f04 do_ade+0x3a4/0x4c0     Not tainted
ra    : ffffffff80081e28 ret_from_exception+0x0/0x1c
Status: 94004ce2    KX SX UX KERNEL EXL
Cause : 00808010
BadVA : 996bffffff40b057
PrId  : 000028a0
Process swapper (pid: 1, threadinfo=9800000000384000, task=9800000000381828)
Stack : 996bffffff40b050 ffffffff80326000 016bfffffe40b050 00067ffffff80326
       ffffffff80081e28 0000000000000000 0000000000000000 ffffffff94004ce0
       9800000001000000 019ffffffe00c980 ffffffff94004ce1 00067ffffff80353
       6800000000000000 9800000000381828 98000000013e9a40 98000000003b3000
       ffffffff80309758 000000000000f6f8 0000000000000001 ffffffff801b9388
       0000000000000000 ffffffff80300000 996bffffff40b050 ffffffff80326000
       016bfffffe40b050 00067ffffff80326 00067ffffff80326 000000000000002d
       fffffffffffffbff 67ffffff80353000 0000000000000010 ffffffff801768d8
       ffffffff800fb5ac ffffffff800fb5ac 9800000000384000 9800000000387f20
       67ffffff80326000 ffffffff8008c4d0 ffffffff94004ce2 0000000000000000
       ...
Call Trace:
[<ffffffff80089f04>] do_ade+0x3a4/0x4c0
[<ffffffff80081e28>] ret_from_exception+0x0/0x1c
[<ffffffff8008c588>] free_initmem+0xe8/0x218
[<ffffffff80080688>] init+0x248/0x510
[<ffffffff80084420>] kernel_thread_helper+0x10/0x18

Code: 00431024  5440ff77  de020100 <69230007> 6d230000  24020000  1440ffba  00051402  08022760
Kernel panic - not syncing: Attempted to kill init!

patch - at http://ftp.jg555.com/revert.working.diff

@@ -145,13 +145,12 @@
 	unsigned long start = memparse(p, &p);
 
 #ifdef CONFIG_64BIT
-	/* HACK: Guess if the sign extension was forgotten */
-	if (start > 0x0000000080000000 && start < 0x00000000ffffffff)
-		start |= 0xffffffff00000000UL;
+	/* Guess if the sign extension was forgotten by bootloader */
+	if (start < XKPHYS)
+		start = (int)start;
 #endif
 	initrd_start = start;
 	initrd_end += start;
-
 	return 0;
 }
 early_param("rd_start", rd_start_early);

@@ -159,41 +158,64 @@
 static int __init rd_size_early(char *p)
 {
 	initrd_end += memparse(p, &p);
-
 	return 0;
 }
 early_param("rd_size", rd_size_early);
 
+/* it returns the next free pfn after initrd */
 static unsigned long __init init_initrd(void)
 {
-	unsigned long tmp, end, size;
+	unsigned long end;
 	u32 *initrd_header;
 
-	ROOT_DEV = Root_RAM0;
-
 	/*
 	 * Board specific code or command line parser should have
 	 * already set up initrd_start and initrd_end. In these cases
 	 * perfom sanity checks and use them if all looks good.
 	 */
-	size = initrd_end - initrd_start;
-	if (initrd_end == 0 || size == 0) {
-		initrd_start = 0;
-		initrd_end = 0;
-	} else
-		return initrd_end;
-
-	end = (unsigned long)&_end;
-	tmp = PAGE_ALIGN(end) - sizeof(u32) * 2;
-	if (tmp < end)
-		tmp += PAGE_SIZE;
-
-	initrd_header = (u32 *)tmp;
-	if (initrd_header[0] == 0x494E5244) {
-		initrd_start = (unsigned long)&initrd_header[2];
-		initrd_end = initrd_start + initrd_header[1];
+	if (initrd_start && initrd_end > initrd_start)
+		goto sanitize;
+
+	/*
+	 * See if initrd has been added to the kernel image by
+	 * arch/mips/boot/addinitrd.c. In that case a header is
+	 * prepended to initrd and is made up by 8 bytes. The fisrt
+	 * word is a magic number and the second one is the size of
+	 * initrd.  Initrd start must be page aligned in any cases.
+	 */
+	initrd_header = __va(PAGE_ALIGN(__pa_symbol(&_end) + 8)) - 8;
+	if (initrd_header[0] != 0x494E5244)
+		goto disable;
+	initrd_start = (unsigned long)(initrd_header + 2);
+	initrd_end = initrd_start + initrd_header[1];
+
+sanitize:
+	if (initrd_start & ~PAGE_MASK) {
+		printk(KERN_ERR "initrd start must be page aligned\n");
+		goto disable;
 	}
-	return initrd_end;
+	if (initrd_start < PAGE_OFFSET) {
+		printk(KERN_ERR "initrd start < PAGE_OFFSET\n");
+		goto disable;
+	}
+
+	/*
+	 * Sanitize initrd addresses. For example firmware
+	 * can't guess if they need to pass them through
+	 * 64-bits values if the kernel has been built in pure
+	 * 32-bit. We need also to switch from KSEG0 to XKPHYS
+	 * addresses now, so the code can now safely use __pa().
+	 */
+	end = __pa(initrd_end);
+	initrd_end = (unsigned long)__va(end);
+	initrd_start = (unsigned long)__va(__pa(initrd_start));
+
+	ROOT_DEV = Root_RAM0;
+	return PFN_UP(end);
+disable:
+	initrd_start = 0;
+	initrd_end = 0;
+	return 0;
 }
 
 static void __init finalize_initrd(void)

@@ -204,12 +226,12 @@
 		printk(KERN_INFO "Initrd not found or empty");
 		goto disable;
 	}
-	if (CPHYSADDR(initrd_end) > PFN_PHYS(max_low_pfn)) {
+	if (__pa(initrd_end) > PFN_PHYS(max_low_pfn)) {
 		printk("Initrd extends beyond end of memory");
 		goto disable;
 	}
 
-	reserve_bootmem(CPHYSADDR(initrd_start), size);
+	reserve_bootmem(__pa(initrd_start), size);
 	initrd_below_start_ok = 1;
 
 	printk(KERN_INFO "Initial ramdisk at: 0x%lx (%lu bytes)\n",

@@ -259,8 +281,7 @@
 	 * not selected. Once that done we can determine the low bound
 	 * of usable memory.
 	 */
-	reserved_end = init_initrd();
-	reserved_end = PFN_UP(CPHYSADDR(max(reserved_end, (unsigned long)&_end)));
+	reserved_end = max(init_initrd(), PFN_UP(__pa_symbol(&_end)));
 
 	/*
 	 * Find the highest page frame number we have available.

@@ -432,10 +453,10 @@
 	if (UNCAC_BASE != IO_BASE)
 		return;
 
-	code_resource.start = virt_to_phys(&_text);
-	code_resource.end = virt_to_phys(&_etext) - 1;
-	data_resource.start = virt_to_phys(&_etext);
-	data_resource.end = virt_to_phys(&_edata) - 1;
+	code_resource.start = __pa_symbol(&_text);
+	code_resource.end = __pa_symbol(&_etext) - 1;
+	data_resource.start = __pa_symbol(&_etext);
+	data_resource.end = __pa_symbol(&_edata) - 1;
 
 	/*
 	 * Request address space for all standard RAM.

@@ -500,7 +521,7 @@
 #endif
 }
 
-int __init fpu_disable(char *s)
+static int __init fpu_disable(char *s)
 {
 	int i;
 

@@ -512,7 +533,7 @@
 
 __setup("nofpu", fpu_disable);
 
-int __init dsp_disable(char *s)
+static int __init dsp_disable(char *s)
 {
 	cpu_data[0].ases &= ~MIPS_ASE_DSP;
 

Hi,

It seems that I broke things again :(

Do you use any initrd ? If so how do you pass its address to the kernel ?

What is your kernel load address ?

can you send your .config file you're using ?

What did the console say ? If nothing early console may help if available.

thanks

              Franck

No.

Not sure

I'll send it to you later, since I'm not at the office right now.

All I get is this
inflate: decompressing
elf64: 00080000 - 0037701f (ffffffff.80326000) (ffffffff.80000000)
elf64: ffffffff.80080000 (80080000) 2957446t + 151450t
net: interface down

Frank any ideas on a solution?

Where does this trace come from ? from a bootloader ?
I don't understand its format, can you explain ? All I can say that it seems that you're using CKSEG0 for kernel addresses.

You also said that you don't have any initrd. And most of the changes you reverted back is related to initrd except this part:

- reserved_end = init_initrd();
- reserved_end = PFN_UP(CPHYSADDR(max(reserved_end, (unsigned long)&_end)));
+ reserved_end = max(init_initrd(), PFN_UP(__pa_symbol(&_end)));

Can you try a plain 2.6.20 with this only change ? If it helps, can you give the value of 'reserved_end' in both cases ?

Do you use default cobalt config file ?

BTW does Cobalt platform have early printk available ? if so can you use it ?

              Franck

Yes, it does since a long time.

Ralf

Frank,
Got it narrowed down further. This reverting these 3 sections will
allow it to boot, but then mounting root it gives a unaligned access error. Reverting all the changes to setup.c, fixes the issue and boots completely.

@@ -204,12 +226,12 @@
               printk(KERN_INFO "Initrd not found or empty");
               goto disable;
       }
-       if (CPHYSADDR(initrd_end) > PFN_PHYS(max_low_pfn)) {
+       if (__pa(initrd_end) > PFN_PHYS(max_low_pfn)) {
               printk("Initrd extends beyond end of memory");
               goto disable;
       }
 
-       reserve_bootmem(CPHYSADDR(initrd_start), size);
+       reserve_bootmem(__pa(initrd_start), size);
       initrd_below_start_ok = 1;
 
       printk(KERN_INFO "Initial ramdisk at: 0x%lx (%lu bytes)\n",

@@ -259,8 +281,7 @@
        * not selected. Once that done we can determine the low bound
        * of usable memory.
        */
-       reserved_end = init_initrd();
-       reserved_end = PFN_UP(CPHYSADDR(max(reserved_end, (unsigned long)&_end)));
+       reserved_end = max(init_initrd(), PFN_UP(__pa_symbol(&_end)));
 
       /*
        * Find the highest page frame number we have available.

@@ -432,10 +453,10 @@
       if (UNCAC_BASE != IO_BASE)
               return;
 
-       code_resource.start = virt_to_phys(&_text);
-       code_resource.end = virt_to_phys(&_etext) - 1;
-       data_resource.start = virt_to_phys(&_etext);
-       data_resource.end = virt_to_phys(&_edata) - 1;
+       code_resource.start = __pa_symbol(&_text);
+       code_resource.end = __pa_symbol(&_etext) - 1;
+       data_resource.start = __pa_symbol(&_etext);
+       data_resource.end = __pa_symbol(&_edata) - 1;
 
       /*
        * Request address space for all standard RAM.

VFS: Mounted root (nfs filesystem) readonly.
Unhandled kernel unaligned access[#1]:
Cpu 0

$ 0   : 0000000000000000 ffffffff802adc70 0000000000000000 0000000000000000
$ 4   : ffffffff80089fac ffffffffde020000 ffffffff8008c648 0000000000000000
$ 8   : 0000000000561024 996bffffff40b050 0000000000000000 000000000000f6f8
$12   : ffffffff94004ce0 000000001000001e 0000000000000000 ffffffff80300000
$16   : 9800000000387df0 ffffffff80326000 0000000000000000 00067ffffff80326
$20   : 00067ffffff80326 000000000000002d fffffffffffffbff 67ffffff80353000
$24   : 0000000000000010 ffffffff80176998
$28   : 9800000000384000 9800000000387dc0 67ffffff80326000 ffffffff80081ee8
Hi    : 0000000000000000
Lo    : 0000000000000000
epc   : ffffffff80089fc4 do_ade+0x3a4/0x4c0     Not tainted
ra    : ffffffff80081ee8 ret_from_exception+0x0/0x1c
Status: 94004ce2    KX SX UX KERNEL EXL
Cause : 00808010
BadVA : 996bffffff40b057
PrId  : 000028a0
Process swapper (pid: 1, threadinfo=9800000000384000, task=9800000000381828)
Stack : 996bffffff40b050 ffffffff80326000 016bfffffe40b050 00067ffffff80326
       ffffffff80081ee8 0000000000000000 0000000000000000 ffffffff94004ce0
       9800000001000000 019ffffffe00c980 ffffffff94004ce1 00067ffffff80353
       6800000000000000 9800000000381828 98000000013e9a40 98000000003b3000
       ffffffff803097a8 000000000000f6f8 0000000000000001 ffffffff801b9448
       0000000000000000 ffffffff80300000 996bffffff40b050 ffffffff80326000
       016bfffffe40b050 00067ffffff80326 00067ffffff80326 000000000000002d
       fffffffffffffbff 67ffffff80353000 0000000000000010 ffffffff80176998
       ffffffff800fb66c ffffffff800fb66c 9800000000384000 9800000000387f20
       67ffffff80326000 ffffffff8008c590 ffffffff94004ce2 0000000000000000
       ...
Call Trace:
[<ffffffff80089fc4>] do_ade+0x3a4/0x4c0
[<ffffffff80081ee8>] ret_from_exception+0x0/0x1c
[<ffffffff8008c648>] free_initmem+0xe8/0x218
[<ffffffff80080688>] init+0x248/0x510
[<ffffffff800844e0>] kernel_thread_helper+0x10/0x18

Code: 00431024  5440ff77  de020100 <69230007> 6d230000  24020000  1440ffba  00051402  08022790

You said you are not using initrd, right? I can not see why these changes affects non-initrd environment. Full boot log and .config would help us to find what was wrong.

---
Atsushi Nemoto

Here's the config file I'm using http://ftp.jg555.com/cobalt.config
Now if I revert all changes that have occurred to setup.c from 2.6.19 to 2.6.20, everything works perfectly.

Without that patch, this is as far as it gets.

inflate: decompressing
elf64: 00080000 - 0037701f (ffffffff.80326000) (ffffffff.80000000)
elf64: ffffffff.80080000 (80080000) 2957446t + 151450t
net: interface down
Linux version 2.6.20.1 (root@build) (gcc version 4.1.2) #1 Sun Mar 18 22:07:40 PDT 2007 CPU revision is: 000028a0
FPU revision is: 000028a0
Cobalt board ID: 6
registering PCI controller with io_map_base unset
Cobalt: early console registered
Determined physical RAM map:
memory: 0000000010000000 @ 0000000000000000 (usable)

With the patch, here's the info

inflate: decompressing
elf64: 00080000 - 0037701f (ffffffff.80326000) (ffffffff.80000000)
elf64: ffffffff.80080000 (80080000) 2957446t + 151450t
net: interface down
Linux version 2.6.20.1 (root@build) (gcc version 4.1.2) #1 Sun Mar 18 22:15:54 PDT 2007 CPU revision is: 000028a0
FPU revision is: 000028a0
Cobalt board ID: 6
registering PCI controller with io_map_base unset
Cobalt: early console registered
Determined physical RAM map:
memory: 0000000010000000 @ 0000000000000000 (usable)
Built 1 zonelists. Total pages: 64640
Kernel command line: root=/dev/nfs nfsroot=192.168.55.2:/nfsroot console=ttyS0,115200 ip=dhcp Primary instruction cache 32kB, physically tagged, 2-way, linesize 32 bytes.
Primary data cache 32kB, 2-way, linesize 32 bytes.
Synthesized TLB refill handler (32 instructions).
Synthesized TLB load handler fastpath (46 instructions).
Synthesized TLB store handler fastpath (46 instructions).
Synthesized TLB modify handler fastpath (45 instructions).
PID hash table entries: 1024 (order: 10, 8192 bytes)
Linux version 2.6.20.1 (root@build) (gcc version 4.1.2) #1 Sun Mar 18 22:15:54 PDT 2007 CPU revision is: 000028a0
FPU revision is: 000028a0
Cobalt board ID: 6
registering PCI controller with io_map_base unset
Cobalt: early console registered
Determined physical RAM map:
memory: 0000000010000000 @ 0000000000000000 (usable)
Built 1 zonelists. Total pages: 64640
Kernel command line: root=/dev/nfs nfsroot=192.168.55.2:/nfsroot console=ttyS0,115200 ip=dhcp Primary instruction cache 32kB, physically tagged, 2-way, linesize 32 bytes.
Primary data cache 32kB, 2-way, linesize 32 bytes.
Synthesized TLB refill handler (32 instructions).
Synthesized TLB load handler fastpath (46 instructions).
Synthesized TLB store handler fastpath (46 instructions).
Synthesized TLB modify handler fastpath (45 instructions).
PID hash table entries: 1024 (order: 10, 8192 bytes)
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
Memory: 254464k/262144k available (2214k kernel code, 7540k reserved, 493k data, 180k init, 0k highmem) Mount-cache hash table entries: 256
Checking for the multiply/shift bug... no.
Checking for the daddi bug... no.
Checking for the daddiu bug... no.
NET: Registered protocol family 16
Galileo: fixed bridge class
Galileo: revision 17
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 2, 16384 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 4096)
TCP reno registered
io scheduler noop registered
io scheduler anticipatory registered (default)
Activating ISA DMA hang workarounds.
rtc: SRM (post-2000) epoch (2000) detected
Real Time Clock Driver v1.12ac
Cobalt LCD Driver v2.10
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
ÿserial8250: ttyS0 at I/O 0xc800000 (irq = 21) is a ST16650V2
Linux Tulip driver version 1.1.14 (December 15, 2004)
PCI: Enabling device 0000:00:07.0 (0041 -> 0043)
io_map_base of root PCI bus 0000:00 unset. Trying to continue but you better
fix this issue or report it to [email protected] or your vendor.

tulip0: Old format EEPROM on 'Cobalt Microserver' board.  Using substitute media control info.
tulip0:  EEPROM default media type Autosense.
tulip0:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
tulip0:  MII transceiver #1 config 1000 status 7809 advertising 01e1.
eth0: Digital DS21142/43 Tulip rev 65 at Port 0x1000, 00:10:E0:00:47:6E, IRQ 19.

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:09.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c586a (rev 27) IDE UDMA33 controller on pci0000:00:09.1
ide0: BM-DMA at 0x10a0-0x10a7, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0x10a8-0x10af, BIOS settings: hdc:pio, hdd:pio
ide0: I/O resource 0xFFFFFFFFF00003F6-0xFFFFFFFFF00003F6 not free.
ide0: ports already in use, skipping probe
ide1: I/O resource 0xFFFFFFFFF0000376-0xFFFFFFFFF0000376 not free.
ide1: ports already in use, skipping probe
ide0: I/O resource 0xFFFFFFFFF00003F6-0xFFFFFFFFF00003F6 not free.
ide0: ports already in use, skipping probe
ide1: I/O resource 0xFFFFFFFFF0000376-0xFFFFFFFFF0000376 not free.
ide1: ports already in use, skipping probe
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Sending DHCP requests .<7>0000:00:07.0: tulip_stop_rxtx() failed (CSR5 0xf0660000 CSR6 0xb20e2202)
eth0: Setting full-duplex based on MII#1 link partner capability of 4de1.
., OK
IP-Config: Got DHCP answer from 192.168.55.2, my address is 192.168.55.112
IP-Config: Complete:

     device=eth0, addr=192.168.55.112, mask=255.255.255.0, gw=192.168.55.1,
    host=raq22, domain=jg555.com, nis-domain=(none),
    bootserver=192.168.55.2, rootserver=192.168.55.2, rootpath=/nfsroot

Looking up port of RPC 100003/2 on 192.168.55.2
Looking up port of RPC 100005/1 on 192.168.55.2
VFS: Mounted root (nfs filesystem) readonly.
Unhandled kernel unaligned access[#1]:
Cpu 0

$ 0   : 0000000000000000 ffffffff802adc70 0000000000000000 0000000000000000
$ 4   : ffffffff80089fac ffffffffde020000 ffffffff8008c648 0000000000000000
$ 8   : 0000000000561024 996bffffff40b050 0000000000000000 000000000000f6f8
$12   : ffffffff94004ce0 000000001000001e 0000000000000000 ffffffff80300000
$16   : 9800000000387df0 ffffffff80326000 0000000000000000 00067ffffff80326
$20   : 00067ffffff80326 000000000000002d fffffffffffffbff 67ffffff80353000
$24   : 0000000000000010 ffffffff80176998
$28   : 9800000000384000 9800000000387dc0 67ffffff80326000 ffffffff80081ee8
Hi    : 0000000000000000
Lo    : 0000000000000000
epc   : ffffffff80089fc4 do_ade+0x3a4/0x4c0     Not tainted
ra    : ffffffff80081ee8 ret_from_exception+0x0/0x1c
Status: 94004ce2    KX SX UX KERNEL EXL
Cause : 00808010
BadVA : 996bffffff40b057
PrId  : 000028a0
Process swapper (pid: 1, threadinfo=9800000000384000, task=9800000000381828)
Stack : 996bffffff40b050 ffffffff80326000 016bfffffe40b050 00067ffffff80326
       ffffffff80081ee8 0000000000000000 0000000000000000 ffffffff94004ce0
       9800000001000000 019ffffffe00c980 ffffffff94004ce1 00067ffffff80353
       6800000000000000 9800000000381828 98000000013e9a40 98000000003b3000
       ffffffff803097a8 000000000000f6f8 0000000000000001 ffffffff801b9448
       0000000000000000 ffffffff80300000 996bffffff40b050 ffffffff80326000
       016bfffffe40b050 00067ffffff80326 00067ffffff80326 000000000000002d
       fffffffffffffbff 67ffffff80353000 0000000000000010 ffffffff80176998
       ffffffff800fb66c ffffffff800fb66c 9800000000384000 9800000000387f20
       67ffffff80326000 ffffffff8008c590 ffffffff94004ce2 0000000000000000
       ...
Call Trace:
[<ffffffff80089fc4>] do_ade+0x3a4/0x4c0
[<ffffffff80081ee8>] ret_from_exception+0x0/0x1c
[<ffffffff8008c648>] free_initmem+0xe8/0x218
[<ffffffff80080688>] init+0x248/0x510
[<ffffffff800844e0>] kernel_thread_helper+0x10/0x18

Code: 00431024  5440ff77  de020100 <69230007> 6d230000  24020000  1440ffba  00051402  08022790
Kernel panic - not syncing: Attempted to kill init!

You are using CONFIG_BUILD_ELF64=y and CKSEG0 load address. This combination does not work. Please refer these threads:

http://www.linux-mips.org/archives/linux-mips/2006-10/msg00064.html
http://www.linux-mips.org/archives/linux-mips/2006-10/msg00154.html
http://www.linux-mips.org/archives/linux-mips/2007-01/msg00305.html

Please try CONFIG_BUILD_ELF64=n.

BTW, Ralf, any chance to Franck's CONFIG_BUILD_ELF64 cleanup patchset? I hope the patchset make things clearer...

---
Atsushi Nemoto

Thanks Atsushi for sorting this out. It's a bit sad to get these type of information after so many email echanges...

Well, this patch may be not enough. From last thread about 64bits kernel issue:

http://marc.info/?l=linux-mips&m=117418351419352&w=2

It seems that objcopy can be used to do some addresses translations. In that case the current patch won't help. At least we could add more sanity checks to detect all buggy configs we can have for 64 bits kernel and panic if they fail.

              Franck

BTW, how this config has ever worked for a 2.6.19 kernel ? I don't see why using __pa() instead of CPHYSADDR() breaks this config...

              Franck

2.6.19:

	CPHYSADDR(0xffffffff80000000) == 0
	__pa(0xffffffff80000000) == 0xffffffff80000000 - 0x9800000000000000
2.6.20 (CONFIG_BUILD_ELF64=y):
	CPHYSADDR(0xffffffff80000000) == 0
	__pa(0xffffffff80000000) == 0xffffffff80000000 - 0x9800000000000000
2.6.20 (CONFIG_BUILD_ELF64=n):
	CPHYSADDR(0xffffffff80000000) == 0
	__pa(0xffffffff80000000) == 0

The reason is obvious, isn't it? ;)

---
Atsushi Nemoto

Yes it is !

After writing this I just realised that I was confused by what you said earlier:

You are using CONFIG_BUILD_ELF64=y and CKSEG0 load address. This combination does not work. Please refer these threads:

This combo should theoritically work but currently does not. Unlike the following one

CONFIG_BUILD_ELF64=n and XKPHYS load address.

which definitely don't work. And I mixed the second case with the first one...

no other comment ;)

              Franck

Cobalt's, being just like IP32, should work fine, provided that the __pa_page_offset() macro gets set properly. The thing isn't whether or not CKSEG0 works or doesn't work (IMHO, it works just fine), it's just making sure that macro gets set properly, and sanely.

These three systems (IP22, IP32, & Cobalt) are the kinds of systems that are gonna violate whatever rule that says CONFIG_BUILD_ELF64 && CKSEG0 is invalid. This is the nature of MIPS, especially on the SGI platform. They're also the most common types of machines end user/hobbyists are gonna get, so these machines need to work. If it was some obscure mips board only available for large sums of <insert currency>, then I figure things would be different.

Can someone review this patch for sanity? It achieves my desire and lets IP32 boot using the way I've been told (BUILD_ELF64 + -msym32 + vmlinux.32). Likely, it'll also do the same for Cobalt and IP22 64bit kernels (good luck getting those to work right anyways).

--Kumba

Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere."  --Elrond

diff -Naurp mipslinux/arch/mips/Kconfig mipslinux.ckseg0-a/arch/mips/Kconfig
@@ -1659,6 +1659,11 @@ config SB1_PASS_2_1_WORKAROUNDS
 	depends on CPU_SB1 && CPU_SB1_PASS_2
 	default y
 
+config SYS_LOADS_IN_CKSEG0
+	bool
+	depends on BUILD_ELF64 && (SGI_IP22 || (SGI_IP32 && (CPU_R5000 || CPU_NEVADA || CPU_RM7000)) || MIPS_COBALT)
+	default y
+
 config 64BIT_PHYS_ADDR
 	bool "Support for 64-bit physical address space"
 	depends on (CPU_R4X00 || CPU_R5000 || CPU_RM7000 || CPU_RM9000 || CPU_R10000 || CPU_SB1 || CPU_MIPS32 || CPU_MIPS64) && 32BIT

diff -Naurp mipslinux/include/asm-mips/page.h mipslinux.ckseg0-a/include/asm-mips/page.h
@@ -149,7 +149,7 @@ typedef struct { unsigned long pgprot; }
 /*
  * __pa()/__va() should be used only during mem init.
  */
-#if defined(CONFIG_64BIT) && !defined(CONFIG_BUILD_ELF64)
+#if defined(CONFIG_64BIT) && (!defined(CONFIG_BUILD_ELF64) || defined(CONFIG_SYS_LOADS_IN_CKSEG0))
 #define __pa_page_offset(x)	((unsigned long)(x) < CKSEG0 ? PAGE_OFFSET : CKSEG0)
 #else
 #define __pa_page_offset(x)	PAGE_OFFSET

Let me ask again: Why do you want to use CONFIG_BUILD_ELF64=y ?

If your board use CKSEG0 load address, I can not see any point setting CONFIG_BUILD_ELF64=y. I think the description in Kconfig (and the name of CONFIG_BUILD_ELF64 itself) should be changed to make people enable it only if really needed. And it is already done by Franck's pending patchset.

---
Atsushi Nemoto

Well, the story, as it's been explained to me a half-dozen times, cause I keep forgetting, is that three particular machines, IP22, IP32 (R5K/Nevada/RM7K), and apparently cobalt, ran best when built with the old -mabi=o64 hack, because it generated less instructions for certain routines (loads, I think). Especially in the case of cobalt, you lack a L2 cache, so you want to squeeze every thing possible out of the cpu.

Well, o64 went away as we all know. It was never a favourable option for very good reasons (although I used it right up until it died and I was forced off of it). The replacement for it, that was more preferred and resulted in similar code was building a kernel for any of these three systems using CONFIG_BUILD_ELF64 + -msym32 (auto selected in the Makefile) + the make vmlinux.32 target. I believe this method is what Debian uses for building their mips kernels for SGI systems, but don't quote me on that. If someone from Debian wants to comment, please do.

The idea being to stuff 64bit code into a 32bit object/kernel, since at least one of these systems, namely IP22, will only accept a 32bit object for booting.
It can't understand 64bit kernel objects. Cobalt's colo bootloader will
handle 64bit I believe, but my experience a year or two ago showed that a 32bit/64bit hybrid kernel ran much faster than a pure 64bit kernel, simply due to the decreased overhead. IP32's prom usually has no problem booting either, but I seem to also see a minor improvement in console redraw speed under the hyrbid kernel as well.

The issue is, if this method is broken, what's its replacement? Is this replacement capable of generating the same (or near enough) code w/o incurring a penalty hit? I mean, part of the reason for discussion going on for as long as it has been is the relative confusion surrounding the proper way to build these kernels for these particular systems. If someone can hash that out, I think we'll all figure out what track to get on and get something in the tree that works, and works well.

--Kumba

Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere."  --Elrond

The replacement is CONFIG_BUILD_ELF64=n (it adds -msym32 option) + CONFIG_BOOT_ELF32=y (it adds vmlinux.32 to "all" target). Not CONFIG_BUILD_ELF64=y.

CONFIG_BUILD_ELF64=n enables -msym32 option, which means the kernel load address should be CKSEG0. And if the kernel load address was CKSEG0, -msym32 make the kernel smaller and faster so it is absolutely preferred.

CONFIG_BOOT_ELF32=y enables objcopying vmlinux to vmlinux.32.

---
Atsushi Nemoto

This sounds wrong to me, since CONFIG_BUILD_ELF64=n will build a ELF64 kernel (from compiler/linker POV). This tricks people into believing they need no ELF64 capable toolchain for a 64bit kernel.

IMO -msym32 should depend on:

    ((Compiler can do -msym32)
     && (load address is in ckseg0)
     && CONFIG_64BIT)

which obsoletes the whole CONFIG_BUILD_ELF* stuff.

Thiemo

Going on this, I propose the following patch to fix our lovely SGI/Cobalt systems, and eliminate a confusing Kconfig option whose time is likely long since passed. The attached patch achieves the following:

* Introduces a new flag for IP22, IP32, and Cobalt called 'kernel_loads_in_ckseg0'.
* Introduces a new header, mem-layout.h, in include/asm-mips/mach-<platform>/ for this flag for these three systems, and a dummy entry for mach-generic, calling it in where appropriate.
* Removes CONFIG_BUILD_ELF64 from Kconfig, Makefile, and several defconfigs, and replaces its few references in header files with 'kernel_loads_in_ckseg0', with appropriate flips in logic (except in stackframe.h).
* Includes Frank's patch to eliminate the need for -mno-explicit-relocs.
* Moves -msym32 calling to the Makefile locations for the three machines that actually need it.

--Kumba

 arch/mips/Kconfig                          |   15 ---------------
 arch/mips/Makefile                         |   11 +++++------
 arch/mips/configs/bigsur_defconfig         |    1 -
 arch/mips/configs/ip27_defconfig           |    1 -
 arch/mips/configs/ip32_defconfig           |    1 -
 arch/mips/configs/ocelot_c_defconfig       |    1 -
 arch/mips/configs/sb1250-swarm_defconfig   |    1 -
 include/asm-mips/mach-cobalt/mem-layout.h  |    7 +++++++
 include/asm-mips/mach-generic/mem-layout.h |    7 +++++++
 include/asm-mips/mach-ip22/mem-layout.h    |    7 +++++++
 include/asm-mips/mach-ip32/mem-layout.h    |    7 +++++++
 include/asm-mips/page.h                    |    3 ++-
 include/asm-mips/pgtable-64.h              |    4 +++-
 include/asm-mips/stackframe.h              |    6 ++++--
 14 files changed, 42 insertions(+), 30 deletions(-)

diff -Naurp mipslinux/arch/mips/Kconfig mipslinux.ckseg0/arch/mips/Kconfig
@@ -2072,21 +2072,6 @@ source "fs/Kconfig.binfmt"
 config TRAD_SIGNALS
 	bool
 
-config BUILD_ELF64
-	bool "Use 64-bit ELF format for building"
-	depends on 64BIT
-	help
-	  A 64-bit kernel is usually built using the 64-bit ELF binary object
-	  format as it's one that allows arbitrary 64-bit constructs.  For
-	  kernels that are loaded within the KSEG compatibility segments the
-	  32-bit ELF format can optionally be used resulting in a somewhat
-	  smaller binary, but this option is not explicitly supported by the
-	  toolchain and since binutils 2.14 it does not even work at all.
-
-	  Say Y to use the 64-bit format or N to use the 32-bit one.
-
-	  If unsure say Y.
-
 config BINFMT_IRIX
 	bool "Include IRIX binary compatibility"
 	depends on CPU_BIG_ENDIAN && 32BIT && BROKEN

diff -Naurp mipslinux/arch/mips/Makefile mipslinux.ckseg0/arch/mips/Makefile
@@ -60,11 +60,6 @@ vmlinux-32		= vmlinux.32
 vmlinux-64		= vmlinux
 
 cflags-y		+= -mabi=64
-ifdef CONFIG_BUILD_ELF64
-cflags-y		+= $(call cc-option,-mno-explicit-relocs)
-else
-cflags-y		+= $(call cc-option,-msym32)
-endif
 endif
 
 

@@ -271,6 +266,9 @@ load-$(CONFIG_MIPS_XXS1500)	+= 0xfffffff
 #
 core-$(CONFIG_MIPS_COBALT)	+= arch/mips/cobalt/
 cflags-$(CONFIG_MIPS_COBALT)	+= -Iinclude/asm-mips/mach-cobalt
+ifdef CONFIG_64BIT
+cflags-$(CONFIG_MIPS_COBALT)	+= $(call cc-option,-msym32)
+endif
 load-$(CONFIG_MIPS_COBALT)	+= 0xffffffff80080000
 
 #

@@ -494,6 +492,7 @@ ifdef CONFIG_32BIT
 load-$(CONFIG_SGI_IP22)		+= 0xffffffff88002000
 endif
 ifdef CONFIG_64BIT
+cflags-$(CONFIG_SGI_IP22)	+= $(call cc-option,-msym32)
 load-$(CONFIG_SGI_IP22)		+= 0xffffffff88004000
 endif
 

@@ -526,7 +525,7 @@ endif
 # will break.
 #
 core-$(CONFIG_SGI_IP32)		+= arch/mips/sgi-ip32/
-cflags-$(CONFIG_SGI_IP32)	+= -Iinclude/asm-mips/mach-ip32
+cflags-$(CONFIG_SGI_IP32)	+= -Iinclude/asm-mips/mach-ip32 $(call cc-option,-msym32)
 load-$(CONFIG_SGI_IP32)		+= 0xffffffff80004000
 
 #

diff -Naurp mipslinux/arch/mips/configs/bigsur_defconfig mipslinux.ckseg0/arch/mips/configs/bigsur_defconfig
@@ -279,7 +279,6 @@ CONFIG_MMU=y
 #
 CONFIG_BINFMT_ELF=y
 # CONFIG_BINFMT_MISC is not set
-# CONFIG_BUILD_ELF64 is not set
 CONFIG_MIPS32_COMPAT=y
 CONFIG_COMPAT=y
 CONFIG_SYSVIPC_COMPAT=y

diff -Naurp mipslinux/arch/mips/configs/ip27_defconfig mipslinux.ckseg0/arch/mips/configs/ip27_defconfig
@@ -272,7 +272,6 @@ CONFIG_MMU=y
 #
 CONFIG_BINFMT_ELF=y
 # CONFIG_BINFMT_MISC is not set
-# CONFIG_BUILD_ELF64 is not set
 CONFIG_MIPS32_COMPAT=y
 CONFIG_COMPAT=y
 CONFIG_SYSVIPC_COMPAT=y

diff -Naurp mipslinux/arch/mips/configs/ip32_defconfig mipslinux.ckseg0/arch/mips/configs/ip32_defconfig
@@ -252,7 +252,6 @@ CONFIG_MMU=y
 #
 CONFIG_BINFMT_ELF=y
 CONFIG_BINFMT_MISC=y
-# CONFIG_BUILD_ELF64 is not set
 CONFIG_MIPS32_COMPAT=y
 CONFIG_COMPAT=y
 CONFIG_SYSVIPC_COMPAT=y

diff -Naurp mipslinux/arch/mips/configs/ocelot_c_defconfig mipslinux.ckseg0/arch/mips/configs/ocelot_c_defconfig
@@ -250,7 +250,6 @@ CONFIG_MMU=y
 #
 CONFIG_BINFMT_ELF=y
 # CONFIG_BINFMT_MISC is not set
-# CONFIG_BUILD_ELF64 is not set
 CONFIG_MIPS32_COMPAT=y
 CONFIG_COMPAT=y
 CONFIG_SYSVIPC_COMPAT=y

diff -Naurp mipslinux/arch/mips/configs/sb1250-swarm_defconfig mipslinux.ckseg0/arch/mips/configs/sb1250-swarm_defconfig
@@ -281,7 +281,6 @@ CONFIG_MMU=y
 #
 CONFIG_BINFMT_ELF=y
 # CONFIG_BINFMT_MISC is not set
-# CONFIG_BUILD_ELF64 is not set
 CONFIG_MIPS32_COMPAT=y
 CONFIG_COMPAT=y
 CONFIG_SYSVIPC_COMPAT=y

diff -Naurp mipslinux/include/asm-mips/mach-cobalt/mem-layout.h mipslinux.ckseg0/include/asm-mips/mach-cobalt/mem-layout.h
@@ -0,0 +1,7 @@
+#ifndef __ASM_MACH_COBALT_MEM_LAYOUT_H
+#define __ASM_MACH_COBALT_MEM_LAYOUT_H
+
+
+#define kernel_loads_in_ckseg0		1
+
+#endif /* __ASM_MACH_COBALT_MEM_LAYOUT_H */

diff -Naurp mipslinux/include/asm-mips/mach-generic/mem-layout.h mipslinux.ckseg0/include/asm-mips/mach-generic/mem-layout.h
@@ -0,0 +1,7 @@
+#ifndef __ASM_MACH_GENERIC_MEM_LAYOUT_H
+#define __ASM_MACH_GENERIC_MEM_LAYOUT_H
+
+
+#define kernel_loads_in_ckseg0		0
+
+#endif /* __ASM_MACH_GENERIC_MEM_LAYOUT_H */

diff -Naurp mipslinux/include/asm-mips/mach-ip22/mem-layout.h mipslinux.ckseg0/include/asm-mips/mach-ip22/mem-layout.h
@@ -0,0 +1,7 @@
+#ifndef __ASM_MACH_IP22_MEM_LAYOUT_H
+#define __ASM_MACH_IP22_MEM_LAYOUT_H
+
+
+#define kernel_loads_in_ckseg0		1
+
+#endif /* __ASM_MACH_IP22_MEM_LAYOUT_H */

diff -Naurp mipslinux/include/asm-mips/mach-ip32/mem-layout.h mipslinux.ckseg0/include/asm-mips/mach-ip32/mem-layout.h
@@ -0,0 +1,7 @@
+#ifndef __ASM_MACH_IP32_MEM_LAYOUT_H
+#define __ASM_MACH_IP32_MEM_LAYOUT_H
+
+
+#define kernel_loads_in_ckseg0		1
+
+#endif /* __ASM_MACH_IP32_MEM_LAYOUT_H */

diff -Naurp mipslinux/include/asm-mips/page.h mipslinux.ckseg0/include/asm-mips/page.h
@@ -13,6 +13,7 @@
 #ifdef __KERNEL__
 
 #include <spaces.h>
+#include <mem-layout.h>
 
 /*
  * PAGE_SHIFT determines the page size

@@ -149,7 +150,7 @@ typedef struct { unsigned long pgprot; }
 /*
  * __pa()/__va() should be used only during mem init.
  */
-#if defined(CONFIG_64BIT) && !defined(CONFIG_BUILD_ELF64)
+#if defined(CONFIG_64BIT) && defined(kernel_loads_in_ckseg0)
 #define __pa_page_offset(x)	((unsigned long)(x) < CKSEG0 ? PAGE_OFFSET : CKSEG0)
 #else
 #define __pa_page_offset(x)	PAGE_OFFSET

diff -Naurp mipslinux/include/asm-mips/pgtable-64.h mipslinux.ckseg0/include/asm-mips/pgtable-64.h
@@ -16,6 +16,8 @@
 #include <asm/cachectl.h>
 #include <asm/fixmap.h>
 
+#include <mem-layout.h>
+
 #include <asm-generic/pgtable-nopud.h>
 
 /*

@@ -104,7 +106,7 @@
 #define VMALLOC_START		MAP_BASE
 #define VMALLOC_END	\
 	(VMALLOC_START + PTRS_PER_PGD * PTRS_PER_PMD * PTRS_PER_PTE * PAGE_SIZE)
-#if defined(CONFIG_MODULES) && !defined(CONFIG_BUILD_ELF64) && \
+#if defined(CONFIG_MODULES) && defined(kernel_loads_in_ckseg0) && \
 	VMALLOC_START != CKSSEG
 /* Load modules into 32bit-compatible segment. */
 #define MODULE_START	CKSSEG

diff -Naurp mipslinux/include/asm-mips/stackframe.h mipslinux.ckseg0/include/asm-mips/stackframe.h
@@ -17,6 +17,8 @@
 #include <asm/mipsregs.h>
 #include <asm/asm-offsets.h>
 
+#include <mem-layout.h>
+
 #ifdef CONFIG_MIPS_MT_SMTC
 #include <asm/mipsmtregs.h>
 #endif /* CONFIG_MIPS_MT_SMTC */

@@ -79,7 +81,7 @@
 #else
 		MFC0	k0, CP0_CONTEXT
 #endif
-#if defined(CONFIG_BUILD_ELF64) || (defined(CONFIG_64BIT) && __GNUC__ < 4)
+#if defined(kernel_loads_in_ckseg0) || (defined(CONFIG_64BIT) && __GNUC__ < 4)
 		lui	k1, %highest(kernelsp)
 		daddiu	k1, %higher(kernelsp)
 		dsll	k1, 16

@@ -104,7 +106,7 @@
 		.endm
 #else
 		.macro	get_saved_sp	/* Uniprocessor variation */
-#if defined(CONFIG_BUILD_ELF64) || (defined(CONFIG_64BIT) && __GNUC__ < 4)
+#if defined(kernel_loads_in_ckseg0) || (defined(CONFIG_64BIT) && __GNUC__ < 4)
 		lui	k1, %highest(kernelsp)
 		daddiu	k1, %higher(kernelsp)
 		dsll	k1, k1, 16

[snip]

Why? I reckon GCC should support them just fine these days.

Maciej

Please remember that we officially only require GCC 3.2 or newer. 3.2 turned out to be too broken to be supported for 64-bit builds but as long as there is no significant problem I'd like to keep support for these compiler antiques alive.

Ralf

Hmm, from the back of my head I think it should not be a problem -- IIRC
the versions of GCC that did not support explicit relocs for 64-bit ELF would force "-mno-explicit-relocs" internally even if asked otherwise. They did not support "-msym32" either, which went in later, and then non-PIC support for 64-bit explicit relocs went in earlier than for PIC -- quite unsurprisingly, as %higher() and %highest() are not necessarily rocket science unlike %disp() and friends.

If anybody cares I could probably make the excavations needed to verify
the above.

Maciej

That would be appreciated. I did that on my side, I also tried to build a few 64-bit test kernels with gcc 3.3 and 4.1.2 yesterday and did not find any real reason why we would still need -mno-explicit-relocs. Thiemo said there was something like a modern gcc in combination with old binutils. That's the comination I haven't tested.

Ralf

I can not see why you handle IP22, IP32, Cobalt as so "special". There are many other platforms which supports 64-bit and uses CKSEG0 load address (well, actually all 64-bit platforms except for IP27).

So I think Franck's approach, which enables -msym32 and defines KBUILD_64BIT_SYM32 automatically if load-y was CKSEG0, is better. Are there any problem with his patchset?

---
Atsushi Nemoto

Note IP27 works fine either way and the code size difference is considerable:
Here are numbers for ip27_defconfig with gcc 4.1.2 and binutils 2.17:

text data bss dec hex filename

3397944  415768  256816 4070528  3e1c80 vmlinux BUILD_ELF64=n
3774968  415768  248624 4439360  43bd40 vmlinux BUILD_ELF64=y

Alot more platforms could make use of this approach; the kernel size savings are considerable.

The worst thing about CONFIG_BUILD_ELF64 is that it's interactivly available so making it easy for the user to choose suboptimal value or one that does not work at all, so it must become unavailable from Kconfig.

Ralf

Impressive figures !

However I can't understand why there's a such difference, I'm surely missing something. AFAIK, we're not doing so many symbol loads in the kernel ? Maybe this difference is related to ksymall ?

Could you make these 2 kernels available for downloading ?

thanks

              Franck

Yes we do, for many local symbols. It's the reason why the toolchain has a -msym32 switch now.

Thiemo

Mainly because, to the best of my knowledge, these are the only three systems where things get weird with ckseg0 and this specific Kconfig option. Afaik with other systems, they don't need weird hacks like stuffing 64bit code into 32bit objects to work best (or at all).

I missed the other two additions to this patch, which is probably why it didn't work :) Taken as a whole, they also boot my O2 now.

--Kumba

Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere."  --Elrond

Thanks, good news!

And Ralf's number shows that we can use -msym32 even for IP27. Another good news.

---
Atsushi Nemoto

Actually, I just realized I didn't rehash my dhcpd, so it booted the wrong kernel. A kernel built with this patchset won't boot without the following change in include/asm-mips/stackframe.h:

@@ -70,7 +70,7 @@
 #else
 		MFC0	k0, CP0_CONTEXT
 #endif
-#if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32)
+#if defined(CONFIG_32BIT) || !defined(KBUILD_64BIT_SYM32)
 		lui	k1, %hi(kernelsp)
 #else
 		lui	k1, %highest(kernelsp)

@@ -95,7 +95,7 @@
 		.endm
 #else
 		.macro	get_saved_sp	/* Uniprocessor variation */
-#if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32)
+#if defined(CONFIG_32BIT) || !defined(KBUILD_64BIT_SYM32)
 		lui	k1, %hi(kernelsp)
 #else
 		lui	k1, %highest(kernelsp)

You'll just get a silent hang after ARCS jumps into the kernel. My guess is these systems need the extra asm commands. Perhaps the use of CONFIG_32BIT is incorrect?

Maybe we should use the older form instead, with appropriate change?

@@ -70,14 +70,14 @@
 #else
 		MFC0	k0, CP0_CONTEXT
 #endif
-#if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32)
-		lui	k1, %hi(kernelsp)
-#else
+#if defined(CONFIG_64BIT) || defined(KBUILD_64BIT_SYM32)
 		lui	k1, %highest(kernelsp)
 		daddiu	k1, %higher(kernelsp)
 		dsll	k1, 16
 		daddiu	k1, %hi(kernelsp)
 		dsll	k1, 16
+#else
+		lui	k1, %hi(kernelsp)
 #endif
 		LONG_SRL	k0, PTEBASE_SHIFT
 		LONG_ADDU	k1, k0

@@ -95,14 +95,14 @@
 		.endm
 #else
 		.macro	get_saved_sp	/* Uniprocessor variation */
-#if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32)
-		lui	k1, %hi(kernelsp)
-#else
+#if defined(CONFIG_64BIT) || defined(KBUILD_64BIT_SYM32)
 		lui	k1, %highest(kernelsp)
 		daddiu	k1, %higher(kernelsp)
 		dsll	k1, k1, 16
 		daddiu	k1, %hi(kernelsp)
 		dsll	k1, k1, 16
+#else
+		lui	k1, %hi(kernelsp)
 #endif
 		LONG_L	k1, %lo(kernelsp)(k1)
 		.endm

--Kumba

Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere."  --Elrond

# mips64-unknown-linux-gnu-ld --version
GNU ld version 2.16.1

# mips64-unknown-linux-gnu-gcc --version
mips64-unknown-linux-gnu-gcc (GCC) 4.1.1 (Gentoo 4.1.1-r3)

And the disassembly of vmlinux.32 for the handle_int function is attached.

I haven't built a kernel w/ gcc-3.x for some time, probably last time being when I was chasing down the strange funkiness in my Octane's userland in 2.6.19.

--Kumba

Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere."  --Elrond

80006ac0 <handle_int>:
80006ac0: 401a6000 mfc0 k0,$12
80006ac4: 001ad0c0 sll k0,k0,0x3
80006ac8: 07400007 bltz k0,80006ae8 <handle_int+0x28>
80006acc: 03a0d82d move k1,sp
80006ad0: 3c1b0000 lui k1,0x0
80006ad4: 677b0000 daddiu k1,k1,0
80006ad8: 001bdc38 dsll k1,k1,0x10
80006adc: 677b8047 daddiu k1,k1,-32697
80006ae0: 001bdc38 dsll k1,k1,0x10
80006ae4: df7b5008 ld k1,20488(k1)
80006ae8: 03a0d02d move k0,sp
80006aec: 677dfed0 daddiu sp,k1,-304
80006af0: ffba00e8 sd k0,232(sp)
80006af4: ffa30018 sd v1,24(sp)
80006af8: ffa00000 sd zero,0(sp)
80006afc: 40036000 mfc0 v1,$12
80006b00: ffa20010 sd v0,16(sp)
80006b04: ffa30100 sd v1,256(sp)
80006b08: ffa40020 sd a0,32(sp)
80006b0c: 40036800 mfc0 v1,$13
80006b10: ffa50028 sd a1,40(sp)
80006b14: ffa30120 sd v1,288(sp)
80006b18: ffa60030 sd a2,48(sp)
80006b1c: 40237000 dmfc0 v1,$14
80006b20: ffa70038 sd a3,56(sp)
80006b24: ffa80040 sd t0,64(sp)
80006b28: ffa90048 sd t1,72(sp)
80006b2c: ffa30128 sd v1,296(sp)
80006b30: ffb900c8 sd t9,200(sp)
80006b34: ffbc00e0 sd gp,224(sp)
80006b38: ffbf00f8 sd ra,248(sp)
80006b3c: 37bc3fff ori gp,sp,0x3fff
80006b40: 3b9c3fff xori gp,gp,0x3fff
80006b44: ffa10008 sd at,8(sp)
80006b48: 00001810 mfhi v1
80006b4c: ffa30108 sd v1,264(sp)
80006b50: 00001812 mflo v1
80006b54: ffaa0050 sd t2,80(sp)
80006b58: ffab0058 sd t3,88(sp)
80006b5c: ffa30110 sd v1,272(sp)
80006b60: ffac0060 sd t4,96(sp)
80006b64: ffad0068 sd t5,104(sp)
80006b68: ffae0070 sd t6,112(sp)
80006b6c: ffaf0078 sd t7,120(sp)
80006b70: ffb800c0 sd t8,192(sp)
80006b74: ffb00080 sd s0,128(sp)
80006b78: ffb10088 sd s1,136(sp)
80006b7c: ffb20090 sd s2,144(sp)
80006b80: ffb30098 sd s3,152(sp)
80006b84: ffb400a0 sd s4,160(sp)
80006b88: ffb500a8 sd s5,168(sp)
80006b8c: ffb600b0 sd s6,176(sp)
80006b90: ffb700b8 sd s7,184(sp)
80006b94: ffbe00f0 sd s8,240(sp)
80006b98: 400c6000 mfc0 t4,$12
80006b9c: 3c0d1000 lui t5,0x1000
80006ba0: 35ad001f ori t5,t5,0x1f
80006ba4: 018d6025 or t4,t4,t5
80006ba8: 398c001f xori t4,t4,0x1f
80006bac: 408c6000 mtc0 t4,$12

	...

80006bbc: df900058 ld s0,88(gp)
80006bc0: ff9d0058 sd sp,88(gp)
80006bc4: 3c1f8000 lui ra,0x8000
80006bc8: 0800154e j 80005538 <plat_irq_dispatch>
80006bcc: 67ff68a0 daddiu ra,ra,26784

Thanks. Is this a disassembly of _failed_ kernel?

If so, it looks KBUILD_64BIT_SYM32 is not defined. So strange...

And even if %highest, etc. were used, it should work for CKSEG0 kernel, while using only %hi should be just an optimization. Another strangeness.

The address of kernelsp should be 0xffffffff80475008. It seems a regular value.

---
Atsushi Nemoto

Note to Self: Drink coffee before attempting to follow clearly-stated instructions on sending in disassembly of failed kernel.

Lets try this one; the kernel was built with gcc-4.1.2 and binutils-2.17 this time around, and I tested it before running objdump on it. It just hangs right after loading:

Setting $netaddr to 192.168.1.12 (from server )
Obtaining from server
4358278+315290 entry: 0x80401000

--Kumba

Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere."  --Elrond

80006ae0 <handle_int>:
80006ae0: 401a6000 mfc0 k0,$12
80006ae4: 001ad0c0 sll k0,k0,0x3
80006ae8: 07400003 bltz k0,80006af8 <handle_int+0x18>
80006aec: 03a0d82d move k1,sp
80006af0: 3c1b8048 lui k1,0x8048
80006af4: df7b9008 ld k1,-28664(k1)
80006af8: 03a0d02d move k0,sp
80006afc: 677dfed0 daddiu sp,k1,-304
80006b00: ffba00e8 sd k0,232(sp)
80006b04: ffa30018 sd v1,24(sp)
80006b08: ffa00000 sd zero,0(sp)
80006b0c: 40036000 mfc0 v1,$12
80006b10: ffa20010 sd v0,16(sp)
80006b14: ffa30100 sd v1,256(sp)
80006b18: ffa40020 sd a0,32(sp)
80006b1c: 40036800 mfc0 v1,$13
80006b20: ffa50028 sd a1,40(sp)
80006b24: ffa30120 sd v1,288(sp)
80006b28: ffa60030 sd a2,48(sp)
80006b2c: 40237000 dmfc0 v1,$14
80006b30: ffa70038 sd a3,56(sp)
80006b34: ffa80040 sd t0,64(sp)
80006b38: ffa90048 sd t1,72(sp)
80006b3c: ffa30128 sd v1,296(sp)
80006b40: ffb900c8 sd t9,200(sp)
80006b44: ffbc00e0 sd gp,224(sp)
80006b48: ffbf00f8 sd ra,248(sp)
80006b4c: 37bc3fff ori gp,sp,0x3fff
80006b50: 3b9c3fff xori gp,gp,0x3fff
80006b54: ffa10008 sd at,8(sp)
80006b58: 00001810 mfhi v1
80006b5c: ffa30108 sd v1,264(sp)
80006b60: 00001812 mflo v1
80006b64: ffaa0050 sd t2,80(sp)
80006b68: ffab0058 sd t3,88(sp)
80006b6c: ffa30110 sd v1,272(sp)
80006b70: ffac0060 sd t4,96(sp)
80006b74: ffad0068 sd t5,104(sp)
80006b78: ffae0070 sd t6,112(sp)
80006b7c: ffaf0078 sd t7,120(sp)
80006b80: ffb800c0 sd t8,192(sp)
80006b84: ffb00080 sd s0,128(sp)
80006b88: ffb10088 sd s1,136(sp)
80006b8c: ffb20090 sd s2,144(sp)
80006b90: ffb30098 sd s3,152(sp)
80006b94: ffb400a0 sd s4,160(sp)
80006b98: ffb500a8 sd s5,168(sp)
80006b9c: ffb600b0 sd s6,176(sp)
80006ba0: ffb700b8 sd s7,184(sp)
80006ba4: ffbe00f0 sd s8,240(sp)
80006ba8: 400c6000 mfc0 t4,$12
80006bac: 3c0d1000 lui t5,0x1000
80006bb0: 35ad001f ori t5,t5,0x1f
80006bb4: 018d6025 or t4,t4,t5
80006bb8: 398c001f xori t4,t4,0x1f
80006bbc: 408c6000 mtc0 t4,$12

	...

80006bcc: df900058 ld s0,88(gp)
80006bd0: ff9d0058 sd sp,88(gp)
80006bd4: 3c1f8000 lui ra,0x8000
80006bd8: 0800154e j 80005538 <plat_irq_dispatch>
80006bdc: 67ff68c0 daddiu ra,ra,26816

Now I can not see any problem with the disassembled code. No idea why it does not work at all...

BTW, why IP32 does not support 32-bit kernel, though it has 32-bit firmware?
---
Atsushi Nemoto

Because we are too lazy to get HIGHMEM working in order to get support for all of its memory. Not to mention that HIGHMEM is Evil(TM).

Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com

Oh I see. The 64-bit kernel should be a right thing.
---
Atsushi Nemoto

It wants to do 64bit register accesses, and supports more memory than KSEG0 can hold. The resulting 32bit kernel was ugly enough to kill it and replace it with a 64bit one.

Thiemo

Well, what's the need to use the move/lui/ld sequence over move/lui/daddui/dsll/daddui/dsll//ld anyways? I'll have to warm the Indy up and try a 64bit kernel there I guess, to see if it exhibits similar issues with this segment of code.

--Kumba

Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere."  --Elrond

Just an optimization. For CKSEG0 symbol, a LUI instruction can fill high 32-bit by sign-extention. Either code should work for CKSEG0 kernel.

---
Atsushi Nemoto

Hmm, strange then. It's gotta be something those four extra commands do that IP32 likes. IP22 boots fine with either form, though that has a separate problem where it looks like serial console on the zilog chip panics the system after booting into a netboot.

Doing some tests, I found out that by commenting out one or more of the daddui/dsll instructions for IP32 produced a kernel that still booted, but hung at running init/freeing kernel memory. Using the single lui booted once, but I suspect that was my fault on not doing something proper, cause the next time around, it didn't boot at all. I tested this all on a real console, versus serial, case there was an early panic or something. But I see nothing to indicate why IP32 dislikes the lui->ld sequence versus the lui->daddui->dsll->etc->ld sequence.

There's no early printk on these systems either, so doing low-level debugging is difficult on them as well.

--Kumba

Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere."  --Elrond

Hmm... really strange.

This is OK:
lui k1, %highest(kernelsp)
daddiu k1, %higher(kernelsp)
dsll k1, k1, 16
daddiu k1, %hi(kernelsp)
dsll k1, k1, 16

This is NG:

		lui	k1, %hi(kernelsp)

So, could you try this one?

		nop
		nop
		nop
		nop
		lui	k1, %hi(kernelsp)

If it booted, the problem should be in something irrelevant place. I.e. this optimization just triggers other bug by code/data movement.

---
Atsushi Nemoto

Yup, it booted. On further testing at iluxa's behest, it turns out it may be some quirk/cpu errata related to the RM5200 I use in my O2. I swapped it out for a plain R5000 @ 200MHz, and removed the nop's -- boots fine.

This may also explain why the cobalt's were hitting something odd. They also use a member of the RM52xx family (RM5231 iirc, O2 uses an RM5261).

--Kumba

Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere."  --Elrond

Well, thinking about it some more, can this stackframe change be segmented out of Frank's main patches, so we can get them into git, and spend time in 2.6.21/2.6.22/2.6.23 chasing down what exactly is up with this specific asm sequence?

Of course, wiring in a quick check on !defined(CONFIG_SGI_IP32) would also work, but that's not proper to go kludging in specific machine checks in a generic file like stackframe, IMHO.

--Kumba

Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere."  --Elrond

This is not Franck's fault. His patchset does not change behavior if kernel load address was CKSEG0 and CONFIG_BUILD_ELF64 was not set (unless you are using gcc 3.x).

Let's clarify things a bit: The Franck's patchset is _not_ fix. It just tried to avoid undesirable configuration (CKSEG0 kernel with BUILD_ELF64=y), and clarify some namings.

So I should ask you again, does current git (or 2.6.20-stable) kernel compiled by binutils-2.17/gcc-4.[12] work for IP32 if you disabled CONFIG_BUILD_ELF64?

So I had thought CONFIG_BUILD_ELF64=n worked for IP32...

---
Atsushi Nemoto

I wasn't implying it was anyone's fault of any kind. I actually didn't see your last response cause Thunderbird got stupid and stopped checking for new mail for some odd reason.

As far as I can tell, the majority of what CONFIG_BUILD_ELF64 did got neutered in 2.6.17. It's pretty much down to those minor #ifdef checks and a few references on the defconfigs. Removing it entirely is probably the best idea, and if Frank's patch is one way of doing it, I'm game. Besides, he's got that loadaddr detector thrown in so we don't have to check on a machine-by-machine basis if they're loading in CKSEG0 or not.

[snip]

If memory serves, yes, it'll boot, because it's close to the old way I that I used to use when building them. Prior to 2.6.17, I did CONFIG_BUILD_ELF64=n with -mabi=o64. This let me use the plain 'vmlinux' target without any special changes. 2.6.17 is when I stopped using gcc-3.x for kernels, moved to 4.x, and started using CONFIG_BUILD_ELF64=y w/ -msym32 and friends. Thus I now use vmlinux.32. I was told that that was the RightWay(TM) to do it.

Hence, the real point of this long chain is mainly to accomplish two things:

1) Finally determine the OneTrueWay(TM) to build 64bit kernels for our three main CKSEG0-based systems (ip22, ip32, cobalt), and get that way documented so as to avoid confusion in the future.

2) Get a solution into the tree that does #1, and does it well. So far, Frank's patch seems like the leading contender here.

--Kumba

Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere."  --Elrond

IMHO here is a root of confusion. The -msym32 option is/was enabled only if CONFIG_BUILD_ELF64=n. The vmlinux.32 thing are controled by CONFIG_BOOT_ELF32 or CONFIG_BOOT_ELF64. The word BOOT and BUILD seems too umbiguous ;)

Yes. I agree.

And I think the answer is

1) Disable CONFIG_BUILD_ELF64 in short term.

2) Apply Franck's patchset with a slight change (enclose -msym32 by $(call cc-option)).

And _if_ this did not work on IP32, something needs to be fixed, but I can not see why for now.

---
Atsushi Nemoto

Well, how about this solution that solve the whole thing entirely with Kconfig?

Ralf

index 0253584..6283fd2 100644
@@ -2072,20 +2072,9 @@ source "fs/Kconfig.binfmt"
 config TRAD_SIGNALS
 	bool
 
-config BUILD_ELF64
-	bool "Use 64-bit ELF format for building"
-	depends on 64BIT
-	help
-	  A 64-bit kernel is usually built using the 64-bit ELF binary object
-	  format as it's one that allows arbitrary 64-bit constructs.  For
-	  kernels that are loaded within the KSEG compatibility segments the
-	  32-bit ELF format can optionally be used resulting in a somewhat
-	  smaller binary, but this option is not explicitly supported by the
-	  toolchain and since binutils 2.14 it does not even work at all.
-
-	  Say Y to use the 64-bit format or N to use the 32-bit one.
-
-	  If unsure say Y.
+config KERNEL_LOADS_IN_CKSEG0
+	bool
+	default y if (SYS_SUPPORTS_32BIT_KERNEL || SGI_IP32 || SGI_IP27) && 64BIT
 
 config BINFMT_IRIX
 	bool "Include IRIX binary compatibility"

index 92bca6a..d31f2d1 100644
@@ -60,10 +60,10 @@ vmlinux-32		= vmlinux.32
 vmlinux-64		= vmlinux
 
 cflags-y		+= -mabi=64
-ifdef CONFIG_BUILD_ELF64
-cflags-y		+= $(call cc-option,-mno-explicit-relocs)
-else
+ifdef CONFIG_KERNEL_LOADS_IN_CKSEG0
 cflags-y		+= $(call cc-option,-msym32)
+else
+cflags-y		+= $(call cc-option,-mno-explicit-relocs)
 endif
 endif
 

index 4713a13..abb0b48 100644
@@ -279,7 +279,7 @@ CONFIG_MMU=y
 #
 CONFIG_BINFMT_ELF=y
 # CONFIG_BINFMT_MISC is not set
-# CONFIG_BUILD_ELF64 is not set
+CONFIG_KERNEL_LOADS_IN_CKSEG0=y
 CONFIG_MIPS32_COMPAT=y
 CONFIG_COMPAT=y
 CONFIG_SYSVIPC_COMPAT=y

index 9ddc3ef..ea625b7 100644
@@ -272,7 +272,7 @@ CONFIG_MMU=y
 #
 CONFIG_BINFMT_ELF=y
 # CONFIG_BINFMT_MISC is not set
-# CONFIG_BUILD_ELF64 is not set
+CONFIG_KERNEL_LOADS_IN_CKSEG0=y
 CONFIG_MIPS32_COMPAT=y
 CONFIG_COMPAT=y
 CONFIG_SYSVIPC_COMPAT=y

index 8fc1880..d8b8c8f 100644
@@ -252,7 +252,7 @@ CONFIG_MMU=y
 #
 CONFIG_BINFMT_ELF=y
 CONFIG_BINFMT_MISC=y
-# CONFIG_BUILD_ELF64 is not set
+CONFIG_KERNEL_LOADS_IN_CKSEG0=y
 CONFIG_MIPS32_COMPAT=y
 CONFIG_COMPAT=y
 CONFIG_SYSVIPC_COMPAT=y

index 82ff6fc..16b4b63 100644
@@ -250,7 +250,7 @@ CONFIG_MMU=y
 #
 CONFIG_BINFMT_ELF=y
 # CONFIG_BINFMT_MISC is not set
-# CONFIG_BUILD_ELF64 is not set
+CONFIG_KERNEL_LOADS_IN_CKSEG0=y
 CONFIG_MIPS32_COMPAT=y
 CONFIG_COMPAT=y
 CONFIG_SYSVIPC_COMPAT=y

index 6c4f09a..0664e3f 100644
@@ -281,7 +281,7 @@ CONFIG_MMU=y
 #
 CONFIG_BINFMT_ELF=y
 # CONFIG_BINFMT_MISC is not set
-# CONFIG_BUILD_ELF64 is not set
+CONFIG_KERNEL_LOADS_IN_CKSEG0=y
 CONFIG_MIPS32_COMPAT=y
 CONFIG_COMPAT=y
 CONFIG_SYSVIPC_COMPAT=y

index d3fbd83..266542a 100644
@@ -149,7 +149,7 @@ typedef struct { unsigned long pgprot; } pgprot_t;
 /*
  * __pa()/__va() should be used only during mem init.
  */
-#if defined(CONFIG_64BIT) && !defined(CONFIG_BUILD_ELF64)
+#if defined(CONFIG_64BIT) && defined(CONFIG_KERNEL_LOADS_IN_CKSEG0)
 #define __pa_page_offset(x)	((unsigned long)(x) < CKSEG0 ? PAGE_OFFSET : CKSEG0)
 #else
 #define __pa_page_offset(x)	PAGE_OFFSET

index 49f5a1a..96c8927 100644
@@ -104,7 +104,7 @@
 #define VMALLOC_START		MAP_BASE
 #define VMALLOC_END	\
 	(VMALLOC_START + PTRS_PER_PGD * PTRS_PER_PMD * PTRS_PER_PTE * PAGE_SIZE)
-#if defined(CONFIG_MODULES) && !defined(CONFIG_BUILD_ELF64) && \
+#if defined(CONFIG_MODULES) && defined(CONFIG_KERNEL_LOADS_IN_CKSEG0) && \
 	VMALLOC_START != CKSSEG
 /* Load modules into 32bit-compatible segment. */
 #define MODULE_START	CKSSEG

index 7afa1fd..9ea32c9 100644
@@ -79,7 +79,7 @@
 #else
 		MFC0	k0, CP0_CONTEXT
 #endif
-#if defined(CONFIG_BUILD_ELF64) || (defined(CONFIG_64BIT) && __GNUC__ < 4)
+#if !defined(CONFIG_KERNEL_LOADS_IN_CKSEG0) || (defined(CONFIG_64BIT) && __GNUC__ < 4)
 		lui	k1, %highest(kernelsp)
 		daddiu	k1, %higher(kernelsp)
 		dsll	k1, 16

@@ -104,7 +104,7 @@
 		.endm
 #else
 		.macro	get_saved_sp	/* Uniprocessor variation */
-#if defined(CONFIG_BUILD_ELF64) || (defined(CONFIG_64BIT) && __GNUC__ < 4)
+#if !defined(CONFIG_KERNEL_LOADS_IN_CKSEG0) || (defined(CONFIG_64BIT) && __GNUC__ < 4)
 		lui	k1, %highest(kernelsp)
 		daddiu	k1, %higher(kernelsp)
 		dsll	k1, k1, 16

Hi Ralf,

Could you explain why you don't actually like the patchset that care about that in Kbuild ?

You were asked several times why this patchset have not been considerated without any answers. So I have no clue why it's broken.

And now we have a third (well at least) solution... and I don't see why it's better than Kbuild one: it still has GCC version test which should be part of Kbuild for this case, if someone changes the kernel load address and don't know about the new Kconfig option, then it will still fail...

thanks for answering...

              Franck

One thing I noticed recently: Your patchset dropped gcc test for availability of -msym32, so may not work with gcc 3.x.

---
Atsushi Nemoto

Hi Atsushi,

I suspect you're asking why I did not do this:

index 3ec0c12..b0d8240 100644
@@ -627,7 +627,7 @@ ifdef CONFIG_64BIT
  endif
 
  ifeq ($(KBUILD_SYM32), y)
-    cflags-y += -msym32 -DKBUILD_64BIT_SYM32
+    cflags-y += $(call cc-option,-msym32) -DKBUILD_64BIT_SYM32
  endif

endif

I remove the call to cc-option because this function removes _silently_ '-msym32' option if it's not supported by the compiler. IOW it's really not what we want.

IIRC I haven't found an other function like 'cc-option-strict' which makes a compilation error in case.

So I assumed that the compiler will complain if it doesn't understand this option. But it may be incorrect. If so I can add an error message in Kbuild or add a new Kbuild helper. But I'd like to understand what's wrong with it before.

Thanks

              Franck

Yes.

I think dropping gcc 3.x support for 64-bit kernel is not what we wanted. And -msym32 is just an optimization and kernel should be buildable without it. So "remove -msym32 silently" is not so bad, I suppose.

"If you used newer compiler, you can get better result" is natural thing, isn't it? ;)
---
Atsushi Nemoto

ok, I suppose a warning is fine. What about this patch on top of the patchset ?

index 3ec0c12..b886945 100644
@@ -627,7 +627,12 @@ ifdef CONFIG_64BIT
  endif
 
  ifeq ($(KBUILD_SYM32), y)
-    cflags-y += -msym32 -DKBUILD_64BIT_SYM32
+    ifeq ($(call cc-option-yn,-msym32), y)
+      cflags-y += -msym32 -DKBUILD_64BIT_SYM32
+    else
+      $(warning '-msym32' option is not supported by your compiler. \
+               You should use a new one to get best result)
+    endif
  endif

endif

              Franck

OK, I'll remove it.

thanks

              Franck

It is _exactly_ what we want. -msym32 is always an optional optimization.

Thiemo

Argh !

              Franck

Sure. And it is already done by Franck but is still pending (why?).

http://www.linux-mips.org/archives/linux-mips/2007-02/msg00228.html
http://www.linux-mips.org/archives/linux-mips/2007-02/msg00227.html
http://www.linux-mips.org/archives/linux-mips/2007-02/msg00231.html

---
Atsushi Nemoto