3.12-rc1: no longer compiles for Nokia n900 (omap based)

3.12-rc1: no longer compiles for Nokia n900 (omap based)

[Pavel Machek]

Hi!

I get:

  CC      arch/arm/kernel/machine_kexec.o
/tmp/ccCFXeXG.s: Assembler messages:
/tmp/ccCFXeXG.s:217: Error: garbage following instruction -- `dsb
nshst'
/tmp/ccCFXeXG.s:225: Error: garbage following instruction -- `dsb nsh'
make[1]: *** [arch/arm/kernel/suspend.o] Error 1
make[1]: *** Waiting for unfinished jobs....

pavel at amd:/data/l/linux-n900$ arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (Debian 4.3.5-4) 4.3.5

Minimum required gcc is 3.2, so I'm safe.

I suspect

commit 62cbbc42e0019aff6310259f275ae812463f8836
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu May 23 18:43:58 2013 +0100

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

3.12-rc1: no longer compiles for Nokia n900 (omap based)

[Will Deacon]

On Thu, Sep 19, 2013 at 10:30:02AM +0100, Pavel Machek wrote:
> Hi!
> 
> I get:
> 
>   CC      arch/arm/kernel/machine_kexec.o
> /tmp/ccCFXeXG.s: Assembler messages:
> /tmp/ccCFXeXG.s:217: Error: garbage following instruction -- `dsb
> nshst'
> /tmp/ccCFXeXG.s:225: Error: garbage following instruction -- `dsb nsh'
> make[1]: *** [arch/arm/kernel/suspend.o] Error 1
> make[1]: *** Waiting for unfinished jobs....
> 
> pavel at amd:/data/l/linux-n900$ arm-linux-gnueabi-gcc --version
> arm-linux-gnueabi-gcc (Debian 4.3.5-4) 4.3.5
> 
> Minimum required gcc is 3.2, so I'm safe.

Please check your binutils. >= 2.22 has been reported to work.

Will1

3.12-rc1: no longer compiles for Nokia n900 (omap based), display no longer works

[Pavel Machek]

On Thu 2013-09-19 11:30:02, Pavel Machek wrote:
> Hi!
> 
> I get:
> 
>   CC      arch/arm/kernel/machine_kexec.o
> /tmp/ccCFXeXG.s: Assembler messages:
> /tmp/ccCFXeXG.s:217: Error: garbage following instruction -- `dsb
> nshst'
> /tmp/ccCFXeXG.s:225: Error: garbage following instruction -- `dsb nsh'
> make[1]: *** [arch/arm/kernel/suspend.o] Error 1
> make[1]: *** Waiting for unfinished jobs....
> 
> pavel at amd:/data/l/linux-n900$ arm-linux-gnueabi-gcc --version
> arm-linux-gnueabi-gcc (Debian 4.3.5-4) 4.3.5
> 
> Minimum required gcc is 3.2, so I'm safe.
> 
> I suspect
> 
> commit 62cbbc42e0019aff6310259f275ae812463f8836
> Author: Will Deacon <will.deacon@arm.com>
> Date:   Thu May 23 18:43:58 2013 +0100

And

commit 6af396a6b6c698eb3834184518fc9a59bc22c817
Author: Will Deacon <will.deacon@arm.com>
Date:   Wed Jun 12 10:03:30 2013 +0100

and

commit 73a6fdc48bf52e93c26874dc8c0f0f8d5585a809
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon May 13 11:39:50 2013 +0100

and

commit 6abdd491698a27f7df04a32ca12cc453810e4396
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon May 13 12:01:12 2013 +0100

Now I've reverted those, and it seems to build... and boot, but
something in 3.12-rc1 broke display :-(. (dmesg diff attached at the
end, maybe someone knows...)

Signed-off-by: Pavel Machek <pavel@ucw.cz>
									Pavel
diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
index 15f2d5b..bfd37e5 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -351,7 +351,7 @@ static inline void flush_cache_vmap(unsigned long start, unsigned long end)
 		 * set_pte_at() called from vmap_pte_range() does not
 		 * have a DSB after cleaning the cache line.
 		 */
-		dsb(ishst);
+		dsb();
 }
 
 static inline void flush_cache_vunmap(unsigned long start, unsigned long end)
diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
index 4f2c280..b07c09e 100644
--- a/arch/arm/include/asm/spinlock.h
+++ b/arch/arm/include/asm/spinlock.h
@@ -46,7 +46,7 @@ static inline void dsb_sev(void)
 {
 #if __LINUX_ARM_ARCH__ >= 7
 	__asm__ __volatile__ (
-		"dsb ishst\n"
+		"dsb\n"
 		SEV
 	);
 #else
diff --git a/arch/arm/include/asm/switch_to.h b/arch/arm/include/asm/switch_to.h
index c99e259..fa09e6b 100644
--- a/arch/arm/include/asm/switch_to.h
+++ b/arch/arm/include/asm/switch_to.h
@@ -4,16 +4,6 @@
 #include <linux/thread_info.h>
 
 /*
- * For v7 SMP cores running a preemptible kernel we may be pre-empted
- * during a TLB maintenance operation, so execute an inner-shareable dsb
- * to ensure that the maintenance completes in case we migrate to another
- * CPU.
- */
-#if defined(CONFIG_PREEMPT) && defined(CONFIG_SMP) && defined(CONFIG_CPU_V7)
-#define finish_arch_switch(prev)	dsb(ish)
-#endif
-
-/*
  * switch_to(prev, next) should switch from task `prev' to `next'
  * `prev' will never be the same as `next'.  schedule() itself
  * contains the memory barrier to tell GCC not to cache `current'.
diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
index 3896026..8471824 100644
--- a/arch/arm/include/asm/tlbflush.h
+++ b/arch/arm/include/asm/tlbflush.h
@@ -335,13 +335,13 @@ static inline void local_flush_tlb_all(void)
 	const unsigned int __tlb_flag = __cpu_tlb_flags;
 
 	if (tlb_flag(TLB_WB))
-		dsb(nshst);
+		dsb();
 
 	__local_flush_tlb_all();
 	tlb_op(TLB_V7_UIS_FULL, "c8, c7, 0", zero);
 
 	if (tlb_flag(TLB_BARRIER)) {
-		dsb(nsh);
+		dsb();
 		isb();
 	}
 }
@@ -352,13 +352,13 @@ static inline void __flush_tlb_all(void)
 	const unsigned int __tlb_flag = __cpu_tlb_flags;
 
 	if (tlb_flag(TLB_WB))
-		dsb(ishst);
+		dsb();
 
 	__local_flush_tlb_all();
 	tlb_op(TLB_V7_UIS_FULL, "c8, c3, 0", zero);
 
 	if (tlb_flag(TLB_BARRIER)) {
-		dsb(ish);
+		dsb();
 		isb();
 	}
 }
@@ -388,13 +388,13 @@ static inline void local_flush_tlb_mm(struct mm_struct *mm)
 	const unsigned int __tlb_flag = __cpu_tlb_flags;
 
 	if (tlb_flag(TLB_WB))
-		dsb(nshst);
+		dsb();
 
 	__local_flush_tlb_mm(mm);
 	tlb_op(TLB_V7_UIS_ASID, "c8, c7, 2", asid);
 
 	if (tlb_flag(TLB_BARRIER))
-		dsb(nsh);
+		dsb();
 }
 
 static inline void __flush_tlb_mm(struct mm_struct *mm)
@@ -402,7 +402,7 @@ static inline void __flush_tlb_mm(struct mm_struct *mm)
 	const unsigned int __tlb_flag = __cpu_tlb_flags;
 
 	if (tlb_flag(TLB_WB))
-		dsb(ishst);
+		dsb();
 
 	__local_flush_tlb_mm(mm);
 #ifdef CONFIG_ARM_ERRATA_720789
@@ -412,7 +412,7 @@ static inline void __flush_tlb_mm(struct mm_struct *mm)
 #endif
 
 	if (tlb_flag(TLB_BARRIER))
-		dsb(ish);
+		dsb();
 }
 
 static inline void
@@ -445,13 +445,13 @@ local_flush_tlb_page(struct vm_area_struct *vma, unsigned long uaddr)
 	uaddr = (uaddr & PAGE_MASK) | ASID(vma->vm_mm);
 
 	if (tlb_flag(TLB_WB))
-		dsb(nshst);
+		dsb();
 
 	__local_flush_tlb_page(vma, uaddr);
 	tlb_op(TLB_V7_UIS_PAGE, "c8, c7, 1", uaddr);
 
 	if (tlb_flag(TLB_BARRIER))
-		dsb(nsh);
+		dsb();
 }
 
 static inline void
@@ -462,7 +462,7 @@ __flush_tlb_page(struct vm_area_struct *vma, unsigned long uaddr)
 	uaddr = (uaddr & PAGE_MASK) | ASID(vma->vm_mm);
 
 	if (tlb_flag(TLB_WB))
-		dsb(ishst);
+		dsb();
 
 	__local_flush_tlb_page(vma, uaddr);
 #ifdef CONFIG_ARM_ERRATA_720789
@@ -472,7 +472,7 @@ __flush_tlb_page(struct vm_area_struct *vma, unsigned long uaddr)
 #endif
 
 	if (tlb_flag(TLB_BARRIER))
-		dsb(ish);
+		dsb();
 }
 
 static inline void __local_flush_tlb_kernel_page(unsigned long kaddr)
@@ -498,13 +498,13 @@ static inline void local_flush_tlb_kernel_page(unsigned long kaddr)
 	kaddr &= PAGE_MASK;
 
 	if (tlb_flag(TLB_WB))
-		dsb(nshst);
+		dsb();
 
 	__local_flush_tlb_kernel_page(kaddr);
 	tlb_op(TLB_V7_UIS_PAGE, "c8, c7, 1", kaddr);
 
 	if (tlb_flag(TLB_BARRIER)) {
-		dsb(nsh);
+		dsb();
 		isb();
 	}
 }
@@ -516,13 +516,13 @@ static inline void __flush_tlb_kernel_page(unsigned long kaddr)
 	kaddr &= PAGE_MASK;
 
 	if (tlb_flag(TLB_WB))
-		dsb(ishst);
+		dsb();
 
 	__local_flush_tlb_kernel_page(kaddr);
 	tlb_op(TLB_V7_UIS_PAGE, "c8, c3, 1", kaddr);
 
 	if (tlb_flag(TLB_BARRIER)) {
-		dsb(ish);
+		dsb();
 		isb();
 	}
 }
@@ -578,7 +578,7 @@ static inline void dummy_flush_tlb_a15_erratum(void)
 	 * Dummy TLBIMVAIS. Using the unmapped address 0 and ASID 0.
 	 */
 	asm("mcr p15, 0, %0, c8, c3, 1" : : "r" (0));
-	dsb(ish);
+	dsb();
 }
 #else
 static inline int erratum_a15_798181(void)
@@ -612,7 +612,7 @@ static inline void flush_pmd_entry(void *pmd)
 	tlb_l2_op(TLB_L2CLEAN_FR, "c15, c9, 1  @ L2 flush_pmd", pmd);
 
 	if (tlb_flag(TLB_WB))
-		dsb(ishst);
+		dsb();
 }
 
 static inline void clean_pmd_entry(void *pmd)
diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
index b5c467a..515b000 100644
--- a/arch/arm/mm/cache-v7.S
+++ b/arch/arm/mm/cache-v7.S
@@ -282,7 +282,7 @@ ENTRY(v7_coherent_user_range)
 	add	r12, r12, r2
 	cmp	r12, r1
 	blo	1b
-	dsb	ishst
+	dsb
 	icache_line_size r2, r3
 	sub	r3, r2, #1
 	bic	r12, r0, r3
@@ -294,7 +294,7 @@ ENTRY(v7_coherent_user_range)
 	mov	r0, #0
 	ALT_SMP(mcr	p15, 0, r0, c7, c1, 6)	@ invalidate BTB Inner Shareable
 	ALT_UP(mcr	p15, 0, r0, c7, c5, 6)	@ invalidate BTB
-	dsb	ishst
+	dsb
 	isb
 	mov	pc, lr
 
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index c63d9bd..f68734f 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -83,7 +83,7 @@ ENTRY(cpu_v7_dcache_clean_area)
 	add	r0, r0, r2
 	subs	r1, r1, r2
 	bhi	2b
-	dsb	ishst
+	dsb
 	mov	pc, lr
 ENDPROC(cpu_v7_dcache_clean_area)
 
diff --git a/arch/arm/mm/tlb-v7.S b/arch/arm/mm/tlb-v7.S
index 3553087..ea94765 100644
--- a/arch/arm/mm/tlb-v7.S
+++ b/arch/arm/mm/tlb-v7.S
@@ -35,7 +35,7 @@
 ENTRY(v7wbi_flush_user_tlb_range)
 	vma_vm_mm r3, r2			@ get vma->vm_mm
 	mmid	r3, r3				@ get vm_mm->context.id
-	dsb	ish
+	dsb
 	mov	r0, r0, lsr #PAGE_SHIFT		@ align address
 	mov	r1, r1, lsr #PAGE_SHIFT
 	asid	r3, r3				@ mask ASID
@@ -56,7 +56,7 @@ ENTRY(v7wbi_flush_user_tlb_range)
 	add	r0, r0, #PAGE_SZ
 	cmp	r0, r1
 	blo	1b
-	dsb	ish
+	dsb
 	mov	pc, lr
 ENDPROC(v7wbi_flush_user_tlb_range)
 
@@ -69,7 +69,7 @@ ENDPROC(v7wbi_flush_user_tlb_range)
  *	- end   - end address (exclusive, may not be aligned)
  */
 ENTRY(v7wbi_flush_kern_tlb_range)
-	dsb	ish
+	dsb
 	mov	r0, r0, lsr #PAGE_SHIFT		@ align address
 	mov	r1, r1, lsr #PAGE_SHIFT
 	mov	r0, r0, lsl #PAGE_SHIFT
@@ -84,7 +84,7 @@ ENTRY(v7wbi_flush_kern_tlb_range)
 	add	r0, r0, #PAGE_SZ
 	cmp	r0, r1
 	blo	1b
-	dsb	ish
+	dsb
 	isb
 	mov	pc, lr
 ENDPROC(v7wbi_flush_kern_tlb_range)
diff --git a/dmesg.qemu b/dmesg.qemu
index 452bc2e..9355be1 100644
--- a/dmesg.qemu
+++ b/dmesg.qemu
@@ -27,6 +27,7 @@ Booting secondary
    No USB host detected

  Loading initfs image info

  Serial console enabled

+omap2_inth_read: Bad register 0x000020
  Booting Linux on physical CPU 0x0

  Initializing cgroup subsys cpu

  revision 3 (ARMv7), cr=10c53c7d

@@ -65,12 +66,15 @@ Booting secondary
  Initializing cgroup subsys blkio

  CPU: Testing write buffer coherency: ok

  devtmpfs: initialized

+ VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 2

  omap_hdq1w_reset: hdq1w: softreset failed (waited 10000 usec)

  omap_hwmod: sham: cannot be enabled for reset (3)

  omap_hwmod: aes: cannot be enabled for reset (3)

  pinctrl core: initialized pinctrl subsystem

  NET: Registered protocol family 16

  DMA: preallocated 256 KiB pool for atomic coherent allocations

+ cpuidle: using governor ladder

+ cpuidle: using governor menu

  Reprogramming SDRC clock to 332000000 Hz

  OMAP GPIO hardware version 2.5

  platform 49022000.mcbsp: alias fck already exists

@@ -114,7 +118,7 @@ Booting secondary
  WARNING: CPU: 0 PID: 1 at drivers/video/omap2/dss/dss.c:540 dss_set_clock_div+0xa0/0xcc()

  clk rate mismatch: 86400000 != 172800000

  Modules linked in:

- CPU: 0 PID: 1 Comm: swapper Not tainted 3.11.0+ #326

+ CPU: 0 PID: 1 Comm: swapper Not tainted 3.12.0-rc1+ #327

  (show_stack+0x14/0x1c)

  (warn_slowpath_common+0x64/0x84)

  (warn_slowpath_fmt+0x30/0x40)

@@ -124,25 +128,23 @@ Booting secondary
  (driver_probe_device+0xc0/0x21c)

  (__driver_attach+0x60/0x84)

  (bus_for_each_dev+0x50/0x98)

- (bus_add_driver+0xb4/0x21c)

- (driver_register+0xa4/0x144)

+ (bus_add_driver+0xb4/0x244)

+ (driver_register+0xa4/0xec)

  (platform_driver_probe+0x1c/0xa8)

- (omap_dss_init2+0x20/0xcc)

+ (omap_dss_init+0x1c/0xbc)

  (do_one_initcall+0x94/0x134)

  (kernel_init_freeable+0xe0/0x1b8)

  (kernel_init+0x8/0x15c)

  (ret_from_fork+0x14/0x3c)

 ---

  OMAP DSS rev 2.0

- omapfb omapfb: no driver for display: lcd

+ omapfb omapfb: no displays

+ omapfb omapfb: failed to setup omapfb

  platform omapfb: Driver omapfb requests probe deferral

  Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled

- omap_uart serial.5: did not get pins for uart0 error: -19

- serial.5: ttyO0 at MMIO 0x4806a000 (irq = 88) is a OMAP UART0

- omap_uart serial.6: did not get pins for uart1 error: -19

- serial.6: ttyO1 at MMIO 0x4806c000 (irq = 89) is a OMAP UART1

- omap_uart serial.7: did not get pins for uart2 error: -19

- serial.7: ttyO2 at MMIO 0x49020000 (irq = 90) is a OMAP UART2

+ serial.5: ttyO0 at MMIO 0x4806a000 (irq = 88, base_baud = 3000000) is a OMAP UART0

+ serial.6: ttyO1 at MMIO 0x4806c000 (irq = 89, base_baud = 3000000) is a OMAP UART1

+ serial.7: ttyO2 at MMIO 0x49020000 (irq = 90, base_baud = 3000000) is a OMAP UART2

  enabled

  brd: module loaded

  loop: module loaded

@@ -151,11 +153,8 @@ Booting secondary
  omap-dma-engine 48056000.dma-controller: allocating channel for 35

  omap-dma-engine 48056000.dma-controller: allocating channel for 40

  omap-dma-engine 48056000.dma-controller: allocating channel for 39

- acx565akm spi1.2: omapfb: acx565akm rev 12 LCD detected

  musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -6

  omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec

- cpuidle: using governor ladder

- cpuidle: using governor menu

  ledtrig-cpu: registered to indicate activity on CPUs

  TCP: cubic registered

  Initializing XFRM netlink socket

@@ -163,10 +162,11 @@ Booting secondary
  NET: Registered protocol family 15

  NET: Registered protocol family 35

  Key type dns_resolver registered

- VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 2

  ThumbEE CPU extension supported.

  registered taskstats version 1

- Console: switching to colour frame buffer device 100x30

+ omapfb omapfb: no displays

+ omapfb omapfb: failed to setup omapfb

+ platform omapfb: Driver omapfb requests probe deferral

  drivers/rtc/hctosys.c: unable to open rtc device (rtc0)

  ALSA device list:

    No soundcards found.



-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

3.12-rc1: no longer compiles for Nokia n900 (omap based)

[Pavel Machek]

On Thu 2013-09-19 10:36:28, Will Deacon wrote:
> On Thu, Sep 19, 2013 at 10:30:02AM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > I get:
> > 
> >   CC      arch/arm/kernel/machine_kexec.o
> > /tmp/ccCFXeXG.s: Assembler messages:
> > /tmp/ccCFXeXG.s:217: Error: garbage following instruction -- `dsb
> > nshst'
> > /tmp/ccCFXeXG.s:225: Error: garbage following instruction -- `dsb nsh'
> > make[1]: *** [arch/arm/kernel/suspend.o] Error 1
> > make[1]: *** Waiting for unfinished jobs....
> > 
> > pavel at amd:/data/l/linux-n900$ arm-linux-gnueabi-gcc --version
> > arm-linux-gnueabi-gcc (Debian 4.3.5-4) 4.3.5
> > 
> > Minimum required gcc is 3.2, so I'm safe.
> 
> Please check your binutils. >= 2.22 has been reported to work.

pavel at amd:/data/l/linux-good$ arm-linux-gnueabi-ld --version
GNU ld (GNU Binutils for Debian) 2.20.1.20100303
Copyright 2009 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License version 3 or (at your option) a later
version.
This program has absolutely no warranty.

but

Documentation/Changes:
o  binutils               2.12                    # ld -v

Can the code be fixed so that binutils 2.12 still work?

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

3.12-rc1: no longer compiles for Nokia n900 (omap based), display no longer works

[Aaro Koskinen]

Hi,

On Thu, Sep 19, 2013 at 11:44:02AM +0200, Pavel Machek wrote:
> something in 3.12-rc1 broke display :-(. (dmesg diff attached at the
> end, maybe someone knows...)

3.12-rc1 for N900 compiles and works (also display) here with binutils
2.23.2.

> + omapfb omapfb: no displays

[...]

> - acx565akm spi1.2: omapfb: acx565akm rev 12 LCD detected

I think this is because the panel driver has changed, and the old one
was deleted. You need to change your kernel configuration with something
like below:

-CONFIG_PANEL_ACX565AKM=y
+CONFIG_DISPLAY_PANEL_SONY_ACX565AKM=y

A.

new binutils needed for arm in 3.12-rc1

[Rob Landley]

On 09/23/2013 06:59:17 PM, Pavel Machek wrote:
> During 3.12-rc, Will Deacon introduced code into arch/arm that
> requires binutils 2.22.

Um, my toolchain is using the last gplv2 snapshot of binutils out of  
git, which is just past 2.17 and can build armv7 (but not armv8).

Binutils 2.12->2.22 is quite the jump. (11 years.) I'd except some  
thought to have gone into that? Possibly a mention of it?

> diff --git a/Documentation/Changes b/Documentation/Changes
> index b175808..0f8deaf 100644
> --- a/Documentation/Changes
> +++ b/Documentation/Changes
> @@ -23,7 +23,7 @@ you probably needn't concern yourself with  
> isdn4k-utils.
> 
>  o  Gnu C                  3.2                     # gcc --version
>  o  Gnu make               3.80                    # make --version
> -o  binutils               2.12                    # ld -v
> +o  binutils               2.22                    # ld -v

When the sh4 platform did this, I just reverted the patch. (It still  
reverts cleanly ~4 years later, and builds with my old tool versions...)

Rob

new binutils needed for arm in 3.12-rc1

[Rob Landley]

On 09/23/2013 06:59:17 PM, Pavel Machek wrote:
> During 3.12-rc, Will Deacon introduced code into arch/arm that
> requires binutils 2.22.

I'm sorry, it occurs to me I should have been more explicit:

AAAAAAAAAAAAAAAAHHHHHHHHHH!!!!!!!!!!!!!!!!!  KILL IT WITH  
FIRE!!!!!!!!!!!!!!!

Rob

new binutils needed for arm in 3.12-rc1

[Måns Rullgård]

Rob Landley <rob@landley.net> writes:

> On 09/23/2013 06:59:17 PM, Pavel Machek wrote:
>> During 3.12-rc, Will Deacon introduced code into arch/arm that
>> requires binutils 2.22.
>
> Um, my toolchain is using the last gplv2 snapshot of binutils out of  
> git, which is just past 2.17 and can build armv7 (but not armv8).
>
> Binutils 2.12->2.22 is quite the jump. (11 years.) I'd except some  
> thought to have gone into that? Possibly a mention of it?

I seriously doubt that 2.12 still works at all (I doubt it can even be
built on a modern system).  In my experience, binutils older than 2.19
or so rarely works properly for ARM.

What value is there in maintaining compatibility with a truly ancient
binutils version anyway?

-- 
M?ns Rullg?rd
mans at mansr.com

new binutils needed for arm in 3.12-rc1

[Rob Landley]

On 09/24/2013 07:11:38 AM, M?ns Rullg?rd wrote:
> Rob Landley <rob@landley.net> writes:
> 
> > On 09/23/2013 06:59:17 PM, Pavel Machek wrote:
> >> During 3.12-rc, Will Deacon introduced code into arch/arm that
> >> requires binutils 2.22.
> >
> > Um, my toolchain is using the last gplv2 snapshot of binutils out of
> > git, which is just past 2.17 and can build armv7 (but not armv8).
> >
> > Binutils 2.12->2.22 is quite the jump. (11 years.) I'd except some
> > thought to have gone into that? Possibly a mention of it?
> 
> I seriously doubt that 2.12 still works at all (I doubt it can even be
> built on a modern system).  In my experience, binutils older than 2.19
> or so rarely works properly for ARM.

I've been building every kernel release with 2.17 for several years, on  
a bunch of different architectures. Toolchain releases after that are  
GPLv3* and I can't distribute those binaries, so I can't ship prebuilt  
binary toolchains.

(Lots of other people produce cross compilers, but nobody else seems to  
produce prebuilt statically linked _native_ compilers. It would be nice  
if they did.)

> What value is there in maintaining compatibility with a truly ancient
> binutils version anyway?

What value is there in requiring the new toolchain? From what I could  
see of the commits it was micro-optimizations around memory barriers.

*shrug* I can revert the patch locally, or patch the extra instruction  
into my toolchain. But I do object to changing the documentation  
globally for every architecture because one architecture did something  
they apparently never thought through (or they'd have commented in the  
commit that it requires a big toolchain version jump; pretty sure they  
didn't actually notice).

Rob

* The Free Software Foundation got so pissed that MacOS X and BSD and  
such were sticking with the last GPLv2 release of binutils that they  
deleted the binutils tarball off their website and replaced it with one  
including GPLv3 source code. Check the FTP site if you don't believe  
me. Some of us have it snapshotted though. In my case, I actually  
fished the last GPLv2 version out of source control, right before the  
license change was committed, because I wanted armv7 support.

new binutils needed for arm in 3.12-rc1

[Russell King - ARM Linux]

On Tue, Sep 24, 2013 at 04:23:48PM -0500, Rob Landley wrote:
> What value is there in requiring the new toolchain? From what I could  
> see of the commits it was micro-optimizations around memory barriers.
>
> *shrug* I can revert the patch locally, or patch the extra instruction  
> into my toolchain. But I do object to changing the documentation  
> globally for every architecture because one architecture did something  
> they apparently never thought through (or they'd have commented in the  
> commit that it requires a big toolchain version jump; pretty sure they  
> didn't actually notice).

Some of us are notoriously slow at updating our toolchains.  I'm still
using gcc 4.5.4 here, and people regard that as bordering on "too old"
because of the amount of warnings it spits out.  Binutils?  I upgraded
to 2.22 when I needed to fix a problem I was having with the previous
binutils I was using (I think that was 2.18).

I generally don't touch my toolchain unless there's a _reason_ I need
to, and as I've already updated to 2.22, it's a normally a pretty safe
bet that everyone else is already using 2.22 or later.  One reason for
this is that I don't want to be messing around trying to work out
whether a bug I'm seeing is because of a toolchain problem or something
in the kernel.

I realised at the time that I'm going to got shouted at if I accepted
the patches by a minority who wanted to keep their old toolchains, but
I also realise that if I don't accept the patches, I'll get shouted at
by another group.  It's the classic damned if I do and damned if I
don't.  So I've chosen the lesser of the two weavels.

Now, if you feel strongly about this, we _could_ introduce a
CONFIG_OLD_BINUTILS and give everyone their cake - but it will be
fragile.  Not everyone will remember to get that right, because they'll
be using the later binutils.  Also, we already have an excessive number
of potential breakage-inducing options and we certainly don't need
another.

Use IS_ENABLED() I hear you say.  That won't get the one dsb instruction
in some SoC code which was missed which will break the build on older
toolchains.

new binutils needed for arm in 3.12-rc1

[Rob Landley]

On 09/24/2013 04:48:00 PM, Russell King - ARM Linux wrote:
> On Tue, Sep 24, 2013 at 04:23:48PM -0500, Rob Landley wrote:
> > What value is there in requiring the new toolchain? From what I  
> could
> > see of the commits it was micro-optimizations around memory  
> barriers.
> >
> > *shrug* I can revert the patch locally, or patch the extra  
> instruction
> > into my toolchain. But I do object to changing the documentation
> > globally for every architecture because one architecture did  
> something
> > they apparently never thought through (or they'd have commented in  
> the
> > commit that it requires a big toolchain version jump; pretty sure  
> they
> > didn't actually notice).
> 
> Some of us are notoriously slow at updating our toolchains.
...

Some of us can't ship GPLv3 binaries and are looking forward to the day  
LLVM or some such provides a complete solution.

> Now, if you feel strongly about this, we _could_ introduce a
> CONFIG_OLD_BINUTILS and give everyone their cake - but it will be
> fragile.  Not everyone will remember to get that right, because  
> they'll
> be using the later binutils.  Also, we already have an excessive  
> number
> of potential breakage-inducing options and we certainly don't need
> another.

I'm doing the regression testing either way, on several different  
architectures. (Although I tend to to only really do a thorough job  
quarterly when a new kernel comes out and it's time to make it work.)  
So I'm going to be doing something locally like this anyway, and if a  
CONFIG_OLD_BINUTILS is acceptable I might as well push it upstream.

My use case is running all these targets under qemu, so it's not  
exactly performance-critical. :)

> Use IS_ENABLED() I hear you say.  That won't get the one dsb  
> instruction
> in some SoC code which was missed which will break the build on older
> toolchains.

My regression test is my http://landley.net/aboriginal/about.html  
project, where I:

1) build cross compilers for ~15 different architecture variants (maybe  
half unique, the rest variants of the others).

2) Use them to build the smallest native development environment  
capable of reproducing itself from soruce code.

3) Boot it under qemu.

4) Build linux from scratch under the result.

I've sometimes had it the whole mess automated from a cron job, but the  
server I had it on blew out its hard drive controller and I haven't  
bothered to set it up again...

Next couple days are crazy but I'll try to get you a patch this weekend.

Thanks,

Rob

new binutils needed for arm in 3.12-rc1

[Nicolas Pitre]

On Tue, 24 Sep 2013, Rob Landley wrote:

> On 09/24/2013 04:48:00 PM, Russell King - ARM Linux wrote:
> > Now, if you feel strongly about this, we _could_ introduce a
> > CONFIG_OLD_BINUTILS and give everyone their cake - but it will be
> > fragile.  Not everyone will remember to get that right, because they'll
> > be using the later binutils.  Also, we already have an excessive number
> > of potential breakage-inducing options and we certainly don't need
> > another.
> 
> I'm doing the regression testing either way, on several different
> architectures. (Although I tend to to only really do a thorough job quarterly
> when a new kernel comes out and it's time to make it work.) So I'm going to be
> doing something locally like this anyway, and if a CONFIG_OLD_BINUTILS is
> acceptable I might as well push it upstream.

If you are convinced you have no choice but to stick to old binutils, 
I'd strongly suggest you make your binutils compatible with newer 
instruction syntax instead of making the kernel more complex.  This is 
more in line with being future proof rather than stuck into the past.

It could be as simple as making gas accept an extra argument for 
instructions like dsb and just ignoring it.


Nicolas

new binutils needed for arm in 3.12-rc1

[Rob Landley]

On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
> On Tue, 24 Sep 2013, Rob Landley wrote:
> 
> > On 09/24/2013 04:48:00 PM, Russell King - ARM Linux wrote:
> > > Now, if you feel strongly about this, we _could_ introduce a
> > > CONFIG_OLD_BINUTILS and give everyone their cake - but it will be
> > > fragile.  Not everyone will remember to get that right, because  
> they'll
> > > be using the later binutils.  Also, we already have an excessive  
> number
> > > of potential breakage-inducing options and we certainly don't need
> > > another.
> >
> > I'm doing the regression testing either way, on several different
> > architectures. (Although I tend to to only really do a thorough job  
> quarterly
> > when a new kernel comes out and it's time to make it work.) So I'm  
> going to be
> > doing something locally like this anyway, and if a  
> CONFIG_OLD_BINUTILS is
> > acceptable I might as well push it upstream.
> 
> If you are convinced you have no choice but to stick to old binutils,

Oh no, long-term other choices include lld.llvm.org and  
http://landley.net/code/qcc but they're not ready yet and I don't have  
time to work on them right now. (I had high hopes for gold, until the  
guy signed it over to the FSF and it vanished into the tiergruben. Oh  
well.)

> I'd strongly suggest you make your binutils compatible with newer
> instruction syntax instead of making the kernel more complex.

Meaning I play whack-a-mole as this becomes permission to depend on  
endless new gnuisms just because they're there and nobody else is  
regression testing against them, not because they actually add anything.

Whereas if I add an old binutils config option, other people might help  
regression test it (if not actually fix it), and the other toolchain  
projects have less of a moving target to catch up to.

> This is more in line with being future proof rather than stuck into  
> the past.

No, it's exactly the opposite of that. Future proof is getting off a  
toolchain whose license is a moving target.

GPLv2: "shut up and show me the code"
GPLv3: "I am altering the bargain, pray I don't alter it any further."
GPLv4: ???

> It could be as simple as making gas accept an extra argument for
> instructions like dsb and just ignoring it.

So you prefer I come up with the reversion patches locally and _not_  
send them upstream?

*shrug* That's what I've been doing for sh4 for around 4 years now.  
(And their breakage still reverts cleanly even.) It's also what I did  
when the arm versatile interrupts changed randomly 3 times in ways that  
weren't backwards compatible with existing qemu versions. And I  
maintained perl removal patches for 5 years before they finally went  
upstream.

But I do at least post said patches publicly, and other people use 'em  
when I do...

Rob

new binutils needed for arm in 3.12-rc1

[Måns Rullgård]

Rob Landley <rob@landley.net> writes:

> On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
>> I'd strongly suggest you make your binutils compatible with newer
>> instruction syntax instead of making the kernel more complex.
>
> Meaning I play whack-a-mole as this becomes permission to depend on  
> endless new gnuisms just because they're there and nobody else is  
> regression testing against them, not because they actually add anything.

Since when is assembling the instructions correctly, as specified in the
arch ref, and not in some other random way a gnuism?

-- 
M?ns Rullg?rd
mans at mansr.com

new binutils needed for arm in 3.12-rc1

[Nicolas Pitre]

On Wed, 25 Sep 2013, Rob Landley wrote:

> On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
> > I'd strongly suggest you make your binutils compatible with newer
> > instruction syntax instead of making the kernel more complex.
> 
> Meaning I play whack-a-mole as this becomes permission to depend on endless
> new gnuisms just because they're there and nobody else is regression testing
> against them, not because they actually add anything.

Gnuism?

Let me quote the ARM ARchitecture Reference Manual, version 7 revision C,  
section A8.8.44 (sorry for the whitespace dammage):

|A8.8.44 DSB
|
|Data Synchronization Barrier is a memory barrier that ensures the 
|completion of memory accesses, see Data Synchronization Barrier (DSB) on 
|page A3-150.
|
|Encoding T1 ARMv7
|
|DSB<c> <option>
|
|15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|
|1 1 1 1 0 0 1 1 1 0 1 1 (1) (1) (1) (1) 1 0 (0) 0 (1) (1) (1) (1) 0 1 0 0 option
|
|// No additional decoding required
|
|Encoding A1 ARMv7
|
|DSB <option>
|
|31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|
|1 1 1 1 0 1 0 1 0 1 1 1 (1) (1) (1) (1) (1) (1) (1) (1) (0) (0) (0) (0) 0 1 0 0 option
|
|// No additional decoding required
|
|Assembler syntax
|
|DSB{<c>}{<q>} {<option>}
|
|where:
|
|<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM DSB 
|instruction must be unconditional.
|
|<option> Specifies an optional limitation on the DSB operation. Values are:
|
|SY Full system is the required shareability domain, reads and writes are 
|the required access types. Can be omitted. This option is referred to as 
|the full system DSB. Encoded as option == '1111'.
|
|ST Full system is the required shareability domain, writes are the 
|required access type. SYST is a synonym for ST. Encoded as option == 
|'1110'.
|
|ISH Inner Shareable is the required shareability domain, reads and 
|writes are the required access types. Encoded as option == '1011'.
|
|ISHST Inner Shareable is the required shareability domain, writes are 
|the required access type. Encoded as option == '1010'.
|
|NSH Non-shareable is the required shareability domain, reads and writes 
|are the required access types. Encoded as option == '0111'.
|
|NSHST Non-shareable is the required shareability domain, writes are the 
|required access type. Encoded as option == '0110'.
|
|OSH Outer Shareable is the required shareability domain, reads and 
|writes are the required access types. Encoded as option == '0011'.
|
|OSHST Outer Shareable is the required shareability domain, writes are 
|the required access type. Encoded as option == '0010'.

So what's the link with the above and your issue with GPLv3, besides the 
fact that the last binutils version to have been released under the 
GPLv2 is defficient?

For the record I have no opinion to provide about GPLv2 vs GPLv3 in the 
context of this thread.

> > It could be as simple as making gas accept an extra argument for
> > instructions like dsb and just ignoring it.
> 
> So you prefer I come up with the reversion patches locally and _not_ send them
> upstream?

Sort of.  And I'm suggesting you patch your binutils rather than the 
kernel.  Given you're not upgrading your binutils anymore that means 
you'll have to apply that patch only once instead of having to apply it 
to every kernel upgrade.

> But I do at least post said patches publicly, and other people use 'em 
> when I do...

Excellent.


Nicolas

new binutils needed for arm in 3.12-rc1

[Russell King - ARM Linux]

On Wed, Sep 25, 2013 at 10:23:06AM -0500, Rob Landley wrote:
> On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
>> It could be as simple as making gas accept an extra argument for
>> instructions like dsb and just ignoring it.
>
> So you prefer I come up with the reversion patches locally and _not_  
> send them upstream?

This is a silly attitude.  What you're effectively saying is that we
are never allowed to use any future ARM instructions in any Linux
kernel because that might break your precious assembler.

I've got news for you.  We're *not* going to listen to that argument.

END OF DISCUSSION (everything else is just a waste of time.)

new binutils needed for arm in 3.12-rc1

[Måns Rullgård]

Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

> On Wed, Sep 25, 2013 at 10:23:06AM -0500, Rob Landley wrote:
>> On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
>>> It could be as simple as making gas accept an extra argument for
>>> instructions like dsb and just ignoring it.
>>
>> So you prefer I come up with the reversion patches locally and _not_  
>> send them upstream?
>
> This is a silly attitude.  What you're effectively saying is that we
> are never allowed to use any future ARM instructions in any Linux
> kernel because that might break your precious assembler.
>
> I've got news for you.  We're *not* going to listen to that argument.
>
> END OF DISCUSSION (everything else is just a waste of time.)

I fully agree.

-- 
M?ns Rullg?rd
mans at mansr.com

new binutils needed for arm in 3.12-rc1

[Rob Landley]

On 09/25/2013 10:52:44 AM, M?ns Rullg?rd wrote:
> Rob Landley <rob@landley.net> writes:
> 
> > On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
> >> I'd strongly suggest you make your binutils compatible with newer
> >> instruction syntax instead of making the kernel more complex.
> >
> > Meaning I play whack-a-mole as this becomes permission to depend on
> > endless new gnuisms just because they're there and nobody else is
> > regression testing against them, not because they actually add  
> anything.
> 
> Since when is assembling the instructions correctly, as specified in  
> the
> arch ref, and not in some other random way a gnuism?

If you require current gnome and drop support for older versions (and  
implicitly all other desktops), people start writing stuff that depends  
on systemd. It doesn't matter if the feature you abandoned support for  
the past 10 years of everthing else for wasn't itself provided by  
systemd.

Rob

3.12-rc1: no longer compiles for Nokia n900 (omap based), display no longer works

[Pavel Machek]

Hi!

> On Thu, Sep 19, 2013 at 11:44:02AM +0200, Pavel Machek wrote:
> > something in 3.12-rc1 broke display :-(. (dmesg diff attached at the
> > end, maybe someone knows...)
> 
> 3.12-rc1 for N900 compiles and works (also display) here with binutils
> 2.23.2.

I updated to eldk-5.4, and now it compiles, but still no display on 

> > + omapfb omapfb: no displays
> 
> [...]
> 
> > - acx565akm spi1.2: omapfb: acx565akm rev 12 LCD detected
> 
> I think this is because the panel driver has changed, and the old one
> was deleted. You need to change your kernel configuration with something
> like below:
> 
> -CONFIG_PANEL_ACX565AKM=y
> +CONFIG_DISPLAY_PANEL_SONY_ACX565AKM=y

Thanks for the hint.. but apparently it was not enough. Still no
display on qemu :-(.

Anyway, "make oldconfig" is expected to produce working kernel, which
is clearly not case here. Perhaps this should be added to fix that?

[Who can take the patch?]
   	       	    	  	       	      	       	      Pavel

PS: whoever named directory in kernel sources "displays-new" should...
think again.

Signed-off-by: Pavel Machek <pavel@ucw.cz>

index 6c90885..d3eabd2 100644
--- a/drivers/video/omap2/displays-new/Kconfig
+++ b/drivers/video/omap2/displays-new/Kconfig
@@ -40,6 +40,7 @@ config DISPLAY_PANEL_DSI_CM
 
 config DISPLAY_PANEL_SONY_ACX565AKM
 	tristate "ACX565AKM Panel"
+	default PANEL_ACX565AKM
 	depends on SPI && BACKLIGHT_CLASS_DEVICE
 	help
 	  This is the LCD panel used on Nokia N900

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

new binutils needed for arm in 3.12-rc1

[Geert Uytterhoeven]

Hi Rob,

On Wed, Sep 25, 2013 at 3:13 AM, Rob Landley <rob@landley.net> wrote:
> Some of us can't ship GPLv3 binaries and are looking forward to the day LLVM
> or some such provides a complete solution.

Sorry, I didn't have a coffee yet, but which subtility am I missing
that prohibits
you from shipping GPLv3 binaries?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

new binutils needed for arm in 3.12-rc1

[Ben Dooks]

On 24/09/13 03:13, Rob Landley wrote:
> On 09/23/2013 06:59:17 PM, Pavel Machek wrote:
>> During 3.12-rc, Will Deacon introduced code into arch/arm that
>> requires binutils 2.22.
>
> Um, my toolchain is using the last gplv2 snapshot of binutils out of
> git, which is just past 2.17 and can build armv7 (but not armv8).
>
> Binutils 2.12->2.22 is quite the jump. (11 years.) I'd except some
> thought to have gone into that? Possibly a mention of it?
>
>> diff --git a/Documentation/Changes b/Documentation/Changes
>> index b175808..0f8deaf 100644
>> --- a/Documentation/Changes
>> +++ b/Documentation/Changes
>> @@ -23,7 +23,7 @@ you probably needn't concern yourself with
>> isdn4k-utils.
>>
>> o Gnu C 3.2 # gcc --version
>> o Gnu make 3.80 # make --version
>> -o binutils 2.12 # ld -v
>> +o binutils 2.22 # ld -v

Out of interest, can I now change my fixes for v3.12 big-endian
series to use .instr instead of .word?

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

new binutils needed for arm in 3.12-rc1

[Måns Rullgård]

Rob Landley <rob@landley.net> writes:

> On 09/25/2013 10:52:44 AM, M?ns Rullg?rd wrote:
>> Rob Landley <rob@landley.net> writes:
>> 
>> > On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
>> >> I'd strongly suggest you make your binutils compatible with newer
>> >> instruction syntax instead of making the kernel more complex.
>> >
>> > Meaning I play whack-a-mole as this becomes permission to depend on
>> > endless new gnuisms just because they're there and nobody else is
>> > regression testing against them, not because they actually add  
>> > anything.
>> 
>> Since when is assembling the instructions correctly, as specified in
>> the arch ref, and not in some other random way a gnuism?
>
> If you require current gnome and drop support for older versions (and  
> implicitly all other desktops), people start writing stuff that depends  
> on systemd. It doesn't matter if the feature you abandoned support for  
> the past 10 years of everthing else for wasn't itself provided by  
> systemd.

Are you saying current binutils depends on gnome and/or systemd?

-- 
M?ns Rullg?rd
mans at mansr.com

new binutils needed for arm in 3.12-rc1

[Rob Landley]

On 09/25/2013 11:13:17 AM, Nicolas Pitre wrote:
> On Wed, 25 Sep 2013, Rob Landley wrote:
> 
> > On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
> > > I'd strongly suggest you make your binutils compatible with newer
> > > instruction syntax instead of making the kernel more complex.
> >
> > Meaning I play whack-a-mole as this becomes permission to depend on  
> endless
> > new gnuisms just because they're there and nobody else is  
> regression testing
> > against them, not because they actually add anything.
> 
> Gnuism?
> 
> Let me quote the ARM ARchitecture Reference Manual, version 7  
> revision C,
> section A8.8.44 (sorry for the whitespace dammage):

Globally changing the binutils requirement for all architectures, as  
the doc patch at the start of this thread proposed doing, would mean  
gnuisms in common code (ext2 and such) wouldn't get caught, giving llvm  
and pcc and such a moving target when trying to build the kernel with  
non-gnu toolchains. That's what I meant by gnuisms breeding.

> So what's the link with the above and your issue with GPLv3, besides  
> the
> fact that the last binutils version to have been released under the
> GPLv2 is defficient?

I apparently wasn't clear. The new instructions aren't gnuisms. The  
lack of widespread regression testing for armv5l and such would allow  
introduction of nonportable constructs in a larger context.

(The fact that armv7 could apparently build fine for ~7 years with  
binutils 2.18 through 2.21, and now it's suddenly can't Because Reasons  
is kinda silly, but not really a big deal. That, I can patch my  
toolchain.)

> > > It could be as simple as making gas accept an extra argument for
> > > instructions like dsb and just ignoring it.
> >
> > So you prefer I come up with the reversion patches locally and  
> _not_ send them
> > upstream?
> 
> Sort of.  And I'm suggesting you patch your binutils rather than the
> kernel.

I had this misidentified as a global arm problem and not specific to  
arm7l. If armv5l still still builds with the old toolchains, it's not a  
big deal.

> Given you're not upgrading your binutils anymore that means
> you'll have to apply that patch only once instead of having to apply  
> it
> to every kernel upgrade.

Indeed. Patching my own toolchain isn't really a problem. My objection  
was to the Documentation patch telling the world at large that for all  
targets, older binutils aren't supported even on x86. That was worth  
pushing back against.

I don't indend to use old gcc/binutils versions forever, I just want to  
be able to use them until I can replace them with llvm or similar.

Rob

new binutils needed for arm in 3.12-rc1

[Rob Landley]

On 09/25/2013 03:49:07 PM, M?ns Rullg?rd wrote:
> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> 
> > On Wed, Sep 25, 2013 at 10:23:06AM -0500, Rob Landley wrote:
> >> On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
> >>> It could be as simple as making gas accept an extra argument for
> >>> instructions like dsb and just ignoring it.
> >>
> >> So you prefer I come up with the reversion patches locally and  
> _not_
> >> send them upstream?
> >
> > This is a silly attitude.  What you're effectively saying is that we
> > are never allowed to use any future ARM instructions in any Linux
> > kernel because that might break your precious assembler.
> >
> > I've got news for you.  We're *not* going to listen to that  
> argument.
> >
> > END OF DISCUSSION (everything else is just a waste of time.)

Who am I to argue with capital letters?

> I fully agree.

Actually, I thought this was an armv5l regression. (My objection was to  
requiring a newer toolchain for architectures that built fine under the  
old one. My attention was attracted by the proposed patch to  
Documentation/changes with a global updated for required binutils  
version.)

I've since had a chance to confirm the armv5 build break I saw was just  
normal mid-rc1 noise (since fixed) and this set of patches just applies  
to armv7, which already required a newer binutils, so objection  
withdrawn.

Rob

new binutils needed for arm in 3.12-rc1

[Pavel Machek]

Hi!

On Thu 2013-09-26 17:48:29, Rob Landley wrote:
> On 09/25/2013 11:13:17 AM, Nicolas Pitre wrote:
> >On Wed, 25 Sep 2013, Rob Landley wrote:
> >
> >> On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
> >> > I'd strongly suggest you make your binutils compatible with newer
> >> > instruction syntax instead of making the kernel more complex.
> >>
> >> Meaning I play whack-a-mole as this becomes permission to depend
> >on endless
> >> new gnuisms just because they're there and nobody else is
> >regression testing
> >> against them, not because they actually add anything.
> >
> >Gnuism?
> >
> >Let me quote the ARM ARchitecture Reference Manual, version 7
> >revision C,
> >section A8.8.44 (sorry for the whitespace dammage):
> 
> Globally changing the binutils requirement for all architectures, as
> the doc patch at the start of this thread proposed doing, would mean
> gnuisms in common code (ext2 and such) wouldn't get caught, giving
> llvm and pcc and such a moving target when trying to build the
> kernel with non-gnu toolchains. That's what I meant by gnuisms
> breeding.

Well. I did the docs patch, but my preferred solution would actually
be to get the patches reverted so that it still works with old
binutils.

(So far, I updated one machine with new cross environment, two more to
go.)

Anyway, it should be solved _somehow_.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

new binutils needed for arm in 3.12-rc1

[Pavel Machek]

Hi!

> >Given you're not upgrading your binutils anymore that means
> >you'll have to apply that patch only once instead of having to
> >apply it
> >to every kernel upgrade.
> 
> Indeed. Patching my own toolchain isn't really a problem. My
> objection was to the Documentation patch telling the world at large
> that for all targets, older binutils aren't supported even on x86.
> That was worth pushing back against.
> 
> I don't indend to use old gcc/binutils versions forever, I just want
> to be able to use them until I can replace them with llvm or
> similar.

So, what is the proposal? Just ignore the problem and make people
wonder why their arm kernels are not compiling?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

new binutils needed for arm in 3.12-rc1

[richard -rw- weinberger]

On Thu, Sep 26, 2013 at 9:18 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Rob,
>
> On Wed, Sep 25, 2013 at 3:13 AM, Rob Landley <rob@landley.net> wrote:
>> Some of us can't ship GPLv3 binaries and are looking forward to the day LLVM
>> or some such provides a complete solution.
>
> Sorry, I didn't have a coffee yet, but which subtility am I missing
> that prohibits
> you from shipping GPLv3 binaries?

/me had coffee but still doesn't get why you can't ship GPLv3 binaries.
Rob, can you please enlighten us?

-- 
Thanks,
//richard

new binutils needed for arm in 3.12-rc1

[Dave Martin]

On Thu, Sep 26, 2013 at 06:00:49PM +0100, Ben Dooks wrote:
> On 24/09/13 03:13, Rob Landley wrote:
> >On 09/23/2013 06:59:17 PM, Pavel Machek wrote:
> >>During 3.12-rc, Will Deacon introduced code into arch/arm that
> >>requires binutils 2.22.
> >
> >Um, my toolchain is using the last gplv2 snapshot of binutils out of
> >git, which is just past 2.17 and can build armv7 (but not armv8).
> >
> >Binutils 2.12->2.22 is quite the jump. (11 years.) I'd except some
> >thought to have gone into that? Possibly a mention of it?
> >
> >>diff --git a/Documentation/Changes b/Documentation/Changes
> >>index b175808..0f8deaf 100644
> >>--- a/Documentation/Changes
> >>+++ b/Documentation/Changes
> >>@@ -23,7 +23,7 @@ you probably needn't concern yourself with
> >>isdn4k-utils.
> >>
> >>o Gnu C 3.2 # gcc --version
> >>o Gnu make 3.80 # make --version
> >>-o binutils 2.12 # ld -v
> >>+o binutils 2.22 # ld -v
> 
> Out of interest, can I now change my fixes for v3.12 big-endian
> series to use .instr instead of .word?

There seems to be a consensus in this thread that demanding newer
binutils for this feature is reasonable, at least for v7, since
older versions may not completely implement v7 anyway.

But I don't see a conclusion on whether it is reasonable to make that
demand for configurations (< v7) where these new features are irrelevant.

I also don't see a clear justification about what version should be
demanded (I only see 2.22 suggested, yet DSB NSH, ISH and friends
actually require only 2.21, if I'm reading the source right).


If such a decision is made globally for all configurations, and if the
chosen version is >= 2.20, then I have no problem with switching to
.inst.  In that case it would make sense to port opcodes.h to use .inst,
or otherwise to port all users of the __inst_*() macros in the kernel to
use .inst directly.

Using .inst conditionally, based on a build-time check would also be
possible -- that's a nice-to-have, which I hadn't attempted for now.
That would at least make those instructions disassemble correctly.


Note that some of the opcodes.h macros do more than .inst does, even
with newer binutils.

Part of the point of the way opcodes.h was written was to encourage
people to think about ARM versus thumb, instead of spraying .long
all over the kernel and watching it break.  .inst may encourage the
same fail, IMHO, unless wrapped by something like the opcodes.h interface
that helps the coder to be explicit about their intentions.

Cheers
---Dave