[meta-xilinx] linux-xlnx kernel recipe changes

[Philip Balister]

On 03/09/2015 09:53 PM, Nathan Rossi wrote:
>> -----Original Message-----
>> From: Philip Balister [mailto:philip at balister.org]
>> Sent: Tuesday, 10 March 2015 4:27 AM
>> To: Nathan Rossi; meta-xilinx at lists.yoctoproject.org
>> Subject: Re: [meta-xilinx] linux-xlnx kernel recipe changes
>>
>>
>>
>> On 03/09/2015 02:25 AM, Nathan Rossi wrote:
>>> Hi all,
>>>
>>> There are some changes that I would like to get feedback on regarding
>> the kernel recipes in meta-xilinx.
>>>
>>> First off, the smaller changes.
>>>
>>> 1. MicroBlaze defaulting to linux-yocto kernel. The mainline and linux-
>> yocto kernels are quite stable regarding MicroBlaze and little has changed
>> (and linux-xlnx kernel provides little in addition to mainline for
>> MicroBlaze).
>>> 2. Drop linux-xlnx 3.10, this kernel is really old and maintaining it
>> has become a bit problematic.
>>>
>>> So the bigger change is quite different to how the current linux-xlnx
>> recipes work. The idea is to only provide a single linux-xlnx kernel via
>> an autorev kernel recipe based on the 'master' branch (sort of like linux-
>> xlnx-dev). There are a number of reasons why this approach can work
>> better, and there are a number of reasons why it might be less useful than
>> the existing approach. The primary reason why I would like to move to this
>> approach is to better support and maintain a functional linux-xlnx kernel
>> as the Xilinx kernel is maintained on the 'master' branch, including
>> features and bug fixes. Given there can be a number of different versions
>> of the linux-xlnx kernel that users would like to target for their
>> projects, it is still possible for a user to include the linux-xlnx.inc
>> and pin the specific version they are after. However I would really like
>> to get some input from those who are relying/using the linux-xlnx recipes.
>>>
>>
>> AUTOREV is evil. It means you need to be very, very careful how you rev
>> the repo it points at, and it means users may changes that break
>> something and this will confuse them.
>>
>> We use the 3.14 recipe with a bbappend to support a product.
>>
>> That said, I'd love to see a working recipe based on the a released
>> Linux kernel.
> 
> What would your opinion of a most current linux-xlnx release recipe be? This would be a recipe that is setup for the 'xilinx-v2014.4' tag of the linux-xlnx kernel. And the recipe would be manually rev'd up upon a new xilinx-v20*.* release tags. However there would only be one release at a time.

Simpler to say, I need to run a kernel that supports all the hardware I
need on the Zynq. (seems like mainline is missing fpga loader, the in
kernel driver isn't perfect for zynq, and I think there are usb issues).

I want to run mainline, since I get requests from guys doing fpga
drivers to use all manner of stuff that is in active development and
going upstream, so sitting on old kernel revs causes pain.

I know this isn't really answering your question, jsut trying get some
focus on solving the issue in the mainline Linux so we can stop worrying
about the vendor tree for anything other than helping you test work in
process.

Philip

> 
>>
>>
>>
>>> There is also the goal to switch Zynq (and ZynqMP in the future) to use
>> linux-yocto by default. However there are still a few drivers that are not
>> upstream that make the linux-yocto kernel a bit limited for the common use
>> cases. I would like to get some feedback on this also to see what everyone
>> is relying on from linux-xlnx to see if some priorities can be made to
>> have this sooner. The list I have at the moment is the following:
>>>
>>>  * macb performance and features (e.g. rgmii2gmii)
>>>  * QSPI
>>>  * devcfg
>>
>> Without devcfg, how is the fpga loaded? We depend on loading the fpga
>> from the user space application.
>>
>> Pihlip
>>
>>
>>>
>>> Thanks,
>>> Nathan
>>>
> 
>