-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi All,
I noticed that in the hardware supported in the tech specs says 64 bit only. I believe that in the f21 time frame we should be able to integrate etnaviv [1][2] and be able to offer a viable arm based option. note that arm ships in two formats, disk image that's ready to run and install tree. there is no support to run anaconda and do a liveinstall type install. For some possible systems putting the image onto a sdcard and running will be fine. But for some others there may be a desire to install onto a hard drive to use.
I personally believe that it is a viable target.
Dennis [1] https://github.com/laanwj/etna_viv [2] https://plus.google.com/+ArndBergmann/posts/bjja7uW9vA4
On Fri, Mar 07, 2014 at 11:52:30AM -0600, Dennis Gilmore wrote:
I noticed that in the hardware supported in the tech specs says 64 bit only. I believe that in the f21 time frame we should be able to integrate etnaviv [1][2] and be able to offer a viable arm based option. note that arm ships in two formats, disk image that's ready to run and install tree. there is no support to run anaconda and do a liveinstall type install. For some possible systems putting the image onto a sdcard and running will be fine. But for some others there may be a desire to install onto a hard drive to use.
It was a requirement that ARM provide Anaconda support where possible in order to be promoted. If we're talking about hardware that's so limited that Anaconda doesn't make sense, I don't think Workstation makes sense either.
On Fri, Mar 7, 2014 at 12:52 PM, Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi All,
I noticed that in the hardware supported in the tech specs says 64 bit only. I believe that in the f21 time frame we should be able to integrate etnaviv [1][2] and be able to offer a viable arm based option. note that arm ships in two formats, disk image that's ready to run and install tree. there is no support to run anaconda and do a liveinstall type install. For some possible systems putting the image onto a sdcard and running will be fine. But for some others there may be a desire to install onto a hard drive to use.
I personally believe that it is a viable target.
I won't speak for the rest of the WG as a whole, but in the few conversations I've had with people ARM wasn't something most thought was a target for Workstation. It might be feasible for interested people to produce Workstation ARM images, but I would be surprised if that were made a requirement at this point.
WG members, thoughts?
josh
On Fri, Mar 07, 2014 at 02:43:10PM -0500, Josh Boyer wrote:
I won't speak for the rest of the WG as a whole, but in the few conversations I've had with people ARM wasn't something most thought was a target for Workstation. It might be feasible for interested people to produce Workstation ARM images, but I would be surprised if that were made a requirement at this point.
There's ARM hardware that is, at least theoretically, capable of running Workstation and has the kind of form factor for which Workstation is probably the appropriate product. As long as the ARM team are willing to take responsibility for ensuring drivers and install media work, and as long as there's someone doing QA, it seems like something we should support in an official sense.
On Fri, 2014-03-07 at 19:49 +0000, Matthew Garrett wrote:
On Fri, Mar 07, 2014 at 02:43:10PM -0500, Josh Boyer wrote:
I won't speak for the rest of the WG as a whole, but in the few conversations I've had with people ARM wasn't something most thought was a target for Workstation. It might be feasible for interested people to produce Workstation ARM images, but I would be surprised if that were made a requirement at this point.
There's ARM hardware that is, at least theoretically, capable of running Workstation and has the kind of form factor for which Workstation is probably the appropriate product. As long as the ARM team are willing to take responsibility for ensuring drivers and install media work, and as long as there's someone doing QA, it seems like something we should support in an official sense.
I think it's reasonable to plan for its inclusion For The Future. From what I hear from dgilmore I'm not sure making it an official arch for F21 would be a great idea, but it seems sensible to keep it in mind for future inclusion while we're implementing the initial design. It certainly seems like workstation/desktop-class ARM hardware is a thing that's happening: there already are ARM-based systems probably powerful enough to run Workstation, the Utilite, the ARM Chromebooks. We don't have all the bits in place to support them *yet*, but it certainly seems like we will, and it seems reasonable to assume others will follow where they lead.
On Fri, Mar 7, 2014 at 3:03 PM, Adam Williamson awilliam@redhat.com wrote:
On Fri, 2014-03-07 at 19:49 +0000, Matthew Garrett wrote:
On Fri, Mar 07, 2014 at 02:43:10PM -0500, Josh Boyer wrote:
I won't speak for the rest of the WG as a whole, but in the few conversations I've had with people ARM wasn't something most thought was a target for Workstation. It might be feasible for interested people to produce Workstation ARM images, but I would be surprised if that were made a requirement at this point.
There's ARM hardware that is, at least theoretically, capable of running Workstation and has the kind of form factor for which Workstation is probably the appropriate product. As long as the ARM team are willing to take responsibility for ensuring drivers and install media work, and as long as there's someone doing QA, it seems like something we should support in an official sense.
I think it's reasonable to plan for its inclusion For The Future. From what I hear from dgilmore I'm not sure making it an official arch for F21 would be a great idea, but it seems sensible to keep it in mind for future inclusion while we're implementing the initial design. It certainly seems like workstation/desktop-class ARM hardware is a thing that's happening: there already are ARM-based systems probably powerful enough to run Workstation, the Utilite, the ARM Chromebooks. We don't have all the bits in place to support them *yet*, but it certainly seems like we will, and it seems reasonable to assume others will follow where they lead.
Sure, future is always up for discussion. We'll likely need to evaluate AArch64 machines when they show up too. Dennis led the discussion with F21 though, hence my hesitation.
josh
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 07 Mar 2014 12:03:28 -0800 Adam Williamson awilliam@redhat.com wrote:
On Fri, 2014-03-07 at 19:49 +0000, Matthew Garrett wrote:
On Fri, Mar 07, 2014 at 02:43:10PM -0500, Josh Boyer wrote:
I won't speak for the rest of the WG as a whole, but in the few conversations I've had with people ARM wasn't something most thought was a target for Workstation. It might be feasible for interested people to produce Workstation ARM images, but I would be surprised if that were made a requirement at this point.
There's ARM hardware that is, at least theoretically, capable of running Workstation and has the kind of form factor for which Workstation is probably the appropriate product. As long as the ARM team are willing to take responsibility for ensuring drivers and install media work, and as long as there's someone doing QA, it seems like something we should support in an official sense.
I think it's reasonable to plan for its inclusion For The Future. From what I hear from dgilmore I'm not sure making it an official arch for F21 would be a great idea, but it seems sensible to keep it in mind for future inclusion while we're implementing the initial design. It certainly seems like workstation/desktop-class ARM hardware is a thing that's happening: there already are ARM-based systems probably powerful enough to run Workstation, the Utilite, the ARM Chromebooks. We don't have all the bits in place to support them *yet*, but it certainly seems like we will, and it seems reasonable to assume others will follow where they lead.
I am okay with planning it as a future things, Server plans to support ARM, and Cloud has it listed as a future thing. I think we can make things work in the f21 time frame on a subset of hardware. But I am okay with it being nice to have, or slipping to f22. I raised my concerns because today it looks like the only consideration is x86_64 with no possibility of anything else.
Dennis
On Fri, Mar 7, 2014 at 3:37 PM, Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 07 Mar 2014 12:03:28 -0800 Adam Williamson awilliam@redhat.com wrote:
On Fri, 2014-03-07 at 19:49 +0000, Matthew Garrett wrote:
On Fri, Mar 07, 2014 at 02:43:10PM -0500, Josh Boyer wrote:
I won't speak for the rest of the WG as a whole, but in the few conversations I've had with people ARM wasn't something most thought was a target for Workstation. It might be feasible for interested people to produce Workstation ARM images, but I would be surprised if that were made a requirement at this point.
There's ARM hardware that is, at least theoretically, capable of running Workstation and has the kind of form factor for which Workstation is probably the appropriate product. As long as the ARM team are willing to take responsibility for ensuring drivers and install media work, and as long as there's someone doing QA, it seems like something we should support in an official sense.
I think it's reasonable to plan for its inclusion For The Future. From what I hear from dgilmore I'm not sure making it an official arch for F21 would be a great idea, but it seems sensible to keep it in mind for future inclusion while we're implementing the initial design. It certainly seems like workstation/desktop-class ARM hardware is a thing that's happening: there already are ARM-based systems probably powerful enough to run Workstation, the Utilite, the ARM Chromebooks. We don't have all the bits in place to support them *yet*, but it certainly seems like we will, and it seems reasonable to assume others will follow where they lead.
I am okay with planning it as a future things, Server plans to support ARM, and Cloud has it listed as a future thing. I think we can make things work in the f21 time frame on a subset of hardware. But I am okay with it being nice to have, or slipping to f22. I raised my concerns because today it looks like the only consideration is x86_64 with no possibility of anything else.
Ah, ok. We should probably put a limiter on the Tech Spec for F21, or conversely say it's a living document like we do with the PRD.
josh
On Fri, Mar 7, 2014 at 2:49 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
On Fri, Mar 07, 2014 at 02:43:10PM -0500, Josh Boyer wrote:
I won't speak for the rest of the WG as a whole, but in the few conversations I've had with people ARM wasn't something most thought was a target for Workstation. It might be feasible for interested people to produce Workstation ARM images, but I would be surprised if that were made a requirement at this point.
There's ARM hardware that is, at least theoretically, capable of running Workstation and has the kind of form factor for which Workstation is probably the appropriate product. As long as the ARM team are willing to take responsibility for ensuring drivers and install media work, and as long as there's someone doing QA, it seems like something we should support in an official sense.
My concern would be that without it being an official target from the start, we run the risk of brokenness being found late in the game. Does it seem possible to add an "official" designation to ARM (and i686 for that matter) if things prove to be working by whatever cutoff date we have? That would seem to put more impetus on the people doing the things you suggest without us declaring either of those architectures by default.
I'm not as optimistic as some when it comes to viable accelerated graphics hardware on ARM in the F21 timeframe. If testing of Workstation ARM can't even begin until things are merged, and that happens at the tail end of the development window, I don't really want us to be stuck in the blocker/demotion game if it doesn't happen. Opportunistic "promotion" seems a decent compromise.
josh
On Fri, Mar 07, 2014 at 03:04:15PM -0500, Josh Boyer wrote:
My concern would be that without it being an official target from the start, we run the risk of brokenness being found late in the game. Does it seem possible to add an "official" designation to ARM (and i686 for that matter) if things prove to be working by whatever cutoff date we have? That would seem to put more impetus on the people doing the things you suggest without us declaring either of those architectures by default.
Yeah, I think that it would be an error to commit to it until there's been a demonstration that this is achievable - and the onus should be on the ARM people to demonstrate that. I don't want to end up with one of our first deliverables being a sub-par experience. If it can't run Shell reliably and with adequate performance then it buys us nothing to ship it.
I'm not as optimistic as some when it comes to viable accelerated graphics hardware on ARM in the F21 timeframe. If testing of Workstation ARM can't even begin until things are merged, and that happens at the tail end of the development window, I don't really want us to be stuck in the blocker/demotion game if it doesn't happen. Opportunistic "promotion" seems a decent compromise.
Not going to disagree.
My concern would be that without it being an official target from the start, we run the risk of brokenness being found late in the game. Does it seem possible to add an "official" designation to ARM (and i686 for that matter) if things prove to be working by whatever cutoff date we have? That would seem to put more impetus on the people doing the things you suggest without us declaring either of those architectures by default.
Yeah, I think that it would be an error to commit to it until there's been a demonstration that this is achievable - and the onus should be on the ARM people to demonstrate that. I don't want to end up with one of our first deliverables being a sub-par experience. If it can't run Shell reliably and with adequate performance then it buys us nothing to ship it.
I agree with this sentiment, but like Dennis I wouldn't want to see it excluded entirely because it wasn't discussed at the beginning.
I'm not as optimistic as some when it comes to viable accelerated graphics hardware on ARM in the F21 timeframe. If testing of Workstation ARM can't even begin until things are merged, and that happens at the tail end of the development window, I don't really want us to be stuck in the blocker/demotion game if it doesn't happen. Opportunistic "promotion" seems a decent compromise.
Not going to disagree.
There are two possible candidates of HW class that would (could) make Workstation a nice option on ARM in the timeframe of F-21 but as both are out of my control I'm not going to get excited until I have them working in front of me let alone be naive to throw the hat in the ring. We've got around 6 months until the release of F-21 if it's something that evolves into that in a reasonable time in the interim and the moving planets align at the right time with enough time I believe it's worth reassessment then.
Peter
----- Original Message -----
From: "Josh Boyer" jwboyer@fedoraproject.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Friday, March 7, 2014 8:43:10 PM Subject: Re: arm support of workstation product
On Fri, Mar 7, 2014 at 12:52 PM, Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi All,
I noticed that in the hardware supported in the tech specs says 64 bit only. I believe that in the f21 time frame we should be able to integrate etnaviv [1][2] and be able to offer a viable arm based option. note that arm ships in two formats, disk image that's ready to run and install tree. there is no support to run anaconda and do a liveinstall type install. For some possible systems putting the image onto a sdcard and running will be fine. But for some others there may be a desire to install onto a hard drive to use.
I personally believe that it is a viable target.
I won't speak for the rest of the WG as a whole, but in the few conversations I've had with people ARM wasn't something most thought was a target for Workstation. It might be feasible for interested people to produce Workstation ARM images, but I would be surprised if that were made a requirement at this point.
WG members, thoughts?
I don't have an issue with ARM (or PPC) builds of the workstation, but I don't think we should decide to make them officially supported platforms before we feel very certain there is a viable community and ecosystem around them to make the product workable medium to long term on those platforms. This means of cause the basic lithmus test of having the shell 'work' on a specific piece of hardware, but also there needs to be a viable roadmap for that hardware going forward. I mean I don't want a situation where we declare ARM supported because someone got a build working on a specific dev board, only to have the manufacturer of that devboard switch GPU provider in the next iteration and leave us without a working open driver.
Rob Clark is doing stellar work on Freedreno and the new Broadcom source code release is good news in this regard, but I think I personally need to feel that a officially supported ARM platform needs to be something we can believe will continue to exist and not a one shot 'the stars aligned for us' situation.
There is also a question of what kind of hardware we want to support here, for instance if someone made ARM based laptops or desktops that seems like an obvious target, but officially supporting something like the RasperryPi or PandaBoard seems maybe something of an overkill. A homebrew devboard seems like it can be 'supported' well by just having an unofficial build for it.
As a sidenote writing portable code is important regardless of what platforms we have chosen to deem be 'supported' by the Workstation product.
Christian
I don't have an issue with ARM (or PPC) builds of the workstation, but I don't think we should decide to make them officially supported platforms before we feel very certain there is a viable community and ecosystem around them to make the product workable medium to long term on those platforms. This means of cause the basic lithmus test of having the shell 'work' on a specific piece of hardware, but also there needs to be a viable roadmap for that hardware going forward. I mean I don't want a situation where we declare ARM supported because someone got a build working on a specific dev board, only to have the manufacturer of that devboard switch GPU provider in the next iteration and leave us without a working open driver.
Believe me you are not alone in that regard, it's a discussion the ARM people have on a regular basis. We've already had one vendor and another SoC go from hero to zero in a short period of time :-)
Rob Clark is doing stellar work on Freedreno and the new Broadcom source code release is good news in this regard, but I think I personally need to feel that a officially supported ARM platform needs to be something we can believe will continue to exist and not a one shot 'the stars aligned for us' situation.
Personally I'm not sure either of those are of much value. The QCom devices are primarily used in phones which aren't really targets for Fedora ARM. There's currently one dev board I'm aware of and it's not widely available and it's not currently anywhere on our roadmap when it comes to the kernel.
The Broadcom one would possibly be of interest if there was a usable driver and HW we could support of which there is neither at the moment.
The two platforms that are of interest to me and I think will provide us value in the short to medium term is SoCs with the Vivante GPU of which there is an open driver that is very close to supporting mesa. These cover the i.MX6 devices of which we already will support well over a dozen discrete devices in the F-21 timeframe, the ARM based OLPC XO laptops, and a bunch of differing Marvell SoC based devices. The other platform is the Tegra K1 devices which will be supported by nouveau and are a being announced in decent devices like netbooks, likely chromebooks and all in one style desktops.
There is also a question of what kind of hardware we want to support here, for instance if someone made ARM based laptops or desktops that seems like an obvious target, but officially supporting something like the RasperryPi or PandaBoard seems maybe something of an overkill. A homebrew devboard seems like it can be 'supported' well by just having an unofficial build for it.
There's already a bunch of mini desktops based on the aforementioned i.MX6 and there's an interesting array of devices that are not dissimilar to a large tablet on a stand all in one style devices but with keyboard and mouse attached, of course there's various netbooks esq devices too. Fedora ARM isn't interested in phones and similar as I just don't believe they would provide a decent user experience with the workstation product.
Peter
On Mar 23, 2014 6:44 AM, "Peter Robinson" pbrobinson@gmail.com wrote:
I don't have an issue with ARM (or PPC) builds of the workstation, but I don't think we should decide to make them officially supported
platforms
before we feel very certain there is a viable community and ecosystem
around
them to make the product workable medium to long term on those
platforms.
This means of cause the basic lithmus test of having the shell 'work'
on a specific
piece of hardware, but also there needs to be a viable roadmap for that
hardware
going forward. I mean I don't want a situation where we declare ARM
supported
because someone got a build working on a specific dev board, only to
have the
manufacturer of that devboard switch GPU provider in the next iteration
and leave
us without a working open driver.
Believe me you are not alone in that regard, it's a discussion the ARM people have on a regular basis. We've already had one vendor and another SoC go from hero to zero in a short period of time :-)
Rob Clark is doing stellar work on Freedreno and the new Broadcom
source code release
is good news in this regard, but I think I personally need to feel that
a
officially supported ARM platform needs to be something we can believe
will
continue to exist and not a one shot 'the stars aligned for us'
situation.
Personally I'm not sure either of those are of much value. The QCom devices are primarily used in phones which aren't really targets for Fedora ARM. There's currently one dev board I'm aware of and it's not widely available and it's not currently anywhere on our roadmap when it comes to the kernel.
I'm guessing you're referring to this: http://mydragonboard.org/db8074/ Although listed as a SoM, it looks like the carrier board is optional with the 12V jack. No idea about the availability, though, but should certainly be capable of running any of the workstation products... if it can actually run any of the workstation products...
<snip>
On Sun, Mar 23, 2014 at 11:03 AM, Liam liam.bulkley@gmail.com wrote:
On Mar 23, 2014 6:44 AM, "Peter Robinson" pbrobinson@gmail.com wrote:
I don't have an issue with ARM (or PPC) builds of the workstation, but I don't think we should decide to make them officially supported platforms before we feel very certain there is a viable community and ecosystem around them to make the product workable medium to long term on those platforms. This means of cause the basic lithmus test of having the shell 'work' on a specific piece of hardware, but also there needs to be a viable roadmap for that hardware going forward. I mean I don't want a situation where we declare ARM supported because someone got a build working on a specific dev board, only to have the manufacturer of that devboard switch GPU provider in the next iteration and leave us without a working open driver.
Believe me you are not alone in that regard, it's a discussion the ARM people have on a regular basis. We've already had one vendor and another SoC go from hero to zero in a short period of time :-)
Rob Clark is doing stellar work on Freedreno and the new Broadcom source code release is good news in this regard, but I think I personally need to feel that a officially supported ARM platform needs to be something we can believe will continue to exist and not a one shot 'the stars aligned for us' situation.
Personally I'm not sure either of those are of much value. The QCom devices are primarily used in phones which aren't really targets for Fedora ARM. There's currently one dev board I'm aware of and it's not widely available and it's not currently anywhere on our roadmap when it comes to the kernel.
I'm guessing you're referring to this: http://mydragonboard.org/db8074/ Although listed as a SoM, it looks like the carrier board is optional with the 12V jack. No idea about the availability, though, but should certainly be capable of running any of the workstation products... if it can actually run any of the workstation products...
fyi: dragonboard: http://shop.intrinsyc.com/products/snapdragon-800-series-apq8074-based-drago... ifc6410: http://www.inforcelive.com/index.php?route=product/product&filter_name=i...
Both are running (the same) f20 userspace + latest mesa/libdrm + xf86-video-freedreno (sorry, I'm lagging on updating for review comments for the .spec file) + custom kernel. Gnome-shell works perfectly. As do most of the games packaged in fedora that I have tried. (xonotic, supertuxkart, etc)
f21 should have a new enough mesa. For just gnome-shell 10.1.x should be enough.. for games, you'll want newer. The missing piece is an upstream kernel. But we are getting there.
BR, -R
<snip>
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Apr 7, 2014 10:58 PM, "Rob Clark" robdclark@gmail.com wrote:
On Sun, Mar 23, 2014 at 11:03 AM, Liam liam.bulkley@gmail.com wrote:
On Mar 23, 2014 6:44 AM, "Peter Robinson" pbrobinson@gmail.com wrote:
I don't have an issue with ARM (or PPC) builds of the workstation,
but
I don't think we should decide to make them officially supported platforms before we feel very certain there is a viable community and ecosystem around them to make the product workable medium to long term on those platforms. This means of cause the basic lithmus test of having the shell
'work' on
a specific piece of hardware, but also there needs to be a viable roadmap for
that
hardware going forward. I mean I don't want a situation where we declare ARM supported because someone got a build working on a specific dev board, only to have the manufacturer of that devboard switch GPU provider in the next
iteration
and leave us without a working open driver.
Believe me you are not alone in that regard, it's a discussion the ARM people have on a regular basis. We've already had one vendor and another SoC go from hero to zero in a short period of time :-)
Rob Clark is doing stellar work on Freedreno and the new Broadcom
source
code release is good news in this regard, but I think I personally need to feel
that
a officially supported ARM platform needs to be something we can
believe
will continue to exist and not a one shot 'the stars aligned for us' situation.
Personally I'm not sure either of those are of much value. The QCom devices are primarily used in phones which aren't really targets for Fedora ARM. There's currently one dev board I'm aware of and it's not widely available and it's not currently anywhere on our roadmap when it comes to the kernel.
I'm guessing you're referring to this: http://mydragonboard.org/db8074/ Although listed as a SoM, it looks like the carrier board is optional
with
the 12V jack. No idea about the availability, though, but should certainly be capable
of
running any of the workstation products... if it can actually run any
of the
workstation products...
fyi: dragonboard:
http://shop.intrinsyc.com/products/snapdragon-800-series-apq8074-based-drago...
ifc6410:
http://www.inforcelive.com/index.php?route=product/product&filter_name=i...
Both are running (the same) f20 userspace + latest mesa/libdrm + xf86-video-freedreno (sorry, I'm lagging on updating for review comments for the .spec file) + custom kernel. Gnome-shell works perfectly. As do most of the games packaged in fedora that I have tried. (xonotic, supertuxkart, etc)
f21 should have a new enough mesa. For just gnome-shell 10.1.x should be enough.. for games, you'll want newer. The missing piece is an upstream kernel. But we are getting there.
BR, -R
To be clear, you're saying f20 currently supports the apq8074? The newer kernel would be needed to make gaming a possibility, but not for hardware enablement? Do you know if f20 is enough for the SoM as well?
Best/Liam
On Mon, Apr 7, 2014 at 11:43 PM, Liam liam.bulkley@gmail.com wrote:
On Apr 7, 2014 10:58 PM, "Rob Clark" robdclark@gmail.com wrote:
On Sun, Mar 23, 2014 at 11:03 AM, Liam liam.bulkley@gmail.com wrote:
On Mar 23, 2014 6:44 AM, "Peter Robinson" pbrobinson@gmail.com wrote:
I don't have an issue with ARM (or PPC) builds of the workstation, but I don't think we should decide to make them officially supported platforms before we feel very certain there is a viable community and ecosystem around them to make the product workable medium to long term on those platforms. This means of cause the basic lithmus test of having the shell 'work' on a specific piece of hardware, but also there needs to be a viable roadmap for that hardware going forward. I mean I don't want a situation where we declare ARM supported because someone got a build working on a specific dev board, only to have the manufacturer of that devboard switch GPU provider in the next iteration and leave us without a working open driver.
Believe me you are not alone in that regard, it's a discussion the ARM people have on a regular basis. We've already had one vendor and another SoC go from hero to zero in a short period of time :-)
Rob Clark is doing stellar work on Freedreno and the new Broadcom source code release is good news in this regard, but I think I personally need to feel that a officially supported ARM platform needs to be something we can believe will continue to exist and not a one shot 'the stars aligned for us' situation.
Personally I'm not sure either of those are of much value. The QCom devices are primarily used in phones which aren't really targets for Fedora ARM. There's currently one dev board I'm aware of and it's not widely available and it's not currently anywhere on our roadmap when it comes to the kernel.
I'm guessing you're referring to this: http://mydragonboard.org/db8074/ Although listed as a SoM, it looks like the carrier board is optional with the 12V jack. No idea about the availability, though, but should certainly be capable of running any of the workstation products... if it can actually run any of the workstation products...
fyi: dragonboard: http://shop.intrinsyc.com/products/snapdragon-800-series-apq8074-based-drago... ifc6410: http://www.inforcelive.com/index.php?route=product/product&filter_name=i...
Both are running (the same) f20 userspace + latest mesa/libdrm + xf86-video-freedreno (sorry, I'm lagging on updating for review comments for the .spec file) + custom kernel. Gnome-shell works perfectly. As do most of the games packaged in fedora that I have tried. (xonotic, supertuxkart, etc)
f21 should have a new enough mesa. For just gnome-shell 10.1.x should be enough.. for games, you'll want newer. The missing piece is an upstream kernel. But we are getting there.
BR, -R
To be clear, you're saying f20 currently supports the apq8074? The newer kernel would be needed to make gaming a possibility, but not for hardware enablement?
well, not quite.. what is missing from f20 userspace amounts to:
* xf86-video-freedreno * newer mesa & libdrm
The remaining improvements vs mesa 10.1 (for games, etc) are all userspace (mesa) and are all on mesa master.
For anyone who has a dragonboard/ifc6410/etc, for f20 I recommend:
http://blog.kwizart.fr/post/2014/03/02/163-mesa-10.2-from-git-for-Fedora-20
(but I expect this all to be in f21)
Do you know if f20 is enough for the SoM as well?
userspace should be the same for the SoM. But for upstream kernel maybe there is need for a different .dts file.
(but that said, I think the dragonboard is just the SoM + carrier board, so maybe from kernel perspective it looks the same as the full dragonboard)
BR, -R
Best/Liam
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Apr 8, 2014 12:02 AM, "Rob Clark" robdclark@gmail.com wrote:
On Mon, Apr 7, 2014 at 11:43 PM, Liam liam.bulkley@gmail.com wrote:
On Apr 7, 2014 10:58 PM, "Rob Clark" robdclark@gmail.com wrote:
On Sun, Mar 23, 2014 at 11:03 AM, Liam liam.bulkley@gmail.com wrote:
On Mar 23, 2014 6:44 AM, "Peter Robinson" pbrobinson@gmail.com
wrote:
I don't have an issue with ARM (or PPC) builds of the workstation, but I don't think we should decide to make them officially supported platforms before we feel very certain there is a viable community and
ecosystem
around them to make the product workable medium to long term on those platforms. This means of cause the basic lithmus test of having the shell
'work'
on a specific piece of hardware, but also there needs to be a viable roadmap for that hardware going forward. I mean I don't want a situation where we declare
ARM
supported because someone got a build working on a specific dev board, only
to
have the manufacturer of that devboard switch GPU provider in the next iteration and leave us without a working open driver.
Believe me you are not alone in that regard, it's a discussion the
ARM
people have on a regular basis. We've already had one vendor and another SoC go from hero to zero in a short period of time :-)
Rob Clark is doing stellar work on Freedreno and the new Broadcom source code release is good news in this regard, but I think I personally need to feel that a officially supported ARM platform needs to be something we can believe will continue to exist and not a one shot 'the stars aligned for us' situation.
Personally I'm not sure either of those are of much value. The QCom devices are primarily used in phones which aren't really targets for Fedora ARM. There's currently one dev board I'm aware of and it's
not
widely available and it's not currently anywhere on our roadmap when it comes to the kernel.
I'm guessing you're referring to this:
http://mydragonboard.org/db8074/
Although listed as a SoM, it looks like the carrier board is optional with the 12V jack. No idea about the availability, though, but should certainly be
capable
of running any of the workstation products... if it can actually run
any of
the workstation products...
fyi: dragonboard:
http://shop.intrinsyc.com/products/snapdragon-800-series-apq8074-based-drago...
ifc6410:
http://www.inforcelive.com/index.php?route=product/product&filter_name=i...
Both are running (the same) f20 userspace + latest mesa/libdrm + xf86-video-freedreno (sorry, I'm lagging on updating for review comments for the .spec file) + custom kernel. Gnome-shell works perfectly. As do most of the games packaged in fedora that I have tried. (xonotic, supertuxkart, etc)
f21 should have a new enough mesa. For just gnome-shell 10.1.x should be enough.. for games, you'll want newer. The missing piece is an upstream kernel. But we are getting there.
BR, -R
To be clear, you're saying f20 currently supports the apq8074? The newer kernel would be needed to make gaming a possibility, but not for
hardware
enablement?
well, not quite.. what is missing from f20 userspace amounts to:
- xf86-video-freedreno
- newer mesa & libdrm
The remaining improvements vs mesa 10.1 (for games, etc) are all userspace (mesa) and are all on mesa master.
For anyone who has a dragonboard/ifc6410/etc, for f20 I recommend:
http://blog.kwizart.fr/post/2014/03/02/163-mesa-10.2-from-git-for-Fedora-20
(but I expect this all to be in f21)
... and that's why I asked:) Thanks for the clarification.
Do you know if f20 is enough for the SoM as well?
userspace should be the same for the SoM. But for upstream kernel maybe there is need for a different .dts file.
(but that said, I think the dragonboard is just the SoM + carrier board, so maybe from kernel perspective it looks the same as the full dragonboard)
It was device tree that I was mainly thinking about and given how board specific those files are, I wasnt sure that even if it was literally, as you say above, that it could still be enabled with the same dts.
Best/Liam
On Sun, Mar 23, 2014 at 6:44 AM, Peter Robinson pbrobinson@gmail.com wrote:
I don't have an issue with ARM (or PPC) builds of the workstation, but I don't think we should decide to make them officially supported platforms before we feel very certain there is a viable community and ecosystem around them to make the product workable medium to long term on those platforms. This means of cause the basic lithmus test of having the shell 'work' on a specific piece of hardware, but also there needs to be a viable roadmap for that hardware going forward. I mean I don't want a situation where we declare ARM supported because someone got a build working on a specific dev board, only to have the manufacturer of that devboard switch GPU provider in the next iteration and leave us without a working open driver.
a potential issue for the SoC's which use 3p gpu (everyone but qcom and nvidia).
ofc, the flip side is some SoC vendor could switch from (for example) IMG to vivante.. Not sure what that means from a planning standpoint. But I don't think we should let that block us. It just might mean that way say (for example) that "XYZ imx6 board is supported" rather than "freescale is supported". A specific SoC part # is not going to have multiple variants with different GPU. It would be a different part #.
Believe me you are not alone in that regard, it's a discussion the ARM people have on a regular basis. We've already had one vendor and another SoC go from hero to zero in a short period of time :-)
Rob Clark is doing stellar work on Freedreno and the new Broadcom source code release is good news in this regard, but I think I personally need to feel that a officially supported ARM platform needs to be something we can believe will continue to exist and not a one shot 'the stars aligned for us' situation.
Personally I'm not sure either of those are of much value. The QCom devices are primarily used in phones which aren't really targets for Fedora ARM. There's currently one dev board I'm aware of and it's not widely available and it's not currently anywhere on our roadmap when it comes to the kernel.
I think upstream kernel on ifc6410 in time for f21 is actually doable. I have very basic stuff (serial console) on upstream kernel since last Dec. Getting display and gpu going has a lot of dependencies, but the clk stuff is there already, and we aren't that far off on the rest. Once linaro qcom landing team is ramped up, things should only be moving faster.
Personally, I'd like to see both etnaviv and freedreno in f21.. etnaviv/imx6 is in better shape on general kernel, but missing drm and x11 support (but that is in-progress). Freedreno/snapdragon is in better shape in userspace and has drm/kms driver for gpu and display, but rest of kernel is further behind (but still I think within reach for f21)
Just fyi: current qcom boards:
+ ifc6410 - has been shipping for a while now ($149) + ifc6412 - not shipping yet ($99) + bstem - not shipping widely yet ($??) + dragonboard - shipping for a while ($if_you_have_to_ask..)
(and, well, I expect we will see more in the future with qcom as a linaro member now.. they were a pretty late on the whole community-hacker-board scene but are catching up)
The Broadcom one would possibly be of interest if there was a usable driver and HW we could support of which there is neither at the moment.
they now know how to drive the hw.. (big props to bcom for docs!).. but there is a lot of work before we can have an upstream driver, due to some of the memory protection challenges w/ the r-pi architecture. And also the armv6 thing. But we should definitely keep an eye on bcom for their future SoC's..
The two platforms that are of interest to me and I think will provide us value in the short to medium term is SoCs with the Vivante GPU of which there is an open driver that is very close to supporting mesa. These cover the i.MX6 devices of which we already will support well over a dozen discrete devices in the F-21 timeframe, the ARM based OLPC XO laptops, and a bunch of differing Marvell SoC based devices. The other platform is the Tegra K1 devices which will be supported by nouveau and are a being announced in decent devices like netbooks, likely chromebooks and all in one style desktops.
given the timeframe for availability of the jetson board, tegra K1 should also be a very real possibility. If not f21 then most certainly f22.
BR, -R
There is also a question of what kind of hardware we want to support here, for instance if someone made ARM based laptops or desktops that seems like an obvious target, but officially supporting something like the RasperryPi or PandaBoard seems maybe something of an overkill. A homebrew devboard seems like it can be 'supported' well by just having an unofficial build for it.
There's already a bunch of mini desktops based on the aforementioned i.MX6 and there's an interesting array of devices that are not dissimilar to a large tablet on a stand all in one style devices but with keyboard and mouse attached, of course there's various netbooks esq devices too. Fedora ARM isn't interested in phones and similar as I just don't believe they would provide a decent user experience with the workstation product.
Peter
desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
desktop@lists.stg.fedoraproject.org
-
Adam Williamson -
Christian Schaller -
Dennis Gilmore -
Josh Boyer -
Liam -
Matthew Garrett -
Peter Robinson -
Rob Clark