bogl: don't know screen type 1

bogl: don't know screen type 1

[mike]

Hi,

Decided to reinstall linux, but this error haunts me.
Adding nolangchooser didnt help.

My boot file looks like this
amiboot -d -m mfile -k vmlinuz-2.4.27-amiga -r initrd.gz root=/dev/ram
video=amifb:pal-lace

Tried pretty much everything, it seems to die around the kbd chooser,
so i added bootkbd=querty/us.
This resulted in a segmentation fault before the bogl'ing started. By
the life of my i cant remember what i did last time.... But im pretty
sure i didnt add nolangchooser.

-Mike

Re: bogl: don't know screen type 1

[Stephen R Marenka]

On Mon, Aug 31, 2009 at 05:28:50AM +0200, mike wrote:
> Hi,
> 
> Decided to reinstall linux, but this error haunts me.
> Adding nolangchooser didnt help.
> 
> My boot file looks like this
> amiboot -d -m mfile -k vmlinuz-2.4.27-amiga -r initrd.gz root=/dev/ram
> video=amifb:pal-lace
> 
> Tried pretty much everything, it seems to die around the kbd chooser,
> so i added bootkbd=querty/us.
> This resulted in a segmentation fault before the bogl'ing started. By
> the life of my i cant remember what i did last time.... But im pretty
> sure i didnt add nolangchooser.

I believe you want to add the parameter fb=false to your kernel 
parameters. bogl is a graphics library that assumes kernel support 
that amiga doesn't have. fb=false tells d-i to not go there.

2.4.27 hasn't been tested with d-i in quite some time, at least not by me.

Peace,

Stephen

-- 
Stephen R. Marenka     If life's not fun, you're not doing it right!
<stephen@marenka.net>

Re: bogl: don't know screen type 1

[mike]

Hi,

Tested that to, its just a modified StartInstall file. i believe i
adjusted the fb= last time around, but to what i dont know. it does
work with 2.6, however i cant find any 1. cd isos i can download apart
from 3.1r8. Last time i installed from a iso image on the hard drive,
i even tracked down the loop.ko from my previous installation. (i
think and hope)

Thanks.

-Mike

2009/8/31 Stephen R Marenka <stephen@marenka.net>:
> On Mon, Aug 31, 2009 at 05:28:50AM +0200, mike wrote:
>> Hi,
>>
>> Decided to reinstall linux, but this error haunts me.
>> Adding nolangchooser didnt help.
>>
>> My boot file looks like this
>> amiboot -d -m mfile -k vmlinuz-2.4.27-amiga -r initrd.gz root=/dev/ram
>> video=amifb:pal-lace
>>
>> Tried pretty much everything, it seems to die around the kbd chooser,
>> so i added bootkbd=querty/us.
>> This resulted in a segmentation fault before the bogl'ing started. By
>> the life of my i cant remember what i did last time.... But im pretty
>> sure i didnt add nolangchooser.
>
> I believe you want to add the parameter fb=false to your kernel
> parameters. bogl is a graphics library that assumes kernel support
> that amiga doesn't have. fb=false tells d-i to not go there.
>
> 2.4.27 hasn't been tested with d-i in quite some time, at least not by me.
>
> Peace,
>
> Stephen
>
> --
> Stephen R. Marenka     If life's not fun, you're not doing it right!
> <stephen@marenka.net>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bogl: don't know screen type 1

[mike]

debian-installer/framebuffer=false
; Stephen R. Marenka, 16 Aug 2004
; nolangchooser replaced with debian-installer/framebuffer=false

amiboot-5.6 -d -k //kernels/vmlinuz-2.4.27-amiga -r //cdrom/initrd.gz
root=/dev/ram ramdisk_size=15000 debian-installer/framebuffer=false

Thanks Stephen :D


2009/8/31 mike <localgost@gmail.com>:
> Hi,
>
> Tested that to, its just a modified StartInstall file. i believe i
> adjusted the fb= last time around, but to what i dont know. it does
> work with 2.6, however i cant find any 1. cd isos i can download apart
> from 3.1r8. Last time i installed from a iso image on the hard drive,
> i even tracked down the loop.ko from my previous installation. (i
> think and hope)
>
> Thanks.
>
> -Mike
>
> 2009/8/31 Stephen R Marenka <stephen@marenka.net>:
>> On Mon, Aug 31, 2009 at 05:28:50AM +0200, mike wrote:
>>> Hi,
>>>
>>> Decided to reinstall linux, but this error haunts me.
>>> Adding nolangchooser didnt help.
>>>
>>> My boot file looks like this
>>> amiboot -d -m mfile -k vmlinuz-2.4.27-amiga -r initrd.gz root=/dev/ram
>>> video=amifb:pal-lace
>>>
>>> Tried pretty much everything, it seems to die around the kbd chooser,
>>> so i added bootkbd=querty/us.
>>> This resulted in a segmentation fault before the bogl'ing started. By
>>> the life of my i cant remember what i did last time.... But im pretty
>>> sure i didnt add nolangchooser.
>>
>> I believe you want to add the parameter fb=false to your kernel
>> parameters. bogl is a graphics library that assumes kernel support
>> that amiga doesn't have. fb=false tells d-i to not go there.
>>
>> 2.4.27 hasn't been tested with d-i in quite some time, at least not by me.
>>
>> Peace,
>>
>> Stephen
>>
>> --
>> Stephen R. Marenka     If life's not fun, you're not doing it right!
>> <stephen@marenka.net>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bogl: don't know screen type 1

[mike]

Btw, i noticed an error
http://people.debian.org/~smarenka/d-i/m68k/images/daily/build_nativehd.log
E: Couldn't find package libnss-dns-udeb
make[2]: *** [stamps/get_udebs-nativehd-stamp] Error 100
make[1]: *** [_build] Error 2
make: *** [build_nativehd] Error 2


2009/9/1 mike <localgost@gmail.com>:
> debian-installer/framebuffer=false
> ; Stephen R. Marenka, 16 Aug 2004
> ; nolangchooser replaced with debian-installer/framebuffer=false
>
> amiboot-5.6 -d -k //kernels/vmlinuz-2.4.27-amiga -r //cdrom/initrd.gz
> root=/dev/ram ramdisk_size=15000 debian-installer/framebuffer=false
>
> Thanks Stephen :D
>
>
> 2009/8/31 mike <localgost@gmail.com>:
>> Hi,
>>
>> Tested that to, its just a modified StartInstall file. i believe i
>> adjusted the fb= last time around, but to what i dont know. it does
>> work with 2.6, however i cant find any 1. cd isos i can download apart
>> from 3.1r8. Last time i installed from a iso image on the hard drive,
>> i even tracked down the loop.ko from my previous installation. (i
>> think and hope)
>>
>> Thanks.
>>
>> -Mike
>>
>> 2009/8/31 Stephen R Marenka <stephen@marenka.net>:
>>> On Mon, Aug 31, 2009 at 05:28:50AM +0200, mike wrote:
>>>> Hi,
>>>>
>>>> Decided to reinstall linux, but this error haunts me.
>>>> Adding nolangchooser didnt help.
>>>>
>>>> My boot file looks like this
>>>> amiboot -d -m mfile -k vmlinuz-2.4.27-amiga -r initrd.gz root=/dev/ram
>>>> video=amifb:pal-lace
>>>>
>>>> Tried pretty much everything, it seems to die around the kbd chooser,
>>>> so i added bootkbd=querty/us.
>>>> This resulted in a segmentation fault before the bogl'ing started. By
>>>> the life of my i cant remember what i did last time.... But im pretty
>>>> sure i didnt add nolangchooser.
>>>
>>> I believe you want to add the parameter fb=false to your kernel
>>> parameters. bogl is a graphics library that assumes kernel support
>>> that amiga doesn't have. fb=false tells d-i to not go there.
>>>
>>> 2.4.27 hasn't been tested with d-i in quite some time, at least not by me.
>>>
>>> Peace,
>>>
>>> Stephen
>>>
>>> --
>>> Stephen R. Marenka     If life's not fun, you're not doing it right!
>>> <stephen@marenka.net>
>>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bogl: don't know screen type 1

[Stephen R Marenka]

On Tue, Sep 01, 2009 at 12:16:27AM +0200, mike wrote:
> Btw, i noticed an error
> http://people.debian.org/~smarenka/d-i/m68k/images/daily/build_nativehd.log
> E: Couldn't find package libnss-dns-udeb
> make[2]: *** [stamps/get_udebs-nativehd-stamp] Error 100
> make[1]: *** [_build] Error 2
> make: *** [build_nativehd] Error 2

Yep. debian-installer dailies are now *dead* until we get a modern libc
working.

> 2009/9/1 mike <localgost@gmail.com>:
> > debian-installer/framebuffer=false
> > ; Stephen R. Marenka, 16 Aug 2004
> > ; nolangchooser replaced with debian-installer/framebuffer=false
> >
> > amiboot-5.6 -d -k //kernels/vmlinuz-2.4.27-amiga -r //cdrom/initrd.gz
> > root=/dev/ram ramdisk_size=15000 debian-installer/framebuffer=false
> >
> > Thanks Stephen :D
> >
> >
> > 2009/8/31 mike <localgost@gmail.com>:
> >> Hi,
> >>
> >> Tested that to, its just a modified StartInstall file. i believe i
> >> adjusted the fb= last time around, but to what i dont know. it does
> >> work with 2.6, however i cant find any 1. cd isos i can download apart
> >> from 3.1r8. Last time i installed from a iso image on the hard drive,
> >> i even tracked down the loop.ko from my previous installation. (i
> >> think and hope)
> >>
> >> Thanks.
> >>
> >> -Mike
> >>
> >> 2009/8/31 Stephen R Marenka <stephen@marenka.net>:
> >>> On Mon, Aug 31, 2009 at 05:28:50AM +0200, mike wrote:
> >>>> Hi,
> >>>>
> >>>> Decided to reinstall linux, but this error haunts me.
> >>>> Adding nolangchooser didnt help.
> >>>>
> >>>> My boot file looks like this
> >>>> amiboot -d -m mfile -k vmlinuz-2.4.27-amiga -r initrd.gz root=/dev/ram
> >>>> video=amifb:pal-lace
> >>>>
> >>>> Tried pretty much everything, it seems to die around the kbd chooser,
> >>>> so i added bootkbd=querty/us.
> >>>> This resulted in a segmentation fault before the bogl'ing started. By
> >>>> the life of my i cant remember what i did last time.... But im pretty
> >>>> sure i didnt add nolangchooser.
> >>>
> >>> I believe you want to add the parameter fb=false to your kernel
> >>> parameters. bogl is a graphics library that assumes kernel support
> >>> that amiga doesn't have. fb=false tells d-i to not go there.
> >>>
> >>> 2.4.27 hasn't been tested with d-i in quite some time, at least not by me.
> >>>
> >>> Peace,
> >>>
> >>> Stephen
> >>>
> >>> --
> >>> Stephen R. Marenka     If life's not fun, you're not doing it right!
> >>> <stephen@marenka.net>
> >>>
> >>
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Stephen R. Marenka     If life's not fun, you're not doing it right!
<stephen@marenka.net>
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bogl: don't know screen type 1

[mike]

> Yep. debian-installer dailies are now *dead* until we get a modern libc
> working.
Ugh... and im still having trouble getting installed, it cant read SFS
or FFS, it loads no modules, and complaied when i tried to modprobe.
and cant mount partitionts, i wonder if its due to the changes of
sector number( i believe ) the 3.9 hdtoolbox did, worked under 3.1
when it detected them but that detected twice the number 3.9 did, and
3.9's way is stable, as far as it was... i ended up typing in the rdb
manually a bunch of times before...

But i've formatted a partition as innocently as i can on amigaos,
havent tested that yet, but it did bloody read all of them before....
And i cant make the installer do tcp/ip over serial (slip) without
attacking it. ( thats basically the next step tho, build the initrd
from hell and work from there )

2009/9/1 Stephen R Marenka <stephen@marenka.net>:
> On Tue, Sep 01, 2009 at 12:16:27AM +0200, mike wrote:
>> Btw, i noticed an error
>> http://people.debian.org/~smarenka/d-i/m68k/images/daily/build_nativehd.log
>> E: Couldn't find package libnss-dns-udeb
>> make[2]: *** [stamps/get_udebs-nativehd-stamp] Error 100
>> make[1]: *** [_build] Error 2
>> make: *** [build_nativehd] Error 2
>
> Yep. debian-installer dailies are now *dead* until we get a modern libc
> working.
>
>> 2009/9/1 mike <localgost@gmail.com>:
>> > debian-installer/framebuffer=false
>> > ; Stephen R. Marenka, 16 Aug 2004
>> > ; nolangchooser replaced with debian-installer/framebuffer=false
>> >
>> > amiboot-5.6 -d -k //kernels/vmlinuz-2.4.27-amiga -r //cdrom/initrd.gz
>> > root=/dev/ram ramdisk_size=15000 debian-installer/framebuffer=false
>> >
>> > Thanks Stephen :D
>> >
>> >
>> > 2009/8/31 mike <localgost@gmail.com>:
>> >> Hi,
>> >>
>> >> Tested that to, its just a modified StartInstall file. i believe i
>> >> adjusted the fb= last time around, but to what i dont know. it does
>> >> work with 2.6, however i cant find any 1. cd isos i can download apart
>> >> from 3.1r8. Last time i installed from a iso image on the hard drive,
>> >> i even tracked down the loop.ko from my previous installation. (i
>> >> think and hope)
>> >>
>> >> Thanks.
>> >>
>> >> -Mike
>> >>
>> >> 2009/8/31 Stephen R Marenka <stephen@marenka.net>:
>> >>> On Mon, Aug 31, 2009 at 05:28:50AM +0200, mike wrote:
>> >>>> Hi,
>> >>>>
>> >>>> Decided to reinstall linux, but this error haunts me.
>> >>>> Adding nolangchooser didnt help.
>> >>>>
>> >>>> My boot file looks like this
>> >>>> amiboot -d -m mfile -k vmlinuz-2.4.27-amiga -r initrd.gz root=/dev/ram
>> >>>> video=amifb:pal-lace
>> >>>>
>> >>>> Tried pretty much everything, it seems to die around the kbd chooser,
>> >>>> so i added bootkbd=querty/us.
>> >>>> This resulted in a segmentation fault before the bogl'ing started. By
>> >>>> the life of my i cant remember what i did last time.... But im pretty
>> >>>> sure i didnt add nolangchooser.
>> >>>
>> >>> I believe you want to add the parameter fb=false to your kernel
>> >>> parameters. bogl is a graphics library that assumes kernel support
>> >>> that amiga doesn't have. fb=false tells d-i to not go there.
>> >>>
>> >>> 2.4.27 hasn't been tested with d-i in quite some time, at least not by me.
>> >>>
>> >>> Peace,
>> >>>
>> >>> Stephen
>> >>>
>> >>> --
>> >>> Stephen R. Marenka     If life's not fun, you're not doing it right!
>> >>> <stephen@marenka.net>
>> >>>
>> >>
>> >
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> --
> Stephen R. Marenka     If life's not fun, you're not doing it right!
> <stephen@marenka.net>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bogl: don't know screen type 1

[mike]

I tried to boot 2.6.29 or whatever... It was so slow compared to 2.4 i
donno what to say, except its crap. Not a surprise if gcc produces
crappier and crappier 68k binaries anyway. Why the hell isnt freescale
on top of this? Fuck damn they should be on top of this and the
68050/70 the natami is trying out, and bloody include talent like Carl
S and Dave H that know what the heck the 68k, electronics, and the
amiga is about....

2009/9/3 mike <localgost@gmail.com>:
>> Yep. debian-installer dailies are now *dead* until we get a modern libc
>> working.
> Ugh... and im still having trouble getting installed, it cant read SFS
> or FFS, it loads no modules, and complaied when i tried to modprobe.
> and cant mount partitionts, i wonder if its due to the changes of
> sector number( i believe ) the 3.9 hdtoolbox did, worked under 3.1
> when it detected them but that detected twice the number 3.9 did, and
> 3.9's way is stable, as far as it was... i ended up typing in the rdb
> manually a bunch of times before...
>
> But i've formatted a partition as innocently as i can on amigaos,
> havent tested that yet, but it did bloody read all of them before....
> And i cant make the installer do tcp/ip over serial (slip) without
> attacking it. ( thats basically the next step tho, build the initrd
> from hell and work from there )
>
> 2009/9/1 Stephen R Marenka <stephen@marenka.net>:
>> On Tue, Sep 01, 2009 at 12:16:27AM +0200, mike wrote:
>>> Btw, i noticed an error
>>> http://people.debian.org/~smarenka/d-i/m68k/images/daily/build_nativehd.log
>>> E: Couldn't find package libnss-dns-udeb
>>> make[2]: *** [stamps/get_udebs-nativehd-stamp] Error 100
>>> make[1]: *** [_build] Error 2
>>> make: *** [build_nativehd] Error 2
>>
>> Yep. debian-installer dailies are now *dead* until we get a modern libc
>> working.
>>
>>> 2009/9/1 mike <localgost@gmail.com>:
>>> > debian-installer/framebuffer=false
>>> > ; Stephen R. Marenka, 16 Aug 2004
>>> > ; nolangchooser replaced with debian-installer/framebuffer=false
>>> >
>>> > amiboot-5.6 -d -k //kernels/vmlinuz-2.4.27-amiga -r //cdrom/initrd.gz
>>> > root=/dev/ram ramdisk_size=15000 debian-installer/framebuffer=false
>>> >
>>> > Thanks Stephen :D
>>> >
>>> >
>>> > 2009/8/31 mike <localgost@gmail.com>:
>>> >> Hi,
>>> >>
>>> >> Tested that to, its just a modified StartInstall file. i believe i
>>> >> adjusted the fb= last time around, but to what i dont know. it does
>>> >> work with 2.6, however i cant find any 1. cd isos i can download apart
>>> >> from 3.1r8. Last time i installed from a iso image on the hard drive,
>>> >> i even tracked down the loop.ko from my previous installation. (i
>>> >> think and hope)
>>> >>
>>> >> Thanks.
>>> >>
>>> >> -Mike
>>> >>
>>> >> 2009/8/31 Stephen R Marenka <stephen@marenka.net>:
>>> >>> On Mon, Aug 31, 2009 at 05:28:50AM +0200, mike wrote:
>>> >>>> Hi,
>>> >>>>
>>> >>>> Decided to reinstall linux, but this error haunts me.
>>> >>>> Adding nolangchooser didnt help.
>>> >>>>
>>> >>>> My boot file looks like this
>>> >>>> amiboot -d -m mfile -k vmlinuz-2.4.27-amiga -r initrd.gz root=/dev/ram
>>> >>>> video=amifb:pal-lace
>>> >>>>
>>> >>>> Tried pretty much everything, it seems to die around the kbd chooser,
>>> >>>> so i added bootkbd=querty/us.
>>> >>>> This resulted in a segmentation fault before the bogl'ing started. By
>>> >>>> the life of my i cant remember what i did last time.... But im pretty
>>> >>>> sure i didnt add nolangchooser.
>>> >>>
>>> >>> I believe you want to add the parameter fb=false to your kernel
>>> >>> parameters. bogl is a graphics library that assumes kernel support
>>> >>> that amiga doesn't have. fb=false tells d-i to not go there.
>>> >>>
>>> >>> 2.4.27 hasn't been tested with d-i in quite some time, at least not by me.
>>> >>>
>>> >>> Peace,
>>> >>>
>>> >>> Stephen
>>> >>>
>>> >>> --
>>> >>> Stephen R. Marenka     If life's not fun, you're not doing it right!
>>> >>> <stephen@marenka.net>
>>> >>>
>>> >>
>>> >
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>> --
>> Stephen R. Marenka     If life's not fun, you're not doing it right!
>> <stephen@marenka.net>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bogl: don't know screen type 1

[Maxim Kuvyrkov]

mike wrote:
> I tried to boot 2.6.29 or whatever... It was so slow compared to 2.4 i
> donno what to say, except its crap. Not a surprise if gcc produces
> crappier and crappier 68k binaries anyway.

Would you mind submitting a bug report or two with preprocessed 
testcases showing examples of bad code generation on m68k, especially if 
the code has regressed since some previous version of GCC?

Please CC me on the bug reports.

Thanks,

--
Maxim K.
CodeSourcery

Re: bogl: don't know screen type 1

[mike]

 Maxim K.
Its this one, i havent tried building myslef since 2.6.28. but i dont
think that was this slow
http://people.debian.org/~smarenka/d-i/m68k/images/20090813-01:13/kernels/
http://aminet.net/search?query=2.6.28

Im still having trouble installing, the installer just cant seem to
read the fs, even formatted a partition to ffs, which should work, and
i have no /lib/modules/asfs etc. Could it be a problem with the way
3.9 has handled the harddrive?

-Mike
2009/9/3 Maxim Kuvyrkov <maxim@codesourcery.com>:
> mike wrote:
>>
>> I tried to boot 2.6.29 or whatever... It was so slow compared to 2.4 i
>> donno what to say, except its crap. Not a surprise if gcc produces
>> crappier and crappier 68k binaries anyway.
>
> Would you mind submitting a bug report or two with preprocessed testcases
> showing examples of bad code generation on m68k, especially if the code has
> regressed since some previous version of GCC?
>
> Please CC me on the bug reports.
>
> Thanks,
>
> --
> Maxim K.
> CodeSourcery
>

toolchain, was Re: bogl: don't know screen type 1

[Finn Thain]

On Tue, 1 Sep 2009, Stephen R Marenka wrote:

> On Tue, Sep 01, 2009 at 12:16:27AM +0200, mike wrote:
> > Btw, i noticed an error
> > http://people.debian.org/~smarenka/d-i/m68k/images/daily/build_nativehd.log
> > E: Couldn't find package libnss-dns-udeb
> > make[2]: *** [stamps/get_udebs-nativehd-stamp] Error 100
> > make[1]: *** [_build] Error 2
> > make: *** [build_nativehd] Error 2
> 
> Yep. debian-installer dailies are now *dead* until we get a modern libc
> working.

I wonder whether there are debian source packages for binutils, gcc and 
glibc having TLS/NPTL support for m68k.

The patches posted to the binutils mailing list are incomplete. The 
binutils patch at
http://people.debian.org/~smarenka/m68k/tls/
is broken according to Kolla:
http://lists.debian.org/debian-68k/2009/07/msg00001.html

But in that post (June 28) Maxim recommends using mainline binutils, and 
since then we have HJL binutils-2.19.51.0.14 released, "...based on 
binutils 2009 0722 in CVS on sourceware.org..." So I guess I should start 
there.

I understand that the current GCC (4.4) lacks the necessary patches, and 
4.5 is still uncooked (and that's a scary prospect). Can someone confirm 
that this is the necessary patch for 4.4:
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01024.html
Presumably not this one?
http://people.debian.org/~smarenka/m68k/tls/gcc_patch2
(and gcc_patch1 is clearly broken... perhaps it was actually the same 
thing before being mangled... Stephen, I don't think this "/tls" directory 
is helping any.)
Or perhaps there is a known-good gcc 4.5 snapshot (FWIW, I'd much rather 
patch a debian compiler instead, which means 4.4 or preferably older.)

As for eglibc, there are a number of branches listed here, 
http://www.eglibc.org/repository
The question is, which branch, snapshot or release might meet be suitable?

With this information, I could attempt to build a toolchain from upstream 
sources, or figure out whether or not the debian archive has the necessary 
source packages...

Finn

Re: toolchain, was Re: bogl: don't know screen type 1

[Stephen R Marenka]

On Sat, Sep 05, 2009 at 01:43:14AM +1000, Finn Thain wrote:
> 
> On Tue, 1 Sep 2009, Stephen R Marenka wrote:
> 
> > On Tue, Sep 01, 2009 at 12:16:27AM +0200, mike wrote:
> > > Btw, i noticed an error
> > > http://people.debian.org/~smarenka/d-i/m68k/images/daily/build_nativehd.log
> > > E: Couldn't find package libnss-dns-udeb
> > > make[2]: *** [stamps/get_udebs-nativehd-stamp] Error 100
> > > make[1]: *** [_build] Error 2
> > > make: *** [build_nativehd] Error 2
> > 
> > Yep. debian-installer dailies are now *dead* until we get a modern libc
> > working.
> 
> I wonder whether there are debian source packages for binutils, gcc and 
> glibc having TLS/NPTL support for m68k.

I'd be surprised if that were the case.

> The patches posted to the binutils mailing list are incomplete. The 
> binutils patch at
> http://people.debian.org/~smarenka/m68k/tls/
> is broken according to Kolla:
> http://lists.debian.org/debian-68k/2009/07/msg00001.html
> 
> But in that post (June 28) Maxim recommends using mainline binutils, and 
> since then we have HJL binutils-2.19.51.0.14 released, "...based on 
> binutils 2009 0722 in CVS on sourceware.org..." So I guess I should start 
> there.
> 
> I understand that the current GCC (4.4) lacks the necessary patches, and 
> 4.5 is still uncooked (and that's a scary prospect). Can someone confirm 
> that this is the necessary patch for 4.4:
> http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01024.html
> Presumably not this one?
> http://people.debian.org/~smarenka/m68k/tls/gcc_patch2
> (and gcc_patch1 is clearly broken... perhaps it was actually the same 
> thing before being mangled... Stephen, I don't think this "/tls" directory 
> is helping any.)

Shall I remove it then?

> Or perhaps there is a known-good gcc 4.5 snapshot (FWIW, I'd much rather 
> patch a debian compiler instead, which means 4.4 or preferably older.)

It would be wonderful to have debian gcc 4.4 building on m68k. It 
never has.

> As for eglibc, there are a number of branches listed here, 
> http://www.eglibc.org/repository
> The question is, which branch, snapshot or release might meet be suitable?
> 
> With this information, I could attempt to build a toolchain from upstream 
> sources, or figure out whether or not the debian archive has the necessary 
> source packages...

The life is fast ebbing from debian/m68k as far as I can tell. I'm not
sure if there is sufficient energy to revitalize it. I'd be delighted to
be proven wrong.

Peace,

Stephen

-- 
Stephen R. Marenka     If life's not fun, you're not doing it right!
<stephen@marenka.net>

Re: toolchain, was Re: bogl: don't know screen type 1

[mike]

The thing is, its been proven that gcc produces slower and slower 68k
binaries, its probably not the linker in binutils at all
see.
http://www.amiga.org/forums/showthread.php?p=519318
and  ( not 100% sure if its the correct thread, but the natami team
have noticed the issue
http://www.natami.net/knowledge.php?b=3&note=2&z=9M0ieT

Including Gunnar Von Boehn in this now, cause they've done alot more
research, and can probably fill in what freescale have, and havent
done. I suspect they have been tweaking the code for newer "68k's" or
coldfires, rather than branching it off?

Cheers
-Spike

2009/9/5 Stephen R Marenka <stephen@marenka.net>:
> On Sat, Sep 05, 2009 at 01:43:14AM +1000, Finn Thain wrote:
>>
>> On Tue, 1 Sep 2009, Stephen R Marenka wrote:
>>
>> > On Tue, Sep 01, 2009 at 12:16:27AM +0200, mike wrote:
>> > > Btw, i noticed an error
>> > > http://people.debian.org/~smarenka/d-i/m68k/images/daily/build_nativehd.log
>> > > E: Couldn't find package libnss-dns-udeb
>> > > make[2]: *** [stamps/get_udebs-nativehd-stamp] Error 100
>> > > make[1]: *** [_build] Error 2
>> > > make: *** [build_nativehd] Error 2
>> >
>> > Yep. debian-installer dailies are now *dead* until we get a modern libc
>> > working.
>>
>> I wonder whether there are debian source packages for binutils, gcc and
>> glibc having TLS/NPTL support for m68k.
>
> I'd be surprised if that were the case.
>
>> The patches posted to the binutils mailing list are incomplete. The
>> binutils patch at
>> http://people.debian.org/~smarenka/m68k/tls/
>> is broken according to Kolla:
>> http://lists.debian.org/debian-68k/2009/07/msg00001.html
>>
>> But in that post (June 28) Maxim recommends using mainline binutils, and
>> since then we have HJL binutils-2.19.51.0.14 released, "...based on
>> binutils 2009 0722 in CVS on sourceware.org..." So I guess I should start
>> there.
>>
>> I understand that the current GCC (4.4) lacks the necessary patches, and
>> 4.5 is still uncooked (and that's a scary prospect). Can someone confirm
>> that this is the necessary patch for 4.4:
>> http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01024.html
>> Presumably not this one?
>> http://people.debian.org/~smarenka/m68k/tls/gcc_patch2
>> (and gcc_patch1 is clearly broken... perhaps it was actually the same
>> thing before being mangled... Stephen, I don't think this "/tls" directory
>> is helping any.)
>
> Shall I remove it then?
>
>> Or perhaps there is a known-good gcc 4.5 snapshot (FWIW, I'd much rather
>> patch a debian compiler instead, which means 4.4 or preferably older.)
>
> It would be wonderful to have debian gcc 4.4 building on m68k. It
> never has.
>
>> As for eglibc, there are a number of branches listed here,
>> http://www.eglibc.org/repository
>> The question is, which branch, snapshot or release might meet be suitable?
>>
>> With this information, I could attempt to build a toolchain from upstream
>> sources, or figure out whether or not the debian archive has the necessary
>> source packages...
>
> The life is fast ebbing from debian/m68k as far as I can tell. I'm not
> sure if there is sufficient energy to revitalize it. I'd be delighted to
> be proven wrong.
>
> Peace,
>
> Stephen
>
> --
> Stephen R. Marenka     If life's not fun, you're not doing it right!
> <stephen@marenka.net>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: toolchain, was Re: bogl: don't know screen type 1

[mike]

*hurm* Well if it is the case that some dev at freescale has assumed
that producing binaries in a certain way that makes sense for the
coldfire series ( which might resemble the original enough to make it
seem sensible )  might explain the slowdown were seeing _across the
line_ ( be it amigaos linux or fuckos).

Bernd Roesch ( now included weather he likes it or not, sorry :) has
also made remarks and comparisons about this. As has the amigaos dev's
of ffmpeg, which has made it bleeding clear in the posts linked to
before

http://www.amiga.org/forums/showthread.php?t=47991&highlight=ffmpeg+slowdown

So no the slowdown from 333,340 to 4xx is not only amigaos, its
clearly visible booting the linux kernel too ... .

2009/9/5 mike <localgost@gmail.com>:
> The thing is, its been proven that gcc produces slower and slower 68k
> binaries, its probably not the linker in binutils at all
> see.
> http://www.amiga.org/forums/showthread.php?p=519318
> and  ( not 100% sure if its the correct thread, but the natami team
> have noticed the issue
> http://www.natami.net/knowledge.php?b=3&note=2&z=9M0ieT
>
> Including Gunnar Von Boehn in this now, cause they've done alot more
> research, and can probably fill in what freescale have, and havent
> done. I suspect they have been tweaking the code for newer "68k's" or
> coldfires, rather than branching it off?
>
> Cheers
> -Spike
>
> 2009/9/5 Stephen R Marenka <stephen@marenka.net>:
>> On Sat, Sep 05, 2009 at 01:43:14AM +1000, Finn Thain wrote:
>>>
>>> On Tue, 1 Sep 2009, Stephen R Marenka wrote:
>>>
>>> > On Tue, Sep 01, 2009 at 12:16:27AM +0200, mike wrote:
>>> > > Btw, i noticed an error
>>> > > http://people.debian.org/~smarenka/d-i/m68k/images/daily/build_nativehd.log
>>> > > E: Couldn't find package libnss-dns-udeb
>>> > > make[2]: *** [stamps/get_udebs-nativehd-stamp] Error 100
>>> > > make[1]: *** [_build] Error 2
>>> > > make: *** [build_nativehd] Error 2
>>> >
>>> > Yep. debian-installer dailies are now *dead* until we get a modern libc
>>> > working.
>>>
>>> I wonder whether there are debian source packages for binutils, gcc and
>>> glibc having TLS/NPTL support for m68k.
>>
>> I'd be surprised if that were the case.
>>
>>> The patches posted to the binutils mailing list are incomplete. The
>>> binutils patch at
>>> http://people.debian.org/~smarenka/m68k/tls/
>>> is broken according to Kolla:
>>> http://lists.debian.org/debian-68k/2009/07/msg00001.html
>>>
>>> But in that post (June 28) Maxim recommends using mainline binutils, and
>>> since then we have HJL binutils-2.19.51.0.14 released, "...based on
>>> binutils 2009 0722 in CVS on sourceware.org..." So I guess I should start
>>> there.
>>>
>>> I understand that the current GCC (4.4) lacks the necessary patches, and
>>> 4.5 is still uncooked (and that's a scary prospect). Can someone confirm
>>> that this is the necessary patch for 4.4:
>>> http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01024.html
>>> Presumably not this one?
>>> http://people.debian.org/~smarenka/m68k/tls/gcc_patch2
>>> (and gcc_patch1 is clearly broken... perhaps it was actually the same
>>> thing before being mangled... Stephen, I don't think this "/tls" directory
>>> is helping any.)
>>
>> Shall I remove it then?
>>
>>> Or perhaps there is a known-good gcc 4.5 snapshot (FWIW, I'd much rather
>>> patch a debian compiler instead, which means 4.4 or preferably older.)
>>
>> It would be wonderful to have debian gcc 4.4 building on m68k. It
>> never has.
>>
>>> As for eglibc, there are a number of branches listed here,
>>> http://www.eglibc.org/repository
>>> The question is, which branch, snapshot or release might meet be suitable?
>>>
>>> With this information, I could attempt to build a toolchain from upstream
>>> sources, or figure out whether or not the debian archive has the necessary
>>> source packages...
>>
>> The life is fast ebbing from debian/m68k as far as I can tell. I'm not
>> sure if there is sufficient energy to revitalize it. I'd be delighted to
>> be proven wrong.
>>
>> Peace,
>>
>> Stephen
>>
>> --
>> Stephen R. Marenka     If life's not fun, you're not doing it right!
>> <stephen@marenka.net>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: toolchain, was Re: bogl: don't know screen type 1

[Petr Stehlik]

Stephen R Marenka píše v Pá 04. 09. 2009 v 20:08 -0500:
> It would be wonderful to have debian gcc 4.4 building on m68k. It 
> never has.

FYI FWIW gcc 4.4.x is used in FreeMiNT (an old BSD-like TOS compatible
OS) and seems to produce a well working m68k code. Of course no glibc or
similar issues there, still using good old a.out :)

Petr


--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: toolchain, was Re: bogl: don't know screen type 1

[Ingo Jürgensmann]

On Fri, 4 Sep 2009 20:08:30 -0500, Stephen R Marenka <stephen@marenka.net>
wrote:

> The life is fast ebbing from debian/m68k as far as I can tell. I'm not
> sure if there is sufficient energy to revitalize it. I'd be delighted to
> be proven wrong.

So am I!
But I must confess that it's not looking good for m68k. It's getting more
and more difficult for the port to survive after the exclusion from Debian,
IMHO, YMMV. Currently my plan is to shutdown most of my buildds and most
likely buildd.net as well in 1-2 years. Maybe I keep one or the other
machine running. 
This is for the current state of m68k. If there is a turnover and
development with the help from other people get's some kind of momentum
again, I'll happily keep the machines going as well as buildd.net. 

-- 
Ciao...            //      Fon: 0381-2744150
Ingo       \X/       http://blog.windfluechter.net

gpg pubkey: http://www.juergensmann.de/ij_public_key.asc

Re: toolchain, was Re: bogl: don't know screen type 1

[Maxim Kuvyrkov]

Finn Thain wrote:
...
> But in that post (June 28) Maxim recommends using mainline binutils, and 
> since then we have HJL binutils-2.19.51.0.14 released, "...based on 
> binutils 2009 0722 in CVS on sourceware.org..." So I guess I should start 
> there.

The last binutils TLS patches went in on 2009-08-26; the patches fixed 
generation of invalid TLS relocations.

> I understand that the current GCC (4.4) lacks the necessary patches, and 
> 4.5 is still uncooked (and that's a scary prospect). Can someone confirm 
> that this is the necessary patch for 4.4:
> http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01024.html

I think GCC 4.4 should be good enough.


> As for eglibc, there are a number of branches listed here, 
> http://www.eglibc.org/repository
> The question is, which branch, snapshot or release might meet be suitable?

EGLIBC does not yet have NPTL patches checked in, they are in review on 
libc-ports@.  Once the review is finished, I will likely backport the 
patches from EGLIBC trunk to 2.10 branch.

> With this information, I could attempt to build a toolchain from upstream 
> sources, or figure out whether or not the debian archive has the necessary 
> source packages...

You will also need a patch for kernel, posted on linux-m68k@.

--
Maxim

Re: toolchain, was Re: bogl: don't know screen type 1

[mike]

> The life is fast ebbing from debian/m68k as far as I can tell. I'm not
> sure if there is sufficient energy to revitalize it. I'd be delighted to
> be proven wrong.

Yep sad isnt it, one hope for the port is that several amigans (
trough natami ) and atarians ( trough the coldfire atari project) or
otherwise some miracle happens at freescale and thereby more people
see a reason to run debian on their 68k's,

Question is tho, as the kernel gets more bloated and slower as time
passes, and the packages that run on top, will it even be usable on
those in a few...

Netbsd seems to have a fast kernel. from what little i've booted of it...

2009/9/5 Maxim Kuvyrkov <maxim@codesourcery.com>:
> Finn Thain wrote:
> ...
>>
>> But in that post (June 28) Maxim recommends using mainline binutils, and
>> since then we have HJL binutils-2.19.51.0.14 released, "...based on binutils
>> 2009 0722 in CVS on sourceware.org..." So I guess I should start there.
>
> The last binutils TLS patches went in on 2009-08-26; the patches fixed
> generation of invalid TLS relocations.
>
>> I understand that the current GCC (4.4) lacks the necessary patches, and
>> 4.5 is still uncooked (and that's a scary prospect). Can someone confirm
>> that this is the necessary patch for 4.4:
>> http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01024.html
>
> I think GCC 4.4 should be good enough.
>
>
>> As for eglibc, there are a number of branches listed here,
>> http://www.eglibc.org/repository
>> The question is, which branch, snapshot or release might meet be suitable?
>
> EGLIBC does not yet have NPTL patches checked in, they are in review on
> libc-ports@.  Once the review is finished, I will likely backport the
> patches from EGLIBC trunk to 2.10 branch.
>
>> With this information, I could attempt to build a toolchain from upstream
>> sources, or figure out whether or not the debian archive has the necessary
>> source packages...
>
> You will also need a patch for kernel, posted on linux-m68k@.
>
> --
> Maxim
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: toolchain

[Finn Thain]

On Sat, 5 Sep 2009, Maxim Kuvyrkov wrote:

> Finn Thain wrote:
> ...
> > But in that post (June 28) Maxim recommends using mainline binutils, 
> > and since then we have HJL binutils-2.19.51.0.14 released, "...based 
> > on binutils 2009 0722 in CVS on sourceware.org..." So I guess I should 
> > start there.
> 
> The last binutils TLS patches went in on 2009-08-26; the patches fixed 
> generation of invalid TLS relocations.

OK. Debian has 2.19.51.20090827-1 in the sid archive. I wonder if it has 
been built yet?

> > I understand that the current GCC (4.4) lacks the necessary patches, 
> > and 4.5 is still uncooked (and that's a scary prospect). Can someone 
> > confirm that this is the necessary patch for 4.4: 
> > http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01024.html
> 
> I think GCC 4.4 should be good enough.

That's encouraging.

> 
> > As for eglibc, there are a number of branches listed here,
> > http://www.eglibc.org/repository
> > The question is, which branch, snapshot or release might meet be suitable?
> 
> EGLIBC does not yet have NPTL patches checked in, they are in review on 
> libc-ports@.  Once the review is finished, I will likely backport the 
> patches from EGLIBC trunk to 2.10 branch.

I guess I'll wait for that, and then perhaps look into patching 2.9 if 
that turns out to be straight forward. (Debian has 2.10 in the 
experimental archive, 2.9 (more or less) in stable and testing.)

> 
> > With this information, I could attempt to build a toolchain from 
> > upstream sources, or figure out whether or not the debian archive has 
> > the necessary source packages...
> 
> You will also need a patch for kernel, posted on linux-m68k@.

Right.

Thanks for the update.

Finn

> 
> --
> Maxim
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: toolchain, was Re: bogl: don't know screen type 1

[Finn Thain]

On Fri, 4 Sep 2009, Stephen R Marenka wrote:

> On Sat, Sep 05, 2009 at 01:43:14AM +1000, Finn Thain wrote:
> > 
> > The patches posted to the binutils mailing list are incomplete. The 
> > binutils patch at
> > http://people.debian.org/~smarenka/m68k/tls/
> > is broken according to Kolla:
> > http://lists.debian.org/debian-68k/2009/07/msg00001.html
> > 
> > But in that post (June 28) Maxim recommends using mainline binutils, and 
> > since then we have HJL binutils-2.19.51.0.14 released, "...based on 
> > binutils 2009 0722 in CVS on sourceware.org..." So I guess I should start 
> > there.
> > 
> > I understand that the current GCC (4.4) lacks the necessary patches, and 
> > 4.5 is still uncooked (and that's a scary prospect). Can someone confirm 
> > that this is the necessary patch for 4.4:
> > http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01024.html
> > Presumably not this one?
> > http://people.debian.org/~smarenka/m68k/tls/gcc_patch2
> > (and gcc_patch1 is clearly broken... perhaps it was actually the same 
> > thing before being mangled... Stephen, I don't think this "/tls" directory 
> > is helping any.)
> 
> Shall I remove it then?

I'd remove it.

The gcc commit in question is this one,
http://gcc.gnu.org/viewcvs?view=revision&revision=147654
which appears to be the very one in the mailing list archive at the URL 
above (you can download a raw version at that URL).

A quick visual shows that tls/gcc_patch2 doesn't match the commit (the 
revision numbers in the diff confirm that it is older).

Finn

Re: toolchain

[Finn Thain]

On Sat, 5 Sep 2009, Maxim Kuvyrkov wrote:

> > With this information, I could attempt to build a toolchain from 
> > upstream sources, or figure out whether or not the debian archive has 
> > the necessary source packages...
> 
> You will also need a patch for kernel, posted on linux-m68k@.

Stephen, this patch will be needed in order to build glibc with TLS, since 
it provides the userspace headers for TLS.

http://marc.info/?l=linux-m68k&m=125145669021517&w=2

Not sure how debian handles the kernel headers. I presume that 
linux-libc-dev (probably 2.6.30) needs the patch? (As will the other 
kernel packages of course.)

Finn

Re: toolchain, was Re: bogl: don't know screen type 1

[Finn Thain]

On Sat, 5 Sep 2009, mike wrote:

> > The life is fast ebbing from debian/m68k as far as I can tell. I'm not 
> > sure if there is sufficient energy to revitalize it. I'd be delighted 
> > to be proven wrong.
> 
> Yep sad isnt it, one hope for the port is that several amigans ( trough 
> natami ) and atarians ( trough the coldfire atari project) or otherwise 
> some miracle happens at freescale and thereby more people see a reason 
> to run debian on their 68k's,
> 
> Question is tho, as the kernel gets more bloated and slower as time 
> passes, and the packages that run on top, will it even be usable on 
> those in a few...

I haven't seen anyone test for kernel performance regressions on m68k 
(other than the scheduler regression) -- let alone work on reversing them. 
Probably because of the usual shortage of skills.

> Netbsd seems to have a fast kernel. from what little i've booted of 
> it...

You have to pick the right architecture. In Linux (the kernel) algorithms 
are tuned for the common case, which is x86. And hence you'd expect a 
Linux operating system's performance to be competitive with any equivalent 
operating system running on that architecture.

Having said that, kernel performance even on x86 is quite variable from 
one release to another:
http://www.phoronix.com/scan.php?page=article&item=linux_2629_benchmarks&num=9 

Of course, benchmarks on Intel architectures should not be taken as 
representative of m68k performance. It would be informative to build and 
run a benchmark suite like that one on debian etch-m68k (it has gcc 3.3 
and 4.1) using the latest kernel.

Finn

Re: toolchain

[Stephen R Marenka]

On Sun, Sep 06, 2009 at 12:37:24PM +1000, Finn Thain wrote:

> OK. Debian has 2.19.51.20090827-1 in the sid archive. I wonder if it has 
> been built yet?

No, binutils buildds were failing, now that are stuck in autoconf 
dependency hell. I've been meaning to have a look. It will at the 
least take manually messing with older dependencies to get a set 
installed.

Peace,

Stephen

-- 
Stephen R. Marenka     If life's not fun, you're not doing it right!
<stephen@marenka.net>

Re: toolchain

[Finn Thain]

On Sun, 6 Sep 2009, I wrote:

> Stephen, this patch will be needed in order to build glibc with TLS, 
> since it provides the userspace headers for TLS.
> 
> http://marc.info/?l=linux-m68k&m=125145669021517&w=2
> 
> Not sure how debian handles the kernel headers. I presume that 
> linux-libc-dev (probably 2.6.30) needs the patch? (As will the other 
> kernel packages of course.)

The patch doesn't apply to 2.6.30, because the rt_tgsigqueueinfo syscall 
is not there.

Will see how far I get with binutils and gcc while I wait for the 2.6.31 
kernel release and eglibc patches.

Finn

Re: bogl: don't know screen type 1

[Kolbjørn Barmen]

On Thu, 3 Sep 2009, mike wrote:

> I tried to boot 2.6.29 or whatever... It was so slow compared to 2.4 i
> donno what to say, except its crap. Not a surprise if gcc produces
> crappier and crappier 68k binaries anyway. Why the hell isnt freescale
> on top of this? Fuck damn they should be on top of this and the 68050/70
> the natami is trying out, and bloody include talent like Carl S and Dave
> H that know what the heck the 68k, electronics, and the amiga is
> about....

For what it's worth - my m68k systems runs current linux kernel, 2.6.30,
compiled with gcc 4.2.4 just fine, and I have not see any slow-down, apart
from obvious things in bootup, like initiating udev, creating nodes and
similar things that have nothing to do with kernel itself. I also make
sure to compile my kernels with only the modules that makes sense for the
hardware I run it on.

My systems are one A1200 with Blizzard 1230III (030+882@50MHz) and 32MB
RAM, one A1200 with Blizzard 1260 (060@50MHz) and 64MB RAM, and one Mac
Quadra 910 (040@25MHz) with 64MB RAM. Oh and my build box, Aranym with a
040@100-180MHz depending on host at bootup, and for the time being, 256MB
RAM (allthough, it is down ATM, fixing filesystem disaster after I somehow
managed to launch aranym twice on same disk image :P) 

The A1200 with Blizz1230III has been running more or less non-stop since
1997 with only a break now and then when moving between locations, being
installed into new tower solutions, and infrequent kernel updates, 

I dont use debian though, I use gentoo since it gives me a tool (portage)
to build packages the way I want them, stripped where needed, bloated for
the things I care about. Almost everything is buildt -Os.

So, in the end, I'm not so sure that what you complain about is for real.

-- kolla

Re: bogl: don't know screen type 1

[Geert Uytterhoeven]

2009/9/11 Kolbjørn Barmen <linux-m68k@kolla.no>:
> On Thu, 3 Sep 2009, mike wrote:
>> I tried to boot 2.6.29 or whatever... It was so slow compared to 2.4 i
>> donno what to say, except its crap. Not a surprise if gcc produces
>> crappier and crappier 68k binaries anyway. Why the hell isnt freescale
>> on top of this? Fuck damn they should be on top of this and the 68050/70
>> the natami is trying out, and bloody include talent like Carl S and Dave
>> H that know what the heck the 68k, electronics, and the amiga is
>> about....
>
> For what it's worth - my m68k systems runs current linux kernel, 2.6.30,
> compiled with gcc 4.2.4 just fine, and I have not see any slow-down, apart
> from obvious things in bootup, like initiating udev, creating nodes and
> similar things that have nothing to do with kernel itself. I also make
> sure to compile my kernels with only the modules that makes sense for the
> hardware I run it on.
>
> My systems are one A1200 with Blizzard 1230III (030+882@50MHz) and 32MB
> RAM, one A1200 with Blizzard 1260 (060@50MHz) and 64MB RAM, and one Mac
> Quadra 910 (040@25MHz) with 64MB RAM. Oh and my build box, Aranym with a
> 040@100-180MHz depending on host at bootup, and for the time being, 256MB
> RAM (allthough, it is down ATM, fixing filesystem disaster after I somehow
> managed to launch aranym twice on same disk image :P)

[...]

> So, in the end, I'm not so sure that what you complain about is for real.

2.6.x is noticable slower than 2.4.x, due to increasing RAM requirements.
Probably you don't notice it that much as even your least machine has 32 MiB of
RAM. I do, as my A4000/040 has only 12 MiB of Fast RAM.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bogl: don't know screen type 1

[fthain]

On Fri, 11 Sep 2009, Kolbj?rn Barmen wrote:

> On Thu, 3 Sep 2009, mike wrote:
> 
> > I tried to boot 2.6.29 or whatever... It was so slow compared to 2.4 i 
> > donno what to say, except its crap. Not a surprise if gcc produces 
> > crappier and crappier 68k binaries anyway. Why the hell isnt freescale 
> > on top of this? Fuck damn they should be on top of this and the 
> > 68050/70 the natami is trying out, and bloody include talent like Carl 
> > S and Dave H that know what the heck the 68k, electronics, and the 
> > amiga is about....
> 
> For what it's worth - my m68k systems runs current linux kernel, 2.6.30, 
> compiled with gcc 4.2.4 just fine, and I have not see any slow-down, 
> apart from obvious things in bootup, like initiating udev, creating 
> nodes and similar things that have nothing to do with kernel itself. I 
> also make sure to compile my kernels with only the modules that makes 
> sense for the hardware I run it on.

What happened to devtmpfs I wonder.
 
> My systems are one A1200 with Blizzard 1230III (030+882@50MHz) and 32MB 
> RAM, one A1200 with Blizzard 1260 (060@50MHz) and 64MB RAM, and one Mac 
> Quadra 910 (040@25MHz) with 64MB RAM. Oh and my build box, Aranym with a 
> 040@100-180MHz depending on host at bootup, and for the time being, 
> 256MB RAM (allthough, it is down ATM, fixing filesystem disaster after I 
> somehow managed to launch aranym twice on same disk image :P)

Can't file locking prevent that? Sounds like a bug...

Finn

> 
> The A1200 with Blizz1230III has been running more or less non-stop since 
> 1997 with only a break now and then when moving between locations, being 
> installed into new tower solutions, and infrequent kernel updates,
> 
> I dont use debian though, I use gentoo since it gives me a tool 
> (portage) to build packages the way I want them, stripped where needed, 
> bloated for the things I care about. Almost everything is buildt -Os.
> 
> So, in the end, I'm not so sure that what you complain about is for 
> real.
> 
> -- kolla
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: toolchain, was Re: bogl: don't know screen type 1

[fthain]

On Sat, 5 Sep 2009, Maxim Kuvyrkov wrote:

> Finn Thain wrote:
> ...
> 
> > I understand that the current GCC (4.4) lacks the necessary patches, 
> > and 4.5 is still uncooked (and that's a scary prospect). Can someone 
> > confirm that this is the necessary patch for 4.4: 
> > http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01024.html
> 
> I think GCC 4.4 should be good enough.

I tried patching 4.4.1 and the patch was rejected. It expects 
m68k_legitimize_address() to have been declared and defined, but that 
routine isn't in gcc-4.4.

So, I edited the patch (see diff below). What bothers me is that this 
removes the call to the new m68k_tls_symbol_p() routine:

../../gcc-4.4.1/gcc/config/m68k/m68k.c: At top level:
../../gcc-4.4.1/gcc/config/m68k/m68k.c:2553: warning: 'm68k_tls_symbol_p' defined but not used

The compiler appears to work, but I haven't run any executable it produced 
as yet. When we get eglibc-2.10 I plan to run the testsuites on '040 
hardware, which is going to take a long time to complete. It would be nice 
to know in advance whether this naive attempt at a backport is likely to 
work or not (?)

Finn



--- gcc-m68k-support-for-tls.patch	2009-09-13 13:16:03.475546800 +1000
+++ gcc-m68k-support-for-tls-backport.patch	2009-09-13 13:16:03.475546800 +1000
@@ -574,12 +574,11 @@
  
  enum reg_class regno_reg_class[] =
  {
-@@ -143,11 +144,13 @@ static tree m68k_handle_fndecl_attribute
+@@ -143,10 +144,12 @@ static tree m68k_handle_fndecl_attribute
  static void m68k_compute_frame_layout (void);
  static bool m68k_save_reg (unsigned int regno, bool interrupt_handler);
  static bool m68k_ok_for_sibcall_p (tree, tree);
 +static bool m68k_tls_symbol_p (rtx);
- static rtx m68k_legitimize_address (rtx, rtx, enum machine_mode);
  static bool m68k_rtx_costs (rtx, int, int, int *, bool);
  #if M68K_HONOR_TARGET_STRICT_ALIGNMENT
  static bool m68k_return_in_memory (const_tree, const_tree);
@@ -613,16 +612,6 @@
        && crtl->uses_pic_offset_table)
      insn = emit_insn (gen_load_got (pic_offset_table_rtx));
  }
-@@ -1431,6 +1441,9 @@ m68k_legitimize_sibcall_address (rtx x)
- rtx
- m68k_legitimize_address (rtx x, rtx oldx, enum machine_mode mode)
- {
-+  if (m68k_tls_symbol_p (x))
-+    return m68k_legitimize_tls_address (x);
-+
-   if (GET_CODE (x) == PLUS)
-     {
-       int ch = (x) != (oldx);
 @@ -1849,7 +1862,7 @@ m68k_illegitimate_symbolic_constant_p (r
  	  && !offset_within_block_p (base, INTVAL (offset)))
  	return true;

Re: toolchain, was Re: bogl: don't know screen type 1

[Maxim Kuvyrkov]

fthain@telegraphics.com.au wrote:
> On Sat, 5 Sep 2009, Maxim Kuvyrkov wrote:
> 
>> Finn Thain wrote:
>> ...
>>
>>> I understand that the current GCC (4.4) lacks the necessary patches, 
>>> and 4.5 is still uncooked (and that's a scary prospect). Can someone 
>>> confirm that this is the necessary patch for 4.4: 
>>> http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01024.html
>> I think GCC 4.4 should be good enough.
> 
> I tried patching 4.4.1 and the patch was rejected. It expects 
> m68k_legitimize_address() to have been declared and defined, but that 
> routine isn't in gcc-4.4.

m68k.c:m68k_legitimize_address() was macro m68k.h:LEGITIMIZE_ADDRESS(), 
you need to move the hunk to m68k.h.

> 
> So, I edited the patch (see diff below). What bothers me is that this 
> removes the call to the new m68k_tls_symbol_p() routine:
> 
> ../../gcc-4.4.1/gcc/config/m68k/m68k.c: At top level:
> ../../gcc-4.4.1/gcc/config/m68k/m68k.c:2553: warning: 'm68k_tls_symbol_p' defined but not used
> 
> The compiler appears to work, but I haven't run any executable it produced 
> as yet. When we get eglibc-2.10 I plan to run the testsuites on '040 
> hardware, which is going to take a long time to complete. It would be nice 
> to know in advance whether this naive attempt at a backport is likely to 
> work or not (?)

It will fail to process __thread variables.

--
Maxim

Re: toolchain, was Re: bogl: don't know screen type 1

[fthain]

On Sun, 13 Sep 2009, Maxim Kuvyrkov wrote:

> fthain@telegraphics.com.au wrote:
>
> > On Sat, 5 Sep 2009, Maxim Kuvyrkov wrote:
> > 
> > > Finn Thain wrote: ...
> > > 
> > > > I understand that the current GCC (4.4) lacks the necessary 
> > > > patches, and 4.5 is still uncooked (and that's a scary prospect). 
> > > > Can someone confirm that this is the necessary patch for 4.4: 
> > > > http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01024.html
> > > I think GCC 4.4 should be good enough.
> > 
> > I tried patching 4.4.1 and the patch was rejected. It expects 
> > m68k_legitimize_address() to have been declared and defined, but that 
> > routine isn't in gcc-4.4.
> 
> m68k.c:m68k_legitimize_address() was macro m68k.h:LEGITIMIZE_ADDRESS(), 
> you need to move the hunk to m68k.h.
> 

Thanks for the tip.

Here's a second cut. This one removes the m68k_tls_symbol_p() routine and 
inlines that logic in the LEGITIMIZE_ADDRESS macro (avoids a reference to 
m68k_tls_symbol_p() from explow.o). The TARGET_HAVE_TLS macro wasn't 
defined in explow.c so I changed it to HAVE_AS_TLS.

It appears to work, but I won't be able to test any binary produced by 
this compiler for a week or so.

Finn


--- gcc-m68k-support-for-tls.patch	2009-09-14 15:11:39.893286532 +1000
+++ gcc-m68k-support-for-tls-backport.patch	2009-09-14 15:11:34.563287784 +1000
@@ -574,13 +574,7 @@
  
  enum reg_class regno_reg_class[] =
  {
-@@ -143,11 +144,13 @@ static tree m68k_handle_fndecl_attribute
- static void m68k_compute_frame_layout (void);
- static bool m68k_save_reg (unsigned int regno, bool interrupt_handler);
- static bool m68k_ok_for_sibcall_p (tree, tree);
-+static bool m68k_tls_symbol_p (rtx);
- static rtx m68k_legitimize_address (rtx, rtx, enum machine_mode);
- static bool m68k_rtx_costs (rtx, int, int, int *, bool);
+@@ -146,6 +147,7 @@ static tree m68k_handle_fndecl_attribute
  #if M68K_HONOR_TARGET_STRICT_ALIGNMENT
  static bool m68k_return_in_memory (const_tree, const_tree);
  #endif
@@ -613,16 +607,6 @@
        && crtl->uses_pic_offset_table)
      insn = emit_insn (gen_load_got (pic_offset_table_rtx));
  }
-@@ -1431,6 +1441,9 @@ m68k_legitimize_sibcall_address (rtx x)
- rtx
- m68k_legitimize_address (rtx x, rtx oldx, enum machine_mode mode)
- {
-+  if (m68k_tls_symbol_p (x))
-+    return m68k_legitimize_tls_address (x);
-+
-   if (GET_CODE (x) == PLUS)
-     {
-       int ch = (x) != (oldx);
 @@ -1849,7 +1862,7 @@ m68k_illegitimate_symbolic_constant_p (r
  	  && !offset_within_block_p (base, INTVAL (offset)))
  	return true;
@@ -957,7 +941,7 @@
  	return orig;
  
        gcc_assert (reg);
-@@ -2196,13 +2421,257 @@ legitimize_pic_address (rtx orig, enum m
+@@ -2196,13 +2421,244 @@ legitimize_pic_address (rtx orig, enum m
  				     base == reg ? 0 : reg);
  
        if (GET_CODE (orig) == CONST_INT)
@@ -1164,19 +1148,6 @@
 +  return orig;
 +}
 +
-+/* Return true if X is a TLS symbol.  */
-+
-+static bool
-+m68k_tls_symbol_p (rtx x)
-+{
-+  if (!TARGET_HAVE_TLS)
-+    return false;
-+
-+  if (GET_CODE (x) != SYMBOL_REF)
-+    return false;
-+
-+  return SYMBOL_REF_TLS_MODEL (x) != 0;
-+}
 +
 +/* Helper for m68k_tls_referenced_p.  */
 +
@@ -1414,6 +1385,18 @@
  
  #define REG_OK_FOR_BASE_P(X) \
    m68k_legitimate_base_reg_p (X, REG_STRICT_P)
+@@ -777,7 +778,10 @@ __transfer_from_trampoline ()					\
+ #define COPY_ONCE(Y) if (!copied) { Y = copy_rtx (Y); copied = ch = 1; }
+ #define LEGITIMIZE_ADDRESS(X,OLDX,MODE,WIN)   \
+ { register int ch = (X) != (OLDX);					\
+-  if (GET_CODE (X) == PLUS)						\
++  if (HAVE_AS_TLS && (GET_CODE (X) == SYMBOL_REF) &&			\
++      (SYMBOL_REF_TLS_MODEL (X) != 0))					\
++    m68k_legitimize_tls_address (X);					\
++  else if (GET_CODE (X) == PLUS)					\
+     { int copied = 0;							\
+       if (GET_CODE (XEXP (X, 0)) == MULT)				\
+ 	{ COPY_ONCE (X); XEXP (X, 0) = force_operand (XEXP (X, 0), 0);} \
 @@ -974,6 +975,9 @@ do { if (cc_prev_status.flags & CC_IN_68
    assemble_name ((FILE), (NAME)),		\
    fprintf ((FILE), ",%u\n", (int)(ROUNDED)))

Re: toolchain, was Re: bogl: don't know screen type 1

[mike]

Seems im not the only soul feeling the bloat
http://news.cnet.com/8301-13505_3-10358024-16.html

I havent seen any 68k linux benchmarks for this yet
http://cshandley.co.uk/temp/membench/
http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=29569&forum=14

It would be interesting if someone could compare a binary compiled
with gcc 2.95 to 3.33 3.40 and or 4.4 for linux, on various systems
even. To see if the slowdown has any consistency.

-Mike


2009/9/14  <fthain@telegraphics.com.au>:
>
> On Sun, 13 Sep 2009, Maxim Kuvyrkov wrote:
>
>> fthain@telegraphics.com.au wrote:
>>
>> > On Sat, 5 Sep 2009, Maxim Kuvyrkov wrote:
>> >
>> > > Finn Thain wrote: ...
>> > >
>> > > > I understand that the current GCC (4.4) lacks the necessary
>> > > > patches, and 4.5 is still uncooked (and that's a scary prospect).
>> > > > Can someone confirm that this is the necessary patch for 4.4:
>> > > > http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01024.html
>> > > I think GCC 4.4 should be good enough.
>> >
>> > I tried patching 4.4.1 and the patch was rejected. It expects
>> > m68k_legitimize_address() to have been declared and defined, but that
>> > routine isn't in gcc-4.4.
>>
>> m68k.c:m68k_legitimize_address() was macro m68k.h:LEGITIMIZE_ADDRESS(),
>> you need to move the hunk to m68k.h.
>>
>
> Thanks for the tip.
>
> Here's a second cut. This one removes the m68k_tls_symbol_p() routine and
> inlines that logic in the LEGITIMIZE_ADDRESS macro (avoids a reference to
> m68k_tls_symbol_p() from explow.o). The TARGET_HAVE_TLS macro wasn't
> defined in explow.c so I changed it to HAVE_AS_TLS.
>
> It appears to work, but I won't be able to test any binary produced by
> this compiler for a week or so.
>
> Finn
>
>
> --- gcc-m68k-support-for-tls.patch      2009-09-14 15:11:39.893286532 +1000
> +++ gcc-m68k-support-for-tls-backport.patch     2009-09-14 15:11:34.563287784 +1000
> @@ -574,13 +574,7 @@
>
>  enum reg_class regno_reg_class[] =
>  {
> -@@ -143,11 +144,13 @@ static tree m68k_handle_fndecl_attribute
> - static void m68k_compute_frame_layout (void);
> - static bool m68k_save_reg (unsigned int regno, bool interrupt_handler);
> - static bool m68k_ok_for_sibcall_p (tree, tree);
> -+static bool m68k_tls_symbol_p (rtx);
> - static rtx m68k_legitimize_address (rtx, rtx, enum machine_mode);
> - static bool m68k_rtx_costs (rtx, int, int, int *, bool);
> +@@ -146,6 +147,7 @@ static tree m68k_handle_fndecl_attribute
>  #if M68K_HONOR_TARGET_STRICT_ALIGNMENT
>  static bool m68k_return_in_memory (const_tree, const_tree);
>  #endif
> @@ -613,16 +607,6 @@
>        && crtl->uses_pic_offset_table)
>      insn = emit_insn (gen_load_got (pic_offset_table_rtx));
>  }
> -@@ -1431,6 +1441,9 @@ m68k_legitimize_sibcall_address (rtx x)
> - rtx
> - m68k_legitimize_address (rtx x, rtx oldx, enum machine_mode mode)
> - {
> -+  if (m68k_tls_symbol_p (x))
> -+    return m68k_legitimize_tls_address (x);
> -+
> -   if (GET_CODE (x) == PLUS)
> -     {
> -       int ch = (x) != (oldx);
>  @@ -1849,7 +1862,7 @@ m68k_illegitimate_symbolic_constant_p (r
>          && !offset_within_block_p (base, INTVAL (offset)))
>        return true;
> @@ -957,7 +941,7 @@
>        return orig;
>
>        gcc_assert (reg);
> -@@ -2196,13 +2421,257 @@ legitimize_pic_address (rtx orig, enum m
> +@@ -2196,13 +2421,244 @@ legitimize_pic_address (rtx orig, enum m
>                                     base == reg ? 0 : reg);
>
>        if (GET_CODE (orig) == CONST_INT)
> @@ -1164,19 +1148,6 @@
>  +  return orig;
>  +}
>  +
> -+/* Return true if X is a TLS symbol.  */
> -+
> -+static bool
> -+m68k_tls_symbol_p (rtx x)
> -+{
> -+  if (!TARGET_HAVE_TLS)
> -+    return false;
> -+
> -+  if (GET_CODE (x) != SYMBOL_REF)
> -+    return false;
> -+
> -+  return SYMBOL_REF_TLS_MODEL (x) != 0;
> -+}
>  +
>  +/* Helper for m68k_tls_referenced_p.  */
>  +
> @@ -1414,6 +1385,18 @@
>
>  #define REG_OK_FOR_BASE_P(X) \
>    m68k_legitimate_base_reg_p (X, REG_STRICT_P)
> +@@ -777,7 +778,10 @@ __transfer_from_trampoline ()                                     \
> + #define COPY_ONCE(Y) if (!copied) { Y = copy_rtx (Y); copied = ch = 1; }
> + #define LEGITIMIZE_ADDRESS(X,OLDX,MODE,WIN)   \
> + { register int ch = (X) != (OLDX);                                    \
> +-  if (GET_CODE (X) == PLUS)                                           \
> ++  if (HAVE_AS_TLS && (GET_CODE (X) == SYMBOL_REF) &&                  \
> ++      (SYMBOL_REF_TLS_MODEL (X) != 0))                                        \
> ++    m68k_legitimize_tls_address (X);                                  \
> ++  else if (GET_CODE (X) == PLUS)                                      \
> +     { int copied = 0;                                                 \
> +       if (GET_CODE (XEXP (X, 0)) == MULT)                             \
> +       { COPY_ONCE (X); XEXP (X, 0) = force_operand (XEXP (X, 0), 0);} \
>  @@ -974,6 +975,9 @@ do { if (cc_prev_status.flags & CC_IN_68
>    assemble_name ((FILE), (NAME)),             \
>    fprintf ((FILE), ",%u\n", (int)(ROUNDED)))
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: benchmarks, was Re: toolchain

[Finn Thain]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 6411 bytes --]



On Tue, 22 Sep 2009, mike wrote:

> Seems im not the only soul feeling the bloat
> http://news.cnet.com/8301-13505_3-10358024-16.html
> 
> I havent seen any 68k linux benchmarks for this yet
> http://cshandley.co.uk/temp/membench/
> http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=29569&forum=14

These benchmarks aren't for linux, right?

> 
> It would be interesting if someone could compare a binary compiled with 
> gcc 2.95 to 3.33 3.40 and or 4.4 for linux, on various systems even. To 
> see if the slowdown has any consistency.

If you would like to run some linux benchmarks, I could build the latest 
kernel using several different compilers for you. I'd need a kernel config 
to suit your hardware though.

But if you want to compare different compilers using benchmarks for a 
different operating system, I can't help with that. You may have more luck 
with that on the relevant mailing list or forum.

Finn

> 
> -Mike
> 
> 
> 2009/9/14  <fthain@telegraphics.com.au>:
> >
> > On Sun, 13 Sep 2009, Maxim Kuvyrkov wrote:
> >
> >> fthain@telegraphics.com.au wrote:
> >>
> >> > On Sat, 5 Sep 2009, Maxim Kuvyrkov wrote:
> >> >
> >> > > Finn Thain wrote: ...
> >> > >
> >> > > > I understand that the current GCC (4.4) lacks the necessary
> >> > > > patches, and 4.5 is still uncooked (and that's a scary prospect).
> >> > > > Can someone confirm that this is the necessary patch for 4.4:
> >> > > > http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01024.html
> >> > > I think GCC 4.4 should be good enough.
> >> >
> >> > I tried patching 4.4.1 and the patch was rejected. It expects
> >> > m68k_legitimize_address() to have been declared and defined, but that
> >> > routine isn't in gcc-4.4.
> >>
> >> m68k.c:m68k_legitimize_address() was macro m68k.h:LEGITIMIZE_ADDRESS(),
> >> you need to move the hunk to m68k.h.
> >>
> >
> > Thanks for the tip.
> >
> > Here's a second cut. This one removes the m68k_tls_symbol_p() routine and
> > inlines that logic in the LEGITIMIZE_ADDRESS macro (avoids a reference to
> > m68k_tls_symbol_p() from explow.o). The TARGET_HAVE_TLS macro wasn't
> > defined in explow.c so I changed it to HAVE_AS_TLS.
> >
> > It appears to work, but I won't be able to test any binary produced by
> > this compiler for a week or so.
> >
> > Finn
> >
> >
> > --- gcc-m68k-support-for-tls.patch      2009-09-14 15:11:39.893286532 +1000
> > +++ gcc-m68k-support-for-tls-backport.patch     2009-09-14 15:11:34.563287784 +1000
> > @@ -574,13 +574,7 @@
> >
> >  enum reg_class regno_reg_class[] =
> >  {
> > -@@ -143,11 +144,13 @@ static tree m68k_handle_fndecl_attribute
> > - static void m68k_compute_frame_layout (void);
> > - static bool m68k_save_reg (unsigned int regno, bool interrupt_handler);
> > - static bool m68k_ok_for_sibcall_p (tree, tree);
> > -+static bool m68k_tls_symbol_p (rtx);
> > - static rtx m68k_legitimize_address (rtx, rtx, enum machine_mode);
> > - static bool m68k_rtx_costs (rtx, int, int, int *, bool);
> > +@@ -146,6 +147,7 @@ static tree m68k_handle_fndecl_attribute
> >  #if M68K_HONOR_TARGET_STRICT_ALIGNMENT
> >  static bool m68k_return_in_memory (const_tree, const_tree);
> >  #endif
> > @@ -613,16 +607,6 @@
> >        && crtl->uses_pic_offset_table)
> >      insn = emit_insn (gen_load_got (pic_offset_table_rtx));
> >  }
> > -@@ -1431,6 +1441,9 @@ m68k_legitimize_sibcall_address (rtx x)
> > - rtx
> > - m68k_legitimize_address (rtx x, rtx oldx, enum machine_mode mode)
> > - {
> > -+  if (m68k_tls_symbol_p (x))
> > -+    return m68k_legitimize_tls_address (x);
> > -+
> > -   if (GET_CODE (x) == PLUS)
> > -     {
> > -       int ch = (x) != (oldx);
> >  @@ -1849,7 +1862,7 @@ m68k_illegitimate_symbolic_constant_p (r
> >          && !offset_within_block_p (base, INTVAL (offset)))
> >        return true;
> > @@ -957,7 +941,7 @@
> >        return orig;
> >
> >        gcc_assert (reg);
> > -@@ -2196,13 +2421,257 @@ legitimize_pic_address (rtx orig, enum m
> > +@@ -2196,13 +2421,244 @@ legitimize_pic_address (rtx orig, enum m
> >                                     base == reg ? 0 : reg);
> >
> >        if (GET_CODE (orig) == CONST_INT)
> > @@ -1164,19 +1148,6 @@
> >  +  return orig;
> >  +}
> >  +
> > -+/* Return true if X is a TLS symbol.  */
> > -+
> > -+static bool
> > -+m68k_tls_symbol_p (rtx x)
> > -+{
> > -+  if (!TARGET_HAVE_TLS)
> > -+    return false;
> > -+
> > -+  if (GET_CODE (x) != SYMBOL_REF)
> > -+    return false;
> > -+
> > -+  return SYMBOL_REF_TLS_MODEL (x) != 0;
> > -+}
> >  +
> >  +/* Helper for m68k_tls_referenced_p.  */
> >  +
> > @@ -1414,6 +1385,18 @@
> >
> >  #define REG_OK_FOR_BASE_P(X) \
> >    m68k_legitimate_base_reg_p (X, REG_STRICT_P)
> > +@@ -777,7 +778,10 @@ __transfer_from_trampoline ()                                     \
> > + #define COPY_ONCE(Y) if (!copied) { Y = copy_rtx (Y); copied = ch = 1; }
> > + #define LEGITIMIZE_ADDRESS(X,OLDX,MODE,WIN)   \
> > + { register int ch = (X) != (OLDX);                                    \
> > +-  if (GET_CODE (X) == PLUS)                                           \
> > ++  if (HAVE_AS_TLS && (GET_CODE (X) == SYMBOL_REF) &&                  \
> > ++      (SYMBOL_REF_TLS_MODEL (X) != 0))                                        \
> > ++    m68k_legitimize_tls_address (X);                                  \
> > ++  else if (GET_CODE (X) == PLUS)                                      \
> > +     { int copied = 0;                                                 \
> > +       if (GET_CODE (XEXP (X, 0)) == MULT)                             \
> > +       { COPY_ONCE (X); XEXP (X, 0) = force_operand (XEXP (X, 0), 0);} \
> >  @@ -974,6 +975,9 @@ do { if (cc_prev_status.flags & CC_IN_68
> >    assemble_name ((FILE), (NAME)),             \
> >    fprintf ((FILE), ",%u\n", (int)(ROUNDED)))
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> 

Re: benchmarks, was Re: toolchain

[mike]

> These benchmarks aren't for linux, right?
Nope, thats amiga c
I see umisef made a mac version , but i cant see a link to it anywhere.


For some reason, probably due to the way amigaos 3.9 has configured
the hd i cant mount, or read SFS partitions from linux, so im dead in
the water as far as linux on the amiga goes, either that or modules
are missing.. Seemed like none were loaded according to lsmod .. I
need to install from a image on the hard drive.. So i cant test until
i figure that out. And i couldnt get it running in e-uae. If i could
get that running, i might be able to stuff the hd in the pc and dd a
partition.

Are there any other VM's i could use to install linux 68k?

2009/9/22 Finn Thain <fthain@telegraphics.com.au>:
>
>
> On Tue, 22 Sep 2009, mike wrote:
>
>> Seems im not the only soul feeling the bloat
>> http://news.cnet.com/8301-13505_3-10358024-16.html
>>
>> I havent seen any 68k linux benchmarks for this yet
>> http://cshandley.co.uk/temp/membench/
>> http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=29569&forum=14
>
> These benchmarks aren't for linux, right?
>
>>
>> It would be interesting if someone could compare a binary compiled with
>> gcc 2.95 to 3.33 3.40 and or 4.4 for linux, on various systems even. To
>> see if the slowdown has any consistency.
>
> If you would like to run some linux benchmarks, I could build the latest
> kernel using several different compilers for you. I'd need a kernel config
> to suit your hardware though.
>
> But if you want to compare different compilers using benchmarks for a
> different operating system, I can't help with that. You may have more luck
> with that on the relevant mailing list or forum.
>
> Finn
>
>>
>> -Mike
>>
>>
>> 2009/9/14  <fthain@telegraphics.com.au>:
>> >
>> > On Sun, 13 Sep 2009, Maxim Kuvyrkov wrote:
>> >
>> >> fthain@telegraphics.com.au wrote:
>> >>
>> >> > On Sat, 5 Sep 2009, Maxim Kuvyrkov wrote:
>> >> >
>> >> > > Finn Thain wrote: ...
>> >> > >
>> >> > > > I understand that the current GCC (4.4) lacks the necessary
>> >> > > > patches, and 4.5 is still uncooked (and that's a scary prospect).
>> >> > > > Can someone confirm that this is the necessary patch for 4.4:
>> >> > > > http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01024.html
>> >> > > I think GCC 4.4 should be good enough.
>> >> >
>> >> > I tried patching 4.4.1 and the patch was rejected. It expects
>> >> > m68k_legitimize_address() to have been declared and defined, but that
>> >> > routine isn't in gcc-4.4.
>> >>
>> >> m68k.c:m68k_legitimize_address() was macro m68k.h:LEGITIMIZE_ADDRESS(),
>> >> you need to move the hunk to m68k.h.
>> >>
>> >
>> > Thanks for the tip.
>> >
>> > Here's a second cut. This one removes the m68k_tls_symbol_p() routine and
>> > inlines that logic in the LEGITIMIZE_ADDRESS macro (avoids a reference to
>> > m68k_tls_symbol_p() from explow.o). The TARGET_HAVE_TLS macro wasn't
>> > defined in explow.c so I changed it to HAVE_AS_TLS.
>> >
>> > It appears to work, but I won't be able to test any binary produced by
>> > this compiler for a week or so.
>> >
>> > Finn
>> >
>> >
>> > --- gcc-m68k-support-for-tls.patch      2009-09-14 15:11:39.893286532 +1000
>> > +++ gcc-m68k-support-for-tls-backport.patch     2009-09-14 15:11:34.563287784 +1000
>> > @@ -574,13 +574,7 @@
>> >
>> >  enum reg_class regno_reg_class[] =
>> >  {
>> > -@@ -143,11 +144,13 @@ static tree m68k_handle_fndecl_attribute
>> > - static void m68k_compute_frame_layout (void);
>> > - static bool m68k_save_reg (unsigned int regno, bool interrupt_handler);
>> > - static bool m68k_ok_for_sibcall_p (tree, tree);
>> > -+static bool m68k_tls_symbol_p (rtx);
>> > - static rtx m68k_legitimize_address (rtx, rtx, enum machine_mode);
>> > - static bool m68k_rtx_costs (rtx, int, int, int *, bool);
>> > +@@ -146,6 +147,7 @@ static tree m68k_handle_fndecl_attribute
>> >  #if M68K_HONOR_TARGET_STRICT_ALIGNMENT
>> >  static bool m68k_return_in_memory (const_tree, const_tree);
>> >  #endif
>> > @@ -613,16 +607,6 @@
>> >        && crtl->uses_pic_offset_table)
>> >      insn = emit_insn (gen_load_got (pic_offset_table_rtx));
>> >  }
>> > -@@ -1431,6 +1441,9 @@ m68k_legitimize_sibcall_address (rtx x)
>> > - rtx
>> > - m68k_legitimize_address (rtx x, rtx oldx, enum machine_mode mode)
>> > - {
>> > -+  if (m68k_tls_symbol_p (x))
>> > -+    return m68k_legitimize_tls_address (x);
>> > -+
>> > -   if (GET_CODE (x) == PLUS)
>> > -     {
>> > -       int ch = (x) != (oldx);
>> >  @@ -1849,7 +1862,7 @@ m68k_illegitimate_symbolic_constant_p (r
>> >          && !offset_within_block_p (base, INTVAL (offset)))
>> >        return true;
>> > @@ -957,7 +941,7 @@
>> >        return orig;
>> >
>> >        gcc_assert (reg);
>> > -@@ -2196,13 +2421,257 @@ legitimize_pic_address (rtx orig, enum m
>> > +@@ -2196,13 +2421,244 @@ legitimize_pic_address (rtx orig, enum m
>> >                                     base == reg ? 0 : reg);
>> >
>> >        if (GET_CODE (orig) == CONST_INT)
>> > @@ -1164,19 +1148,6 @@
>> >  +  return orig;
>> >  +}
>> >  +
>> > -+/* Return true if X is a TLS symbol.  */
>> > -+
>> > -+static bool
>> > -+m68k_tls_symbol_p (rtx x)
>> > -+{
>> > -+  if (!TARGET_HAVE_TLS)
>> > -+    return false;
>> > -+
>> > -+  if (GET_CODE (x) != SYMBOL_REF)
>> > -+    return false;
>> > -+
>> > -+  return SYMBOL_REF_TLS_MODEL (x) != 0;
>> > -+}
>> >  +
>> >  +/* Helper for m68k_tls_referenced_p.  */
>> >  +
>> > @@ -1414,6 +1385,18 @@
>> >
>> >  #define REG_OK_FOR_BASE_P(X) \
>> >    m68k_legitimate_base_reg_p (X, REG_STRICT_P)
>> > +@@ -777,7 +778,10 @@ __transfer_from_trampoline ()                                     \
>> > + #define COPY_ONCE(Y) if (!copied) { Y = copy_rtx (Y); copied = ch = 1; }
>> > + #define LEGITIMIZE_ADDRESS(X,OLDX,MODE,WIN)   \
>> > + { register int ch = (X) != (OLDX);                                    \
>> > +-  if (GET_CODE (X) == PLUS)                                           \
>> > ++  if (HAVE_AS_TLS && (GET_CODE (X) == SYMBOL_REF) &&                  \
>> > ++      (SYMBOL_REF_TLS_MODEL (X) != 0))                                        \
>> > ++    m68k_legitimize_tls_address (X);                                  \
>> > ++  else if (GET_CODE (X) == PLUS)                                      \
>> > +     { int copied = 0;                                                 \
>> > +       if (GET_CODE (XEXP (X, 0)) == MULT)                             \
>> > +       { COPY_ONCE (X); XEXP (X, 0) = force_operand (XEXP (X, 0), 0);} \
>> >  @@ -974,6 +975,9 @@ do { if (cc_prev_status.flags & CC_IN_68
>> >    assemble_name ((FILE), (NAME)),             \
>> >    fprintf ((FILE), ",%u\n", (int)(ROUNDED)))
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: benchmarks, was Re: toolchain

[Geert Uytterhoeven]

On Tue, Sep 22, 2009 at 16:51, mike <localgost@gmail.com> wrote:
>> These benchmarks aren't for linux, right?
> Nope, thats amiga c
> I see umisef made a mac version , but i cant see a link to it anywhere.
>
>
> For some reason, probably due to the way amigaos 3.9 has configured
> the hd i cant mount, or read SFS partitions from linux, so im dead in

Linux can't read SFS/PFS.

> Are there any other VM's i could use to install linux 68k?

ARAnyM?

> 2009/9/22 Finn Thain <fthain@telegraphics.com.au>:
>>
>>
>> On Tue, 22 Sep 2009, mike wrote:
>>
>>> Seems im not the only soul feeling the bloat
>>> http://news.cnet.com/8301-13505_3-10358024-16.html
>>>
>>> I havent seen any 68k linux benchmarks for this yet
>>> http://cshandley.co.uk/temp/membench/
>>> http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=29569&forum=14
>>
>> These benchmarks aren't for linux, right?
>>
>>>
>>> It would be interesting if someone could compare a binary compiled with
>>> gcc 2.95 to 3.33 3.40 and or 4.4 for linux, on various systems even. To
>>> see if the slowdown has any consistency.
>>
>> If you would like to run some linux benchmarks, I could build the latest
>> kernel using several different compilers for you. I'd need a kernel config
>> to suit your hardware though.
>>
>> But if you want to compare different compilers using benchmarks for a
>> different operating system, I can't help with that. You may have more luck
>> with that on the relevant mailing list or forum.
>>
>> Finn
>>
>>>
>>> -Mike
>>>
>>>
>>> 2009/9/14  <fthain@telegraphics.com.au>:
>>> >
>>> > On Sun, 13 Sep 2009, Maxim Kuvyrkov wrote:
>>> >
>>> >> fthain@telegraphics.com.au wrote:
>>> >>
>>> >> > On Sat, 5 Sep 2009, Maxim Kuvyrkov wrote:
>>> >> >
>>> >> > > Finn Thain wrote: ...
>>> >> > >
>>> >> > > > I understand that the current GCC (4.4) lacks the necessary
>>> >> > > > patches, and 4.5 is still uncooked (and that's a scary prospect).
>>> >> > > > Can someone confirm that this is the necessary patch for 4.4:
>>> >> > > > http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01024.html
>>> >> > > I think GCC 4.4 should be good enough.
>>> >> >
>>> >> > I tried patching 4.4.1 and the patch was rejected. It expects
>>> >> > m68k_legitimize_address() to have been declared and defined, but that
>>> >> > routine isn't in gcc-4.4.
>>> >>
>>> >> m68k.c:m68k_legitimize_address() was macro m68k.h:LEGITIMIZE_ADDRESS(),
>>> >> you need to move the hunk to m68k.h.
>>> >>
>>> >
>>> > Thanks for the tip.
>>> >
>>> > Here's a second cut. This one removes the m68k_tls_symbol_p() routine and
>>> > inlines that logic in the LEGITIMIZE_ADDRESS macro (avoids a reference to
>>> > m68k_tls_symbol_p() from explow.o). The TARGET_HAVE_TLS macro wasn't
>>> > defined in explow.c so I changed it to HAVE_AS_TLS.
>>> >
>>> > It appears to work, but I won't be able to test any binary produced by
>>> > this compiler for a week or so.
>>> >
>>> > Finn
>>> >
>>> >
>>> > --- gcc-m68k-support-for-tls.patch      2009-09-14 15:11:39.893286532 +1000
>>> > +++ gcc-m68k-support-for-tls-backport.patch     2009-09-14 15:11:34.563287784 +1000
>>> > @@ -574,13 +574,7 @@
>>> >
>>> >  enum reg_class regno_reg_class[] =
>>> >  {
>>> > -@@ -143,11 +144,13 @@ static tree m68k_handle_fndecl_attribute
>>> > - static void m68k_compute_frame_layout (void);
>>> > - static bool m68k_save_reg (unsigned int regno, bool interrupt_handler);
>>> > - static bool m68k_ok_for_sibcall_p (tree, tree);
>>> > -+static bool m68k_tls_symbol_p (rtx);
>>> > - static rtx m68k_legitimize_address (rtx, rtx, enum machine_mode);
>>> > - static bool m68k_rtx_costs (rtx, int, int, int *, bool);
>>> > +@@ -146,6 +147,7 @@ static tree m68k_handle_fndecl_attribute
>>> >  #if M68K_HONOR_TARGET_STRICT_ALIGNMENT
>>> >  static bool m68k_return_in_memory (const_tree, const_tree);
>>> >  #endif
>>> > @@ -613,16 +607,6 @@
>>> >        && crtl->uses_pic_offset_table)
>>> >      insn = emit_insn (gen_load_got (pic_offset_table_rtx));
>>> >  }
>>> > -@@ -1431,6 +1441,9 @@ m68k_legitimize_sibcall_address (rtx x)
>>> > - rtx
>>> > - m68k_legitimize_address (rtx x, rtx oldx, enum machine_mode mode)
>>> > - {
>>> > -+  if (m68k_tls_symbol_p (x))
>>> > -+    return m68k_legitimize_tls_address (x);
>>> > -+
>>> > -   if (GET_CODE (x) == PLUS)
>>> > -     {
>>> > -       int ch = (x) != (oldx);
>>> >  @@ -1849,7 +1862,7 @@ m68k_illegitimate_symbolic_constant_p (r
>>> >          && !offset_within_block_p (base, INTVAL (offset)))
>>> >        return true;
>>> > @@ -957,7 +941,7 @@
>>> >        return orig;
>>> >
>>> >        gcc_assert (reg);
>>> > -@@ -2196,13 +2421,257 @@ legitimize_pic_address (rtx orig, enum m
>>> > +@@ -2196,13 +2421,244 @@ legitimize_pic_address (rtx orig, enum m
>>> >                                     base == reg ? 0 : reg);
>>> >
>>> >        if (GET_CODE (orig) == CONST_INT)
>>> > @@ -1164,19 +1148,6 @@
>>> >  +  return orig;
>>> >  +}
>>> >  +
>>> > -+/* Return true if X is a TLS symbol.  */
>>> > -+
>>> > -+static bool
>>> > -+m68k_tls_symbol_p (rtx x)
>>> > -+{
>>> > -+  if (!TARGET_HAVE_TLS)
>>> > -+    return false;
>>> > -+
>>> > -+  if (GET_CODE (x) != SYMBOL_REF)
>>> > -+    return false;
>>> > -+
>>> > -+  return SYMBOL_REF_TLS_MODEL (x) != 0;
>>> > -+}
>>> >  +
>>> >  +/* Helper for m68k_tls_referenced_p.  */
>>> >  +
>>> > @@ -1414,6 +1385,18 @@
>>> >
>>> >  #define REG_OK_FOR_BASE_P(X) \
>>> >    m68k_legitimate_base_reg_p (X, REG_STRICT_P)
>>> > +@@ -777,7 +778,10 @@ __transfer_from_trampoline ()                                     \
>>> > + #define COPY_ONCE(Y) if (!copied) { Y = copy_rtx (Y); copied = ch = 1; }
>>> > + #define LEGITIMIZE_ADDRESS(X,OLDX,MODE,WIN)   \
>>> > + { register int ch = (X) != (OLDX);                                    \
>>> > +-  if (GET_CODE (X) == PLUS)                                           \
>>> > ++  if (HAVE_AS_TLS && (GET_CODE (X) == SYMBOL_REF) &&                  \
>>> > ++      (SYMBOL_REF_TLS_MODEL (X) != 0))                                        \
>>> > ++    m68k_legitimize_tls_address (X);                                  \
>>> > ++  else if (GET_CODE (X) == PLUS)                                      \
>>> > +     { int copied = 0;                                                 \
>>> > +       if (GET_CODE (XEXP (X, 0)) == MULT)                             \
>>> > +       { COPY_ONCE (X); XEXP (X, 0) = force_operand (XEXP (X, 0), 0);} \
>>> >  @@ -974,6 +975,9 @@ do { if (cc_prev_status.flags & CC_IN_68
>>> >    assemble_name ((FILE), (NAME)),             \
>>> >    fprintf ((FILE), ",%u\n", (int)(ROUNDED)))
>>> > --
>>> > To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
>>> > the body of a message to majordomo@vger.kernel.org
>>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> >
>>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: toolchain, was Re: bogl: don't know screen type 1

[mike]

Ok, i've nearly finished my manual install of 3.1r8...
I've got two problems, im missing
/lib/modules/2.4.27-amiga/modules.dep ( does anyone have it handy? )

And a "passwd: Authentication token manipulation error"
I've checked the perms of /etc/shadow they are shadow root and correct
rw. so is passwd

And i can so far only boot into single user mode. But that will work for now.

-Mike

2009/9/22 mike <localgost@gmail.com>:
> Seems im not the only soul feeling the bloat
> http://news.cnet.com/8301-13505_3-10358024-16.html
>
> I havent seen any 68k linux benchmarks for this yet
> http://cshandley.co.uk/temp/membench/
> http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=29569&forum=14
>
> It would be interesting if someone could compare a binary compiled
> with gcc 2.95 to 3.33 3.40 and or 4.4 for linux, on various systems
> even. To see if the slowdown has any consistency.
>
> -Mike
>
>
> 2009/9/14  <fthain@telegraphics.com.au>:
>>
>> On Sun, 13 Sep 2009, Maxim Kuvyrkov wrote:
>>
>>> fthain@telegraphics.com.au wrote:
>>>
>>> > On Sat, 5 Sep 2009, Maxim Kuvyrkov wrote:
>>> >
>>> > > Finn Thain wrote: ...
>>> > >
>>> > > > I understand that the current GCC (4.4) lacks the necessary
>>> > > > patches, and 4.5 is still uncooked (and that's a scary prospect).
>>> > > > Can someone confirm that this is the necessary patch for 4.4:
>>> > > > http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01024.html
>>> > > I think GCC 4.4 should be good enough.
>>> >
>>> > I tried patching 4.4.1 and the patch was rejected. It expects
>>> > m68k_legitimize_address() to have been declared and defined, but that
>>> > routine isn't in gcc-4.4.
>>>
>>> m68k.c:m68k_legitimize_address() was macro m68k.h:LEGITIMIZE_ADDRESS(),
>>> you need to move the hunk to m68k.h.
>>>
>>
>> Thanks for the tip.
>>
>> Here's a second cut. This one removes the m68k_tls_symbol_p() routine and
>> inlines that logic in the LEGITIMIZE_ADDRESS macro (avoids a reference to
>> m68k_tls_symbol_p() from explow.o). The TARGET_HAVE_TLS macro wasn't
>> defined in explow.c so I changed it to HAVE_AS_TLS.
>>
>> It appears to work, but I won't be able to test any binary produced by
>> this compiler for a week or so.
>>
>> Finn
>>
>>
>> --- gcc-m68k-support-for-tls.patch      2009-09-14 15:11:39.893286532 +1000
>> +++ gcc-m68k-support-for-tls-backport.patch     2009-09-14 15:11:34.563287784 +1000
>> @@ -574,13 +574,7 @@
>>
>>  enum reg_class regno_reg_class[] =
>>  {
>> -@@ -143,11 +144,13 @@ static tree m68k_handle_fndecl_attribute
>> - static void m68k_compute_frame_layout (void);
>> - static bool m68k_save_reg (unsigned int regno, bool interrupt_handler);
>> - static bool m68k_ok_for_sibcall_p (tree, tree);
>> -+static bool m68k_tls_symbol_p (rtx);
>> - static rtx m68k_legitimize_address (rtx, rtx, enum machine_mode);
>> - static bool m68k_rtx_costs (rtx, int, int, int *, bool);
>> +@@ -146,6 +147,7 @@ static tree m68k_handle_fndecl_attribute
>>  #if M68K_HONOR_TARGET_STRICT_ALIGNMENT
>>  static bool m68k_return_in_memory (const_tree, const_tree);
>>  #endif
>> @@ -613,16 +607,6 @@
>>        && crtl->uses_pic_offset_table)
>>      insn = emit_insn (gen_load_got (pic_offset_table_rtx));
>>  }
>> -@@ -1431,6 +1441,9 @@ m68k_legitimize_sibcall_address (rtx x)
>> - rtx
>> - m68k_legitimize_address (rtx x, rtx oldx, enum machine_mode mode)
>> - {
>> -+  if (m68k_tls_symbol_p (x))
>> -+    return m68k_legitimize_tls_address (x);
>> -+
>> -   if (GET_CODE (x) == PLUS)
>> -     {
>> -       int ch = (x) != (oldx);
>>  @@ -1849,7 +1862,7 @@ m68k_illegitimate_symbolic_constant_p (r
>>          && !offset_within_block_p (base, INTVAL (offset)))
>>        return true;
>> @@ -957,7 +941,7 @@
>>        return orig;
>>
>>        gcc_assert (reg);
>> -@@ -2196,13 +2421,257 @@ legitimize_pic_address (rtx orig, enum m
>> +@@ -2196,13 +2421,244 @@ legitimize_pic_address (rtx orig, enum m
>>                                     base == reg ? 0 : reg);
>>
>>        if (GET_CODE (orig) == CONST_INT)
>> @@ -1164,19 +1148,6 @@
>>  +  return orig;
>>  +}
>>  +
>> -+/* Return true if X is a TLS symbol.  */
>> -+
>> -+static bool
>> -+m68k_tls_symbol_p (rtx x)
>> -+{
>> -+  if (!TARGET_HAVE_TLS)
>> -+    return false;
>> -+
>> -+  if (GET_CODE (x) != SYMBOL_REF)
>> -+    return false;
>> -+
>> -+  return SYMBOL_REF_TLS_MODEL (x) != 0;
>> -+}
>>  +
>>  +/* Helper for m68k_tls_referenced_p.  */
>>  +
>> @@ -1414,6 +1385,18 @@
>>
>>  #define REG_OK_FOR_BASE_P(X) \
>>    m68k_legitimate_base_reg_p (X, REG_STRICT_P)
>> +@@ -777,7 +778,10 @@ __transfer_from_trampoline ()                                     \
>> + #define COPY_ONCE(Y) if (!copied) { Y = copy_rtx (Y); copied = ch = 1; }
>> + #define LEGITIMIZE_ADDRESS(X,OLDX,MODE,WIN)   \
>> + { register int ch = (X) != (OLDX);                                    \
>> +-  if (GET_CODE (X) == PLUS)                                           \
>> ++  if (HAVE_AS_TLS && (GET_CODE (X) == SYMBOL_REF) &&                  \
>> ++      (SYMBOL_REF_TLS_MODEL (X) != 0))                                        \
>> ++    m68k_legitimize_tls_address (X);                                  \
>> ++  else if (GET_CODE (X) == PLUS)                                      \
>> +     { int copied = 0;                                                 \
>> +       if (GET_CODE (XEXP (X, 0)) == MULT)                             \
>> +       { COPY_ONCE (X); XEXP (X, 0) = force_operand (XEXP (X, 0), 0);} \
>>  @@ -974,6 +975,9 @@ do { if (cc_prev_status.flags & CC_IN_68
>>    assemble_name ((FILE), (NAME)),             \
>>    fprintf ((FILE), ",%u\n", (int)(ROUNDED)))
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: debian installation

[Finn Thain]

On Mon, 28 Sep 2009, mike wrote:

> Ok, i've nearly finished my manual install of 3.1r8...
> I've got two problems, im missing
> /lib/modules/2.4.27-amiga/modules.dep ( does anyone have it handy? )

It is generated using the "depmod -ae" command (I think those are the 
correct arguments...) Normally it is generated at boot time, but I guess 
it is not run if you stop at the single user run level.

> 
> And a "passwd: Authentication token manipulation error"

Sounds familiar but I don't recall what the cause was. Maybe google it.

Finn

> I've checked the perms of /etc/shadow they are shadow root and correct
> rw. so is passwd
> 
> And i can so far only boot into single user mode. But that will work for now.
> 
> -Mike

Re: debian installation

[mike]

Thanks Finn

depmod -ae did it.

With a bit of luck i can get a dist-upgrade if i can get slip working
and sharing between my box here.. Think i'll upload this install to
aminet so i dont loose it when im done with a detailed guide on how to
configure etc...... This is the most complicated install i've ever
done

-Mike

2009/9/28 Finn Thain <fthain@telegraphics.com.au>:
>
>
> On Mon, 28 Sep 2009, mike wrote:
>
>> Ok, i've nearly finished my manual install of 3.1r8...
>> I've got two problems, im missing
>> /lib/modules/2.4.27-amiga/modules.dep ( does anyone have it handy? )
>
> It is generated using the "depmod -ae" command (I think those are the
> correct arguments...) Normally it is generated at boot time, but I guess
> it is not run if you stop at the single user run level.
>
>>
>> And a "passwd: Authentication token manipulation error"
>
> Sounds familiar but I don't recall what the cause was. Maybe google it.
>
> Finn
>
>> I've checked the perms of /etc/shadow they are shadow root and correct
>> rw. so is passwd
>>
>> And i can so far only boot into single user mode. But that will work for now.
>>
>> -Mike
>

Re: debian installation

[mike]

Hm,

Is there a problem with slip?
When i do ifup sl0 i get siocsifflags no such file or directory

-Mike

2009/9/28 mike <localgost@gmail.com>:
> Thanks Finn
>
> depmod -ae did it.
>
> With a bit of luck i can get a dist-upgrade if i can get slip working
> and sharing between my box here.. Think i'll upload this install to
> aminet so i dont loose it when im done with a detailed guide on how to
> configure etc...... This is the most complicated install i've ever
> done
>
> -Mike
>
> 2009/9/28 Finn Thain <fthain@telegraphics.com.au>:
>>
>>
>> On Mon, 28 Sep 2009, mike wrote:
>>
>>> Ok, i've nearly finished my manual install of 3.1r8...
>>> I've got two problems, im missing
>>> /lib/modules/2.4.27-amiga/modules.dep ( does anyone have it handy? )
>>
>> It is generated using the "depmod -ae" command (I think those are the
>> correct arguments...) Normally it is generated at boot time, but I guess
>> it is not run if you stop at the single user run level.
>>
>>>
>>> And a "passwd: Authentication token manipulation error"
>>
>> Sounds familiar but I don't recall what the cause was. Maybe google it.
>>
>> Finn
>>
>>> I've checked the perms of /etc/shadow they are shadow root and correct
>>> rw. so is passwd
>>>
>>> And i can so far only boot into single user mode. But that will work for now.
>>>
>>> -Mike
>>
>

Re: debian installation

[Rolf Anders]

[-- Attachment #1: Type: text/plain, Size: 388 bytes --]

On Tue, Sep 29, 2009 at 11:45:27AM +0200, mike wrote:
> Is there a problem with slip?
> When i do ifup sl0 i get siocsifflags no such file or directory

You probably need to run slattach first, which is in package net-tools.
You also need kernel-support for slip (CONFIG_SLIP).

Greetings,

Rolf

-- 
gpg public key: http://www-2.physik.uni-augsburg.de/~andersro/gpg-key.txt

[-- Attachment #2: Type: application/pgp-signature, Size: 183 bytes --]