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

[Khem Raj <raj.khem@gmail.com>]

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