On 12-09-07 01:29 PM, Philip Balister wrote:
On 09/07/2012 12:30 PM, Bruce Ashfield wrote:
On 12-09-07 12:19 PM, Richard Purdie wrote:
On Fri, 2012-09-07 at 08:27 -0400, Bruce Ashfield wrote:
On Fri, Sep 7, 2012 at 7:22 AM, Philip Balister<phi...@balister.org>
wrote:
On 09/06/2012 06:19 PM, Bruce Ashfield wrote:
Speaking of zynq, I have a simple BSP here for the zc702 board:
https://github.com/balister/meta-zynq
We have a namespace collision, there is also:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-zynq/
Before creating the layer I checked:
http://www.openembedded.org/wiki/LayerIndex
This is where layer information is collected. If a layer is not
listed here,
yo can expect namespace collisions.
Sure, I don't argue with that, but I wasn't the original owner of the
layer so
I can't say why it was or wasn't put into the wiki .. I'm not really
concerned
about the minor oversight. They layer I pointed to was done under
contract
by xilinx themselves, and contributed to be maintained as a yocto
BSP, so
the layers name is not something that I control or can change.
Other similar layers can use the same name if they want, I was
pointing it
out for reference, since I've had the same thing pointed out to me in
the past ;)
The bigger question is whether that layer is getting maintained. If it
isn't, it will likely get removed. I'd prefer it to get added to the
layer index and the namespace collision getting fixed.
I was going to cc the maintainer but there isn't one listed in the
README which is a really bad start. The feedback I gave when this was
added has not all been acted upon either (multi-dtb.inc,
layencytop/sysprof nastiness).
This puts it right at the top of my "likely to get removed soon" list.
It is being maintained, updates are pending.
Bruce: Since you have an idea who wrote it, could you find out whether
its going to get fixed (at the very least fix the README, add to the
index and resolve the namespace) or whether I should be deleting it.
Don't delete it. Work is being done. This was supposed to be a primary
repository for work, and it is the basis for spin off BSPs. There was
a handoff issue between Wind River and Xylinx .. but I don't have all
the details.
And it's something that I'll be carrying forward and pulling kernel
patches into linux-yocto on the next kernel bump.
I'll do the simple updates to the README and put it in the layer index.
I'm concerned the kernel version is the yocto project version is based
off 3.2 and the code in git.xilinx.com is based of 3.3 now.
True. But the work I mentioned is happening is to move this to 3.4.
3.2 is the version that Xilinx requested for initial integration as a
yocto BSP, so that's where it sits for now.
I do not like either situation :)
Niether do I.
But, working with vendors who provide git repos of their work, it is
easier for people using the boards to track the vendor tree, and not
spend time figuring out how to get from linux releases to the vendor tree.
In this case, they were hoping to track the yocto kernel versions to
not make version skew or spread the version landscape anymore. As far
as I know, this is still the case, since it makes the route to commercial
support simpler in some cases.
I'd like to see the layers unifed, since we need to reduce confusion,
but have some reservations about the layer on the Yocto Project server.
I'm sure we can work through them, I'm raising the right people at
Xilinx to discuss as well, since in the end, their voice carries the
most weight.
Cheers,
Bruce
Philip
Cheers,
Bruce
Cheers,
Richard
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
