Looking at getting a cubietruck, (http://www.cubietruck.com/collections/frontpage/products/cubietruck-cubieboa...) which appear to be covered by: https://fedoraproject.org/wiki/Architectures/ARM/F20/Remixes
So figured I'd ask. Would Fedora install and run on it, or remix only?
Hi,
On 12/22/2013 10:36 AM, Frank Murphy wrote:
Looking at getting a cubietruck, (http://www.cubietruck.com/collections/frontpage/products/cubietruck-cubieboa...) which appear to be covered by: https://fedoraproject.org/wiki/Architectures/ARM/F20/Remixes
So figured I'd ask. Would Fedora install and run on it, or remix only?
Remix only (which still needs to be updated to F-20, it is F-19 atm). The plan is to offer native support for cubietruck in F-21.
Regards,
Hans (the author of the remix)
I see vfat images dated this month, however still indicating the serial console requirement.
When will we get to a bootable image, with usb/hdmi support please?
Adrian ... vk4tux
I see vfat images dated this month, however still indicating the serial console requirement.
When will we get to a bootable image, with usb/hdmi support please?
Adrian ... vk4tux
On Sun, Dec 22, 2013 at 12:59 PM, Adrian vk4tux@bigpond.com wrote:
I see vfat images dated this month, however still indicating the serial console requirement.
When will we get to a bootable image, with usb/hdmi support please?
When I get time. I'll send out an email to the list when I do.
Peter
On 12/22/2013 08:59 PM, Adrian wrote:
I see vfat images dated this month, however still indicating the serial console requirement.
When will we get to a bootable image, with usb/hdmi support please?
Adrian ... vk4tux
This month's VFAT image for the Beaglebone Black is badly broken. If you want something workable use an older image.Fedora-Minimal-VFAT-armhfp-20-1-sda.raw.xz http://ftp.jaist.ac.jp/pub/Linux/Fedora/releases/20/Images/armhfp/Fedora-Minimal-VFAT-armhfp-20-1-sda.raw.xz contains a kernel which keep oops'ing on certain operations, like an outbound slogin attempt. I reported that and the response was kernel RPM 3.12.5-302 which results in a board which will not boot at all.
It looks like kernel-3.12.5-302 fixes various things for x86_64 machines, so it is an improvement for them, yet it really wrecks an ARM installation. I guess we can expect ARM to always be a secondary architecture, with anything that benefits x86_64 users being pushed, regardless of its effects on other users.
Regards, Steve
On Sun, Dec 22, 2013 at 2:34 PM, Steve Underwood steveu@coppice.org wrote:
On 12/22/2013 08:59 PM, Adrian wrote:
I see vfat images dated this month, however still indicating the serial console requirement.
When will we get to a bootable image, with usb/hdmi support please?
Adrian ... vk4tux
This month's VFAT image for the Beaglebone Black is badly broken. If you want something workable use an older image.Fedora-Minimal-VFAT-armhfp-20-1-sda.raw.xz http://ftp.jaist.ac.jp/pub/Linux/Fedora/releases/20/Images/armhfp/Fedora-Minimal-VFAT-armhfp-20-1-sda.raw.xz contains a kernel which keep oops'ing on certain operations, like an outbound slogin attempt. I reported that and the response was kernel RPM 3.12.5-302 which results in a board which will not boot at all.
What do you mean by "this months image". The release image does have some known and documented limitations but it's relatively stable for the documented use case.
It looks like kernel-3.12.5-302 fixes various things for x86_64 machines, so it is an improvement for them, yet it really wrecks an ARM installation. I guess we can expect ARM to always be a secondary architecture, with anything that benefits x86_64 users being pushed, regardless of its effects on other users.
That's not exactly true. Firstly whether it be x86 or ARM no one particularly device blocks a kernel release. If there's an issue with a particular piece of HW it's then fixed in a later release. In the case of the BB Black the 3.12.x kernel massively improves a number of things such as usb, hdmi and other things. There was one known regression which is the ethernet, which while it works isn't the most stable. I've today pushed a patch that should fix this for the next kernel build and I've put up a scratch kernel [1] for those that wish to try it while we wait for the Fedora kernel devs to push a new kernel.
We the Fedora ARM kernel people and wider testers are doing our best with limited time and many devices to support with a greatly moving target that is the upstream kernel. We do our best but there's many combinations of hardware which people use in many different ways and we do try our hardest to support all the many different ways and means that people want to use Fedora on ARM.
Peter
[1] http://pbrobinson.fedorapeople.org/arm-kernel/kernel-devel-3.12.6-300.fc20.a...
On 12/29/2013 06:32 AM, Peter Robinson wrote:
On Sun, Dec 22, 2013 at 2:34 PM, Steve Underwood steveu@coppice.org wrote:
On 12/22/2013 08:59 PM, Adrian wrote:
I see vfat images dated this month, however still indicating the serial console requirement.
When will we get to a bootable image, with usb/hdmi support please?
Adrian ... vk4tux
This month's VFAT image for the Beaglebone Black is badly broken. If you want something workable use an older image.Fedora-Minimal-VFAT-armhfp-20-1-sda.raw.xz http://ftp.jaist.ac.jp/pub/Linux/Fedora/releases/20/Images/armhfp/Fedora-Minimal-VFAT-armhfp-20-1-sda.raw.xz contains a kernel which keep oops'ing on certain operations, like an outbound slogin attempt. I reported that and the response was kernel RPM 3.12.5-302 which results in a board which will not boot at all.
What do you mean by "this months image". The release image does have some known and documented limitations but it's relatively stable for the documented use case.
If you try to slogin to another box from the release image you get an oops. That's a severe enough kernel problem to make the image pretty useless for most people.
It looks like kernel-3.12.5-302 fixes various things for x86_64 machines, so it is an improvement for them, yet it really wrecks an ARM installation. I guess we can expect ARM to always be a secondary architecture, with anything that benefits x86_64 users being pushed, regardless of its effects on other users.
That's not exactly true. Firstly whether it be x86 or ARM no one particularly device blocks a kernel release. If there's an issue with a particular piece of HW it's then fixed in a later release. In the case of the BB Black the 3.12.x kernel massively improves a number of things such as usb, hdmi and other things. There was one known regression which is the ethernet, which while it works isn't the most stable. I've today pushed a patch that should fix this for the next kernel build and I've put up a scratch kernel [1] for those that wish to try it while we wait for the Fedora kernel devs to push a new kernel.
No single piece of *new* hardware holds up a kernel, but they are very reluctant to break things that were working. Its rare that a "yum update" on a working x86_64 machine has a negative effect. "yum update" is still an adventure on an ARM machine.
The 3.12.x kernel apparently does a lot of good things. However, updating to the 3.12.5 RPM results in a BeagleBone Black which will not boot. I feel that's a serious drawback. If you look at https://bugzilla.redhat.com/show_bug.cgi?id=1043033 you will see the issue is marked as closed a while after I reported that the "fix" bricks boards. I'm sure a report that the RPM brocks x86_64 boards would have been taken more seriously. With that approach to updates "yum update" is going to remain an adventure. Remember that 3.12.5 is an update to a release. We aren't talking about betas.
We the Fedora ARM kernel people and wider testers are doing our best with limited time and many devices to support with a greatly moving target that is the upstream kernel. We do our best but there's many combinations of hardware which people use in many different ways and we do try our hardest to support all the many different ways and means that people want to use Fedora on ARM.
Unless there is a change of course you are fighting a loosing battle. Ubuntu are less strict about how they put things together, and have had a satisfactory installer for the BeagleBone Black pretty much from its release date. That means almost all BeagleBone users are using Ubuntu, and only a handful of determined Fedora users like me are even testing Fedora on this hardware. A small pool of testers is not a recipe for success.
As a software development platform (mostly for me to try using NEON to accelerate some of my DSP code on ARMs) the betas of Fedora 20 work very well. However, all I really need are the SD card and Ethernet port working. :-\
Peter
[1] http://pbrobinson.fedorapeople.org/arm-kernel/kernel-devel-3.12.6-300.fc20.a...
Regards, Steve
[snip]
Unless there is a change of course you are fighting a loosing battle. Ubuntu are less strict about how they put things together, and have had a satisfactory installer for the BeagleBone Black pretty much from its release date. That means almost all BeagleBone users are using Ubuntu, and only a handful of determined Fedora users like me are even testing Fedora on this hardware. A small pool of testers is not a recipe for success.
They (whatever other distro) can enjoy maintaining the patches to make things work. Fedora will continue to follow upstream kernel, based on principles. I personally used to spin remix images for BBB and carry patches, but it's just silly.
We need the bits to be upstream.... this has always been a win (not a loosing battle). So pardon my very public disagreement with you... it just seems that we are not actually competing with other distros, but doing the right thing the hard way. Ultimately everyone wins in the end. We are willing to lose a popularity contest to maintain principles. And; by maintaining principles the entire community (at large) wins!
For example, we are at the forefront of multi-platform support for ARM kernel. I believe the upstream devs cite Fedora as a great development platform in that (MP) regard. (your miles may vary)
Best regards, -Jon
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On 12/29/2013 06:32 AM, Peter Robinson wrote:
On Sun, Dec 22, 2013 at 2:34 PM, Steve Underwood steveu@coppice.org wrote:
On 12/22/2013 08:59 PM, Adrian wrote:
I see vfat images dated this month, however still indicating the serial console requirement.
When will we get to a bootable image, with usb/hdmi support please?
Adrian ... vk4tux
This month's VFAT image for the Beaglebone Black is badly broken. If you want something workable use an older image.Fedora-Minimal-VFAT-armhfp-20-1-sda.raw.xz http://ftp.jaist.ac.jp/pub/Linux/Fedora/releases/20/Images/armhfp/Fedora-Minimal-VFAT-armhfp-20-1-sda.raw.xz contains a kernel which keep oops'ing on certain operations, like an outbound slogin attempt. I reported that and the response was kernel RPM 3.12.5-302 which results in a board which will not boot at all.
What do you mean by "this months image". The release image does have some known and documented limitations but it's relatively stable for the documented use case.
It looks like kernel-3.12.5-302 fixes various things for x86_64 machines, so it is an improvement for them, yet it really wrecks an ARM installation. I guess we can expect ARM to always be a secondary architecture, with anything that benefits x86_64 users being pushed, regardless of its effects on other users.
That's not exactly true. Firstly whether it be x86 or ARM no one particularly device blocks a kernel release. If there's an issue with a particular piece of HW it's then fixed in a later release. In the case of the BB Black the 3.12.x kernel massively improves a number of things such as usb, hdmi and other things. There was one known regression which is the ethernet, which while it works isn't the most stable. I've today pushed a patch that should fix this for the next kernel build and I've put up a scratch kernel [1] for those that wish to try it while we wait for the Fedora kernel devs to push a new kernel.
We the Fedora ARM kernel people and wider testers are doing our best with limited time and many devices to support with a greatly moving target that is the upstream kernel. We do our best but there's many combinations of hardware which people use in many different ways and we do try our hardest to support all the many different ways and means that people want to use Fedora on ARM.
Peter
[1] http://pbrobinson.fedorapeople.org/arm-kernel/kernel-devel-3.12.6-300.fc20.a...
Obviously Peter should have referenced http://pbrobinson.fedorapeople.org/arm-kernel/kernel-3.12.6-300.fc20.armv7hl..., rather than the kernel-devel RPM. This RPM gives me a BeagleBone Black which has been working solidly with a fully updated Fedora 20 for the past few hours. Things are looking good.
Is Fedora 20 supposed to work on a Pandaboard? There are Pandaboard uboot files in the distro, but no reference to it on https://fedoraproject.org/wiki/Architectures/ARM/F20/Installation. I tried to install it, but I haven't been able to make it boot.
Regards, Steve
On Sun, Dec 22, 2013 at 12:59 PM, Adrian vk4tux@bigpond.com wrote:
I see vfat images dated this month, however still indicating the serial console requirement.
When will we get to a bootable image, with usb/hdmi support please?
Which device are you referring to, you have two in the subject.
Peter
Yes Beaglebone black, sorry for the mess on subject line.
Adrian ... vk4tux
Which device are you referring to, you have two in the subject.
Peter
On Sun, Dec 22, 2013 at 09:36:00AM +0000, Frank Murphy wrote:
Looking at getting a cubietruck, (http://www.cubietruck.com/collections/frontpage/products/cubietruck-cubieboa...) which appear to be covered by: https://fedoraproject.org/wiki/Architectures/ARM/F20/Remixes
So figured I'd ask. Would Fedora install and run on it, or remix only?
Other people have covered your original question.
In case you've not seen it, I've managed to get the upstream kernel and KVM (ie. hardware-accelerated virtualization) working on the Cubietruck:
http://rwmj.wordpress.com/2013/12/13/kvm-working-on-the-cubietruck/#content http://rwmj.wordpress.com/2013/12/02/upstream-kernel-running-on-the-cubietru...
This is definitely the hardware to choose if you are interested in running KVM / virtualization stuff on ARM.
Rich.
-
Adrian -
Frank Murphy -
Hans de Goede -
Jon -
Peter Robinson -
Richard W.M. Jones -
Steve Underwood