Re: new binutils needed for arm in 3.12-rc1
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new binutils needed for arm in 3.12-rc1
On Thu, Sep 26, 2013 at 9:18 AM, Geert Uytterhoeven ge...@linux-m68k.org wrote: Hi Rob, On Wed, Sep 25, 2013 at 3:13 AM, Rob Landley r...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new binutils needed for arm in 3.12-rc1
Hi Rob,
On Wed, Sep 25, 2013 at 3:13 AM, Rob Landley r...@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 -- ge...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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 r...@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-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new binutils needed for arm in 3.12-rc1
Rob Landley r...@landley.net writes: On 09/25/2013 10:52:44 AM, Måns Rullgård wrote: Rob Landley r...@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 m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 li...@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-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new binutils needed for arm in 3.12-rc1
Rob Landley r...@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 m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
|
|DSBc 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 == ''.
|
|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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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.) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new binutils needed for arm in 3.12-rc1
Russell King - ARM Linux li...@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 m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new binutils needed for arm in 3.12-rc1
Rob Landley r...@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 m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 r...@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.-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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: HH! KILL IT WITH FIRE!!! Rob-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
