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

[permalink] [raw]

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

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@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 <[email protected]>
> Date: Thu May 23 18:43:58 2013 +0100

And

commit 6af396a6b6c698eb3834184518fc9a59bc22c817
Author: Will Deacon <[email protected]>
Date: Wed Jun 12 10:03:30 2013 +0100

and

commit 73a6fdc48bf52e93c26874dc8c0f0f8d5585a809
Author: Will Deacon <[email protected]>
Date: Mon May 13 11:39:50 2013 +0100

and

commit 6abdd491698a27f7df04a32ca12cc453810e4396
Author: Will Deacon <[email protected]>
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 <[email protected]>
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

2013-09-19 09:57:16

[permalink] [raw]

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

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

2013-09-19 18:47:14

by Aaro Koskinen

[permalink] [raw]

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

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.

2013-09-23 23:59:25

[permalink] [raw]

Subject: new binutils needed for arm in 3.12-rc1

During 3.12-rc, Will Deacon introduced code into arch/arm that
requires binutils 2.22.

Signed-off-by: Pavel Machek <[email protected]>

---

Or that changes should be reverted. I have updated my buildsystem on main
machine, but ... it seems that debian-cross repository does not
contain new enough bintuils for kernel now. We are talking

62cbbc42e0019aff6310259f275ae812463f8836
6af396a6b6c698eb3834184518fc9a59bc22c817
73a6fdc48bf52e93c26874dc8c0f0f8d5585a809
6abdd491698a27f7df04a32ca12cc453810e4396

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
o util-linux 2.10o # fdformat --version
o module-init-tools 0.9.10 # depmod -V
o e2fsprogs 1.41.4 # e2fsck -V

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

2013-09-24 02:13:26

[permalink] [raw]

Subject: Re: new binutils needed for arm in 3.12-rc1

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-

2013-09-24 02:20:51

[permalink] [raw]

Subject: Re: new binutils needed for arm in 3.12-rc1

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-

2013-09-24 12:11:45

[permalink] [raw]

Subject: Re: new binutils needed for arm in 3.12-rc1

Rob Landley <[email protected]> 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
[email protected]

2013-09-24 21:23:53

[permalink] [raw]

Subject: Re: new binutils needed for arm in 3.12-rc1

On 09/24/2013 07:11:38 AM, M?ns Rullg?rd wrote:
> Rob Landley <[email protected]> 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.-

2013-09-24 21:48:28

by Russell King - ARM Linux

[permalink] [raw]

Subject: Re: new binutils needed for arm in 3.12-rc1

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.

2013-09-25 01:13:34

[permalink] [raw]

Subject: Re: new binutils needed for arm in 3.12-rc1

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-

2013-09-25 02:08:00

by Nicolas Pitre

[permalink] [raw]

Subject: Re: new binutils needed for arm in 3.12-rc1

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

2013-09-25 15:23:11

[permalink] [raw]

Subject: Re: new binutils needed for arm in 3.12-rc1

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-

2013-09-25 15:52:50

[permalink] [raw]

Subject: Re: new binutils needed for arm in 3.12-rc1

Rob Landley <[email protected]> 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
[email protected]

2013-09-25 16:13:49

by Nicolas Pitre

[permalink] [raw]

Subject: Re: new binutils needed for arm in 3.12-rc1

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

2013-09-25 20:45:09

by Russell King - ARM Linux

[permalink] [raw]

Subject: Re: new binutils needed for arm in 3.12-rc1

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

2013-09-25 20:49:13

[permalink] [raw]

Subject: Re: new binutils needed for arm in 3.12-rc1

Russell King - ARM Linux <[email protected]> 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
[email protected]

2013-09-26 00:23:52

[permalink] [raw]

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

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 <[email protected]>

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

2013-09-26 07:18:13

by Geert Uytterhoeven

[permalink] [raw]

Subject: Re: new binutils needed for arm in 3.12-rc1

Hi Rob,

On Wed, Sep 25, 2013 at 3:13 AM, Rob Landley <[email protected]> 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 -- [email protected]

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

2013-09-26 22:06:36

[permalink] [raw]

Subject: Re: new binutils needed for arm in 3.12-rc1

On 09/25/2013 10:52:44 AM, M?ns Rullg?rd wrote:
> Rob Landley <[email protected]> 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-

2013-09-26 22:24:15

[permalink] [raw]

Subject: Re: new binutils needed for arm in 3.12-rc1

Rob Landley <[email protected]> writes:

> On 09/25/2013 10:52:44 AM, M?ns Rullg?rd wrote:
>> Rob Landley <[email protected]> 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
[email protected]

2013-09-26 22:48:34

[permalink] [raw]

Subject: Re: new binutils needed for arm in 3.12-rc1

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

2013-09-26 22:50:23

[permalink] [raw]

Subject: Re: new binutils needed for arm in 3.12-rc1

On 09/25/2013 03:49:07 PM, M?ns Rullg?rd wrote:
> Russell King - ARM Linux <[email protected]> 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-

2013-09-27 19:41:36

[permalink] [raw]

Subject: Re: new binutils needed for arm in 3.12-rc1

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

2013-09-28 08:43:32