[GIT PULL] Trivial sh64 updates for 2.6.23-rc1

[GIT PULL] Trivial sh64 updates for 2.6.23-rc1

[Paul Mundt]

Please pull from:

	master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh64-2.6.git

Which contains:

Paul Mundt (5):
      sh64: Wire up fallocate() syscall.
      sh64: Update cayman defconfig.
      sh64: Fix up PCI section mismatch warnings.
      sh64: Move entry point code to .text.head.
      sh64: Flag sh64_get_page() as __init_refok.

 arch/sh64/configs/cayman_defconfig |  158 ++++++++----------------------------
 arch/sh64/kernel/head.S            |    2 +-
 arch/sh64/kernel/pci_sh5.c         |    4 +-
 arch/sh64/kernel/syscalls.S        |    1 +
 arch/sh64/kernel/vmlinux.lds.S     |    1 +
 arch/sh64/mm/ioremap.c             |    2 +-
 include/asm-sh64/unistd.h          |    3 +-
 7 files changed, 41 insertions(+), 130 deletions(-)

Re: [GIT PULL] Trivial sh64 updates for 2.6.23-rc1

[Jan Dittmer]

Paul Mundt wrote:
> Paul Mundt (5):
>       sh64: Wire up fallocate() syscall.
>       sh64: Update cayman defconfig.
>       sh64: Fix up PCI section mismatch warnings.
>       sh64: Move entry point code to .text.head.
>       sh64: Flag sh64_get_page() as __init_refok.

Tangential question. Which is the currently recommended cross toolchain
for sh64? With "gcc 3.2 20020529", "binutils 020306 20030206" (some
binary toolchain from ~2 years ago somewhere off the web) I get [1]

   CC      fs/seq_file.o
   CC      fs/xattr.o
fs/xattr.c: In function `vfs_listxattr':
fs/xattr.c:161: unrecognizable insn:
(insn 162 159 114 (set (subreg:DI (reg:SI 181) 0)
         (reg:DI 182)) -1 (nil)
     (nil))
fs/xattr.c:161: Internal compiler error in get_attr_highpart, at 
insn-attrtab.c:6211
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
make[2]: *** [fs/xattr.o] Error 1
make[1]: *** [fs] Error 2
make: *** [_all] Error 2

gcc 3.4.x, 4.0.x, 4.1.x don't build for me from source
(target -superh-linux-gnu, binutils 2.15.x or 2.17.x).

Thanks,

Jan

[1] http://l4x.org/k/?d=32100

Re: [GIT PULL] Trivial sh64 updates for 2.6.23-rc1

[Paul Mundt]

On Fri, Jul 20, 2007 at 04:07:21PM +0200, Jan Dittmer wrote:
> Paul Mundt wrote:
> >Paul Mundt (5):
> >      sh64: Wire up fallocate() syscall.
> >      sh64: Update cayman defconfig.
> >      sh64: Fix up PCI section mismatch warnings.
> >      sh64: Move entry point code to .text.head.
> >      sh64: Flag sh64_get_page() as __init_refok.
> 
> Tangential question. Which is the currently recommended cross toolchain
> for sh64? With "gcc 3.2 20020529", "binutils 020306 20030206" (some
> binary toolchain from ~2 years ago somewhere off the web) I get [1]
> 
>   CC      fs/seq_file.o
>   CC      fs/xattr.o
> fs/xattr.c: In function `vfs_listxattr':
> fs/xattr.c:161: unrecognizable insn:
> (insn 162 159 114 (set (subreg:DI (reg:SI 181) 0)
>         (reg:DI 182)) -1 (nil)
>     (nil))
> fs/xattr.c:161: Internal compiler error in get_attr_highpart, at 
> insn-attrtab.c:6211
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
> make[2]: *** [fs/xattr.o] Error 1
> make[1]: *** [fs] Error 2
> make: *** [_all] Error 2
> 
> gcc 3.4.x, 4.0.x, 4.1.x don't build for me from source
> (target -superh-linux-gnu, binutils 2.15.x or 2.17.x).

I've been using sh64-linux targetted toolchains created from the gentoo
crossdev, which works fine with stock versions. I can send you a tarball
of the toolchain off-list if you like.

Applications are still in a pretty questionable state with recent
compilers, but the kernel does hold up well enough.

Re: [GIT PULL] Trivial sh64 updates for 2.6.23-rc1

[Jan Dittmer]

Paul Mundt wrote:
> On Fri, Jul 20, 2007 at 04:07:21PM +0200, Jan Dittmer wrote:
>> Paul Mundt wrote:
>> Tangential question. Which is the currently recommended cross toolchain
>> for sh64? With "gcc 3.2 20020529", "binutils 020306 20030206" (some
>> binary toolchain from ~2 years ago somewhere off the web) I get [1]

<error snipped>

>> gcc 3.4.x, 4.0.x, 4.1.x don't build for me from source
>> (target -superh-linux-gnu, binutils 2.15.x or 2.17.x).
> 
> I've been using sh64-linux targetted toolchains created from the gentoo
> crossdev, which works fine with stock versions. I can send you a tarball
> of the toolchain off-list if you like.

Binutils, gcc versions would be fine to. Meanwhile I got binutils
2.17.50.0.17.20070615 and gcc 4.1.3 20070704 (prerelease) to compile
(supplying it with uclibc- and lk-headers). But compiling 2.6.22-git17
now fails with

  CC      drivers/video/cfbimgblt.o
  CC      drivers/video/fb_defio.o
  LD      drivers/video/built-in.o
  LD      drivers/built-in.o
sh64-linux-ld: sh3 architecture of input file `drivers/media/built-in.o'
is incompatible with sh5 output
sh64-linux-ld: sh3 architecture of input file `drivers/i2c/built-in.o'
is incompatible with sh5 output
make[2]: *** [drivers/built-in.o] Error 1
make[1]: *** [drivers] Error 2
make: *** [_all] Error 2

Known?

Thanks,

Jan

Re: [GIT PULL] Trivial sh64 updates for 2.6.23-rc1

[Paul Mundt]

On Sun, Jul 22, 2007 at 01:18:27PM +0200, Jan Dittmer wrote:
> Paul Mundt wrote:
> > On Fri, Jul 20, 2007 at 04:07:21PM +0200, Jan Dittmer wrote:
> >> Paul Mundt wrote:
> >> Tangential question. Which is the currently recommended cross toolchain
> >> for sh64? With "gcc 3.2 20020529", "binutils 020306 20030206" (some
> >> binary toolchain from ~2 years ago somewhere off the web) I get [1]
> 
> <error snipped>
> 
> >> gcc 3.4.x, 4.0.x, 4.1.x don't build for me from source
> >> (target -superh-linux-gnu, binutils 2.15.x or 2.17.x).
> > 
> > I've been using sh64-linux targetted toolchains created from the gentoo
> > crossdev, which works fine with stock versions. I can send you a tarball
> > of the toolchain off-list if you like.
> 
> Binutils, gcc versions would be fine to. Meanwhile I got binutils
> 2.17.50.0.17.20070615 and gcc 4.1.3 20070704 (prerelease) to compile
> (supplying it with uclibc- and lk-headers). But compiling 2.6.22-git17
> now fails with
> 
>   CC      drivers/video/cfbimgblt.o
>   CC      drivers/video/fb_defio.o
>   LD      drivers/video/built-in.o
>   LD      drivers/built-in.o
> sh64-linux-ld: sh3 architecture of input file `drivers/media/built-in.o'
> is incompatible with sh5 output
> sh64-linux-ld: sh3 architecture of input file `drivers/i2c/built-in.o'
> is incompatible with sh5 output
> make[2]: *** [drivers/built-in.o] Error 1
> make[1]: *** [drivers] Error 2
> make: *** [_all] Error 2
> 
> Known?
> 
It's known that empty objects require explicit tuning for the ABI,
however, this has never been anything that was fatal. If you flip
something on within each of those subsystems, does the error go away?

Re: [GIT PULL] Trivial sh64 updates for 2.6.23-rc1

[Jan Dittmer]

Paul Mundt wrote:
> On Sun, Jul 22, 2007 at 01:18:27PM +0200, Jan Dittmer wrote:
>> Paul Mundt wrote:
>>> On Fri, Jul 20, 2007 at 04:07:21PM +0200, Jan Dittmer wrote:
>>>> Paul Mundt wrote:
>>>> Tangential question. Which is the currently recommended cross toolchain
>>>> for sh64? With "gcc 3.2 20020529", "binutils 020306 20030206" (some
>>>> binary toolchain from ~2 years ago somewhere off the web) I get [1]
>> <error snipped>
>>
>>>> gcc 3.4.x, 4.0.x, 4.1.x don't build for me from source
>>>> (target -superh-linux-gnu, binutils 2.15.x or 2.17.x).
>>> I've been using sh64-linux targetted toolchains created from the gentoo
>>> crossdev, which works fine with stock versions. I can send you a tarball
>>> of the toolchain off-list if you like.
>> Binutils, gcc versions would be fine to. Meanwhile I got binutils
>> 2.17.50.0.17.20070615 and gcc 4.1.3 20070704 (prerelease) to compile
>> (supplying it with uclibc- and lk-headers). But compiling 2.6.22-git17
>> now fails with
>>
>>   CC      drivers/video/cfbimgblt.o
>>   CC      drivers/video/fb_defio.o
>>   LD      drivers/video/built-in.o
>>   LD      drivers/built-in.o
>> sh64-linux-ld: sh3 architecture of input file `drivers/media/built-in.o'
>> is incompatible with sh5 output
>> sh64-linux-ld: sh3 architecture of input file `drivers/i2c/built-in.o'
>> is incompatible with sh5 output
>> make[2]: *** [drivers/built-in.o] Error 1
>> make[1]: *** [drivers] Error 2
>> make: *** [_all] Error 2
>>
>> Known?
>>
> It's known that empty objects require explicit tuning for the ABI,
> however, this has never been anything that was fatal. If you flip
> something on within each of those subsystems, does the error go away?

Yes, thanks this fixes it. Would you accept a patch to modify the
defconfig so that it builds by default? Would be most useful for
my pet project (http://l4x.org/k/). A fixed toolchain would of course
also be nice.

Thanks,

Jan

Re: [GIT PULL] Trivial sh64 updates for 2.6.23-rc1

[Paul Mundt]

On Sun, Jul 22, 2007 at 06:39:08PM +0200, Jan Dittmer wrote:
> Paul Mundt wrote:
> > On Sun, Jul 22, 2007 at 01:18:27PM +0200, Jan Dittmer wrote:
> >> 2.17.50.0.17.20070615 and gcc 4.1.3 20070704 (prerelease) to compile
> >> (supplying it with uclibc- and lk-headers). But compiling 2.6.22-git17
> >> now fails with
> >>
> >>   CC      drivers/video/cfbimgblt.o
> >>   CC      drivers/video/fb_defio.o
> >>   LD      drivers/video/built-in.o
> >>   LD      drivers/built-in.o
> >> sh64-linux-ld: sh3 architecture of input file `drivers/media/built-in.o'
> >> is incompatible with sh5 output
> >> sh64-linux-ld: sh3 architecture of input file `drivers/i2c/built-in.o'
> >> is incompatible with sh5 output
> >> make[2]: *** [drivers/built-in.o] Error 1
> >> make[1]: *** [drivers] Error 2
> >> make: *** [_all] Error 2
> >>
> >> Known?
> >>
> > It's known that empty objects require explicit tuning for the ABI,
> > however, this has never been anything that was fatal. If you flip
> > something on within each of those subsystems, does the error go away?
> 
> Yes, thanks this fixes it. Would you accept a patch to modify the
> defconfig so that it builds by default? Would be most useful for
> my pet project (http://l4x.org/k/). A fixed toolchain would of course
> also be nice.
> 
I'll certainly apply patches that help getting it building, so feel free
to send updates for that. As I also noted, the empty object thing is
non-fatal with my toolchain, so I'd also appreciate it if you could put
a tarball of yours up somewhere so this is a bit easier to verify. I
suspect this is just something we're going to have to change in binutils,
however.

Re: [GIT PULL] Trivial sh64 updates for 2.6.23-rc1

[Jan Dittmer]

Paul Mundt wrote:
> On Sun, Jul 22, 2007 at 06:39:08PM +0200, Jan Dittmer wrote:
>> Paul Mundt wrote:
>>> It's known that empty objects require explicit tuning for the ABI,
>>> however, this has never been anything that was fatal. If you flip
>>> something on within each of those subsystems, does the error go away?
>> Yes, thanks this fixes it. Would you accept a patch to modify the
>> defconfig so that it builds by default? Would be most useful for
>> my pet project (http://l4x.org/k/). A fixed toolchain would of course
>> also be nice.
>>
> I'll certainly apply patches that help getting it building, so feel free
> to send updates for that. As I also noted, the empty object thing is
> non-fatal with my toolchain, so I'd also appreciate it if you could put
> a tarball of yours up somewhere so this is a bit easier to verify. I
> suspect this is just something we're going to have to change in binutils,
> however.

You can find it here:

http://l4x.org/~jdittmer/sh64-linux-binutils-2.17-gcc-4.1.3pre.tar.bz2

binutils 2.17.50.0.17 (from ftp.kernel.org)
gcc 4.1.3 prerelease (svn, fixes a build bug for sh64)

Jan