Hi,
Naresh and I have been working together over the past few weeks to get the Linux UEFI Validation project [0] building for ARMv8, and while progress is being made, there's been a couple of obstacles along the way.
The main problem is that I think there are parts of meta-linaro that really need to be upstream in openembedded-core, like the meta-aarch64 layer.
Traditionally the way development of the LUV project has gone is that all the necessary core architecture support has been handled upstream in oe-core (and subsequently poky) and only the UEFI/ACPI testing components have been handled in the separate meta-luv layer. The luv-yocto repository [0] is an umbrella repository that combines poky and meta-luv, intended to alleviate the need for developers to do any layer integration themselves.
We only require very minimal architecture support and genericx86-64 has been adequate for all our needs so far, and I had originally assumed that genericaarch64 would be OK for aarch64. But that target doesn't appear to be available upstream.
Is anyone looking at getting parts of meta-linaro merged upstream?
[0] - https://github.com/01org/luv-yocto
Looping in Koen and Fathi
Graeme
On 11 November 2014 14:15, Matt Fleming matt@console-pimps.org wrote:
On 11 November 2014 15:35, G Gregory graeme.gregory@linaro.org wrote:
O no! Scary layers are scary! We must not let people know they exist!!!!one!!!
Let's start with the good news: yes, someone is looking at that. The bad news: The patches are a joke and the submitter doesn't seem to understand the objections raised.
But to get back to the big picture, you haven't said what the 'obstacles' actually are, just some vague handwaving about missing aarch64 support in OE-core. I'm curious to know what you have actually accomplished so far and even more curious to know which concrete problems you are facing. Bundling poky instead of plain OE-core makes me strongly suspect meta-luv being broken to start with.
Hi,
On 11 November 2014 17:45, Koen Kooi koen.kooi@linaro.org wrote:
ok, I understand better why Naresh asked about building poky for ARMv8.
As you may know, some work is in progress to include a new qemu machine for ARMv8 architecture. It will help in getting meta-aarch64 bits merged as YOCTO will be able to test this architecture.
Koen is referring to http://patches.openembedded.org/patch/82875/
Obviously, we're actively working on keeping metal-linaro layer a small delta as possible. We're regularly sending patches *and* test them on our autobuilders for the architectures that we care about.
I think Koen's point is valid: what are the issues observed? Is meta-luv usable with meta-linaro? i.e. can we just include the layer in our daily builds and see what breaks
Cheers,
On 11 November 2014 19:09, Fathi Boudra fathi.boudra@linaro.org wrote:
I've not seen any feedback on the latest series beyond patch squashing. I'm aware that there are now two libpng patches (and to be honest, Koen's form is neater), but what are the other issues? I've not given Kai's series a comprehensive review yet beyond seeing that it builds.
Bundling poky instead of plain OE-core makes me strongly suspect meta-luv
being broken to start with.
luv uses poky because the genericx86* BSPs in meta-yocto-bsp actually target more machines in the wild than the meta-intel BSPs, which are focused at specific chipsets.
Ross
On Tue, 11 Nov, at 09:09:18PM, Fathi Boudra wrote:
Ah, that's awesome news. That will certainly help me out with validating the arm64 kernel changes I take through my kernel.org EFI tree.
Sure you can, the layer itself is available here,
http://git.yoctoproject.org/cgit/cgit.cgi/meta-luv/
You'll need to set the DISTRO to "luv", but other than that I don't think there's anything else required.
The issues have mainly been around the fact that we rely upon the genericx86-64 currently and there's no armv8 equivalent, so I can't build and try things out without pulling in the meta-linaro layer.
Of course, we could integrate meta-linaro into luv-yocto umbrella repository, but that seems like the wrong approach to me. I'm sure other projects would benefit from seeing generic aarch64 support upstream.
-
Burton, Ross -
Fathi Boudra -
G Gregory -
Koen Kooi -
Matt Fleming