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@...>:
> > 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@...>:
> >> 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@...>:
> >>> 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@...>
> >>>
> >>
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@...
> 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@...>


--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Mike-183]

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

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

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Mike-183]

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

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

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Maxim Kuvyrkov-2]

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


--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Mike-183]

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

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

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[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


--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

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


--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Mike-183]

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¬e=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@...>:

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

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Mike-183]

*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@...>:

> 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¬e=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@...>:
>> 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@...>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
>> the body of a message to majordomo@...
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[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, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ingo Jürgensmann-3]

On Fri, 4 Sep 2009 20:08:30 -0500, Stephen R Marenka <stephen@...>
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


--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Maxim Kuvyrkov-2]

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, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Mike-183]

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

> 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@...
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[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@...
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[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


--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[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


--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[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


--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

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


--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[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


--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Kolbjørn Barmen-3]

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


--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...