introducing a new architecture/machine; policy ? (and a question)

introducing a new architecture/machine; policy ? (and a question)

[Frans Meulenbroeks]

Hi,

I'm about to complete bringing a new architecture (nios2 with mmu) and
machine (cyclone III FPGA starter kit, and maybe also the Nios2
Embeddeded Evaluation Kit (aka neek)) to oe.
Is there a policy on on the process how to do this.

Changes are fairly localised:
- add suport to binutils for the new architecture (currently based
upon binutils 2.17.50.0.12)
- add support to gcc for the new architecture (based upon gcc 4.1.2)
- added a kernel recipe (and a linux-libc-headers recipe for 2.6.34)
- some hardware specific changes to glibc 2.5

And some smaller changes (e.g. adding the machines, adding the
architecture to insane.bbclass and siteinfo.class, and a small patch
or two on other recipes (mainly busybox)).

Can I just commit these? It does not impact other architectures/machines.
Patches are fairly big (because of the new files that contain the
machine specific stuff), so posting them is impractical
If someone wants to review I can also make a branch, but this is only
useful if someone is actually going to review this (volunteers
welcome).

Please advise.

Some concluding remarks:
Only a minor part of the work is mine. Most comes from the nios2 git
(git://sopc.et.ntust.edu.tw/git/toolchain-mmu.git). The stuff on that
git is based upon a windriver version of the csl toolchain.
My activity was mostly isolating the nios2 specific stuff and create
patches for mainstream package versions.
That is also the reason why it is based upon old versions of
gcc/binutils/glibc: I didn't want to deviate too much from what is in
the git.

BTW: as nios2 is a programmable core, there may be different variants.
So you need to program the board with the appropriate .sof file.
The one I used for neek is the one found here:
http://www.nioswiki.com/Try_out_without_compilation
Should I put this sof file somewhere in the oe tree? No idea if this
is legally ok, and no idea where to put it.
Or should I put a reference somewhere? (and if so, where?)

Suggestions welcome!

Have fun! Frans

Re: introducing a new architecture/machine; policy ? (and a question)

[Frans Meulenbroeks]

2010/6/20 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
> Hi,
>
> I'm about to complete bringing a new architecture (nios2 with mmu) and
> machine (cyclone III FPGA starter kit, and maybe also the Nios2
> Embeddeded Evaluation Kit (aka neek)) to oe.
> Is there a policy on on the process how to do this.
>
> Changes are fairly localised:
> - add suport to binutils for the new architecture (currently based
> upon binutils 2.17.50.0.12)
> - add support to gcc for the new architecture (based upon gcc 4.1.2)
> - added a kernel recipe (and a linux-libc-headers recipe for 2.6.34)
> - some hardware specific changes to glibc 2.5
>
> And some smaller changes (e.g. adding the machines, adding the
> architecture to insane.bbclass and siteinfo.class, and a small patch
> or two on other recipes (mainly busybox)).
>
> Can I just commit these? It does not impact other architectures/machines.
> Patches are fairly big (because of the new files that contain the
> machine specific stuff), so posting them is impractical
> If someone wants to review I can also make a branch, but this is only
> useful if someone is actually going to review this (volunteers
> welcome).
>
> Please advise.
>
> Some concluding remarks:
> Only a minor part of the work is mine. Most comes from the nios2 git
> (git://sopc.et.ntust.edu.tw/git/toolchain-mmu.git). The stuff on that
> git is based upon a windriver version of the csl toolchain.
> My activity was mostly isolating the nios2 specific stuff and create
> patches for mainstream package versions.
> That is also the reason why it is based upon old versions of
> gcc/binutils/glibc: I didn't want to deviate too much from what is in
> the git.
>
> BTW: as nios2 is a programmable core, there may be different variants.
> So you need to program the board with the appropriate .sof file.
> The one I used for neek is the one found here:
> http://www.nioswiki.com/Try_out_without_compilation
> Should I put this sof file somewhere in the oe tree? No idea if this
> is legally ok, and no idea where to put it.
> Or should I put a reference somewhere? (and if so, where?)
>
> Suggestions welcome!
>
> Have fun! Frans
>
Oops. forgot one thing:

gcc for nios2 only seems to build on a 32 bit architecture. While
cross compling gcc on a 64 bit architecture gcc bails out with an
internal compilation error: segmentation fault.
(actually only tried on ubunti 10.04, 64 bit).
No idea yet on how to fix this. Moving to a different version of gcc
did not help.
Open to suggestions on how to fix this.

Frans

Re: introducing a new architecture/machine; policy ? (and a question)

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 20-06-10 11:58, Frans Meulenbroeks wrote:
> Hi,
> 
> I'm about to complete bringing a new architecture (nios2 with mmu) and
> machine (cyclone III FPGA starter kit, and maybe also the Nios2
> Embeddeded Evaluation Kit (aka neek)) to oe.
> Is there a policy on on the process how to do this.

Have a look at the nios2 patches Leon sent last december, they were
reviewed on this list, but not committed.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMHgsMMkyGM64RGpERAjbyAKCx3AW4OPKg0UEVSHgKIKX877U+uACeNm9I
9UQaYv3tscAimq4FpFqjJ0A=
=Xh3N
-----END PGP SIGNATURE-----

Re: introducing a new architecture/machine; policy ? (and a question)

[Frans Meulenbroeks]

2010/6/20 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 20-06-10 11:58, Frans Meulenbroeks wrote:
>> Hi,
>>
>> I'm about to complete bringing a new architecture (nios2 with mmu) and
>> machine (cyclone III FPGA starter kit, and maybe also the Nios2
>> Embeddeded Evaluation Kit (aka neek)) to oe.
>> Is there a policy on on the process how to do this.
>
> Have a look at the nios2 patches Leon sent last december, they were
> reviewed on this list, but not committed.

Koen, thanks for reminding me the look at the review comments.

I'm well aware of the work of Leon and Walter (and they are well aware
of my work).
Note that what Leon posted was for a non-mmu nios2 core, whereas the
changes I have is for an mmu core.

Triggered by Koens reminder I revisited the review comments. Actually
none but one are applicable for me.
The one that is applicable is the one about pinning versions in
machine descriptions.
I have also done that, as there are simply no other versions of
binutils and gcc that can be used by this hardware.
Also I don't feel empowered to make changes in distribution specific files.

The only alternative way that I can think of is doing something like:
DEFAULT_PREFERENCE_nios2 = "1" in the recipes I need.
No idea if that overrules the distro settings or not, but I can give
it a try later today.

Have fun! Frans.

Re: introducing a new architecture/machine; policy ? (and a question)

[Khem Raj]

On Sun, Jun 20, 2010 at 2:58 AM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> Hi,
>
> I'm about to complete bringing a new architecture (nios2 with mmu) and
> machine (cyclone III FPGA starter kit, and maybe also the Nios2
> Embeddeded Evaluation Kit (aka neek)) to oe.
> Is there a policy on on the process how to do this.
>
> Changes are fairly localised:
> - add suport to binutils for the new architecture (currently based
> upon binutils 2.17.50.0.12)
> - add support to gcc for the new architecture (based upon gcc 4.1.2)
> - added a kernel recipe (and a linux-libc-headers recipe for 2.6.34)
> - some hardware specific changes to glibc 2.5
>
> And some smaller changes (e.g. adding the machines, adding the
> architecture to insane.bbclass and siteinfo.class, and a small patch
> or two on other recipes (mainly busybox)).
>
> Can I just commit these? It does not impact other architectures/machines.
> Patches are fairly big (because of the new files that contain the
> machine specific stuff), so posting them is impractical
> If someone wants to review I can also make a branch, but this is only
> useful if someone is actually going to review this (volunteers
> welcome).

you can commit them to a user branch and post your user branch for
review if you want
it reviewed.

>
> Please advise.
>
> Some concluding remarks:
> Only a minor part of the work is mine. Most comes from the nios2 git
> (git://sopc.et.ntust.edu.tw/git/toolchain-mmu.git). The stuff on that
> git is based upon a windriver version of the csl toolchain.
> My activity was mostly isolating the nios2 specific stuff and create
> patches for mainstream package versions.
> That is also the reason why it is based upon old versions of
> gcc/binutils/glibc: I didn't want to deviate too much from what is in
> the git.
>
> BTW: as nios2 is a programmable core, there may be different variants.
> So you need to program the board with the appropriate .sof file.
> The one I used for neek is the one found here:
> http://www.nioswiki.com/Try_out_without_compilation
> Should I put this sof file somewhere in the oe tree? No idea if this
> is legally ok, and no idea where to put it.
> Or should I put a reference somewhere? (and if so, where?)
>
> Suggestions welcome!
>
> Have fun! Frans
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: introducing a new architecture/machine; policy ? (and a question)

[Frans Meulenbroeks]

2010/6/20 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
> 2010/6/20 Koen Kooi <k.kooi@student.utwente.nl>:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 20-06-10 11:58, Frans Meulenbroeks wrote:
>>> Hi,
>>>
>>> I'm about to complete bringing a new architecture (nios2 with mmu) and
>>> machine (cyclone III FPGA starter kit, and maybe also the Nios2
>>> Embeddeded Evaluation Kit (aka neek)) to oe.
>>> Is there a policy on on the process how to do this.
>>
>> Have a look at the nios2 patches Leon sent last december, they were
>> reviewed on this list, but not committed.
>
> Koen, thanks for reminding me the look at the review comments.
>
> I'm well aware of the work of Leon and Walter (and they are well aware
> of my work).
> Note that what Leon posted was for a non-mmu nios2 core, whereas the
> changes I have is for an mmu core.
>
> Triggered by Koens reminder I revisited the review comments. Actually
> none but one are applicable for me.
> The one that is applicable is the one about pinning versions in
> machine descriptions.
> I have also done that, as there are simply no other versions of
> binutils and gcc that can be used by this hardware.
> Also I don't feel empowered to make changes in distribution specific files.
>
> The only alternative way that I can think of is doing something like:
> DEFAULT_PREFERENCE_nios2 = "1" in the recipes I need.
> No idea if that overrules the distro settings or not, but I can give
> it a try later today.

Well, tried it and apparently a distro pin has priority over a
DEFAULT_PREFERENCE_nios2 in the recipe.
Guess I'll have to do the pinning the the machine description as
described above.

Frans.

Re: introducing a new architecture/machine; policy ? (and a question)

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23-06-10 10:53, Frans Meulenbroeks wrote:
> 2010/6/20 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
>> 2010/6/20 Koen Kooi <k.kooi@student.utwente.nl>:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 20-06-10 11:58, Frans Meulenbroeks wrote:
>>>> Hi,
>>>>
>>>> I'm about to complete bringing a new architecture (nios2 with mmu) and
>>>> machine (cyclone III FPGA starter kit, and maybe also the Nios2
>>>> Embeddeded Evaluation Kit (aka neek)) to oe.
>>>> Is there a policy on on the process how to do this.
>>>
>>> Have a look at the nios2 patches Leon sent last december, they were
>>> reviewed on this list, but not committed.
>>
>> Koen, thanks for reminding me the look at the review comments.
>>
>> I'm well aware of the work of Leon and Walter (and they are well aware
>> of my work).
>> Note that what Leon posted was for a non-mmu nios2 core, whereas the
>> changes I have is for an mmu core.
>>
>> Triggered by Koens reminder I revisited the review comments. Actually
>> none but one are applicable for me.
>> The one that is applicable is the one about pinning versions in
>> machine descriptions.
>> I have also done that, as there are simply no other versions of
>> binutils and gcc that can be used by this hardware.
>> Also I don't feel empowered to make changes in distribution specific files.
>>
>> The only alternative way that I can think of is doing something like:
>> DEFAULT_PREFERENCE_nios2 = "1" in the recipes I need.
>> No idea if that overrules the distro settings or not, but I can give
>> it a try later today.
> 
> Well, tried it and apparently a distro pin has priority over a
> DEFAULT_PREFERENCE_nios2 in the recipe.
> Guess I'll have to do the pinning the the machine description as
> described above.

NO! Machines *never* pin versions, that's what distros and to a lesser
extent recipes are for.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMIdLYMkyGM64RGpERAlPnAKCdByYCC57ozSFv9XUpFP+F7oujgwCbBVC3
yqZUWZMlMXNv5b9ZuQwu6sI=
=A9rs
-----END PGP SIGNATURE-----

Re: introducing a new architecture/machine; policy ? (and a question)

[Graeme Gregory]

> >> Also I don't feel empowered to make changes in distribution
> >> specific files.

Why not, chances are Angstrom maintainers would be quite happy for you
to patch angstrom*.conf if you ask us.

Graeme

Re: introducing a new architecture/machine; policy ? (and a question)

[Frans Meulenbroeks]

2010/6/23 Graeme Gregory <dp@xora.org.uk>:
>> >> Also I don't feel empowered to make changes in distribution
>> >> specific files.
>
> Why not, chances are Angstrom maintainers would be quite happy for you
> to patch angstrom*.conf if you ask us.
>
> Graeme

distribution != angstrom
There are more distributions out there.

The root cause of the problem is that a distro can specify a version
of a tool (let's take gcc as an example) that is not supported by a
specific hardware architecture.
I'd say what we really need is a way to allow a processor architecture
to specify which versions of binutls and gcc and friends are supported
for that hw architecture.
Mind you I talk about processor architectures, not boards.
(actually I guess this extends to every package that contains assembly
files or inline assembly)

The problem became more visible with nios2 as this is an architecture
that is not (yet) supported by gcc. Patches for now exist only for
4.1.2.

Frans.

Re: introducing a new architecture/machine; policy ? (and a question)

[Graeme Gregory]

On Wed, 23 Jun 2010 11:54:21 +0200
Frans Meulenbroeks <fransmeulenbroeks@gmail.com> wrote:

> 2010/6/23 Graeme Gregory <dp@xora.org.uk>:
> >> >> Also I don't feel empowered to make changes in distribution
> >> >> specific files.
> >
> > Why not, chances are Angstrom maintainers would be quite happy for
> > you to patch angstrom*.conf if you ask us.
> >
> > Graeme
> 
> distribution != angstrom
> There are more distributions out there.
> 
I think the other distros are almost as friendly as us :-)

Anyway the sane-* files are free for all with Acks.

Graeme

Re: introducing a new architecture/machine; policy ? (and a question)

[Philip Balister]

On 06/23/2010 12:03 PM, Graeme Gregory wrote:
> On Wed, 23 Jun 2010 11:54:21 +0200
> Frans Meulenbroeks<fransmeulenbroeks@gmail.com>  wrote:
>
>> 2010/6/23 Graeme Gregory<dp@xora.org.uk>:
>>>>>> Also I don't feel empowered to make changes in distribution
>>>>>> specific files.
>>>
>>> Why not, chances are Angstrom maintainers would be quite happy for
>>> you to patch angstrom*.conf if you ask us.
>>>
>>> Graeme
>>
>> distribution != angstrom
>> There are more distributions out there.

Right now, toolchain selection is done in distro files not machine 
files. I agree this is not the clearest approach, however adding the 
toolchain selection to the machine files may have unexpected side effects.

I would ask DISTRO maintainers to add the needed overrides, and explore 
alternative methods as a separate effort.

Philip


>>
> I think the other distros are almost as friendly as us :-)
>
> Anyway the sane-* files are free for all with Acks.
>
> Graeme
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: introducing a new architecture/machine; policy ? (and a question)

[Frans Meulenbroeks]

2010/6/23 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 23-06-10 10:53, Frans Meulenbroeks wrote:
>> 2010/6/20 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
>>> 2010/6/20 Koen Kooi <k.kooi@student.utwente.nl>:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 20-06-10 11:58, Frans Meulenbroeks wrote:
>>>>> Hi,
>>>>>
>>>>> I'm about to complete bringing a new architecture (nios2 with mmu) and
>>>>> machine (cyclone III FPGA starter kit, and maybe also the Nios2
>>>>> Embeddeded Evaluation Kit (aka neek)) to oe.
>>>>> Is there a policy on on the process how to do this.
>>>>
>>>> Have a look at the nios2 patches Leon sent last december, they were
>>>> reviewed on this list, but not committed.
>>>
>>> Koen, thanks for reminding me the look at the review comments.
>>>
>>> I'm well aware of the work of Leon and Walter (and they are well aware
>>> of my work).
>>> Note that what Leon posted was for a non-mmu nios2 core, whereas the
>>> changes I have is for an mmu core.
>>>
>>> Triggered by Koens reminder I revisited the review comments. Actually
>>> none but one are applicable for me.
>>> The one that is applicable is the one about pinning versions in
>>> machine descriptions.
>>> I have also done that, as there are simply no other versions of
>>> binutils and gcc that can be used by this hardware.
>>> Also I don't feel empowered to make changes in distribution specific files.
>>>
>>> The only alternative way that I can think of is doing something like:
>>> DEFAULT_PREFERENCE_nios2 = "1" in the recipes I need.
>>> No idea if that overrules the distro settings or not, but I can give
>>> it a try later today.
>>
>> Well, tried it and apparently a distro pin has priority over a
>> DEFAULT_PREFERENCE_nios2 in the recipe.
>> Guess I'll have to do the pinning the the machine description as
>> described above.
>
> NO! Machines *never* pin versions, that's what distros and to a lesser
> extent recipes are for.

The issue is that I have no way to specify which versions of a
toolchain that are supported (and to enforce that only a supported
version works).
If the DEFAULT_PREFERENCE in recipes had priority above whatever a
distro pins using DEFAULT_PREFERENCE in the recipe could work.
(e.g. if  DEFAULT_PREFERENCE = "-1" does mean something like: "does
not work" and that is respected by the distro).

Actually I do not want the machine to pin the recipe, I want the
architecture to pin the recipe (or at least tell which versions are
sound, and avoid that non-functional versions are used).

If I cannot pin in a machine file, the only alternative seems to be to
make gcc-nios2-* recipes and use a virtual/gcc in the conf file to
select gcc-nios2 as the preferred versions (just like a lot of
machines do with virtual/kernel). Seems like a waste of effort to me,
but oh well

BTW where did the rule come from that machines never pin versions?
When was that decided?
And as an owner of the machine file, isn't its contents something
which is at my discretion ???

And as a final remark:
I did a quick grep in conf/machine:
$ grep PREFERRED_VERSION * -l | wc
     71      71    1065
$ grep PREFERRED_VERSION * | wc
    104     314    5761

So there are 71 machine descriptions that pin at least one package. In
total these 71 contain 104 pins.
Most of these pin kernel and/or u-boot but there are also two other
machines that pin gcc.

Frans.

Re: introducing a new architecture/machine; policy ? (and a question)

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23-06-10 12:09, Frans Meulenbroeks wrote:
> 2010/6/23 Koen Kooi <k.kooi@student.utwente.nl>:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 23-06-10 10:53, Frans Meulenbroeks wrote:
>>> 2010/6/20 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
>>>> 2010/6/20 Koen Kooi <k.kooi@student.utwente.nl>:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> On 20-06-10 11:58, Frans Meulenbroeks wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm about to complete bringing a new architecture (nios2 with mmu) and
>>>>>> machine (cyclone III FPGA starter kit, and maybe also the Nios2
>>>>>> Embeddeded Evaluation Kit (aka neek)) to oe.
>>>>>> Is there a policy on on the process how to do this.
>>>>>
>>>>> Have a look at the nios2 patches Leon sent last december, they were
>>>>> reviewed on this list, but not committed.
>>>>
>>>> Koen, thanks for reminding me the look at the review comments.
>>>>
>>>> I'm well aware of the work of Leon and Walter (and they are well aware
>>>> of my work).
>>>> Note that what Leon posted was for a non-mmu nios2 core, whereas the
>>>> changes I have is for an mmu core.
>>>>
>>>> Triggered by Koens reminder I revisited the review comments. Actually
>>>> none but one are applicable for me.
>>>> The one that is applicable is the one about pinning versions in
>>>> machine descriptions.
>>>> I have also done that, as there are simply no other versions of
>>>> binutils and gcc that can be used by this hardware.
>>>> Also I don't feel empowered to make changes in distribution specific files.
>>>>
>>>> The only alternative way that I can think of is doing something like:
>>>> DEFAULT_PREFERENCE_nios2 = "1" in the recipes I need.
>>>> No idea if that overrules the distro settings or not, but I can give
>>>> it a try later today.
>>>
>>> Well, tried it and apparently a distro pin has priority over a
>>> DEFAULT_PREFERENCE_nios2 in the recipe.
>>> Guess I'll have to do the pinning the the machine description as
>>> described above.
>>
>> NO! Machines *never* pin versions, that's what distros and to a lesser
>> extent recipes are for.
> 
> The issue is that I have no way to specify which versions of a
> toolchain that are supported (and to enforce that only a supported
> version works).

You have no way to pin versions based on arch? Angstrom does that just
fine for blackfin, avr32 and armv4:

# Blackfin has its on gcc
ANGSTROM_GCC_VERSION_bfin           = "4.1.2"

#avr32 only has support for gcc 4.2.2
ANGSTROM_GCC_VERSION_avr32      ?= "4.2.2"

#armv4 needs at least gcc 4.4.2 for eabi
ANGSTROM_GCC_VERSION_armv4              ?= "4.4.2"

#Everybody else can just use this:
ANGSTROM_GCC_VERSION                     ?= "4.3.3"

PREFERRED_VERSION_gcc                    ?= "${ANGSTROM_GCC_VERSION}"
PREFERRED_VERSION_gcc-cross              ?= "${ANGSTROM_GCC_VERSION}"
PREFERRED_VERSION_gcc-cross-sdk          ?= "${ANGSTROM_GCC_VERSION}"
PREFERRED_VERSION_gcc-cross-initial      ?= "${ANGSTROM_GCC_VERSION}"
PREFERRED_VERSION_gcc-cross-intermediate ?= "${ANGSTROM_GCC_VERSION}"

So what's stopping you from creating a patch that does

+ANGSTROM_GCC_VERSION_nios2-mmu = "4.1.2"

And similar for binutils? For other distros you can use sane-toolchain
or something.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMIeJUMkyGM64RGpERAs9AAJ4smKJ3ErSKzGa5ge5AJecDNjukqACaA/t/
ljn0G+lPaOSpjcI+l8B6LaA=
=vlrX
-----END PGP SIGNATURE-----

Re: introducing a new architecture/machine; policy ? (and a question)

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23-06-10 12:07, Philip Balister wrote:
> On 06/23/2010 12:03 PM, Graeme Gregory wrote:
>> On Wed, 23 Jun 2010 11:54:21 +0200
>> Frans Meulenbroeks<fransmeulenbroeks@gmail.com>  wrote:
>>
>>> 2010/6/23 Graeme Gregory<dp@xora.org.uk>:
>>>>>>> Also I don't feel empowered to make changes in distribution
>>>>>>> specific files.
>>>>
>>>> Why not, chances are Angstrom maintainers would be quite happy for
>>>> you to patch angstrom*.conf if you ask us.
>>>>
>>>> Graeme
>>>
>>> distribution != angstrom
>>> There are more distributions out there.
> 
> Right now, toolchain selection is done in distro files not machine
> files. I agree this is not the clearest approach, however adding the
> toolchain selection to the machine files may have unexpected side effects.

Think of multimachine builds. What happens when someone else adds
*another* nios2 based machine with different toolchain versions, how do
I know which toolchain avahi_1.0_nios2.ipk was compiled with?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMIeLXMkyGM64RGpERAk0iAKCcXvyrUxGj2ZlsiV52sVhddsqr5wCcDgIS
Noq5qjHf0Qm7qObCuCRL1bM=
=VOH+
-----END PGP SIGNATURE-----

Re: introducing a new architecture/machine; policy ? (and a question)

[Frans Meulenbroeks]

2010/6/23 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 23-06-10 12:07, Philip Balister wrote:
>> On 06/23/2010 12:03 PM, Graeme Gregory wrote:
>>> On Wed, 23 Jun 2010 11:54:21 +0200
>>> Frans Meulenbroeks<fransmeulenbroeks@gmail.com>  wrote:
>>>
>>>> 2010/6/23 Graeme Gregory<dp@xora.org.uk>:
>>>>>>>> Also I don't feel empowered to make changes in distribution
>>>>>>>> specific files.
>>>>>
>>>>> Why not, chances are Angstrom maintainers would be quite happy for
>>>>> you to patch angstrom*.conf if you ask us.
>>>>>
>>>>> Graeme
>>>>
>>>> distribution != angstrom
>>>> There are more distributions out there.
>>
>> Right now, toolchain selection is done in distro files not machine
>> files. I agree this is not the clearest approach, however adding the
>> toolchain selection to the machine files may have unexpected side effects.
>
> Think of multimachine builds. What happens when someone else adds
> *another* nios2 based machine with different toolchain versions, how do
> I know which toolchain avahi_1.0_nios2.ipk was compiled with

If toolchain is interesting to know in ipk's it should be part of the name.
And note that I am really in favour of an architecture specific
solution, not a machine one.
That is why I used an include file to contain the pinnings.

And actually the situation with nios2 is much much worse.
As it is a soft-core people can come up with all kind of variants.
(e.g. with/without fp). Actually nios2 adds pragma's to gcc to select
which instructions are there and which not.
Not sure whether the latter is a good idea as it is one of the things
that fail moving to a newer gcc.

The good news is that most of the variants used have different
peripherals, but seem to stick to just a few cpu cores.
(nios2 is used as a generic name for the SoC as well as the core,
doesn't help to separate things either).

Frans

Re: introducing a new architecture/machine; policy ? (and a question)

[Khem Raj]

On (23/06/10 11:54), Frans Meulenbroeks wrote:
> 2010/6/23 Graeme Gregory <dp@xora.org.uk>:
> >> >> Also I don't feel empowered to make changes in distribution
> >> >> specific files.
> >
> > Why not, chances are Angstrom maintainers would be quite happy for you
> > to patch angstrom*.conf if you ask us.
> >
> > Graeme
> 
> distribution != angstrom
> There are more distributions out there.
> 
> The root cause of the problem is that a distro can specify a version
> of a tool (let's take gcc as an example) that is not supported by a
> specific hardware architecture.
> I'd say what we really need is a way to allow a processor architecture
> to specify which versions of binutls and gcc and friends are supported
> for that hw architecture.
> Mind you I talk about processor architectures, not boards.
> (actually I guess this extends to every package that contains assembly
> files or inline assembly)
> 
> The problem became more visible with nios2 as this is an architecture
> that is not (yet) supported by gcc. Patches for now exist only for
> 4.1.2.
> 

some architectures may not support particular version of say gcc but
still if that architecture is supported by a given distro then it should
define the required version of say gcc in distro.conf with override

for instance check conf/distro/include/sane-toolchain.inc which is serving
a few distributions overrides default compiler versions for AVR32
you need to do something same for nios2

Thanks
-Khem

> Frans.
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: introducing a new architecture/machine; policy ? (and a question)

[Tom Rini]

Khem Raj wrote:

> some architectures may not support particular version of say gcc but
> still if that architecture is supported by a given distro then it should
> define the required version of say gcc in distro.conf with override
> 
> for instance check conf/distro/include/sane-toolchain.inc which is serving
> a few distributions overrides default compiler versions for AVR32
> you need to do something same for nios2

In short, some of us would love it if we could all rely on either 
sane-toolchain.inc or at least everyone using the same variables for 
picking a toolchain so that the "We must use x/y/z tools" could move to 
tune-ARCH.inc.  But there's probably some issue that doesn't come to 
mind with moving that override control to the machine level.

-- 
Tom Rini
Mentor Graphics Corporation

Re: introducing a new architecture/machine; policy ? (and a question)

[Khem Raj]

On (23/06/10 13:16), Frans Meulenbroeks wrote:
> 2010/6/23 Koen Kooi <k.kooi@student.utwente.nl>:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 23-06-10 12:07, Philip Balister wrote:
> >> On 06/23/2010 12:03 PM, Graeme Gregory wrote:
> >>> On Wed, 23 Jun 2010 11:54:21 +0200
> >>> Frans Meulenbroeks<fransmeulenbroeks@gmail.com>  wrote:
> >>>
> >>>> 2010/6/23 Graeme Gregory<dp@xora.org.uk>:
> >>>>>>>> Also I don't feel empowered to make changes in distribution
> >>>>>>>> specific files.
> >>>>>
> >>>>> Why not, chances are Angstrom maintainers would be quite happy for
> >>>>> you to patch angstrom*.conf if you ask us.
> >>>>>
> >>>>> Graeme
> >>>>
> >>>> distribution != angstrom
> >>>> There are more distributions out there.
> >>
> >> Right now, toolchain selection is done in distro files not machine
> >> files. I agree this is not the clearest approach, however adding the
> >> toolchain selection to the machine files may have unexpected side effects.
> >
> > Think of multimachine builds. What happens when someone else adds
> > *another* nios2 based machine with different toolchain versions, how do
> > I know which toolchain avahi_1.0_nios2.ipk was compiled with
> 
> If toolchain is interesting to know in ipk's it should be part of the name.
> And note that I am really in favour of an architecture specific
> solution, not a machine one.
> That is why I used an include file to contain the pinnings.
> 
> And actually the situation with nios2 is much much worse.
> As it is a soft-core people can come up with all kind of variants.
> (e.g. with/without fp). 

not new. Other arches have similar variants already in OE


> Actually nios2 adds pragma's to gcc to select
> which instructions are there and which not.

Well I would have preferred commandline options that way you could
have many variants and we could have overrides like we have arm sub-arches


> Not sure whether the latter is a good idea as it is one of the things
> that fail moving to a newer gcc.
> 
> The good news is that most of the variants used have different
> peripherals, but seem to stick to just a few cpu cores.
> (nios2 is used as a generic name for the SoC as well as the core,
> doesn't help to separate things either).
> 
> Frans
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: introducing a new architecture/machine; policy ? (and a question)

[Khem Raj]

On (23/06/10 12:09), Frans Meulenbroeks wrote:
> 2010/6/23 Koen Kooi <k.kooi@student.utwente.nl>:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 23-06-10 10:53, Frans Meulenbroeks wrote:
> >> 2010/6/20 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
> >>> 2010/6/20 Koen Kooi <k.kooi@student.utwente.nl>:
> >>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>> Hash: SHA1
> >>>>
> >>>> On 20-06-10 11:58, Frans Meulenbroeks wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I'm about to complete bringing a new architecture (nios2 with mmu) and
> >>>>> machine (cyclone III FPGA starter kit, and maybe also the Nios2
> >>>>> Embeddeded Evaluation Kit (aka neek)) to oe.
> >>>>> Is there a policy on on the process how to do this.
> >>>>
> >>>> Have a look at the nios2 patches Leon sent last december, they were
> >>>> reviewed on this list, but not committed.
> >>>
> >>> Koen, thanks for reminding me the look at the review comments.
> >>>
> >>> I'm well aware of the work of Leon and Walter (and they are well aware
> >>> of my work).
> >>> Note that what Leon posted was for a non-mmu nios2 core, whereas the
> >>> changes I have is for an mmu core.
> >>>
> >>> Triggered by Koens reminder I revisited the review comments. Actually
> >>> none but one are applicable for me.
> >>> The one that is applicable is the one about pinning versions in
> >>> machine descriptions.
> >>> I have also done that, as there are simply no other versions of
> >>> binutils and gcc that can be used by this hardware.
> >>> Also I don't feel empowered to make changes in distribution specific files.
> >>>
> >>> The only alternative way that I can think of is doing something like:
> >>> DEFAULT_PREFERENCE_nios2 = "1" in the recipes I need.
> >>> No idea if that overrules the distro settings or not, but I can give
> >>> it a try later today.
> >>
> >> Well, tried it and apparently a distro pin has priority over a
> >> DEFAULT_PREFERENCE_nios2 in the recipe.
> >> Guess I'll have to do the pinning the the machine description as
> >> described above.
> >
> > NO! Machines *never* pin versions, that's what distros and to a lesser
> > extent recipes are for.
> 
> The issue is that I have no way to specify which versions of a
> toolchain that are supported (and to enforce that only a supported
> version works).
> If the DEFAULT_PREFERENCE in recipes had priority above whatever a
> distro pins using DEFAULT_PREFERENCE in the recipe could work.
> (e.g. if  DEFAULT_PREFERENCE = "-1" does mean something like: "does
> not work" and that is respected by the distro).
> 
> Actually I do not want the machine to pin the recipe, I want the
> architecture to pin the recipe (or at least tell which versions are
> sound, and avoid that non-functional versions are used).

you can use the TARGET_ARCH override to do that
> 
> If I cannot pin in a machine file, the only alternative seems to be to
> make gcc-nios2-* recipes and use a virtual/gcc in the conf file to
> select gcc-nios2 as the preferred versions (just like a lot of
> machines do with virtual/kernel). Seems like a waste of effort to me,
> but oh well

Already suggested a solution in prior reply.

> 
> BTW where did the rule come from that machines never pin versions?
> When was that decided?
> And as an owner of the machine file, isn't its contents something
> which is at my discretion ???

Well yes but within bounds of design and common structure. You dont get a license to
kill with maintainership if you know what I mean :)

> 
> And as a final remark:
> I did a quick grep in conf/machine:
> $ grep PREFERRED_VERSION * -l | wc
>      71      71    1065
> $ grep PREFERRED_VERSION * | wc
>     104     314    5761
> 
> So there are 71 machine descriptions that pin at least one package. In
> total these 71 contain 104 pins.
> Most of these pin kernel and/or u-boot but there are also two other
> machines that pin gcc.
> 
> Frans.
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: introducing a new architecture/machine; policy ? (and a question)

[Frans Meulenbroeks]

2010/6/23 Khem Raj <raj.khem@gmail.com>:
> On (23/06/10 13:16), Frans Meulenbroeks wrote:
>> 2010/6/23 Koen Kooi <k.kooi@student.utwente.nl>:
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > On 23-06-10 12:07, Philip Balister wrote:
>> >> On 06/23/2010 12:03 PM, Graeme Gregory wrote:
>> >>> On Wed, 23 Jun 2010 11:54:21 +0200
>> >>> Frans Meulenbroeks<fransmeulenbroeks@gmail.com>  wrote:
>> >>>
>> >>>> 2010/6/23 Graeme Gregory<dp@xora.org.uk>:
>> >>>>>>>> Also I don't feel empowered to make changes in distribution
>> >>>>>>>> specific files.
>> >>>>>
>> >>>>> Why not, chances are Angstrom maintainers would be quite happy for
>> >>>>> you to patch angstrom*.conf if you ask us.
>> >>>>>
>> >>>>> Graeme
>> >>>>
>> >>>> distribution != angstrom
>> >>>> There are more distributions out there.
>> >>
>> >> Right now, toolchain selection is done in distro files not machine
>> >> files. I agree this is not the clearest approach, however adding the
>> >> toolchain selection to the machine files may have unexpected side effects.
>> >
>> > Think of multimachine builds. What happens when someone else adds
>> > *another* nios2 based machine with different toolchain versions, how do
>> > I know which toolchain avahi_1.0_nios2.ipk was compiled with
>>
>> If toolchain is interesting to know in ipk's it should be part of the name.
>> And note that I am really in favour of an architecture specific
>> solution, not a machine one.
>> That is why I used an include file to contain the pinnings.
>>
>> And actually the situation with nios2 is much much worse.
>> As it is a soft-core people can come up with all kind of variants.
>> (e.g. with/without fp).
>
> not new. Other arches have similar variants already in OE

I know, but at least in those architectures if you have a board the
situation is static.
In fpga's capable of having a nios2 machine, it is still possible to
load different configurations.
As such it is different from everything we have (as far as I know we
have no microblaze boards yet).
>
>
>> Actually nios2 adds pragma's to gcc to select
>> which instructions are there and which not.
>
> Well I would have preferred commandline options that way you could
> have many variants and we could have overrides like we have arm sub-arches

You would indeed get many variants and many options.
Anyway, the code I started with had the pragma's.There were other
higher priority things to dig into (like getting it to compile on 64
bit hw).

Frans
>
>
>> Not sure whether the latter is a good idea as it is one of the things
>> that fail moving to a newer gcc.
>>
>> The good news is that most of the variants used have different
>> peripherals, but seem to stick to just a few cpu cores.
>> (nios2 is used as a generic name for the SoC as well as the core,
>> doesn't help to separate things either).
>>
>> Frans
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: introducing a new architecture/machine; policy ? (and a question)

[Frans Meulenbroeks]

2010/6/23 Khem Raj <raj.khem@gmail.com>:
> On (23/06/10 12:09), Frans Meulenbroeks wrote:
>> 2010/6/23 Koen Kooi <k.kooi@student.utwente.nl>:
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > On 23-06-10 10:53, Frans Meulenbroeks wrote:
>> >> 2010/6/20 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
>> >>> 2010/6/20 Koen Kooi <k.kooi@student.utwente.nl>:
>> >>>> -----BEGIN PGP SIGNED MESSAGE-----
>> >>>> Hash: SHA1
>> >>>>
>> >>>> On 20-06-10 11:58, Frans Meulenbroeks wrote:
>> >>>>> Hi,
>> >>>>>
>> >>>>> I'm about to complete bringing a new architecture (nios2 with mmu) and
>> >>>>> machine (cyclone III FPGA starter kit, and maybe also the Nios2
>> >>>>> Embeddeded Evaluation Kit (aka neek)) to oe.
>> >>>>> Is there a policy on on the process how to do this.
>> >>>>
>> >>>> Have a look at the nios2 patches Leon sent last december, they were
>> >>>> reviewed on this list, but not committed.
>> >>>
>> >>> Koen, thanks for reminding me the look at the review comments.
>> >>>
>> >>> I'm well aware of the work of Leon and Walter (and they are well aware
>> >>> of my work).
>> >>> Note that what Leon posted was for a non-mmu nios2 core, whereas the
>> >>> changes I have is for an mmu core.
>> >>>
>> >>> Triggered by Koens reminder I revisited the review comments. Actually
>> >>> none but one are applicable for me.
>> >>> The one that is applicable is the one about pinning versions in
>> >>> machine descriptions.
>> >>> I have also done that, as there are simply no other versions of
>> >>> binutils and gcc that can be used by this hardware.
>> >>> Also I don't feel empowered to make changes in distribution specific files.
>> >>>
>> >>> The only alternative way that I can think of is doing something like:
>> >>> DEFAULT_PREFERENCE_nios2 = "1" in the recipes I need.
>> >>> No idea if that overrules the distro settings or not, but I can give
>> >>> it a try later today.
>> >>
>> >> Well, tried it and apparently a distro pin has priority over a
>> >> DEFAULT_PREFERENCE_nios2 in the recipe.
>> >> Guess I'll have to do the pinning the the machine description as
>> >> described above.
>> >
>> > NO! Machines *never* pin versions, that's what distros and to a lesser
>> > extent recipes are for.
>>
>> The issue is that I have no way to specify which versions of a
>> toolchain that are supported (and to enforce that only a supported
>> version works).
>> If the DEFAULT_PREFERENCE in recipes had priority above whatever a
>> distro pins using DEFAULT_PREFERENCE in the recipe could work.
>> (e.g. if  DEFAULT_PREFERENCE = "-1" does mean something like: "does
>> not work" and that is respected by the distro).
>>
>> Actually I do not want the machine to pin the recipe, I want the
>> architecture to pin the recipe (or at least tell which versions are
>> sound, and avoid that non-functional versions are used).
>
> you can use the TARGET_ARCH override to do that

I'm not fully sure how one would actually do that.Please explain it to
me on irc.

>>
>> If I cannot pin in a machine file, the only alternative seems to be to
>> make gcc-nios2-* recipes and use a virtual/gcc in the conf file to
>> select gcc-nios2 as the preferred versions (just like a lot of
>> machines do with virtual/kernel). Seems like a waste of effort to me,
>> but oh well
>
> Already suggested a solution in prior reply.

I can pin in sane-toolchain, but only a few distro's seem to use that.
For now I think it is probably best to have gcc-nios recipes and
define virtual/gcc in the machine configurations. (haven't really seen
objections to that, and for virtual/kernel this seems common practise)
The best solution is indeed to have a sane-toolchain.inc that defines
the available versions for an architecture and that is used by every
distro, but somehow I doubt if that will happen.
>
>>
>> BTW where did the rule come from that machines never pin versions?
>> When was that decided?
>> And as an owner of the machine file, isn't its contents something
>> which is at my discretion ???
>
> Well yes but within bounds of design and common structure. You dont get a license to
> kill with maintainership if you know what I mean :)

I know what you mean, but I don't like it if people sell me crap like
"NO! Machines *never* pin versions" while within a few seconds I can
provide evidence that there are not one or two, but 71 machines that
pin something in their conf.

Frans.

>
>>
>> And as a final remark:
>> I did a quick grep in conf/machine:
>> $ grep PREFERRED_VERSION * -l | wc
>>      71      71    1065
>> $ grep PREFERRED_VERSION * | wc
>>     104     314    5761
>>
>> So there are 71 machine descriptions that pin at least one package. In
>> total these 71 contain 104 pins.
>> Most of these pin kernel and/or u-boot but there are also two other
>> machines that pin gcc.
>>
>> Frans.
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: introducing a new architecture/machine; policy ? (and a question)

[Adrian Alonso]

Hi,

I'm working on xilinx platforms support (virtex4, virtex5,
generic-microblaze) [1]
and trying to do it as generic possible, in my case the target boards
depending on the
family can target a hard core arch (powerpc) or a soft-cpu (microblaze),
As far of my work progress I select the supported combinations of
gcc/binutils/glibc in
distro conf files (angstrom-2008).
In config machine files I add u-boot and linux preferred version since this
recipes inherits
xilinx-bsp.bbclass to able to copy some headers to match the
hardware/software model.
Also in xilinx-bsp I handle the possible combinations of configuring u-boot
for the final arch.

But I also require a way to override the final target-tune instead of
introducing a new variable
TARGET_TUNE see [2];

What could be a good approach to handle the final arch configuration
options?

Regards

[1] http://www.gitorious.org/oe-microblaze/<http://www.gitorious.org/oe-microblaze/oe-microblaze/blobs/xilinx-support/conf/machine/xilinx-virtex4.conf>
[2]
http://www.gitorious.org/oe-microblaze/oe-microblaze/blobs/xilinx-support/conf/machine/xilinx-virtex4.conf

On Wed, Jun 23, 2010 at 3:04 PM, Frans Meulenbroeks <
fransmeulenbroeks@gmail.com> wrote:

> 2010/6/23 Khem Raj <raj.khem@gmail.com>:
> > On (23/06/10 12:09), Frans Meulenbroeks wrote:
> >> 2010/6/23 Koen Kooi <k.kooi@student.utwente.nl>:
> >> > -----BEGIN PGP SIGNED MESSAGE-----
> >> > Hash: SHA1
> >> >
> >> > On 23-06-10 10:53, Frans Meulenbroeks wrote:
> >> >> 2010/6/20 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
> >> >>> 2010/6/20 Koen Kooi <k.kooi@student.utwente.nl>:
> >> >>>> -----BEGIN PGP SIGNED MESSAGE-----
> >> >>>> Hash: SHA1
> >> >>>>
> >> >>>> On 20-06-10 11:58, Frans Meulenbroeks wrote:
> >> >>>>> Hi,
> >> >>>>>
> >> >>>>> I'm about to complete bringing a new architecture (nios2 with mmu)
> and
> >> >>>>> machine (cyclone III FPGA starter kit, and maybe also the Nios2
> >> >>>>> Embeddeded Evaluation Kit (aka neek)) to oe.
> >> >>>>> Is there a policy on on the process how to do this.
> >> >>>>
> >> >>>> Have a look at the nios2 patches Leon sent last december, they were
> >> >>>> reviewed on this list, but not committed.
> >> >>>
> >> >>> Koen, thanks for reminding me the look at the review comments.
> >> >>>
> >> >>> I'm well aware of the work of Leon and Walter (and they are well
> aware
> >> >>> of my work).
> >> >>> Note that what Leon posted was for a non-mmu nios2 core, whereas the
> >> >>> changes I have is for an mmu core.
> >> >>>
> >> >>> Triggered by Koens reminder I revisited the review comments.
> Actually
> >> >>> none but one are applicable for me.
> >> >>> The one that is applicable is the one about pinning versions in
> >> >>> machine descriptions.
> >> >>> I have also done that, as there are simply no other versions of
> >> >>> binutils and gcc that can be used by this hardware.
> >> >>> Also I don't feel empowered to make changes in distribution specific
> files.
> >> >>>
> >> >>> The only alternative way that I can think of is doing something
> like:
> >> >>> DEFAULT_PREFERENCE_nios2 = "1" in the recipes I need.
> >> >>> No idea if that overrules the distro settings or not, but I can give
> >> >>> it a try later today.
> >> >>
> >> >> Well, tried it and apparently a distro pin has priority over a
> >> >> DEFAULT_PREFERENCE_nios2 in the recipe.
> >> >> Guess I'll have to do the pinning the the machine description as
> >> >> described above.
> >> >
> >> > NO! Machines *never* pin versions, that's what distros and to a lesser
> >> > extent recipes are for.
> >>
> >> The issue is that I have no way to specify which versions of a
> >> toolchain that are supported (and to enforce that only a supported
> >> version works).
> >> If the DEFAULT_PREFERENCE in recipes had priority above whatever a
> >> distro pins using DEFAULT_PREFERENCE in the recipe could work.
> >> (e.g. if  DEFAULT_PREFERENCE = "-1" does mean something like: "does
> >> not work" and that is respected by the distro).
> >>
> >> Actually I do not want the machine to pin the recipe, I want the
> >> architecture to pin the recipe (or at least tell which versions are
> >> sound, and avoid that non-functional versions are used).
> >
> > you can use the TARGET_ARCH override to do that
>
> I'm not fully sure how one would actually do that.Please explain it to
> me on irc.
>
> >>
> >> If I cannot pin in a machine file, the only alternative seems to be to
> >> make gcc-nios2-* recipes and use a virtual/gcc in the conf file to
> >> select gcc-nios2 as the preferred versions (just like a lot of
> >> machines do with virtual/kernel). Seems like a waste of effort to me,
> >> but oh well
> >
> > Already suggested a solution in prior reply.
>
> I can pin in sane-toolchain, but only a few distro's seem to use that.
> For now I think it is probably best to have gcc-nios recipes and
> define virtual/gcc in the machine configurations. (haven't really seen
> objections to that, and for virtual/kernel this seems common practise)
> The best solution is indeed to have a sane-toolchain.inc that defines
> the available versions for an architecture and that is used by every
> distro, but somehow I doubt if that will happen.
> >
> >>
> >> BTW where did the rule come from that machines never pin versions?
> >> When was that decided?
> >> And as an owner of the machine file, isn't its contents something
> >> which is at my discretion ???
> >
> > Well yes but within bounds of design and common structure. You dont get a
> license to
> > kill with maintainership if you know what I mean :)
>
> I know what you mean, but I don't like it if people sell me crap like
> "NO! Machines *never* pin versions" while within a few seconds I can
> provide evidence that there are not one or two, but 71 machines that
> pin something in their conf.
>
> Frans.
>
> >
> >>
> >> And as a final remark:
> >> I did a quick grep in conf/machine:
> >> $ grep PREFERRED_VERSION * -l | wc
> >>      71      71    1065
> >> $ grep PREFERRED_VERSION * | wc
> >>     104     314    5761
> >>
> >> So there are 71 machine descriptions that pin at least one package. In
> >> total these 71 contain 104 pins.
> >> Most of these pin kernel and/or u-boot but there are also two other
> >> machines that pin gcc.
> >>
> >> Frans.
> >>
> >> _______________________________________________
> >> Openembedded-devel mailing list
> >> Openembedded-devel@lists.openembedded.org
> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



-- 
Saludos
Adrian Alonso
http://aalonso.wordpress.com

Re: introducing a new architecture/machine; policy ? (and a question)

[Khem Raj]

On (23/06/10 16:55), Adrian Alonso wrote:
> Hi,
> 
> I'm working on xilinx platforms support (virtex4, virtex5,
> generic-microblaze) [1]
> and trying to do it as generic possible, in my case the target boards
> depending on the
> family can target a hard core arch (powerpc) or a soft-cpu (microblaze),
> As far of my work progress I select the supported combinations of
> gcc/binutils/glibc in
> distro conf files (angstrom-2008).

fine.

> In config machine files I add u-boot and linux preferred version since this
> recipes inherits
> xilinx-bsp.bbclass to able to copy some headers to match the
> hardware/software model.

uboot and kernel are machine dependent. It would still be nice if you
pinned the recipes instead.

> Also in xilinx-bsp I handle the possible combinations of configuring u-boot
> for the final arch.
> 
> But I also require a way to override the final target-tune instead of
> introducing a new variable
> TARGET_TUNE see [2];

TARGET_TUNE seems to be a convenience var only so its ok even if you did
not use it.

> 
> What could be a good approach to handle the final arch configuration
> options?
> 
> Regards
> 
> [1] http://www.gitorious.org/oe-microblaze/<http://www.gitorious.org/oe-microblaze/oe-microblaze/blobs/xilinx-support/conf/machine/xilinx-virtex4.conf>
> [2]
> http://www.gitorious.org/oe-microblaze/oe-microblaze/blobs/xilinx-support/conf/machine/xilinx-virtex4.conf
> 
> On Wed, Jun 23, 2010 at 3:04 PM, Frans Meulenbroeks <
> fransmeulenbroeks@gmail.com> wrote:
> 
> > 2010/6/23 Khem Raj <raj.khem@gmail.com>:
> > > On (23/06/10 12:09), Frans Meulenbroeks wrote:
> > >> 2010/6/23 Koen Kooi <k.kooi@student.utwente.nl>:
> > >> > -----BEGIN PGP SIGNED MESSAGE-----
> > >> > Hash: SHA1
> > >> >
> > >> > On 23-06-10 10:53, Frans Meulenbroeks wrote:
> > >> >> 2010/6/20 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
> > >> >>> 2010/6/20 Koen Kooi <k.kooi@student.utwente.nl>:
> > >> >>>> -----BEGIN PGP SIGNED MESSAGE-----
> > >> >>>> Hash: SHA1
> > >> >>>>
> > >> >>>> On 20-06-10 11:58, Frans Meulenbroeks wrote:
> > >> >>>>> Hi,
> > >> >>>>>
> > >> >>>>> I'm about to complete bringing a new architecture (nios2 with mmu)
> > and
> > >> >>>>> machine (cyclone III FPGA starter kit, and maybe also the Nios2
> > >> >>>>> Embeddeded Evaluation Kit (aka neek)) to oe.
> > >> >>>>> Is there a policy on on the process how to do this.
> > >> >>>>
> > >> >>>> Have a look at the nios2 patches Leon sent last december, they were
> > >> >>>> reviewed on this list, but not committed.
> > >> >>>
> > >> >>> Koen, thanks for reminding me the look at the review comments.
> > >> >>>
> > >> >>> I'm well aware of the work of Leon and Walter (and they are well
> > aware
> > >> >>> of my work).
> > >> >>> Note that what Leon posted was for a non-mmu nios2 core, whereas the
> > >> >>> changes I have is for an mmu core.
> > >> >>>
> > >> >>> Triggered by Koens reminder I revisited the review comments.
> > Actually
> > >> >>> none but one are applicable for me.
> > >> >>> The one that is applicable is the one about pinning versions in
> > >> >>> machine descriptions.
> > >> >>> I have also done that, as there are simply no other versions of
> > >> >>> binutils and gcc that can be used by this hardware.
> > >> >>> Also I don't feel empowered to make changes in distribution specific
> > files.
> > >> >>>
> > >> >>> The only alternative way that I can think of is doing something
> > like:
> > >> >>> DEFAULT_PREFERENCE_nios2 = "1" in the recipes I need.
> > >> >>> No idea if that overrules the distro settings or not, but I can give
> > >> >>> it a try later today.
> > >> >>
> > >> >> Well, tried it and apparently a distro pin has priority over a
> > >> >> DEFAULT_PREFERENCE_nios2 in the recipe.
> > >> >> Guess I'll have to do the pinning the the machine description as
> > >> >> described above.
> > >> >
> > >> > NO! Machines *never* pin versions, that's what distros and to a lesser
> > >> > extent recipes are for.
> > >>
> > >> The issue is that I have no way to specify which versions of a
> > >> toolchain that are supported (and to enforce that only a supported
> > >> version works).
> > >> If the DEFAULT_PREFERENCE in recipes had priority above whatever a
> > >> distro pins using DEFAULT_PREFERENCE in the recipe could work.
> > >> (e.g. if  DEFAULT_PREFERENCE = "-1" does mean something like: "does
> > >> not work" and that is respected by the distro).
> > >>
> > >> Actually I do not want the machine to pin the recipe, I want the
> > >> architecture to pin the recipe (or at least tell which versions are
> > >> sound, and avoid that non-functional versions are used).
> > >
> > > you can use the TARGET_ARCH override to do that
> >
> > I'm not fully sure how one would actually do that.Please explain it to
> > me on irc.
> >
> > >>
> > >> If I cannot pin in a machine file, the only alternative seems to be to
> > >> make gcc-nios2-* recipes and use a virtual/gcc in the conf file to
> > >> select gcc-nios2 as the preferred versions (just like a lot of
> > >> machines do with virtual/kernel). Seems like a waste of effort to me,
> > >> but oh well
> > >
> > > Already suggested a solution in prior reply.
> >
> > I can pin in sane-toolchain, but only a few distro's seem to use that.
> > For now I think it is probably best to have gcc-nios recipes and
> > define virtual/gcc in the machine configurations. (haven't really seen
> > objections to that, and for virtual/kernel this seems common practise)
> > The best solution is indeed to have a sane-toolchain.inc that defines
> > the available versions for an architecture and that is used by every
> > distro, but somehow I doubt if that will happen.
> > >
> > >>
> > >> BTW where did the rule come from that machines never pin versions?
> > >> When was that decided?
> > >> And as an owner of the machine file, isn't its contents something
> > >> which is at my discretion ???
> > >
> > > Well yes but within bounds of design and common structure. You dont get a
> > license to
> > > kill with maintainership if you know what I mean :)
> >
> > I know what you mean, but I don't like it if people sell me crap like
> > "NO! Machines *never* pin versions" while within a few seconds I can
> > provide evidence that there are not one or two, but 71 machines that
> > pin something in their conf.
> >
> > Frans.
> >
> > >
> > >>
> > >> And as a final remark:
> > >> I did a quick grep in conf/machine:
> > >> $ grep PREFERRED_VERSION * -l | wc
> > >>      71      71    1065
> > >> $ grep PREFERRED_VERSION * | wc
> > >>     104     314    5761
> > >>
> > >> So there are 71 machine descriptions that pin at least one package. In
> > >> total these 71 contain 104 pins.
> > >> Most of these pin kernel and/or u-boot but there are also two other
> > >> machines that pin gcc.
> > >>
> > >> Frans.
> > >>
> > >> _______________________________________________
> > >> Openembedded-devel mailing list
> > >> Openembedded-devel@lists.openembedded.org
> > >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> > >
> > > _______________________________________________
> > > Openembedded-devel mailing list
> > > Openembedded-devel@lists.openembedded.org
> > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> > >
> >
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >
> 
> 
> 
> -- 
> Saludos
> Adrian Alonso
> http://aalonso.wordpress.com
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: introducing a new architecture/machine; policy ? (and a question)

[Khem Raj]

On (23/06/10 21:55), Frans Meulenbroeks wrote:
> 2010/6/23 Khem Raj <raj.khem@gmail.com>:
> > On (23/06/10 13:16), Frans Meulenbroeks wrote:
> >> 2010/6/23 Koen Kooi <k.kooi@student.utwente.nl>:
> >> > -----BEGIN PGP SIGNED MESSAGE-----
> >> > Hash: SHA1
> >> >
> >> > On 23-06-10 12:07, Philip Balister wrote:
> >> >> On 06/23/2010 12:03 PM, Graeme Gregory wrote:
> >> >>> On Wed, 23 Jun 2010 11:54:21 +0200
> >> >>> Frans Meulenbroeks<fransmeulenbroeks@gmail.com>  wrote:
> >> >>>
> >> >>>> 2010/6/23 Graeme Gregory<dp@xora.org.uk>:
> >> >>>>>>>> Also I don't feel empowered to make changes in distribution
> >> >>>>>>>> specific files.
> >> >>>>>
> >> >>>>> Why not, chances are Angstrom maintainers would be quite happy for
> >> >>>>> you to patch angstrom*.conf if you ask us.
> >> >>>>>
> >> >>>>> Graeme
> >> >>>>
> >> >>>> distribution != angstrom
> >> >>>> There are more distributions out there.
> >> >>
> >> >> Right now, toolchain selection is done in distro files not machine
> >> >> files. I agree this is not the clearest approach, however adding the
> >> >> toolchain selection to the machine files may have unexpected side effects.
> >> >
> >> > Think of multimachine builds. What happens when someone else adds
> >> > *another* nios2 based machine with different toolchain versions, how do
> >> > I know which toolchain avahi_1.0_nios2.ipk was compiled with
> >>
> >> If toolchain is interesting to know in ipk's it should be part of the name.
> >> And note that I am really in favour of an architecture specific
> >> solution, not a machine one.
> >> That is why I used an include file to contain the pinnings.
> >>
> >> And actually the situation with nios2 is much much worse.
> >> As it is a soft-core people can come up with all kind of variants.
> >> (e.g. with/without fp).
> >
> > not new. Other arches have similar variants already in OE
> 
> I know, but at least in those architectures if you have a board the
> situation is static.
> In fpga's capable of having a nios2 machine, it is still possible to
> load different configurations.

how many ? if they are managable you can still use the existing relation of
machine to them but if you really want to make it configurable then you
might think of writing a class which would define these configurations
somehow may be you can denote various configs through some bitbake var
then.

Re: introducing a new architecture/machine; policy ? (and a question)

[Khem Raj]

On (23/06/10 22:04), Frans Meulenbroeks wrote:
> 2010/6/23 Khem Raj <raj.khem@gmail.com>:
> > On (23/06/10 12:09), Frans Meulenbroeks wrote:
> >> 2010/6/23 Koen Kooi <k.kooi@student.utwente.nl>:
> >> > -----BEGIN PGP SIGNED MESSAGE-----
> >> > Hash: SHA1
> >> >
> >> > On 23-06-10 10:53, Frans Meulenbroeks wrote:
> >> >> 2010/6/20 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
> >> >>> 2010/6/20 Koen Kooi <k.kooi@student.utwente.nl>:
> >> >>>> -----BEGIN PGP SIGNED MESSAGE-----
> >> >>>> Hash: SHA1
> >> >>>>
> >> >>>> On 20-06-10 11:58, Frans Meulenbroeks wrote:
> >> >>>>> Hi,
> >> >>>>>
> >> >>>>> I'm about to complete bringing a new architecture (nios2 with mmu) and
> >> >>>>> machine (cyclone III FPGA starter kit, and maybe also the Nios2
> >> >>>>> Embeddeded Evaluation Kit (aka neek)) to oe.
> >> >>>>> Is there a policy on on the process how to do this.
> >> >>>>
> >> >>>> Have a look at the nios2 patches Leon sent last december, they were
> >> >>>> reviewed on this list, but not committed.
> >> >>>
> >> >>> Koen, thanks for reminding me the look at the review comments.
> >> >>>
> >> >>> I'm well aware of the work of Leon and Walter (and they are well aware
> >> >>> of my work).
> >> >>> Note that what Leon posted was for a non-mmu nios2 core, whereas the
> >> >>> changes I have is for an mmu core.
> >> >>>
> >> >>> Triggered by Koens reminder I revisited the review comments. Actually
> >> >>> none but one are applicable for me.
> >> >>> The one that is applicable is the one about pinning versions in
> >> >>> machine descriptions.
> >> >>> I have also done that, as there are simply no other versions of
> >> >>> binutils and gcc that can be used by this hardware.
> >> >>> Also I don't feel empowered to make changes in distribution specific files.
> >> >>>
> >> >>> The only alternative way that I can think of is doing something like:
> >> >>> DEFAULT_PREFERENCE_nios2 = "1" in the recipes I need.
> >> >>> No idea if that overrules the distro settings or not, but I can give
> >> >>> it a try later today.
> >> >>
> >> >> Well, tried it and apparently a distro pin has priority over a
> >> >> DEFAULT_PREFERENCE_nios2 in the recipe.
> >> >> Guess I'll have to do the pinning the the machine description as
> >> >> described above.
> >> >
> >> > NO! Machines *never* pin versions, that's what distros and to a lesser
> >> > extent recipes are for.
> >>
> >> The issue is that I have no way to specify which versions of a
> >> toolchain that are supported (and to enforce that only a supported
> >> version works).
> >> If the DEFAULT_PREFERENCE in recipes had priority above whatever a
> >> distro pins using DEFAULT_PREFERENCE in the recipe could work.
> >> (e.g. if  DEFAULT_PREFERENCE = "-1" does mean something like: "does
> >> not work" and that is respected by the distro).
> >>
> >> Actually I do not want the machine to pin the recipe, I want the
> >> architecture to pin the recipe (or at least tell which versions are
> >> sound, and avoid that non-functional versions are used).
> >
> > you can use the TARGET_ARCH override to do that
> 
> I'm not fully sure how one would actually do that.Please explain it to
> me on irc.
> 

as I said see AVR32 in sane-toolchain.inc

> >>
> >> If I cannot pin in a machine file, the only alternative seems to be to
> >> make gcc-nios2-* recipes and use a virtual/gcc in the conf file to
> >> select gcc-nios2 as the preferred versions (just like a lot of
> >> machines do with virtual/kernel). Seems like a waste of effort to me,
> >> but oh well
> >
> > Already suggested a solution in prior reply.
> 
> I can pin in sane-toolchain, but only a few distro's seem to use that.

distro's are fairly independent so if you intend to support so many of them
and then you have change distro files accordingly.

> For now I think it is probably best to have gcc-nios recipes and
> define virtual/gcc in the machine configurations. (haven't really seen
> objections to that, and for virtual/kernel this seems common practise)

why do you want to compicate already complicated gcc recipes and
mechanisms. Goal should be to consolidate not to diverge.

> The best solution is indeed to have a sane-toolchain.inc that defines
> the available versions for an architecture and that is used by every
> distro, but somehow I doubt if that will happen.

well even this does come with some pricetag. There is a downside to it that changing
versions in sane-toolchain.inc would require qualification on all distro's
that use it. so more distro's harder it will be. But it could be an
achievable goal but thats distro maintainer's choice and I am fine with
whatever they choose.

Re: introducing a new architecture/machine; policy ? (and a question)

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23-06-10 22:04, Frans Meulenbroeks wrote:

> I can pin in sane-toolchain, but only a few distro's seem to use that.
> For now I think it is probably best to have gcc-nios recipes and
> define virtual/gcc in the machine configurations. (haven't really seen
> objections to that,

I object to that. Nios is no more special than avr32 or blackfin in this
regard.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMIyTlMkyGM64RGpERAuIUAJ9NiIi7TUVoRCXhHlE6JdapxKbBnwCeI6lw
+//ekU5ga2zfxNiVwnZlL/Q=
=QJca
-----END PGP SIGNATURE-----

Re: introducing a new architecture/machine; policy ? (and a question)

[Frans Meulenbroeks]

2010/6/24 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 23-06-10 22:04, Frans Meulenbroeks wrote:
>
>> I can pin in sane-toolchain, but only a few distro's seem to use that.
>> For now I think it is probably best to have gcc-nios recipes and
>> define virtual/gcc in the machine configurations. (haven't really seen
>> objections to that,
>
> I object to that. Nios is no more special than avr32 or blackfin in this
> regard.

objection noted.
btw: avr and bfin are supported gcc architectures, whereas nios2 isn't.

Frans

Re: introducing a new architecture/machine; policy ? (and a question)

[Khem Raj]

On (24/06/10 13:23), Frans Meulenbroeks wrote:
> 2010/6/24 Koen Kooi <k.kooi@student.utwente.nl>:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 23-06-10 22:04, Frans Meulenbroeks wrote:
> >
> >> I can pin in sane-toolchain, but only a few distro's seem to use that.
> >> For now I think it is probably best to have gcc-nios recipes and
> >> define virtual/gcc in the machine configurations. (haven't really seen
> >> objections to that,
> >
> > I object to that. Nios is no more special than avr32 or blackfin in this
> > regard.
> 
> objection noted.
> btw: avr and bfin are supported gcc architectures, whereas nios2 isn't.

well nios2 has patches which are not upstream fully same is true for avr
and bfin too. 

> 
> Frans
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel