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
>

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
> 

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

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

[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

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

[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: 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 --]

Toolchain

[Virgilia Eigner]

[-- Attachment #1: Type: text/html, Size: 1027 bytes --]

Toolchain

[Michael Gloff]

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

Is there a reason why the toolchain cannot be built with a machine name
that contains capital letters? Seems weird, everything else builds fine,
but meta-toolchain fails complaining about caps.

Thanks,

Michael Gloff

[-- Attachment #2: Type: text/html, Size: 291 bytes --]

Re: Toolchain

[Paul Eggleton]

Hi Michael,

On Sunday 02 March 2014 19:58:41 Michael Gloff wrote:
> Is there a reason why the toolchain cannot be built with a machine name
> that contains capital letters? Seems weird, everything else builds fine,
> but meta-toolchain fails complaining about caps.

Although machine names are traditionally all lower case in our build system, 
there's no deliberate restriction in place that enforces this.

Would you be able to provide more details, such as the version of the build 
system you are using, the exact capital letters you used in the machine name, 
and the error you received? 

Thanks,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Toolchain

[Michael Gloff]

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

Paul,
The error is below. Machine name: PMX-090T. This is on dora 1.5.1

ERROR: Function failed: opkg-build execution failed
ERROR: Logfile of failure stored in:
/opt/oe/build/tmp/work/i686-nativesdk-emacsdk-linux/meta-environment-PMX-090T/1.0-r8/temp/log.do_package_write_ipk.15358
Log data follows:
| DEBUG: Executing python function sstate_task_prefunc
| DEBUG: Python function sstate_task_prefunc finished
| DEBUG: Executing python function do_package_write_ipk
| DEBUG: Executing python function read_subpackage_metadata
| DEBUG: Python function read_subpackage_metadata finished
| DEBUG: Executing python function do_package_ipk
| meta-environment-PMX-090T
| *** Error: Package name  contains illegal characters, (other than
[a-z0-9.+-])
|
| opkg-build: Please fix the above errors and try again.
| DEBUG: Python function do_package_ipk finished
| DEBUG: Python function do_package_write_ipk finished
| ERROR: Function failed: opkg-build execution failed
ERROR: Task 788 (/opt/oe/recipes/poky/meta/recipes-core/meta/
meta-environment.bb, do_package_write_ipk) failed with exit code '1'

Thanks,

Michael Gloff



On Mon, Mar 3, 2014 at 12:52 PM, Paul Eggleton <
paul.eggleton@linux.intel.com> wrote:

> Hi Michael,
>
> On Sunday 02 March 2014 19:58:41 Michael Gloff wrote:
> > Is there a reason why the toolchain cannot be built with a machine name
> > that contains capital letters? Seems weird, everything else builds fine,
> > but meta-toolchain fails complaining about caps.
>
> Although machine names are traditionally all lower case in our build
> system,
> there's no deliberate restriction in place that enforces this.
>
> Would you be able to provide more details, such as the version of the build
> system you are using, the exact capital letters you used in the machine
> name,
> and the error you received?
>
> Thanks,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>

[-- Attachment #2: Type: text/html, Size: 2540 bytes --]

Re: Toolchain

[Paul Eggleton]

On Wednesday 05 March 2014 11:00:31 Michael Gloff wrote:
> On Mon, Mar 3, 2014 at 12:52 PM, Paul Eggleton 
> <paul.eggleton@linux.intel.com> wrote:
> > On Sunday 02 March 2014 19:58:41 Michael Gloff wrote:
> > > Is there a reason why the toolchain cannot be built with a machine name
> > > that contains capital letters? Seems weird, everything else builds fine,
> > > but meta-toolchain fails complaining about caps.
> > 
> > Although machine names are traditionally all lower case in our build
> > system, there's no deliberate restriction in place that enforces this.
> > 
> > Would you be able to provide more details, such as the version of the
> > build system you are using, the exact capital letters you used in the
> > machine name, and the error you received?
>
> The error is below. Machine name: PMX-090T. This is on dora 1.5.1
> 
> ERROR: Function failed: opkg-build execution failed
> ERROR: Logfile of failure stored in:
> /opt/oe/build/tmp/work/i686-nativesdk-emacsdk-linux/meta-environment-PMX-090
> T/1.0-r8/temp/log.do_package_write_ipk.15358
> Log data follows:
> | DEBUG: Executing python function sstate_task_prefunc
> | DEBUG: Python function sstate_task_prefunc finished
> | DEBUG: Executing python function do_package_write_ipk
> | DEBUG: Executing python function read_subpackage_metadata
> | DEBUG: Python function read_subpackage_metadata finished
> | DEBUG: Executing python function do_package_ipk
> | meta-environment-PMX-090T
> | *** Error: Package name  contains illegal characters, (other than
> [a-z0-9.+-])

Perhaps I spoke too soon. There might not be a direct restriction on machine 
names; but opkg does restrict characters allowed in package names, and for 
meta-environment the machine name ends up as part of the package name. You 
could probably hack around it if you felt the need to, but the simplest thing 
would be to just change the machine name to be all lower-case.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Toolchain

[Michael Gloff]

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

Thanks,
Not a big deal at all to build the toolchain with a different machine name.
Just curious.

Michael Gloff


On Wed, Mar 5, 2014 at 11:45 AM, Paul Eggleton <
paul.eggleton@linux.intel.com> wrote:

> On Wednesday 05 March 2014 11:00:31 Michael Gloff wrote:
> > On Mon, Mar 3, 2014 at 12:52 PM, Paul Eggleton
> > <paul.eggleton@linux.intel.com> wrote:
> > > On Sunday 02 March 2014 19:58:41 Michael Gloff wrote:
> > > > Is there a reason why the toolchain cannot be built with a machine
> name
> > > > that contains capital letters? Seems weird, everything else builds
> fine,
> > > > but meta-toolchain fails complaining about caps.
> > >
> > > Although machine names are traditionally all lower case in our build
> > > system, there's no deliberate restriction in place that enforces this.
> > >
> > > Would you be able to provide more details, such as the version of the
> > > build system you are using, the exact capital letters you used in the
> > > machine name, and the error you received?
> >
> > The error is below. Machine name: PMX-090T. This is on dora 1.5.1
> >
> > ERROR: Function failed: opkg-build execution failed
> > ERROR: Logfile of failure stored in:
> >
> /opt/oe/build/tmp/work/i686-nativesdk-emacsdk-linux/meta-environment-PMX-090
> > T/1.0-r8/temp/log.do_package_write_ipk.15358
> > Log data follows:
> > | DEBUG: Executing python function sstate_task_prefunc
> > | DEBUG: Python function sstate_task_prefunc finished
> > | DEBUG: Executing python function do_package_write_ipk
> > | DEBUG: Executing python function read_subpackage_metadata
> > | DEBUG: Python function read_subpackage_metadata finished
> > | DEBUG: Executing python function do_package_ipk
> > | meta-environment-PMX-090T
> > | *** Error: Package name  contains illegal characters, (other than
> > [a-z0-9.+-])
>
> Perhaps I spoke too soon. There might not be a direct restriction on
> machine
> names; but opkg does restrict characters allowed in package names, and for
> meta-environment the machine name ends up as part of the package name. You
> could probably hack around it if you felt the need to, but the simplest
> thing
> would be to just change the machine name to be all lower-case.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>

[-- Attachment #2: Type: text/html, Size: 2987 bytes --]

Re: Toolchain

[Khem Raj]

On Wed, Mar 5, 2014 at 9:00 AM, Michael Gloff <mgloff@emacinc.com> wrote:
> | *** Error: Package name  contains illegal characters, (other than
> [a-z0-9.+-])

hmm meta-environment-PMX-090T is a package name and
thats limitation of opkg backend, if you are too tied to

Re: Toolchain

[Paul Barker]

On 5 March 2014 21:14, Khem Raj <raj.khem@gmail.com> wrote:
> On Wed, Mar 5, 2014 at 9:00 AM, Michael Gloff <mgloff@emacinc.com> wrote:
>> | *** Error: Package name  contains illegal characters, (other than
>> [a-z0-9.+-])
>
> hmm meta-environment-PMX-090T is a package name and
> thats limitation of opkg backend, if you are too tied to

opkg itself doesn't seem to have this limitation, I just created and installed a
test package named 'A' perfectly fine.

The Debian policy says:
    Package names (both source and binary, see Package, Section 5.6.7) must
    consist only of lower case letters (a-z), digits (0-9), plus (+) and minus
    (-) signs, and periods (.). They must be at least two characters long and
    must start with an alphanumeric character.

So I think the restriction is there to keep generated packages
compatible with dpkg-deb.

We could consider removing the restriction if that compatibility isn't
necessary.

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

toolchain

[Edward Vidal]

[-- Attachment #1.1: Type: text/plain, Size: 941 bytes --]

Hello all,
I am currently working with the zedboard using a rootfs generated with a
dylan branch of yocto (gsl, gnuplot, gnuradio, java, vlc, v4l-utils, and
openCV with C920 camera).  My zImage and devicetree.dtb were built with
yocto sdk.  My BOOT.BIN (FSBL system.bit and u-boot) were built with 14.4
of Xilinx Tools.  This requires dual booting a CentOS 6.4 x86_64 (Xilinx
Tools) and Fedora19 x86_64 (Yocto).  I have not been able to run Yocto on
CentOS since the need for higher version of python.

Is it possible to generate a BOOT.BIN with the files generated with
Yocto?

This requires 2 toolchains.  I was checking the difference between the 2
see the attached files.
Should the difference between the toolchains be of concern going forward?

My Xilinx tools are node locked and I can only use on a single system.
Is there a method to run Yocto on CentOS6.4 x86_64?
Any and all help will be appreciated.

Thanks

[-- Attachment #1.2: Type: text/html, Size: 996 bytes --]

[-- Attachment #2: poky-toolchain.txt --]
[-- Type: text/plain, Size: 2953 bytes --]

arm-poky-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-poky-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/lto-wrapper
Target: arm-poky-linux-gnueabi
Configured with: /home/vidal/POKY/dylan_build/poky/build/tmp/work-shared/gcc-4.7.2-r20/gcc-4.7.2/configure 
--build=x86_64-linux 
--host=x86_64-pokysdk-linux 
--target=arm-poky-linux-gnueabi 
--prefix=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr 
--exec_prefix=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr 
--bindir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi 
--sbindir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi 
--libexecdir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi 
--datadir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr/share 
--sysconfdir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/etc 
--sharedstatedir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/com 
--localstatedir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/var 
--libdir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr/lib/armv7a-vfp-neon-poky-linux-gnueabi 
--includedir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr/include 
--oldincludedir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr/include 
--infodir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr/share/info 
--mandir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr/share/man 
--disable-silent-rules 
--disable-dependency-tracking 
--with-libtool-sysroot=/home/vidal/POKY/dylan_build/poky/build/tmp/sysroots/x86_64-nativesdk-pokysdk-linux 
--with-gnu-ld 
--enable-shared 
--enable-languages=c,c++ 
--enable-threads=posix 
--enable-multilib 
--enable-c99 
--enable-long-long 
--enable-symvers=gnu 
--enable-libstdcxx-pch 
--program-prefix=arm-poky-linux-gnueabi- 
--without-local-prefix 
--enable-target-optspace 
--enable-lto 
--enable-libssp 
--disable-bootstrap 
--disable-libmudflap 
--with-system-zlib 
--with-linker-hash-style=gnu 
--enable-linker-build-id 
--with-ppl=no 
--with-cloog=no 
--enable-checking=release 
--enable-cheaders=c_global 
--with-gxx-include-dir=/opt/poky/1.4.3/sysroots/armv7a-vfp-neon-poky-linux-gnueabi/usr/include/c++ 
--with-build-time-tools=/home/vidal/POKY/dylan_build/poky/build/tmp/sysroots/x86_64-linux/usr/arm-poky-linux-gnueabi/bin 
--with-sysroot=/opt/poky/1.4.3/sysroots/armv7a-vfp-neon-poky-linux-gnueabi 
--with-build-sysroot=/home/vidal/POKY/dylan_build/poky/build/tmp/sysroots/zedboard 
--disable-libunwind-exceptions 
--disable-libssp 
--disable-libgomp 
--disable-libmudflap 
--with-mpfr=/home/vidal/POKY/dylan_build/poky/build/tmp/sysroots/x86_64-nativesdk-pokysdk-linux 
--with-mpc=/home/vidal/POKY/dylan_build/poky/build/tmp/sysroots/x86_64-nativesdk-pokysdk-linux 
--enable-nls
Thread model: posix
gcc version 4.7.2 (GCC)

[-- Attachment #3: xilinx-toolchain.txt --]
[-- Type: text/plain, Size: 2986 bytes --]

arm-xilinx-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-xilinx-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/opt/Xilinx/14.4/SDK/SDK/gnu/arm/lin/bin/../libexec/gcc/arm-xilinx-linux-gnueabi/4.6.3/lto-wrapper
Target: arm-xilinx-linux-gnueabi
Configured with: /scratch/janisjo/2012.03-xilinx-linux-lite/src/gcc-4.6-2012.03/configure 
--build=i686-pc-linux-gnu 
--host=i686-pc-linux-gnu 
--target=arm-xilinx-linux-gnueabi 
--enable-threads 
--disable-libmudflap 
--disable-libssp 
--disable-libstdcxx-pch 
--enable-extra-sgxxlite-multilibs 
--with-arch=armv5te 
--with-cpu=cortex-a9 
--with-float=softfp 
--with-fpu=neon-fp16 
--disable-multilib 
--with-gnu-as 
--with-gnu-ld 
--with-specs='%{save-temps: -fverbose-asm} %{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables} -D__CS_SOURCERYGXX_MAJ__=2012 -D__CS_SOURCERYGXX_MIN__=3 -D__CS_SOURCERYGXX_REV__=79 %{O2:%{!fno-remove-local-statics: -fremove-local-statics}} %{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics: -fremove-local-statics}}}' 
--enable-languages=c,c++ 
--enable-shared 
--enable-lto 
--enable-symvers=gnu 
--enable-__cxa_atexit 
--with-pkgversion='Sourcery CodeBench Lite 2012.03-79' 
--with-bugurl=https://support.codesourcery.com/GNUToolchain/ 
--disable-nls 
--prefix=/opt/codesourcery 
--with-sysroot=/opt/codesourcery/arm-xilinx-linux-gnueabi/libc 
--with-build-sysroot=/scratch/janisjo/2012.03-xilinx-linux-lite/install/arm-xilinx-linux-gnueabi/libc 
--with-gmp=/scratch/janisjo/2012.03-xilinx-linux-lite/obj/pkg-2012.03-79-arm-xilinx-linux-gnueabi/xilinx-2012.03-79-arm-xilinx-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr 
--with-mpfr=/scratch/janisjo/2012.03-xilinx-linux-lite/obj/pkg-2012.03-79-arm-xilinx-linux-gnueabi/xilinx-2012.03-79-arm-xilinx-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr 
--with-mpc=/scratch/janisjo/2012.03-xilinx-linux-lite/obj/pkg-2012.03-79-arm-xilinx-linux-gnueabi/xilinx-2012.03-79-arm-xilinx-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr 
--with-ppl=/scratch/janisjo/2012.03-xilinx-linux-lite/obj/pkg-2012.03-79-arm-xilinx-linux-gnueabi/xilinx-2012.03-79-arm-xilinx-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr 
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' 
--with-cloog=/scratch/janisjo/2012.03-xilinx-linux-lite/obj/pkg-2012.03-79-arm-xilinx-linux-gnueabi/xilinx-2012.03-79-arm-xilinx-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr 
--with-libelf=/scratch/janisjo/2012.03-xilinx-linux-lite/obj/pkg-2012.03-79-arm-xilinx-linux-gnueabi/xilinx-2012.03-79-arm-xilinx-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr 
--disable-libgomp 
--disable-libitm 
--enable-poison-system-directories 
--with-build-time-tools=/scratch/janisjo/2012.03-xilinx-linux-lite/install/arm-xilinx-linux-gnueabi/bin 
--with-build-time-tools=/scratch/janisjo/2012.03-xilinx-linux-lite/install/arm-xilinx-linux-gnueabi/bin
Thread model: posix
gcc version 4.6.3 (Sourcery CodeBench Lite 2012.03-79)

Re: toolchain

[Philip Balister]

Please post meta-xilinx questions to the meta-xilinx list.

On 01/03/2014 11:46 AM, Edward Vidal wrote:
> Hello all,
> I am currently working with the zedboard using a rootfs generated with a
> dylan branch of yocto (gsl, gnuplot, gnuradio, java, vlc, v4l-utils, and
> openCV with C920 camera).  My zImage and devicetree.dtb were built with
> yocto sdk.  My BOOT.BIN (FSBL system.bit and u-boot) were built with 14.4
> of Xilinx Tools.  This requires dual booting a CentOS 6.4 x86_64 (Xilinx
> Tools) and Fedora19 x86_64 (Yocto).  I have not been able to run Yocto on
> CentOS since the need for higher version of python.
> 
> Is it possible to generate a BOOT.BIN with the files generated with
> Yocto?

See:

https://github.com/balister/meta-xilinx/tree/working-branch/recipes-bsp/u-boot

Basically, I use a pre-compiled fsbl.elf. This only needs the bootgen
command (from ISE) in the path. U-boot builds fine with the toolchain
built in OE. (Also, you can build the fsbl with an OE toolchain last
time I checked.

Philip

> 
> This requires 2 toolchains.  I was checking the difference between the 2
> see the attached files.
> Should the difference between the toolchains be of concern going forward?
> 
> My Xilinx tools are node locked and I can only use on a single system.
> Is there a method to run Yocto on CentOS6.4 x86_64?
> Any and all help will be appreciated.
> 
> Thanks
> 
> 
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> 

Re: toolchain

[Gary Thomas]

On 2014-01-03 15:48, Philip Balister wrote:
> Please post meta-xilinx questions to the meta-xilinx list.
>
> On 01/03/2014 11:46 AM, Edward Vidal wrote:
>> Hello all,
>> I am currently working with the zedboard using a rootfs generated with a
>> dylan branch of yocto (gsl, gnuplot, gnuradio, java, vlc, v4l-utils, and
>> openCV with C920 camera).  My zImage and devicetree.dtb were built with
>> yocto sdk.  My BOOT.BIN (FSBL system.bit and u-boot) were built with 14.4
>> of Xilinx Tools.  This requires dual booting a CentOS 6.4 x86_64 (Xilinx
>> Tools) and Fedora19 x86_64 (Yocto).  I have not been able to run Yocto on
>> CentOS since the need for higher version of python.
>>
>> Is it possible to generate a BOOT.BIN with the files generated with
>> Yocto?
>
> See:
>
> https://github.com/balister/meta-xilinx/tree/working-branch/recipes-bsp/u-boot
>
> Basically, I use a pre-compiled fsbl.elf. This only needs the bootgen
> command (from ISE) in the path. U-boot builds fine with the toolchain
> built in OE. (Also, you can build the fsbl with an OE toolchain last
> time I checked.
>
> Philip
>
>>
>> This requires 2 toolchains.  I was checking the difference between the 2
>> see the attached files.
>> Should the difference between the toolchains be of concern going forward?
>>
>> My Xilinx tools are node locked and I can only use on a single system.
>> Is there a method to run Yocto on CentOS6.4 x86_64?
>> Any and all help will be appreciated.

You could try installing the meta-toolchain which installs updated host
tools that Yocto can use.  Find them at
   http://downloads.yoctoproject.org/releases/yocto/yocto-1.5/toolchain/x86_64/

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

qt4x11 vs. uicmoc4-native vs. qmake2-native

[Geoffrey Wossum]

Hi all,

I've been doing some work with some Qt4 based applications, and I must say 
that I'm confused by the relationship between OE's qt4x11, uicmoc4-native, 
and qmake2-native packages.

As far as I can tell, this is what each package provides:

qt4x11 - headers and libraries for target system
uicmoc4-native - All Qt tools except qmake for host system
qmake2-native - qmake and mkspecs for host system

My main question is why can't uicmoc4-native and qmake2-native be combined 
into a single package?  Let me share my pain.

I need Qt 4.4 because I'm using Phonon.  So I make a new Bitbake recipe for 
qt4x11-4.4.0.  uicmoc4-native is still from 4.3.3.  Oh, noes!  uic from 4.3.3 
doesn't generate code that works with QT_NO_ACCESSIBILITY, but that was fixed 
in 4.4.0.  So I make a uicmoc4-native recipe and patches for 4.4.0.  Now I'm 
building a package that uses CMake (phonon-vlc-mplayer) and Qt.  CMake uses 
qmake (NOOOOO!) to figure out how to build Qt based applications.  
phonon-vlc-mplayer's build system punts because the qmake it finds from 
qmake2-native is for 4.3.3, and it wants at least 4.4.0.  So now I'm creating 
a qmake2-native recipe and patches that builds qmake from 4.4.0, and it feels 
like deja vu all over again.  

But it gets even worse.  uicmoc4-native gets its version number from the 
version of Qt used to build it.  But qmake2-native gets it's version number 
from the qmake version, which is independent of the Qt version.  Both Qt 
4.3.3 and 4.4.0 include qmake 2.10a.  However, qmake also remembers the 
version of Qt used to build it, which is what makes CMake unhappy.  So the 
qmake version of 2.10a really isn't the whole story.

I understand that Qt's build system doesn't really handle building host tools 
and target libraries in one shot, so at least two recipes are almost 
certainly necessary.  However, is there any good reason why uicmoc4-native 
and qmake2-native couldn't be combined into a single package?

TIA,
---
Geoffrey

Toolchain

[Stefano Regno]

In openEmbedded Project where is the file to undestanding the toolchain?
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>
>   


-- 
Peace cannot be kept by force; it can only be achieved by understanding --Albert Einstein

Re: Toolchain

[Leon Woestenberg]

Hello Stefano,

On Fri, Jul 4, 2008 at 8:54 AM, Stefano Regno
<stefano.regno@spesonline.com> wrote:
> In openEmbedded Project where is the file to undestanding the toolchain?
>>
Start with org.openembedded.dev/packages/gcc/gcc-cross-4.3.1.bb

Regards,
-- 
Leon

Re: Toolchain

[Stefano Regno]

i don't undestand what are u doing there is a mistake in your work or i 
m wronning?


-- 
Peace cannot be kept by force; it can only be achieved by understanding --Albert Einstein