[meta-xilinx] linux-xlnx kernel recipe changes

[Nathan Rossi]

> -----Original Message-----
> From: Philip Balister [mailto:philip at balister.org]
> Sent: Tuesday, 10 March 2015 12:08 PM
> To: Nathan Rossi
> Cc: meta-xilinx at lists.yoctoproject.org
> Subject: Re: [meta-xilinx] linux-xlnx kernel recipe changes
> 
> 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).

For the 3.19+ kernels the USB driver is at least common (between linux-xlnx and mainline), and usb gpio resetting is there although might not cover every use case. This is handled by the chipidea driver, and a usb phy driver handles the gpio reset.

> 
> 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.

It's good to know that we are interested in the same goal, mainline. And this is the exact reason I am after feedback, as to what is preventing people from switching.

Thanks,
Nathan

> 
> 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
> >>>
> >
> >