[meta-xilinx] linux-xlnx kernel recipe changes

[Joe Nicholson]

Hi Nathan

We use meta-xilinx with the Zynq 702.  I like the aim of moving over to
linux-yocto kernel for standardisation and onward development reasons.

Taking a look through the drivers that aren't yet mainline,  I see a few
we'd definitely need:

- devcfg (to program the PL from userspace)
- USB gadget (need for configuring our device)
- Ethernet MAC

Less importantly
- QSPI

So, that's our wish list :-)

Cheers!

Joe Nicholson


-----Original Message-----
From: meta-xilinx-bounces at yoctoproject.org
[mailto:meta-xilinx-bounces at yoctoproject.org] On Behalf Of Nathan Rossi
Sent: 10 March 2015 03:41
To: Philip Balister
Cc: meta-xilinx at lists.yoctoproject.org
Subject: Re: [meta-xilinx] linux-xlnx kernel recipe changes

> -----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
> >>>
> >
> >
--
_______________________________________________
meta-xilinx mailing list
meta-xilinx at yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx